linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Johan Hovold <johan@kernel.org>
Subject: Re: [PATCH] gpiolib: Disallow identical line names in the same chip
Date: Mon, 14 Dec 2020 10:23:55 +0100	[thread overview]
Message-ID: <X9cvK3M20tAj3GwS@localhost> (raw)
In-Reply-To: <CACRpkdaGQRHwVnXU6e9apKhxCFf_qWEfSF8ggodOCHjXDSCg1Q@mail.gmail.com>

On Sat, Dec 12, 2020 at 01:51:59PM +0100, Linus Walleij wrote:
> On Sat, Dec 12, 2020 at 10:23 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> 
> > As the names are specified in DT, I think the biggest "use case" for
> > collisions is GPIO chips on expansion boards, if multiple instances
> > of the same board can be connected.
> 
> The actual case that happens in reality is GPIO chips on USB.
> For example if you plug in two FTDI adapters (these have GPIOs)
> and they have named their lines statically in the driver.
> 
> This is what Johan points out and also what I find from Googling.
> 
> So I would say hot-pluggable buses. Greybus would have the
> same issue I think.

But it could be anything that provides default names, such as some
controller connected over i2c.

Having the driver provide default names that then can (but does not have
to be) overridden in devicetree if you really want to make sure the
lines are unique (or just named for the particular application).
 
> > This is a bit similar to clock outputs, cfr. commit f491276a51685987
> > ("clk: vc5: Allow Versaclock driver to support multiple instances"), but
> > in the clock case, the name of the clock output is dictated by the
> > driver, not by DT.
> 
> Yeah actually the collisions we have seen in GPIO is the same
> type, where we assign the names in gc->names and not in the
> device tree (or ACPI).
> 
> But I think it is good to establish this habit already so we don't
> end up depending on having to support flat namespaces with

I think you meant non-flat here?

> several lines on the same chip named the same at least.

Right, enforcing per-chip-unique names seems perfectly reasonable.

The only "use case" of non-unique names that comes to mind would be to
provide some kind of grouping like "input"/"output" but then the names
can still be made unique by adding an index (e.g. "input0").

Johan

  reply	other threads:[~2020-12-14  9:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12  0:34 [PATCH] gpiolib: Disallow identical line names in the same chip Linus Walleij
2020-12-12  9:23 ` Geert Uytterhoeven
2020-12-12 12:51   ` Linus Walleij
2020-12-14  9:23     ` Johan Hovold [this message]
2020-12-13 15:00 ` Andy Shevchenko
2020-12-14  8:45   ` Bartosz Golaszewski
2020-12-14  9:17 ` Linus Walleij
2020-12-14  9:29 ` Johan Hovold
2020-12-14 22:39   ` Linus Walleij
2020-12-15  8:24     ` Geert Uytterhoeven

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=X9cvK3M20tAj3GwS@localhost \
    --to=johan@kernel.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=geert@linux-m68k.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@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
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).