Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: usb: thoughts of adding more support for FT232H
To:     Anatolij Gustschin <agust@denx.de>
Cc:     johan@kernel.org, gregkh@linuxfoundation.org,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
References: <48bc71bb-68e4-8b29-f609-940c9aedc0a9@gmail.com>
 <20181205161718.7451d98f@crub>
From:   Song Qiang <songqiang1304521@gmail.com>
Message-ID: <924d4ebb-5f9c-f863-c698-9f978e9bc337@gmail.com>
Date:   Thu, 6 Dec 2018 14:02:21 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181205161718.7451d98f@crub>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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