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

[Benjamin Tissoires]

On Sep 16 2026, Lee Jones wrote:
> 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.

Historically speaking, HID devices always have been under drivers/hid.
They are usually leaf drivers, only hooking to input/battery/LEDs.

As mentioned, hid-sensor-hub is an exception but this got sorted out by
splitting the HID part from the IIO.

Looking at the various MFD-like HID drivers, they all share the common
point of not really being HID devices: they rely on a custom protocol
handled in .raw_event().

So I think I'd be OK to have those drivers moved to the mfd tree as long
as they only rely on low level HID API, and do not have to deal with
"generic" HID report descriptors. If that arise, I think we should split
the HID/MFD parts like hid-sensor-hub does.

So you can have my unformal acked-by for transfering those drivers.

Last, I'm currently using a cp2112 as a i2c-hid bridge in my upstream
CI. It's relying on a DSDT override in the VM to actually work, and I'd
like to keep that around. So my main request here is to keep the
equivalent of the DSDT override in the MFD cells, at least for this one.

Cheers,
Benjamin

> 
> You'd be surprised what "creative" engineers can do with it!
> 
> -- 
> Lee Jones
>