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

[Benjamin Tissoires <bentiss@kernel.org>]

On Aug 28 2026, Michael Zaidman wrote:
> On Thu, 27 Aug 2026 at 21:51 +0100, Lee Jones wrote:
> > That's precisely what MFD is.  It's one chip, usually with a shared and
> > overlapping register spaces, that conducts multiple functions.  This is
> > no different to any other single-chip device or SoC.
> >
> > Shoving everything into a single driver isn't how things are done in
> > Linux.  This should be divided up into the associated sub-systems where
> > each part can be reviewed and looked after by the appropriate SMEs.
> 
> Understood, and I am not going to argue MFD scope with you. But this
> is not specific to my series, so I would rather not decide it here on
> my own.
> 
> drivers/hid already registers other subsystems' devices from a
> hid_driver: hid-cp2112 adds an i2c_adapter and a gpiochip, hid-mcp2221
> adds an i2c_adapter, a gpiochip and an IIO device, and hid-ft260 has
> hosted the I2C adapter since v5.13, commit 6a82582d9fa4 ("HID: ft260:
> add usb hid to i2c host bridge driver").
> 
> So the split you are asking for is not a change to this series. It
> means moving code that has been in drivers/hid since v5.13 into an MFD
> parent with cells, and the same reasoning would apply to cp2112 and
> mcp2221. I am willing to discuss that as its own conversion, but it
> needs the HID maintainers to agree on the direction first, and I do
> not think the UART and GPIO support should wait behind it.

I don't think Lee or Linus ever asked you to do any conversion of
existing drivers. Just show the example on how things should be done :)

If moving to MFD gives real benefits, these other drivers can be done
later.

> 
> It would also spread the driver over four trees, so a fix touching the
> shared chip state becomes a cross-tree series with coordinated merges
> between four maintainers - a cost the single driver does not have.
> 
> Jiri, Benjamin - this is your call. Do you want FT260 functionality to
> keep growing inside hid-ft260, as cp2112 and mcp2221 do today, or do
> you want a drivers/hid to MFD conversion for this class of USB HID
> bridge chips?

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

And of course, we have the exception with the standardly defined sensors
through hid-sensor-hub.c which goes through MFD :)

TL;DR: I'm not opposed to a MFD conversion of hid-ft260.c, nor I'm not
formally pushing towards it. I think we need to take the pragmatic
approach and see if the benefits for it are worth it.

From the description on how the ft260 works and the intrications between
all functions, this seems like a lot of pain to maintain a single core
MFD chip, but not having to maintain I2C, UART, GPIO is appealing.

The question about the cross tree merging is something that can't really
be discussed without having seen the code. Assuming you can split all
the drivers into their own subsystem + MFD HID parent, we could very
well merge the newly additions independently, assuming the MFD HID
parent API is stable enough. The only cross subsystem we need to take
care of today is the existing functionality, but that can be sorted out
by splitting the i2c_adapter part into its own file, and then let the
I2C maintainer move the file into their tree later.

It is maybe a lot to ask, but Michael, can you demo the MFD split on
one/two functionality so we can check which approach is the best?
Ideally 2 features that would be intricating well enough to demonstrate
how hard/easy it would be.

Cheers,
Benjamin