mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Linus Walleij <linusw@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>,
	Michael Zaidman <michael.zaidman@gmail.com>,
	jikos@kernel.org, brgl@kernel.org, linux-input@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/13] HID: ft260: add UART and GPIO support, plus I2C fixes
Date: Wed, 16 Sep 2026 13:58:06 +0100	[thread overview]
Message-ID: <20260916125806.GR11487@google.com> (raw)
In-Reply-To: <CAD++jLng_gdqoehT+c8sXoqy+tdUc7eAXXpAvhC_zJZwnX5tzA@mail.gmail.com>

On Mon, 14 Sep 2026, Linus Walleij wrote:

> Hi Benjamin, Lee,
> 
> On Tue, Sep 1, 2026 at 4:03 PM Benjamin Tissoires <bentiss@kernel.org> wrote:
> 
> > TBH, I'm not a big fan of having multiple subsystems children into HID.
> > Mostly because I can't review the best practive in each of them. However,
> > for quite a long time, HID was mostly for input devices, and input is a
> > different subsystem.
> >
> > That being said, there are 2 types of HID devices:
> > - ones with defined standard usages (keyboards, mice, touchscreen,
> >         battery, etc) and using MFD for those would certainly be overthinking
> > - others use raw HID device with a custom protocol (cp2112, mcp2221,
> >         ft260), these could be MFD candidates
> 
> Surely, as HID start to attract chips which clearly fall into the MFD
> category of things, with a plethora of subsystems hooking into the
> same HID device, we must find a way for HID devices to spawn
> MFD cells?
> 
> MFD solved and evolved a system for handling exactly this type
> of situation.
> 
> Whether there should be an MFD device in the middle spawning
> each a HID, GPIO, I2C, UART cell or whether HID device itself should
> sit in the nexus and gain the ability to simply spawn out MFD cells
> from itself is what we need to figure out.

There's no figuring that part out.

If you want to use the MFD API, the part that uses it must reside in
drivers/mfd.  Else it becomes a nightmare to maintain and things get
wild, quickly.

You'd be surprised what "creative" engineers can do with it!

-- 
Lee Jones

      reply	other threads:[~2026-09-16 12:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-22 21:39 Michael Zaidman
2026-08-22 21:39 ` [PATCH 01/13] HID: ft260: add serial driver Michael Zaidman
2026-08-25  7:49   ` Linus Walleij
2026-08-25  8:12   ` Linus Walleij
2026-08-27 19:16     ` Michael Zaidman
2026-08-22 21:39 ` [PATCH 02/13] HID: ft260: uart: bring-up fixes Michael Zaidman
2026-08-22 21:39 ` [PATCH 03/13] HID: ft260: add GPIO support on top of UART Michael Zaidman
2026-08-25  7:44   ` Linus Walleij
2026-08-27 20:39     ` Michael Zaidman
2026-08-22 21:39 ` [PATCH 04/13] HID: ft260: i2c: reduce driver module loading time Michael Zaidman
2026-08-22 21:39 ` [PATCH 05/13] HID: ft260: i2c: silence sysfs store big-numbers Michael Zaidman
2026-08-22 21:39 ` [PATCH 06/13] HID: ft260: i2c: reduce bus-error message severity Michael Zaidman
2026-08-22 21:39 ` [PATCH 07/13] HID: ft260: uart: enable flow control Michael Zaidman
2026-08-22 21:39 ` [PATCH 08/13] HID: ft260: uart: add modem pins control via ioctl Michael Zaidman
2026-08-25  8:08   ` Linus Walleij
2026-08-27 22:08     ` Michael Zaidman
2026-09-14  8:57       ` Linus Walleij
2026-08-22 21:39 ` [PATCH 09/13] HID: ft260: gpio: group sysfs attrs per HID interface Michael Zaidman
2026-08-25  8:13   ` Linus Walleij
2026-08-27 20:50     ` Michael Zaidman
2026-08-22 21:39 ` [PATCH 10/13] HID: ft260: uart: fix active-low RTS/CTS/DTR/DSR polarity Michael Zaidman
2026-08-25  8:16   ` Linus Walleij
2026-08-27 21:08     ` Michael Zaidman
2026-08-22 21:39 ` [PATCH 11/13] HID: ft260: i2c: fix large write transaction failure Michael Zaidman
2026-08-22 21:39 ` [PATCH 12/13] HID: ft260: workaround for TN_189 errata endpoint STALL after enumeration Michael Zaidman
2026-08-22 21:39 ` [PATCH 13/13] HID: ft260: i2c: abort in-flight transfers with STOP before reset Michael Zaidman
2026-08-25  8:21 ` [PATCH 00/13] HID: ft260: add UART and GPIO support, plus I2C fixes Linus Walleij
2026-08-27 13:27   ` Lee Jones
2026-08-27 18:53     ` Michael Zaidman
2026-08-27 20:51       ` Lee Jones
2026-08-27 22:25         ` Michael Zaidman
2026-09-01 14:02           ` Benjamin Tissoires
2026-09-14  9:27             ` Linus Walleij
2026-09-16 12:58               ` Lee Jones [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=20260916125806.GR11487@google.com \
    --to=lee@kernel.org \
    --cc=bentiss@kernel.org \
    --cc=brgl@kernel.org \
    --cc=jikos@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.zaidman@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

all inboxes | Powered by JetHome®