From: Johan Hovold <johan@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Manivannan Sadhasivam <mani@kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
linux-usb <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
patong.mxl@gmail.com,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Angelo Dureghello <angelo.dureghello@timesys.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support
Date: Mon, 14 Dec 2020 09:58:40 +0100 [thread overview]
Message-ID: <X9cpQO3IV4IgX1dh@localhost> (raw)
In-Reply-To: <CACRpkdZ6MUzRe9m=NrqA_5orhZXDtWj+qoFMHX7v6Zjsx-rVGg@mail.gmail.com>
On Sat, Dec 12, 2020 at 01:03:32AM +0100, Linus Walleij wrote:
> On Thu, Dec 10, 2020 at 9:53 AM Johan Hovold <johan@kernel.org> wrote:
> > On Wed, Dec 09, 2020 at 05:25:32PM +0100, Linus Walleij wrote:
>
> > I just replied to that thread, but to summarize, you can't rely on
> > having the sysfs code detect collisions since that will trigger a bunch
> > of nasty warnings and backtraces. We also don't want the sysfs interface
> > for a specific USB device to depend on probe order (only the first one
> > plugged in gets to use the line names). And adding line names now could
> > in fact be what breaks currently working scripts.
>
> Yes the sysfs ABI is very volatile and easy to break.
>
> As pointed out in the other reply, sysfs base GPIO number is all
> wibbly-wobbly on anything hot-pluggable so in a way I feel it
> is the right thing to disallow sysfs altogether on hotpluggable
> devices.
No, the gpio numbers will of course vary, but since gpiolib exports the
base number for the chip, a scripts can easily determine the right gpio
number as base + offset.
Having probe order break that by sometimes exporting the line using it's
name is what would be a problem.
> > Just did a super quick check and it seems libgpiod still assumes a flat
> > name space. For example, gpiod_chip_find_line() returns only the first
> > line found that matches a name. Shouldn't be impossible to extend, but
> > just want to make sure this flat namespace assumption hasn't been to
> > heavily relied upon.
>
> The unique way to identify a GPIO is gpiochip instance (with
> topology from sysfs) and then a line number on that chip.
> This is done e.g. in the example tool
> tools/gpio/gpio-hammer.c
>
> As you can see the tool doesn't use these line names.
>
> The line names are really like symbolic links or something.
> But they are indeed in a flat namespace so we should try to
> at least make them unique if it turns out people love to use
> these.
Not necessarily, they could be unique per chip as we're discussing here
with respect to hotpluggable controllers. We just can't have it both
ways.
> As it is now system designers mostly use device tree to assign
> line names and they try to make these unique because they don't
> like the nasty warnings from gpiolib.
>
> If I google for the phrase "Detected name collision for GPIO name"
> I just find the code, our discussions and some USB serial devices
> warning about this so far.
>
> Maybe we should just make a patch to disallow it?
That would make it impossible to provide name lines on hotpluggable
controllers, which would be nice to support.
Johan
next prev parent reply other threads:[~2020-12-14 9:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-22 17:08 [PATCH v5 0/3] Add support for MaxLinear/Exar USB to serial converters Manivannan Sadhasivam
2020-11-22 17:08 ` [PATCH v5 1/3] usb: serial: Add MaxLinear/Exar USB to Serial driver Manivannan Sadhasivam
2021-01-21 10:19 ` Johan Hovold
2021-01-26 15:46 ` Manivannan Sadhasivam
2021-01-26 16:26 ` Johan Hovold
2021-02-22 15:27 ` Mauro Carvalho Chehab
2021-02-22 15:47 ` Johan Hovold
2021-02-24 8:51 ` Mauro Carvalho Chehab
2021-02-25 17:58 ` Mauro Carvalho Chehab
2021-02-25 18:04 ` Mauro Carvalho Chehab
2021-02-26 10:07 ` Johan Hovold
2021-02-26 10:37 ` Mauro Carvalho Chehab
2020-11-22 17:08 ` [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support Manivannan Sadhasivam
2020-12-01 14:37 ` Linus Walleij
2020-12-01 15:51 ` Johan Hovold
2020-12-05 22:21 ` Linus Walleij
2020-12-08 9:58 ` Johan Hovold
2020-12-08 12:41 ` Linus Walleij
2020-12-08 12:52 ` Manivannan Sadhasivam
2020-12-09 15:31 ` Johan Hovold
2020-12-09 15:25 ` Johan Hovold
2020-12-09 16:25 ` Linus Walleij
2020-12-10 8:53 ` Johan Hovold
2020-12-10 9:04 ` Johan Hovold
2020-12-12 0:03 ` Linus Walleij
2020-12-14 8:58 ` Johan Hovold [this message]
2020-12-14 9:19 ` Linus Walleij
2020-12-14 9:31 ` Johan Hovold
2020-12-01 18:00 ` Manivannan Sadhasivam
2021-01-21 11:06 ` Johan Hovold
2020-11-22 17:08 ` [PATCH v5 3/3] usb: cdc-acm: Ignore Exar XR21V141X when serial driver is built Manivannan Sadhasivam
2021-01-21 10:23 ` Johan Hovold
2020-12-08 10:51 ` [PATCH v5 0/3] Add support for MaxLinear/Exar USB to serial converters Manivannan Sadhasivam
2020-12-14 9:51 ` Johan Hovold
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=X9cpQO3IV4IgX1dh@localhost \
--to=johan@kernel.org \
--cc=angelo.dureghello@timesys.com \
--cc=bgolaszewski@baylibre.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mani@kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=patong.mxl@gmail.com \
/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).