Linux-GPIO Archive on lore.kernel.org
 help / color / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH v1 2/6] gpio: dwapb: Read GPIO base from snps,gpio-base property
Date: Wed, 10 Jun 2020 16:41:26 +0300
Message-ID: <20200610134126.GG2428291@smile.fi.intel.com> (raw)
In-Reply-To: <CACRpkdZD5VNxZzycwbFWrzpT1TxkkViBuzAp5P0KQOW4oWjpVw@mail.gmail.com>

On Wed, Jun 10, 2020 at 01:26:59PM +0200, Linus Walleij wrote:
> On Mon, Jun 8, 2020 at 3:43 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > For backward compatibility with some legacy devices, introduce
> > a new property snps,gpio-base to read GPIO base. Don't advertise
> > to discourage users from utilizing it.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> I usually have a very negative gut reaction to any attempts to hardcode
> the heavily deprecated use of the gpio_base for the global GPIO
> numberspace. The reason is clear from drivers/gpio/TODO I think.
> 
> I need a really good explanation why this is needed, the only reason
> people have been pushing this in the past is "oh we are using the
> sysfs and we don't wanna change the GPIO numbers in our scripts"
> which I really want to push back on now that we have the chardev and
> the libgpiod utils.

I understand the point, that's why this property is not being advertised.
The problem here is that on existing (legacy) platform we have to deal with an absolute numbers of GPIOs and those numbers can work if we keep the base

> If this is needed for something driver internal, it should stay in a
> driver-local
> variable.

It's a cross drivers variable. The purpose of this series is to unify interface
in the GPIO driver how to deal with device properties (so, be agnostic from
resource provider at the end).

Everything so far so good, but then we need a mean how not to break the
platform. Because dropping the base in this case will immediately make a
regression.

We can re-use 'gpio-base' as gpio-mockup is using it silently. So, in such case
we won't add any deviation to the property namespace.

Or we can rename above to linux,gpio-base and re-use it here with this name to
explicitly show that this is not firmware property.

-- 
With Best Regards,
Andy Shevchenko



  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 13:42 [PATCH v1 0/6] mfd: Make use of software nodes Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 1/6] gpio: dwapb: Replace irq_shared flag with fwnode type check Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 2/6] gpio: dwapb: Read GPIO base from snps,gpio-base property Andy Shevchenko
2020-06-10 11:26   ` Linus Walleij
2020-06-10 13:41     ` Andy Shevchenko [this message]
2020-06-08 13:42 ` [PATCH v1 3/6] mfd: core: Propagate software node group to the sub devices Andy Shevchenko
2020-06-08 19:25   ` Lee Jones
2020-06-09 12:40     ` Andy Shevchenko
2020-06-17 12:51       ` Lee Jones
2020-06-08 13:42 ` [PATCH v1 4/6] mfd: intel_quark_i2c_gpio: Convert to use software nodes Andy Shevchenko
2020-06-10 11:38   ` Linus Walleij
2020-06-10 13:43     ` Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 5/6] gpio: dwapb: Get rid of legacy platform data Andy Shevchenko
2020-06-10 11:39   ` Linus Walleij
2020-06-10 13:47     ` Andy Shevchenko
2020-06-08 13:43 ` [PATCH v1 6/6] gpio: dwapb: Define magic number for IRQ and GPIO lines Andy Shevchenko
2020-06-16 20:02 ` [PATCH v1 0/6] mfd: Make use of software nodes Serge Semin
2020-06-16 21:40   ` Andy Shevchenko
2020-06-16 22:56     ` Serge Semin
2020-06-18  8:56       ` Andy Shevchenko
2020-06-19 22:12         ` Serge Semin
2020-06-20 10:13           ` Andy Shevchenko
2020-06-23  1:49             ` Serge Semin
2020-06-24 12:43               ` 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=20200610134126.GG2428291@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=fancer.lancer@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.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

Linux-GPIO Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-gpio/0 linux-gpio/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-gpio linux-gpio/ https://lore.kernel.org/linux-gpio \
		linux-gpio@vger.kernel.org
	public-inbox-index linux-gpio

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-gpio


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git