Message-ID: <20181213132315.GN3500@localhost>
Date:   Thu, 13 Dec 2018 14:23:15 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Song Qiang <songqiang1304521@...il.com>
Cc:     Anatolij Gustschin <agust@...x.de>, johan@...nel.org,
        gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: usb: thoughts of adding more support for FT232H

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

Powered by blists - more mailing lists