Message-ID: <1aedd285-967a-4876-66be-c881fb81476c@gmail.com>
Date:   Sun, 16 Dec 2018 23:45:45 +0800
From:   Song Qiang <songqiang1304521@...il.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     Anatolij Gustschin <agust@...x.de>, gregkh@...uxfoundation.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: usb: thoughts of adding more support for FT232H


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

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

Powered by blists - more mailing lists