[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <X9DwXS2xaiOs033B@localhost>
Date: Wed, 9 Dec 2020 16:42:21 +0100
From: Johan Hovold <johan@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Johan Hovold <johan@...nel.org>, Marc Zyngier <maz@...nel.org>,
linux-usb <linux-usb@...r.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
kernel-team@...roid.com
Subject: Re: [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes
On Wed, Dec 09, 2020 at 10:20:38AM +0100, Linus Walleij wrote:
> On Mon, Dec 7, 2020 at 4:48 PM Johan Hovold <johan@...nel.org> wrote:
> > On Mon, Dec 07, 2020 at 03:34:23PM +0000, Marc Zyngier wrote:
>
> > > If they claim that their lines are available, and then refuse to
> > > let the user play with it, that's just a bug willing to be fixed.
> >
> > My point was that this is how *all* gpio drivers work, and that muxing
> > is somewhat orthogonal to the gpio controller implementation.
>
> This is true. It's because it is orthogonal that the separate subsystem
> for pin control including pin muxing exists.
>
> Should I be really overly picky, the drivers that can mux lines like
> this should be implementing the pin control mux driver side as
> well just to make Linux aware of this. But if the muxing cannot
> be changed by the kernel (albeit with special tools) then it would
> be pretty overengineered for this case. Things would be much
> easier if this wasn't some flashing configuration but more of a
> runtime thing (which is kind of the implicit assumption in pin
> control land).
We'd still have problem of how to configure these hot-pluggable devices
at runtime, so it's not necessarily easier.
If I remember correctly the xr_serial driver under review is doing
something like muxing at runtime, but by simply having whichever
interface (tty or gpio) that claims the resource first implicitly set
the mux configuration. I have to revisit that.
> We don't really have many drivers that are "muxable by
> (intrusive) flashing" as opposed to "muxable by setting some
> bits" so in that way these FTDI drivers and siblings are special.
Yeah, but the gpio-reserved-range (valid-mask) feature which Marc used
comes close here.
Johan
Powered by blists - more mailing lists