From: Johan Hovold <johan@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>, Marc Zyngier <maz@kernel.org>,
linux-usb <linux-usb@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kernel-team@android.com
Subject: Re: [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes
Date: Wed, 9 Dec 2020 16:42:21 +0100 [thread overview]
Message-ID: <X9DwXS2xaiOs033B@localhost> (raw)
In-Reply-To: <CACRpkdZ06vWY+mqR7bYd_WcEM6+N6v5GgTAYhr0p0KkNLa3Qnw@mail.gmail.com>
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@kernel.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
prev parent reply other threads:[~2020-12-09 15:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 16:47 [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes Marc Zyngier
2020-12-04 16:47 ` [PATCH 1/4] gpiolib: cdev: Flag invalid GPIOs as used Marc Zyngier
2020-12-07 14:16 ` Johan Hovold
2020-12-07 14:59 ` Marc Zyngier
2020-12-09 9:25 ` Linus Walleij
2020-12-04 16:47 ` [PATCH 2/4] USB: serial: ftdi_sio: Report the valid GPIO lines to gpiolib Marc Zyngier
2020-12-09 9:28 ` Linus Walleij
2020-12-04 16:47 ` [PATCH 3/4] USB: serial: ftdi_sio: Log the CBUS GPIO validity Marc Zyngier
2020-12-07 14:29 ` Johan Hovold
2020-12-07 15:00 ` Marc Zyngier
2020-12-07 15:19 ` Johan Hovold
2020-12-09 9:35 ` Linus Walleij
2020-12-09 17:05 ` Johan Hovold
2020-12-09 17:39 ` Johan Hovold
2020-12-04 16:47 ` [PATCH 4/4] USB: serial: ftdi_sio: Drop GPIO line checking dead code Marc Zyngier
2020-12-07 9:55 ` [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes Andy Shevchenko
2020-12-07 14:01 ` Johan Hovold
2020-12-07 14:41 ` Marc Zyngier
2020-12-07 15:08 ` Johan Hovold
2020-12-07 15:34 ` Marc Zyngier
2020-12-07 15:49 ` Johan Hovold
2020-12-09 9:20 ` Linus Walleij
2020-12-09 15:42 ` Johan Hovold [this message]
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=X9DwXS2xaiOs033B@localhost \
--to=johan@kernel.org \
--cc=bgolaszewski@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=maz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.