linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Rob Herring <robh+dt@kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Hoan Tran <hoan@os.amperecomputing.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v1 2/4] gpio: dwapb: Read GPIO base from gpio-base property
Date: Mon, 2 Aug 2021 18:52:28 +0300	[thread overview]
Message-ID: <CAHp75Vcz=vkaGObUcOOTZA51pHPoMc50RpPBLg4fgZgHdUStRA@mail.gmail.com> (raw)
In-Reply-To: <20210802135839.4clqd34npppwasyh@mobilestation>

On Mon, Aug 2, 2021 at 5:14 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> On Mon, Jul 26, 2021 at 03:54:34PM +0300, Andy Shevchenko wrote:
> > For backward compatibility with some legacy devices introduce
> > a new (*) property gpio-base to read GPIO base. This will allow
> > further cleanup of the driver.

Thanks for the review! My answers below.

> > *) Note, it's not new for GPIO library since mockup driver is
> >    using it already.
>
> You are right but I don't think it's a good idea to advertise the
> pure Linux-internal property "gpio-base" to any use-case like OF
> and ACPI FW nodes.

I don't want to advertise them, actually (that's why no bindings are
modified). Perhaps introducing a paragraph in the GPIO documentation
about this (and / or in GPIO generic bindings) that gpio-base property
is solely for internal use and should't be used in actual DTs?

>  Especially seeing we don't have it described in the
> DT-bindings and noting that the mockup driver is dedicated for the
> GPIO tests only. What about restricting the property usage for the
> SW-nodes only by adding an additional check: is_software_node() here?

I don't think we need this. But if you think it's better this way just
to avoid usage of this property outside of internal properties, I'm
fine to add. Perhaps we may issue a warning and continue? (see also
above)

> @Linus, @Bartosz, @Rob, what do you think about that?

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2021-08-02 15:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 12:54 [PATCH v1 1/4] gpio: dwapb: Unify ACPI enumeration checks in get_irq() and configure_irqs() Andy Shevchenko
2021-07-26 12:54 ` [PATCH v1 2/4] gpio: dwapb: Read GPIO base from gpio-base property Andy Shevchenko
2021-08-02 13:58   ` Serge Semin
2021-08-02 15:52     ` Andy Shevchenko [this message]
2021-08-04 12:44       ` Serge Semin
2021-08-04 14:43         ` Andy Shevchenko
2021-08-11 12:40           ` Linus Walleij
2021-08-11 12:47             ` Serge Semin
2021-08-11 12:37   ` Linus Walleij
2021-08-11 13:11     ` Andy Shevchenko
2021-07-26 12:54 ` [PATCH v1 3/4] mfd: intel_quark_i2c_gpio: Convert GPIO to use software nodes Andy Shevchenko
2021-08-11  8:38   ` Linus Walleij
2021-08-11 10:55     ` Andy Shevchenko
2021-08-16 13:05   ` Lee Jones
2021-08-16 13:18     ` Andy Shevchenko
2021-08-16 13:33       ` Lee Jones
2021-08-16 14:00         ` Andy Shevchenko
2021-08-16 14:19           ` Lee Jones
2021-08-16 14:53             ` Andy Shevchenko
2021-08-17  7:26               ` Lee Jones
2021-08-17 11:23                 ` Andy Shevchenko
2021-08-18  6:34                   ` Lee Jones
2021-08-18 11:04                     ` Andy Shevchenko
2021-09-21 15:25                   ` Lee Jones
2021-07-26 12:54 ` [PATCH v1 4/4] gpio: dwapb: Get rid of legacy platform data Andy Shevchenko
2021-08-02 14:07   ` Serge Semin
2021-08-02 15:54     ` Andy Shevchenko
2021-08-02  8:48 ` [PATCH v1 1/4] gpio: dwapb: Unify ACPI enumeration checks in get_irq() and configure_irqs() Lee Jones
2021-08-02 13:40 ` Serge Semin
2021-08-02 18:37   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHp75Vcz=vkaGObUcOOTZA51pHPoMc50RpPBLg4fgZgHdUStRA@mail.gmail.com' \
    --to=andy.shevchenko@gmail.com \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=fancer.lancer@gmail.com \
    --cc=hoan@os.amperecomputing.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).