usb: thoughts of adding more support for FT232H

usb: thoughts of adding more support for FT232H

[Song Qiang]

Hi Johan,


I've been developing some iio device drivers and found that some people
would like to test their devices with a qemu system which requires an
i2c or spi port on our development hosts. Usually this is achieved with
a DLN-2 adapter, while this is a bit difficult for me because it costs
~175$ in my country. Then I found that FTDI's FT232H supports both these
two modes and costs only less than 5$ but without full support in kernel.
The ftdi-sio driver supports FT232H only as a serial converter.
So I'm planning to write a mfd driver for it supports both these three
modes, here are my thoughts:
  - This device cannot support these three modes together because they
    share some common pins, so I'm planning to add a sysfs entry
    'current_mode' for selecting which mode the device should be working
    on.
  - This device is in uart mode on reset, so default mode would be reset,
    too. This also helps for people only want to use this as a serial
    converter feels nothing has happened (compatible).
  - I was trying to reuse the ftdi-sio driver but it seems like mfd can
    only register platform devices, while this is a usb driver. I may
    have to copy some functions from this driver.

Would you share any ideas? I'd appreciate it.

yours,

Song Qiang

Re: usb: thoughts of adding more support for FT232H

[Anatolij Gustschin]

Hi,

On Wed, 5 Dec 2018 22:10:40 +0800
Song Qiang songqiang1304521@gmail.com wrote:
...
>I've been developing some iio device drivers and found that some people
>would like to test their devices with a qemu system which requires an
>i2c or spi port on our development hosts. Usually this is achieved with
>a DLN-2 adapter, while this is a bit difficult for me because it costs
>~175$ in my country. Then I found that FTDI's FT232H supports both these
>two modes and costs only less than 5$ but without full support in kernel.
>The ftdi-sio driver supports FT232H only as a serial converter.
>So I'm planning to write a mfd driver for it supports both these three
>modes, here are my thoughts:

There already has been a discussion [1] about adding an MFD driver for
FT232H, since the operating modes are mutually exclusive (and bus pins
shared between different modes), the MFD approach doesn't seem to be
a good fit.

>  - This device cannot support these three modes together because they
>    share some common pins, so I'm planning to add a sysfs entry
>    'current_mode' for selecting which mode the device should be working
>    on.
>  - This device is in uart mode on reset, so default mode would be reset,
>    too. This also helps for people only want to use this as a serial
>    converter feels nothing has happened (compatible).
>  - I was trying to reuse the ftdi-sio driver but it seems like mfd can
>    only register platform devices, while this is a usb driver. I may
>    have to copy some functions from this driver.
>
>Would you share any ideas? I'd appreciate it.

There is a patch series [2] adding an interface driver for FT232H-
based adapter devices, it already supports adding custom MPSSE based
SPI busses with SPI slaves for a custom USB PID. It already supports
adding custom CBUS-/MPSSE-GPIO adapters for user-defined USB PID.
Adding I2C driver/adapter support should be easy, too. Maybe you can
re-use it.

Thanks,
Anatolij

[1] https://patchwork.kernel.org/patch/9828985
[2] https://patchwork.kernel.org/project/linux-usb/list/?series=48255

Re: usb: thoughts of adding more support for FT232H

[Johan Hovold]

On Wed, Dec 05, 2018 at 04:17:18PM +0100, Anatolij Gustschin wrote:
> Hi,
> 
> On Wed, 5 Dec 2018 22:10:40 +0800
> Song Qiang songqiang1304521@gmail.com wrote:
> ...
> >I've been developing some iio device drivers and found that some people
> >would like to test their devices with a qemu system which requires an
> >i2c or spi port on our development hosts. Usually this is achieved with
> >a DLN-2 adapter, while this is a bit difficult for me because it costs
> >~175$ in my country. Then I found that FTDI's FT232H supports both these
> >two modes and costs only less than 5$ but without full support in kernel.
> >The ftdi-sio driver supports FT232H only as a serial converter.
> >So I'm planning to write a mfd driver for it supports both these three
> >modes, here are my thoughts:
> 
> There already has been a discussion [1] about adding an MFD driver for
> FT232H, since the operating modes are mutually exclusive (and bus pins
> shared between different modes), the MFD approach doesn't seem to be
> a good fit.
> 
> >  - This device cannot support these three modes together because they
> >    share some common pins, so I'm planning to add a sysfs entry
> >    'current_mode' for selecting which mode the device should be working
> >    on.
> >  - This device is in uart mode on reset, so default mode would be reset,
> >    too. This also helps for people only want to use this as a serial
> >    converter feels nothing has happened (compatible).
> >  - I was trying to reuse the ftdi-sio driver but it seems like mfd can
> >    only register platform devices, while this is a usb driver. I may
> >    have to copy some functions from this driver.
> >
> >Would you share any ideas? I'd appreciate it.
> 
> There is a patch series [2] adding an interface driver for FT232H-
> based adapter devices, it already supports adding custom MPSSE based
> SPI busses with SPI slaves for a custom USB PID. It already supports
> adding custom CBUS-/MPSSE-GPIO adapters for user-defined USB PID.
> Adding I2C driver/adapter support should be easy, too. Maybe you can
> re-use it.

> [1] https://patchwork.kernel.org/patch/9828985
> [2] https://patchwork.kernel.org/project/linux-usb/list/?series=48255

I was going to refer to these series, but Anatolij beat me to it
(haven't looked at [2] myself yet, though).

Thanks,
Johan

Re: usb: thoughts of adding more support for FT232H

[Song Qiang]

On 12/5/18 11:17 PM, Anatolij Gustschin wrote:
> Hi,
>
> On Wed, 5 Dec 2018 22:10:40 +0800
> Song Qiang songqiang1304521@gmail.com wrote:
> ...
>> I've been developing some iio device drivers and found that some people
>> would like to test their devices with a qemu system which requires an
>> i2c or spi port on our development hosts. Usually this is achieved with
>> a DLN-2 adapter, while this is a bit difficult for me because it costs
>> ~175$ in my country. Then I found that FTDI's FT232H supports both these
>> two modes and costs only less than 5$ but without full support in kernel.
>> The ftdi-sio driver supports FT232H only as a serial converter.
>> So I'm planning to write a mfd driver for it supports both these three
>> modes, here are my thoughts:
> There already has been a discussion [1] about adding an MFD driver for
> FT232H, since the operating modes are mutually exclusive (and bus pins
> shared between different modes), the MFD approach doesn't seem to be
> a good fit.
>
>>   - This device cannot support these three modes together because they
>>     share some common pins, so I'm planning to add a sysfs entry
>>     'current_mode' for selecting which mode the device should be working
>>     on.
>>   - This device is in uart mode on reset, so default mode would be reset,
>>     too. This also helps for people only want to use this as a serial
>>     converter feels nothing has happened (compatible).
>>   - I was trying to reuse the ftdi-sio driver but it seems like mfd can
>>     only register platform devices, while this is a usb driver. I may
>>     have to copy some functions from this driver.
>>
>> Would you share any ideas? I'd appreciate it.
> There is a patch series [2] adding an interface driver for FT232H-
> based adapter devices, it already supports adding custom MPSSE based
> SPI busses with SPI slaves for a custom USB PID. It already supports
> adding custom CBUS-/MPSSE-GPIO adapters for user-defined USB PID.
> Adding I2C driver/adapter support should be easy, too. Maybe you can
> re-use it.
>
> Thanks,
> Anatolij
>
> [1] https://patchwork.kernel.org/patch/9828985
> [2] https://patchwork.kernel.org/project/linux-usb/list/?series=48255

Hi Anatolij, Johan,


Great work you've done! While there still some thing confusing me.

Patch series [2] added new custom PIDs to distinguish the mode this device 
should be in when powered on, is this right? Since USB has a convention for all 
the VIDs and PIDs, is this really a good approach to use some us-defined PIDs?

In the discussion [1] #4, Johan said that mfd is not suitable for this situation 
because 'all drivers for these devices be able to retrieve the current mode 
during probe and only bind when the mode matches'.

I think this is saying that we can only register these devices(i2c, spi, gpio) 
when we plug it in, but FT232H's functions are surely mutually exclusive, so 
can't we dynamically register these devices in userspace? I mean through a sysfs 
interface, and through the implementation functions of this interface, we can 
try to use mfd_add_devices() and mfd_remove_devices() to unload one 
function(like uart) and load it as another device like a spi adapter. Is there 
any side effects of doing this in this way?

And also my English may be not very well so please correct me if I'm 
understanding anything wrong. :)


yours,

Song

Re: usb: thoughts of adding more support for FT232H

[Johan Hovold]

Hi Song,

Sorry about the late reply.

On Thu, Dec 06, 2018 at 02:02:21PM +0800, Song Qiang wrote:
> 
> On 12/5/18 11:17 PM, Anatolij Gustschin wrote:
> > Hi,
> >
> > On Wed, 5 Dec 2018 22:10:40 +0800
> > Song Qiang songqiang1304521@gmail.com wrote:
> > ...
> >> I've been developing some iio device drivers and found that some people
> >> would like to test their devices with a qemu system which requires an
> >> i2c or spi port on our development hosts. Usually this is achieved with
> >> a DLN-2 adapter, while this is a bit difficult for me because it costs
> >> ~175$ in my country. Then I found that FTDI's FT232H supports both these
> >> two modes and costs only less than 5$ but without full support in kernel.
> >> The ftdi-sio driver supports FT232H only as a serial converter.
> >> So I'm planning to write a mfd driver for it supports both these three
> >> modes, here are my thoughts:
> > There already has been a discussion [1] about adding an MFD driver for
> > FT232H, since the operating modes are mutually exclusive (and bus pins
> > shared between different modes), the MFD approach doesn't seem to be
> > a good fit.
> >
> >>   - This device cannot support these three modes together because they
> >>     share some common pins, so I'm planning to add a sysfs entry
> >>     'current_mode' for selecting which mode the device should be working
> >>     on.
> >>   - This device is in uart mode on reset, so default mode would be reset,
> >>     too. This also helps for people only want to use this as a serial
> >>     converter feels nothing has happened (compatible).
> >>   - I was trying to reuse the ftdi-sio driver but it seems like mfd can
> >>     only register platform devices, while this is a usb driver. I may
> >>     have to copy some functions from this driver.
> >>
> >> Would you share any ideas? I'd appreciate it.
> > There is a patch series [2] adding an interface driver for FT232H-
> > based adapter devices, it already supports adding custom MPSSE based
> > SPI busses with SPI slaves for a custom USB PID. It already supports
> > adding custom CBUS-/MPSSE-GPIO adapters for user-defined USB PID.
> > Adding I2C driver/adapter support should be easy, too. Maybe you can
> > re-use it.

> > [1] https://patchwork.kernel.org/patch/9828985
> > [2] https://patchwork.kernel.org/project/linux-usb/list/?series=48255

> Patch series [2] added new custom PIDs to distinguish the mode this device 
> should be in when powered on, is this right? Since USB has a convention for all 
> the VIDs and PIDs, is this really a good approach to use some us-defined PIDs?

As I mentioned, I have not really had time to look at [2] yet, but yes,
the driver appears to encode the mode configuration in the device id
table.

> In the discussion [1] #4, Johan said that mfd is not suitable for this situation 
> because 'all drivers for these devices be able to retrieve the current mode 
> during probe and only bind when the mode matches'.

Right, MFD is for devices exposing multiple functions concurrently, but
the FTDI serial-engine modes are mutually exclusive (as you also point
out below).

> I think this is saying that we can only register these devices(i2c, spi, gpio) 
> when we plug it in, but FT232H's functions are surely mutually exclusive, so 
> can't we dynamically register these devices in userspace? I mean through a sysfs 
> interface, and through the implementation functions of this interface, we can 
> try to use mfd_add_devices() and mfd_remove_devices() to unload one 
> function(like uart) and load it as another device like a spi adapter. Is there 
> any side effects of doing this in this way?

It gets pretty messy implementation wise. That's one reason why having
separate drivers and binding based on PID is preferable (another is
being able to determine the mode at probe).

But if this is to be implemented, we probably also do want to be able to
share some code (e.g. for managing the cbus pins as gpios, and that
part could possibly be modelled as an mfd...).

Then you also have the problem of describing the buses that the FTDI
chip exposes. There's currently no way for example to load a device-tree
overlay from userspace after you configure the mode for, say, spi in
order to register the spi slaves.

This is also related to what we want to solve for serial-connected
devices (serdev). Using device-tree overlays for this has been
discussed, but there are some missing pieces for that to be realised
(not least a user-space interface for loading overlays).

Thanks,
Johan

Re: usb: thoughts of adding more support for FT232H

[Song Qiang]

On 2018/12/13 下午9:23, Johan Hovold wrote:

> Hi Song,
>
> Sorry about the late reply.
>
> On Thu, Dec 06, 2018 at 02:02:21PM +0800, Song Qiang wrote:
>> On 12/5/18 11:17 PM, Anatolij Gustschin wrote:
>>> Hi,
>>>
>>> On Wed, 5 Dec 2018 22:10:40 +0800
>>> Song Qiang songqiang1304521@gmail.com wrote:
>>> ...
>>>> I've been developing some iio device drivers and found that some people
>>>> would like to test their devices with a qemu system which requires an
>>>> i2c or spi port on our development hosts. Usually this is achieved with
>>>> a DLN-2 adapter, while this is a bit difficult for me because it costs
>>>> ~175$ in my country. Then I found that FTDI's FT232H supports both these
>>>> two modes and costs only less than 5$ but without full support in kernel.
>>>> The ftdi-sio driver supports FT232H only as a serial converter.
>>>> So I'm planning to write a mfd driver for it supports both these three
>>>> modes, here are my thoughts:
>>> There already has been a discussion [1] about adding an MFD driver for
>>> FT232H, since the operating modes are mutually exclusive (and bus pins
>>> shared between different modes), the MFD approach doesn't seem to be
>>> a good fit.
>>>
>>>>    - This device cannot support these three modes together because they
>>>>      share some common pins, so I'm planning to add a sysfs entry
>>>>      'current_mode' for selecting which mode the device should be working
>>>>      on.
>>>>    - This device is in uart mode on reset, so default mode would be reset,
>>>>      too. This also helps for people only want to use this as a serial
>>>>      converter feels nothing has happened (compatible).
>>>>    - I was trying to reuse the ftdi-sio driver but it seems like mfd can
>>>>      only register platform devices, while this is a usb driver. I may
>>>>      have to copy some functions from this driver.
>>>>
>>>> Would you share any ideas? I'd appreciate it.
>>> There is a patch series [2] adding an interface driver for FT232H-
>>> based adapter devices, it already supports adding custom MPSSE based
>>> SPI busses with SPI slaves for a custom USB PID. It already supports
>>> adding custom CBUS-/MPSSE-GPIO adapters for user-defined USB PID.
>>> Adding I2C driver/adapter support should be easy, too. Maybe you can
>>> re-use it.
>>> [1] https://patchwork.kernel.org/patch/9828985
>>> [2] https://patchwork.kernel.org/project/linux-usb/list/?series=48255
>> Patch series [2] added new custom PIDs to distinguish the mode this device
>> should be in when powered on, is this right? Since USB has a convention for all
>> the VIDs and PIDs, is this really a good approach to use some us-defined PIDs?
> As I mentioned, I have not really had time to look at [2] yet, but yes,
> the driver appears to encode the mode configuration in the device id
> table.
>
>> In the discussion [1] #4, Johan said that mfd is not suitable for this situation
>> because 'all drivers for these devices be able to retrieve the current mode
>> during probe and only bind when the mode matches'.
> Right, MFD is for devices exposing multiple functions concurrently, but
> the FTDI serial-engine modes are mutually exclusive (as you also point
> out below).
>
>> I think this is saying that we can only register these devices(i2c, spi, gpio)
>> when we plug it in, but FT232H's functions are surely mutually exclusive, so
>> can't we dynamically register these devices in userspace? I mean through a sysfs
>> interface, and through the implementation functions of this interface, we can
>> try to use mfd_add_devices() and mfd_remove_devices() to unload one
>> function(like uart) and load it as another device like a spi adapter. Is there
>> any side effects of doing this in this way?
> It gets pretty messy implementation wise. That's one reason why having
> separate drivers and binding based on PID is preferable (another is
> being able to determine the mode at probe).
>
> But if this is to be implemented, we probably also do want to be able to
> share some code (e.g. for managing the cbus pins as gpios, and that
> part could possibly be modelled as an mfd...).
>
> Then you also have the problem of describing the buses that the FTDI
> chip exposes. There's currently no way for example to load a device-tree
> overlay from userspace after you configure the mode for, say, spi in
> order to register the spi slaves.
>
> This is also related to what we want to solve for serial-connected
> devices (serdev). Using device-tree overlays for this has been
> discussed, but there are some missing pieces for that to be realised
> (not least a user-space interface for loading overlays).
>
> Thanks,
> Johan

Hi Johan,


Thanks for your reply, now I understand why the mfd doesn't fit.

So this is saying that currently there is not a very proper way of 
implementing this kind of driver, right? I also noticed that there are 
other series of chips supporting mutually exclusive multi-functions.  I 
think we quite need a framework for them.

Is there a kind of this framework under development? I'm curious and 
want to know how everyone thinks about this problem.


yours,

Song Qiang