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

[Michael Zaidman <michael.zaidman@gmail.com>]

Hi Benjamin, Lee, Linus,

On Thu, 17 Sep 2026 at 13:07 +0200, Benjamin Tissoires wrote:

> I think HID is just the transport layer (like USB, I2C, SPI, etc...) so
> it shouldn't count as one of the additional subsystems to MFD.

Agreed for the FT260. The HID reports are the transport. The functions
are UART, GPIO and I2C.

Jiri answered me off-list on 11 September, before the mails of 14 to
17 September. He has no strong preference, and he left the sequencing
to me.

I will land the current driver first, and do the MFD split as its own
series once this one is in the tree.

GPIO support has been in the out-of-tree driver since 20 November 2022
[1]. The serial driver was added there on 12 January 2024.
That is where its bugs were found and fixed. Folding an MFD conversion
into the same series would replace that structure while the UART and
GPIO support is still under review. Landing the tested layout first
keeps those two reviews apart.

I maintain this driver in my free time, and my bandwidth for the next
few months is limited. A split across drivers/mfd, drivers/tty,
drivers/gpio and drivers/i2c in this series would stall the UART and
GPIO support.

The parent device depends on the strap pins. One HID feature report,
0xA1 System Settings, carries chip mode, the clock, i2c_enable,
uart_mode, the UART frame and flow control, and the GPIO pin-function
selects. The I2C interface owns that report, and registers the
gpiochip, in I2C-only mode. The UART interface does both once UART is
strapped. Enabling I2C or changing the UART mode moves pins between the
I2C or UART function and GPIO. That parent is easier to define against
a driver that is already in the tree.

The MFD series will follow the constraints from this thread. Lee, the
code that calls the MFD API will live in drivers/mfd, and that file
will do the shared setup only. The UART, GPIO and I2C drivers will live
in their own subsystems. Benjamin, the child devices will keep fwnode
support, so an ACPI or DT child can attach the way your cp2112 CI does
today.

On Tue, 1 Sep 2026 at 16:02 +0200, Benjamin Tissoires wrote:

> 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.

The two features that interact here are GPIO and the I2C and UART
functions.
The split is one MFD parent for the two HID interfaces. A demo that
splits only the I2C part cannot show the gpiochip ownership above,
which moves between the I2C and the UART interface: with the I2C side
moved out, there is no configuration where that change can be tested.
The MFD series has to do the whole device at once, and it comes after
this one.

[1] https://github.com/MichaelZaidman/hid-ft260/commit/e40e56953e8c2b23c222d76e97b5f5e274b91603

Thanks,
Michael