Re: [PATCH 00/13] HID: ft260: add UART and GPIO support, plus I2C fixes

From: Lee Jones

Date: Wed Sep 16 2026 - 09:07:12 EST


On Mon, 14 Sep 2026, Linus Walleij wrote:

> Hi Benjamin, Lee,
>
> On Tue, Sep 1, 2026 at 4:03 PM Benjamin Tissoires <bentiss@xxxxxxxxxx> 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