linux-kernel - Re: [PATCH 0/2] FTDI CBUS GPIO support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <77568c206b51c50da927d69ea6b15957@agner.ch>
Date:	Wed, 24 Jun 2015 00:08:50 +0200
From:	Stefan Agner <stefan@...er.ch>
To:	Johan Hovold <johan@...nel.org>
Cc:	linus.walleij@...aro.org, gnurou@...il.com,
	grant.likely@...retlab.ca, gregkh@...uxfoundation.org,
	x-linux@...ra-silbe.de, hachti@...hti.de,
	linux-usb@...r.kernel.org, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org, Johan Hovold <jhovold@...il.com>
Subject: Re: [PATCH 0/2] FTDI CBUS GPIO support

On 2015-06-23 11:22, Johan Hovold wrote:
> On Mon, Jun 22, 2015 at 10:11:35PM +0200, Stefan Agner wrote:
>> On 2015-06-22 19:26, Johan Hovold wrote:
> 
>> > Instead, hang the gpio chip directly off the usb interface (not the
>> > port), add a new config option, and keep the gpio implementation under
>> > drivers/usb/serial (possibly in its own file ftdi_sio-gpio.c).
>>
>> Agreed sounds like a good plan. Will try this approach in v2.
>>
>> Except I don't think hanging it directly to the USB interface is the
>> right thing to do.
>>
>> Looking at the block diagram of FT232R or FT232H, the CBUS pins seem to
>> be part of the UART/FIFO controller. And I think the dual UART FT2232D
>> actually supports controlling the CBUS pins of the two UART controllers
>> individually, at least the block diagram thereof suggests so.
> 
> The port is a Linux abstraction, and for FTDI we happen to have exactly
> one port child device per USB interface. As I see it, the gpio
> controller for the CBUS pins should be a sibling rather than a child
> device to the port.
> 
> Note that we'd still have two gpio-controllers on FT2232D (one per USB
> interface).

I did some research. I think the FT2232D or FT2232H devices do not
support the CBUS Bit Bang mode. For instance the D2XX Programmer's Guide
indicates that on page 69 (CBUS Bit Bang Mode (FT232R and FT232H devices
only)) as well as the AN_184 "FTDI Device Input Output Pin States", does
not mention that the CBUS pins as EEPROM selectable (the same document
does so for FT232R/FT232H devices)...

I don't have such a device, hence I can't try it out...

> I'm aware that this requires some restructuring of the ftdi_sio-driver
> (e.g. the device type and ftdi-interface number should be a feature of
> the usb-serial rather than usb-serial-port device).

The findings above probably do not change the fact that we should not
use the Linux port abstraction to attach the GPIO controller...

I looked into that a bit more in depth. Do I see things right that the
multi-port devices have multiple USB interfaces, which leads to
usb_serial_probe and in turn ftdi_sio_probe getting called multiple
times by the USB stack? If yes, I think I have the bigger picture to go
ahead and try to implement it accordingly.

--
Stefan




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/