usb/138659: uftdi driver broken in RELENG_8/CURRENT

[Pierre-Luc Drouin]

Hans Petter Selasky wrote:
> On Tuesday 22 September 2009 20:22:06 Pierre-Luc Drouin wrote:
>   
>> Hans Petter Selasky wrote:
>>     
>>> On Tuesday 22 September 2009 18:40:40 Pierre-Luc Drouin wrote:
>>>       
>>>> Hans Petter Selasky wrote:
>>>>         
>>>>> On Tuesday 22 September 2009 18:15:19 Pierre-Luc Drouin wrote:
>>>>>           
>>>>>> Hans Petter Selasky wrote:
>>>>>>             
>>>>>>> On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote:
>>>>>>>               
>>>>>>>>>> Thanks!
>>>>>>>>>>                     
>>>>>>>>> It indicates that your device is not sending any data.
>>>>>>>>>
>>>>>>>>> --HPS
>>>>>>>>>                   
>>>>>>>> So does it mean that the write statement (a status request) is not
>>>>>>>> transmitted to the device either?
>>>>>>>>                 
>>>>>>> No, the "xxx_get()" message means that the data you write is sent and
>>>>>>> transmitted.
>>>>>>>
>>>>>>> BTW: I have a FTDI adapter here, and it works fine with loopback when
>>>>>>> the baudrate is set correctly.
>>>>>>>
>>>>>>>               
>>>>>>>> Because this write statement should be
>>>>>>>> followed by data sent from the device and it effectively does on
>>>>>>>> Linux. And about SIGIO, shouldn't this signal be generated only when
>>>>>>>> there is data available to read? Why is it generated in asynchronous
>>>>>>>> mode and then the read statement returns EINTR?
>>>>>>>>                 
>>>>>>> Ed has to answer these questions. This stuff is not handled in the
>>>>>>> USB stack for FTDI devices.
>>>>>>>
>>>>>>> --HPS
>>>>>>>               
>>>>>> In the manual page for the uftdi driver, the chip I am using (FT232BL)
>>>>>> is not listed. According to the FTDI website, it is based on
>>>>>> FT8U232AM, but  it has extra functionalities. Have you had the chance
>>>>>> to test an device that uses either a FT232BM, FT232BL or FT232BQ chip?
>>>>>> I just tested the device on FreeBSD 7.2 and it does not work either...
>>>>>>             
>>>>> No, I haven't.
>>>>>
>>>>> --HPS
>>>>>           
>>>> Are there additional tests I can do in synchronous mode to try pinning
>>>> down the problem?
>>>>         
>>> Hi,
>>>
>>> If the device doesn't work, then there are probably some FTDI USB
>>> registers which are not programmed correctly.
>>>
>>> If you could debug that it would be great.
>>>
>>> --HPS
>>>       
>> ok, so yes I can probably try debugging the driver for the FT232BL chip,
>> but the support for my device's manufacturer is very limited, so it
>> might not be optimal to try doing debugging with that. Plus although I
>> do programming all day (statistical data analysis), I've never done
>> coding at the kernel level or driver programming, so I will need to get
>> familiar with it first.
>>     
>
> Don't worry about your coding skills. If you can add the code that makes it 
> working, I will fix the rest for you.
>
>   
>> Would something like
>> http://www.eurodesign.bg/eudesignbg/USB_RS232.html be the ideal tool for
>> debugging?
>>     
>
> I don't know ....
>
> --HPS
>   
Hi,

so I compared the control commands sent by uftdi to the ones sent by 
ftdio_sio (linux kernel module) and I tried different hacks to finally 
realize that the problem was that FreeBSD was not sending the right baud 
rate to the device. FreeBSD uses c_ospeed (in termios struct) to get the 
baud rate while Linux uses c_cflag. So I removed the baud rate from 
c_cflag in my code and I am now using cfsetispeed and cfsetospeed. I 
though the termios structure and flags were Posix but it looks like it's 
not :S.


So to conclude, it looks like uftdi is working fine :)

Thanks for the support!