| Message ID | 20231003001135.2713961-1-sbertrand@witekio.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | USB: serial: ftdi_sio: add ftdi serial to gpiochip label | expand |
On Mon, Oct 02, 2023 at 05:11:35PM -0700, Stan Bertrand wrote: > From: Stanislas Bertrand <stanislasbertrand@gmail.com> > > Use ftdi serial number on gpiochip label. > Allows to interface with gpiod utils using the serial number: > > $ gpiodetect > gpiochip5 [ftdi-cbus-FTRelay2] (4 lines) > gpiochip6 [ftdi-cbus] (4 lines) > gpiochip7 [ftdi-cbus-A106TPEC] (4 lines) > > $ gpioget ftdi-cbus-FTRelay2 2 > 0 I don't think this is a good idea, for example, as not all devices have a unique serial string. Looks like the naming of gpiochips are all over the place, and ideally this should not have been something that was left up to individual driver to decide. I see several drivers using the name of the corresponding platform device as label, which works in most cases, but not always either. The only unique and always available identifier is the gpiochip's place in the device tree itself. For USB, we already encode the bus topology in the USB device names (e.g. 1-11.5.1) and we could possibly consider using that. But we already have USB serial devices with multiple GPIO chips so also that would require some further thought (e.g. using the interface name instead). Johan
On Friday, December 15, 2023 2:10:15 AM PST Johan Hovold wrote: > On Mon, Oct 02, 2023 at 05:11:35PM -0700, Stan Bertrand wrote: > > From: Stanislas Bertrand <stanislasbertrand@gmail.com> > > > > Use ftdi serial number on gpiochip label. > > Allows to interface with gpiod utils using the serial number: > > > > $ gpiodetect > > gpiochip5 [ftdi-cbus-FTRelay2] (4 lines) > > gpiochip6 [ftdi-cbus] (4 lines) > > gpiochip7 [ftdi-cbus-A106TPEC] (4 lines) > > > > $ gpioget ftdi-cbus-FTRelay2 2 > > 0 > > I don't think this is a good idea, for example, as not all devices have > a unique serial string. The goal is to identify the gpiochip corresponding to a known FTDI device. If serials are not unique, it can still differentiate others. A device serial can be set (FT Prog, Python lib, ...) for direct of access. > Looks like the naming of gpiochips are all over the place, and ideally > this should not have been something that was left up to individual > driver to decide. > > I see several drivers using the name of the corresponding platform > device as label, which works in most cases, but not always either. The > only unique and always available identifier is the gpiochip's place in > the device tree itself. > > For USB, we already encode the bus topology in the USB device names > (e.g. 1-11.5.1) and we could possibly consider using that. But we > already have USB serial devices with multiple GPIO chips so also that > would require some further thought (e.g. using the interface name > instead). The aim is identification while being platform agnostic, device tree or x86. The FTDI serial allows device identification regardless of the system topology. > Johan Thanks, Stan
On Mon, Jan 01, 2024 at 06:00:22PM -0800, Stan Bertrand wrote: > On Friday, December 15, 2023 2:10:15 AM PST Johan Hovold wrote: > > On Mon, Oct 02, 2023 at 05:11:35PM -0700, Stan Bertrand wrote: > > > From: Stanislas Bertrand <stanislasbertrand@gmail.com> > > > > > > Use ftdi serial number on gpiochip label. > > > Allows to interface with gpiod utils using the serial number: > > > > > > $ gpiodetect > > > gpiochip5 [ftdi-cbus-FTRelay2] (4 lines) > > > gpiochip6 [ftdi-cbus] (4 lines) > > > gpiochip7 [ftdi-cbus-A106TPEC] (4 lines) > > > > > > $ gpioget ftdi-cbus-FTRelay2 2 > > > 0 > > > > I don't think this is a good idea, for example, as not all devices have > > a unique serial string. > > The goal is to identify the gpiochip corresponding to a known FTDI device. > If serials are not unique, it can still differentiate others. > A device serial can be set (FT Prog, Python lib, ...) for direct of access. I understand why you want this, I just don't think it's a good interface and this something that will become ABI. Also note that all gpiochips on a multiport FTDI device will all end up with the same label with the current proposal. > > Looks like the naming of gpiochips are all over the place, and ideally > > this should not have been something that was left up to individual > > driver to decide. > > > > I see several drivers using the name of the corresponding platform > > device as label, which works in most cases, but not always either. The > > only unique and always available identifier is the gpiochip's place in > > the device tree itself. > > > > For USB, we already encode the bus topology in the USB device names > > (e.g. 1-11.5.1) and we could possibly consider using that. But we > > already have USB serial devices with multiple GPIO chips so also that > > would require some further thought (e.g. using the interface name > > instead). > > The aim is identification while being platform agnostic, device tree or x86. > The FTDI serial allows device identification regardless of the system topology. The USB bus topology will be the same regardless whether you use devicetree or ACPI. Granted, the USB bus numbers are not stable on Linux but that is a generic problem. Johan
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 1bf23611be12..3e1b1c3194a2 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -2094,6 +2094,8 @@ static int ftdi_gpio_init(struct usb_serial_port *port) { struct ftdi_private *priv = usb_get_serial_port_data(port); struct usb_serial *serial = port->serial; + struct usb_device *udev = serial->dev; + const char *label; int result; switch (priv->chip_type) { @@ -2116,6 +2118,15 @@ static int ftdi_gpio_init(struct usb_serial_port *port) mutex_init(&priv->gpio_lock); priv->gc.label = "ftdi-cbus"; + + if (udev->serial) { + label = devm_kasprintf(&udev->dev, GFP_KERNEL, "ftdi-cbus-%s", + udev->serial); + if (label) { + priv->gc.label = label; + } + } + priv->gc.request = ftdi_gpio_request; priv->gc.get_direction = ftdi_gpio_direction_get; priv->gc.direction_input = ftdi_gpio_direction_input;