From: Manivannan Sadhasivam <mani@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
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: Tue, 8 Dec 2020 18:22:50 +0530 [thread overview]
Message-ID: <20201208125250.GB9925@work> (raw)
In-Reply-To: <CACRpkdavm7GG8HdV1xk0W_b1EzUmvF0kKAGnp0u6t42NAWa9iA@mail.gmail.com>
On Tue, Dec 08, 2020 at 01:41:52PM +0100, Linus Walleij wrote:
> On Tue, Dec 8, 2020 at 10:57 AM Johan Hovold <johan@kernel.org> wrote:
> > [Me]
>
> > > A better approach might be to create an array of names
> > > prepended with something device-unique like the USB
> > > bus topology? Or do we need a helper to help naming the
> > > GPIOs? What would be helpful here?
> > >
> > > name = kasprintf(GFP_KERNEL, "%s-NAME", topology_str);
> >
> > Well we started discussing this back when we only had the sysfs
> > interface which suffered from the same problem. I thought the chardev
> > interface was supposed to get rid of the assumption of a flat name
> > space? Perhaps in v3 of the ABI. ;P
>
> It's "mostly true" that the line names are unique per-chip actually,
> because people don't like the nasty warning message. I wonder
> if anything would really break if I go in and make a patch to
> enforce it, since all drivers passing ->names in the gpiochip
> are in the kernel we can check them all.
>
> If the names are unique-per-chip, we can add a restriction like this
> with the requirement:
>
> depends on !GPIO_SYSFS
>
This sounds reasonable to me.
> so it can't even be compiled in if someone is using the sysfs.
>
> That should solve the situation where people are (ab)using
> the sysfs and getting name collisions as a result.
>
> Then it should be fine for any driver to provide a names array
> provided all the names are unique on that gpiochip.
>
> I doubt it would break anything, but let's see what Geert says.
> He has some special usecases in the gpio-aggregator driver
> which will incidentally look for just linenames when
> aggregating gpios, but I feel it is a bit thick for it to work
> with multiple hot-pluggable GPIO chips as well, I don't think
> that is its usecase. (We all want to be perfect but...)
>
> > But what about any other non-pluggable
> > IC, which provides a few named GPIO lines and of which there could be
> > more than one in a system?
>
> I think if there are such, and the lines are unique per-chip
> we should make the drivers depend on !GPIO_SYSFS.
>
> > The topology is already encoded in sysfs and it seems backwards to have
> > each and every gpio driver reconstruct it.
>
> I agree.
>
> I think if this driver already has unique line-names per-gpiochip
> we could actually make it depend on !GPIO_SYSFS and
> just add the names.
>
Sure thing.
Johan, if you are okay with this I can resubmit incorporating Linus's
suggestion.
Thanks,
Mani
> Yours,
> Linus Walleij
next prev parent reply other threads:[~2020-12-08 12:53 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 [this message]
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
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=20201208125250.GB9925@work \
--to=mani@kernel.org \
--cc=angelo.dureghello@timesys.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.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=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).