serdev: How to attach serdev devices to USB based tty devices?

serdev: How to attach serdev devices to USB based tty devices?

[Andreas Färber]

Hi Rob et al.,

For my LoRa network driver project [1] I have found your serdev
framework to be a valuable help for dealing with hardware modules
exposing some textual or binary UART interface.

In particular on arm(64) and mips this allows to define an unlimited
number of serdev drivers [2] that are associated via their Device Tree
compatible string and can optionally be configured via DT properties.

And in theory it seems serdev has also grown support for ACPI.

Now, a growing number of vendors are placing such modules on a USB stick
for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
cards using their USB pins. While I do not yet have access to such a
device myself, it is my understanding that devices with USB-UART bridge
chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
will show up as /dev/ttyACMx.
On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
information to on-board devices such as MAC address to Ethernet chipset,
but that does not seem all that useful for passing a serdev child node
to hot-plugged devices at unpredictable hub/port location (where it
should not interfere with regular USB-UART cables for debugging), nor
would it help ACPI based platforms such as x86_64.

My idea then was that if we had some unique criteria like vendor and
product IDs (or whatever is supported in usb_device_id), we could write
a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
could call into the existing tty driver's probe function and afterwards
try creating and attaching the appropriate serdev device, i.e. a fixed
USB-to-serdev driver mapping. Problem is that most devices don't seem to
implement any unique identifier I could make this depend on - either by
using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
virtual com port identifiers in CDC firmware and only differing in the
textual description [3] the usb_device_id does not seem to match on.

The obvious solution would of course be if hardware vendors could revise
their designs to configure FTDI/etc. chips uniquely. I hear that that
may involve exchanging the chipset, increasing costs, and may impact
existing drivers. Wouldn't help for devices out there today either.

For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
so it would seem possible to allocate their own product IDs for SX1301
and SX1308 respectively to replace the generic STMicroelectronics IDs,
which the various vendors could offer as firmware updates.

All outside my control though.

Oliver therefore suggested to not mess with USB drivers and instead use
a line discipline (ldisc). It seems that for example the userspace tool
slattach takes a tty device and performs an ioctl to switch the generic
tty device into a special N_SLIP protocol mode, implemented in [4].

However, the existing number of such ldisc modes appears to be below 30,
with hardly any vendor-specific implementation, so polluting its number
space seems undesirable? And in some cases I would like to use the same
protocol implementation over direct UART and over USB, so would like to
avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.

Long story short, has there been any thinking about a userspace
interface to attach a given serdev driver to a tty device?

Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
a DT fragment (!= DT Overlay) with a given USB device dynamically, to
attach a serdev node with sub-nodes?

Any other ideas how to cleanly solve this?

In some cases we're talking about a "simple" AT-like command interface;
the picoGW implements a semi-generic USB-SPI bridge that may host a
choice of 2+ chipsets, which in turn has two further sub-devices with 3+
chipset choices (theoretically clk output and rx/tx options etc.) each.
(For the latter I'm thinking we'll need a serdev driver exposing a
regmap_bus and then implement regmap_bus based versions of the SPI
drivers like Ben and I refactored SX1257 in [2] last weekend.)

Thanks,
Andreas

[1] https://patchwork.ozlabs.org/cover/937545/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
[3]
https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

serdev: How to attach serdev devices to USB based tty devices?

[Andreas Färber]

Hi Rob et al.,

For my LoRa network driver project [1] I have found your serdev
framework to be a valuable help for dealing with hardware modules
exposing some textual or binary UART interface.

In particular on arm(64) and mips this allows to define an unlimited
number of serdev drivers [2] that are associated via their Device Tree
compatible string and can optionally be configured via DT properties.

And in theory it seems serdev has also grown support for ACPI.

Now, a growing number of vendors are placing such modules on a USB stick
for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
cards using their USB pins. While I do not yet have access to such a
device myself, it is my understanding that devices with USB-UART bridge
chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
will show up as /dev/ttyACMx.
On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
information to on-board devices such as MAC address to Ethernet chipset,
but that does not seem all that useful for passing a serdev child node
to hot-plugged devices at unpredictable hub/port location (where it
should not interfere with regular USB-UART cables for debugging), nor
would it help ACPI based platforms such as x86_64.

My idea then was that if we had some unique criteria like vendor and
product IDs (or whatever is supported in usb_device_id), we could write
a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
could call into the existing tty driver's probe function and afterwards
try creating and attaching the appropriate serdev device, i.e. a fixed
USB-to-serdev driver mapping. Problem is that most devices don't seem to
implement any unique identifier I could make this depend on - either by
using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
virtual com port identifiers in CDC firmware and only differing in the
textual description [3] the usb_device_id does not seem to match on.

The obvious solution would of course be if hardware vendors could revise
their designs to configure FTDI/etc. chips uniquely. I hear that that
may involve exchanging the chipset, increasing costs, and may impact
existing drivers. Wouldn't help for devices out there today either.

For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
so it would seem possible to allocate their own product IDs for SX1301
and SX1308 respectively to replace the generic STMicroelectronics IDs,
which the various vendors could offer as firmware updates.

All outside my control though.

Oliver therefore suggested to not mess with USB drivers and instead use
a line discipline (ldisc). It seems that for example the userspace tool
slattach takes a tty device and performs an ioctl to switch the generic
tty device into a special N_SLIP protocol mode, implemented in [4].

However, the existing number of such ldisc modes appears to be below 30,
with hardly any vendor-specific implementation, so polluting its number
space seems undesirable? And in some cases I would like to use the same
protocol implementation over direct UART and over USB, so would like to
avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.

Long story short, has there been any thinking about a userspace
interface to attach a given serdev driver to a tty device?

Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
a DT fragment (!= DT Overlay) with a given USB device dynamically, to
attach a serdev node with sub-nodes?

Any other ideas how to cleanly solve this?

In some cases we're talking about a "simple" AT-like command interface;
the picoGW implements a semi-generic USB-SPI bridge that may host a
choice of 2+ chipsets, which in turn has two further sub-devices with 3+
chipset choices (theoretically clk output and rx/tx options etc.) each.
(For the latter I'm thinking we'll need a serdev driver exposing a
regmap_bus and then implement regmap_bus based versions of the SPI
drivers like Ben and I refactored SX1257 in [2] last weekend.)

Thanks,
Andreas

[1] https://patchwork.ozlabs.org/cover/937545/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
[3]
https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

serdev: How to attach serdev devices to USB based tty devices?

[Andreas Färber]

Hi Rob et al.,

For my LoRa network driver project [1] I have found your serdev
framework to be a valuable help for dealing with hardware modules
exposing some textual or binary UART interface.

In particular on arm(64) and mips this allows to define an unlimited
number of serdev drivers [2] that are associated via their Device Tree
compatible string and can optionally be configured via DT properties.

And in theory it seems serdev has also grown support for ACPI.

Now, a growing number of vendors are placing such modules on a USB stick
for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
cards using their USB pins. While I do not yet have access to such a
device myself, it is my understanding that devices with USB-UART bridge
chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
will show up as /dev/ttyACMx.
On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
information to on-board devices such as MAC address to Ethernet chipset,
but that does not seem all that useful for passing a serdev child node
to hot-plugged devices at unpredictable hub/port location (where it
should not interfere with regular USB-UART cables for debugging), nor
would it help ACPI based platforms such as x86_64.

My idea then was that if we had some unique criteria like vendor and
product IDs (or whatever is supported in usb_device_id), we could write
a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
could call into the existing tty driver's probe function and afterwards
try creating and attaching the appropriate serdev device, i.e. a fixed
USB-to-serdev driver mapping. Problem is that most devices don't seem to
implement any unique identifier I could make this depend on - either by
using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
virtual com port identifiers in CDC firmware and only differing in the
textual description [3] the usb_device_id does not seem to match on.

The obvious solution would of course be if hardware vendors could revise
their designs to configure FTDI/etc. chips uniquely. I hear that that
may involve exchanging the chipset, increasing costs, and may impact
existing drivers. Wouldn't help for devices out there today either.

For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
so it would seem possible to allocate their own product IDs for SX1301
and SX1308 respectively to replace the generic STMicroelectronics IDs,
which the various vendors could offer as firmware updates.

All outside my control though.

Oliver therefore suggested to not mess with USB drivers and instead use
a line discipline (ldisc). It seems that for example the userspace tool
slattach takes a tty device and performs an ioctl to switch the generic
tty device into a special N_SLIP protocol mode, implemented in [4].

However, the existing number of such ldisc modes appears to be below 30,
with hardly any vendor-specific implementation, so polluting its number
space seems undesirable? And in some cases I would like to use the same
protocol implementation over direct UART and over USB, so would like to
avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.

Long story short, has there been any thinking about a userspace
interface to attach a given serdev driver to a tty device?

Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
a DT fragment (!= DT Overlay) with a given USB device dynamically, to
attach a serdev node with sub-nodes?

Any other ideas how to cleanly solve this?

In some cases we're talking about a "simple" AT-like command interface;
the picoGW implements a semi-generic USB-SPI bridge that may host a
choice of 2+ chipsets, which in turn has two further sub-devices with 3+
chipset choices (theoretically clk output and rx/tx options etc.) each.
(For the latter I'm thinking we'll need a serdev driver exposing a
regmap_bus and then implement regmap_bus based versions of the SPI
drivers like Ben and I refactored SX1257 in [2] last weekend.)

Thanks,
Andreas

[1] https://patchwork.ozlabs.org/cover/937545/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
[3]
https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: serdev: How to attach serdev devices to USB based tty devices?

[Oliver Neukum]

On Di, 2018-08-14 at 04:28 +0200, Andreas Färber  wrote:
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.

If you really must do this you can benignly fail probe(). Thus you
can compare strings within your probe() method.
This sucks because you need to make sure your drivers are always
loaded in a certain order and you really rely on undocumented
properties, but it can be done.

	Regards
		Oliver

Re: serdev: How to attach serdev devices to USB based tty devices?

[Oliver Neukum]

On Di, 2018-08-14 at 04:28 +0200, Andreas Färber  wrote:
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.

If you really must do this you can benignly fail probe(). Thus you
can compare strings within your probe() method.
This sucks because you need to make sure your drivers are always
loaded in a certain order and you really rely on undocumented
properties, but it can be done.

	Regards
		Oliver

serdev: How to attach serdev devices to USB based tty devices?

[Oliver Neukum]

On Di, 2018-08-14 at 04:28 +0200, Andreas F?rber  wrote:
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.

If you really must do this you can benignly fail probe(). Thus you
can compare strings within your probe() method.
This sucks because you need to make sure your drivers are always
loaded in a certain order and you really rely on undocumented
properties, but it can be done.

	Regards
		Oliver

Re: serdev: How to attach serdev devices to USB based tty devices?

[Andrew Lunn]

Hi Andreas

This not my area of expertise. But i wanted to point out that there
exists a mechanism to make the FDTI driver release a port so that it
can be used from user space, e.g. for JTAG. It might be possible to
extend this mechanism to make the FTDI driver perform the registration
to serdev.

It is however not a generic solution.

   Andrew

Re: serdev: How to attach serdev devices to USB based tty devices?

[Andrew Lunn]

Hi Andreas

This not my area of expertise. But i wanted to point out that there
exists a mechanism to make the FDTI driver release a port so that it
can be used from user space, e.g. for JTAG. It might be possible to
extend this mechanism to make the FTDI driver perform the registration
to serdev.

It is however not a generic solution.

   Andrew

serdev: How to attach serdev devices to USB based tty devices?

[Andrew Lunn]

Hi Andreas

This not my area of expertise. But i wanted to point out that there
exists a mechanism to make the FDTI driver release a port so that it
can be used from user space, e.g. for JTAG. It might be possible to
extend this mechanism to make the FTDI driver perform the registration
to serdev.

It is however not a generic solution.

   Andrew

Re: serdev: How to attach serdev devices to USB based tty devices?

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 5346 bytes --]

Hi,

+cc Johan Hovold <johan@kernel.org>

Johan told me, that he is working on this at ELCE 2017. Also he is
the subsystem maintainer of the USB serial subsystem.

-- Sebastian

On Tue, Aug 14, 2018 at 04:28:20AM +0200, Andreas Färber wrote:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)
> 
> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: serdev: How to attach serdev devices to USB based tty devices?

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 5346 bytes --]

Hi,

+cc Johan Hovold <johan@kernel.org>

Johan told me, that he is working on this at ELCE 2017. Also he is
the subsystem maintainer of the USB serial subsystem.

-- Sebastian

On Tue, Aug 14, 2018 at 04:28:20AM +0200, Andreas Färber wrote:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)
> 
> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

serdev: How to attach serdev devices to USB based tty devices?

[Sebastian Reichel]

Hi,

+cc Johan Hovold <johan@kernel.org>

Johan told me, that he is working on this at ELCE 2017. Also he is
the subsystem maintainer of the USB serial subsystem.

-- Sebastian

On Tue, Aug 14, 2018 at 04:28:20AM +0200, Andreas F?rber wrote:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)
> 
> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton
> HRB 21284 (AG N?rnberg)
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180815/bad148ee/attachment.sig>

Re: serdev: How to attach serdev devices to USB based tty devices?

[Rob Herring]

On Mon, Aug 13, 2018 at 8:28 PM Andreas Färber <afaerber@suse.de> wrote:
>
> Hi Rob et al.,
>
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
>
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
>
> And in theory it seems serdev has also grown support for ACPI.
>
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
>
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
>
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
>
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
>
> All outside my control though.
>
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
>
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?

There was this[1] posted.

The main problem is the only way we know to instantiate a serdev ctrlr
is if there's a slave device described. I did make a series[2] that
makes serdev and tty device co-exist. Then you can more easily
manually attach a device. The problems are you get mismatches in
opens/closes in the tty layer and what should the behavior be if
userspace is trying to access the same port via both the tty and
serdev. After breaking things last time I touched tty open and close,
I'm hesitant to do that again. :)

> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?

There's been some discussions but no real progress. I think we need to
be able to support multiple DT roots and then assign/apply DTs to
arbitrary devices. That's first going to require that of_root is not
exposed outside of drivers/of/ and then there could be some issues
with assuming root==NULL is the base of the single DT. Beyond that, I
haven't given it too much thought.

An alternative is we create DT nodes for all devices which don't have
them (or only certain buses) and then we can apply overlays. This is
kind of headed down the path of doing an OpenFirmware implementation
which would enumerate all the devices and pass that DT to the OS.

Rob

[1] https://www.spinics.net/lists/linux-serial/msg30732.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=serdev-ldisc-v2

Re: serdev: How to attach serdev devices to USB based tty devices?

[Rob Herring]

On Mon, Aug 13, 2018 at 8:28 PM Andreas Färber <afaerber@suse.de> wrote:
>
> Hi Rob et al.,
>
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
>
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
>
> And in theory it seems serdev has also grown support for ACPI.
>
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
>
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
>
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
>
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
>
> All outside my control though.
>
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
>
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?

There was this[1] posted.

The main problem is the only way we know to instantiate a serdev ctrlr
is if there's a slave device described. I did make a series[2] that
makes serdev and tty device co-exist. Then you can more easily
manually attach a device. The problems are you get mismatches in
opens/closes in the tty layer and what should the behavior be if
userspace is trying to access the same port via both the tty and
serdev. After breaking things last time I touched tty open and close,
I'm hesitant to do that again. :)

> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?

There's been some discussions but no real progress. I think we need to
be able to support multiple DT roots and then assign/apply DTs to
arbitrary devices. That's first going to require that of_root is not
exposed outside of drivers/of/ and then there could be some issues
with assuming root==NULL is the base of the single DT. Beyond that, I
haven't given it too much thought.

An alternative is we create DT nodes for all devices which don't have
them (or only certain buses) and then we can apply overlays. This is
kind of headed down the path of doing an OpenFirmware implementation
which would enumerate all the devices and pass that DT to the OS.

Rob

[1] https://www.spinics.net/lists/linux-serial/msg30732.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=serdev-ldisc-v2

serdev: How to attach serdev devices to USB based tty devices?

[Rob Herring]

On Mon, Aug 13, 2018 at 8:28 PM Andreas F?rber <afaerber@suse.de> wrote:
>
> Hi Rob et al.,
>
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
>
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
>
> And in theory it seems serdev has also grown support for ACPI.
>
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
>
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
>
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
>
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
>
> All outside my control though.
>
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
>
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?

There was this[1] posted.

The main problem is the only way we know to instantiate a serdev ctrlr
is if there's a slave device described. I did make a series[2] that
makes serdev and tty device co-exist. Then you can more easily
manually attach a device. The problems are you get mismatches in
opens/closes in the tty layer and what should the behavior be if
userspace is trying to access the same port via both the tty and
serdev. After breaking things last time I touched tty open and close,
I'm hesitant to do that again. :)

> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?

There's been some discussions but no real progress. I think we need to
be able to support multiple DT roots and then assign/apply DTs to
arbitrary devices. That's first going to require that of_root is not
exposed outside of drivers/of/ and then there could be some issues
with assuming root==NULL is the base of the single DT. Beyond that, I
haven't given it too much thought.

An alternative is we create DT nodes for all devices which don't have
them (or only certain buses) and then we can apply overlays. This is
kind of headed down the path of doing an OpenFirmware implementation
which would enumerate all the devices and pass that DT to the OS.

Rob

[1] https://www.spinics.net/lists/linux-serial/msg30732.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=serdev-ldisc-v2

Re: serdev: How to attach serdev devices to USB based tty devices?

[Tony Lee]

[-- Attachment #1: Type: text/plain, Size: 5682 bytes --]

Dear Andreas,

About adding vendor ID our GL5x12, it seems we will need to modify our hardware after investigation.
So, this hardware modification and schedule will be discuss and plan at Maxiiot. Please wait for further update.





Best Regards,

李弘彬
Tony Lee

CN Mobile  +86.135.3778.7870
TW Mobile  +886.939.979.139    

MAXIIOT 深圳市派洛德科技有限公司
TEL: +86.755.2645.9429
FAX: +86.755.2947.6513
信用代碼: 91440300359881668D
Email: tony.lee@maxiiot.com
Web: www.maxiiot.com

深圳市宝安区留仙二路1巷16号南天辉创研中心3楼302室
Room 302, 3F, No. 16, Lane 1, Liuxian No.2 Road, 
Bao an District. 518100 Shenzhen, China 

> Andreas Färber <afaerber@suse.de> 於 2018年8月14日 10:28 寫道：
> 
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)
> 
> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)


[-- Attachment #2: Type: text/html, Size: 8503 bytes --]

Re: serdev: How to attach serdev devices to USB based tty devices?

[Johan Hovold]

On Wed, Aug 15, 2018 at 08:21:50PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> +cc Johan Hovold <johan@kernel.org>
> 
> Johan told me, that he is working on this at ELCE 2017. Also he is
> the subsystem maintainer of the USB serial subsystem.

I haven't done much work on this; it's more of a low-priority background
task that keeps popping up. ;)

Rob already linked to Ricardo's series in which this was recently
discussed [1][2].

In one of those threads I also posted to some code I've been using to
test serdev with USB-serial devices [3]. There are some known issues
blocking this from being merged (e.g. serdev not supporting hangups and
agreement on DT bindings), but it would otherwise allow you to use
serdev for fixed topologies (i.e. you know beforehand which port you'll
be plugging your USB-serial device into). So that might still be useful
for development purposes as is.

With DT-overlay support this could be extended also to the dynamic case
(e.g. loading overlays from userspace or passing the equivalent data
from a tty driver).

Johan


[1] https://lkml.kernel.org/r/CAPybu_0RRNMsdzv4CKyw922hX3_EF=-LKD_QWZV0DoQmjG0aRQ@mail.gmail.com
[2] https://lkml.kernel.org/r/20180611115240.32606-1-ricardo.ribalda@gmail.com
[3] https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-serial-of

serdev: How to attach serdev devices to USB based tty devices?

[Johan Hovold]

On Wed, Aug 15, 2018 at 08:21:50PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> +cc Johan Hovold <johan@kernel.org>
> 
> Johan told me, that he is working on this at ELCE 2017. Also he is
> the subsystem maintainer of the USB serial subsystem.

I haven't done much work on this; it's more of a low-priority background
task that keeps popping up. ;)

Rob already linked to Ricardo's series in which this was recently
discussed [1][2].

In one of those threads I also posted to some code I've been using to
test serdev with USB-serial devices [3]. There are some known issues
blocking this from being merged (e.g. serdev not supporting hangups and
agreement on DT bindings), but it would otherwise allow you to use
serdev for fixed topologies (i.e. you know beforehand which port you'll
be plugging your USB-serial device into). So that might still be useful
for development purposes as is.

With DT-overlay support this could be extended also to the dynamic case
(e.g. loading overlays from userspace or passing the equivalent data
from a tty driver).

Johan


[1] https://lkml.kernel.org/r/CAPybu_0RRNMsdzv4CKyw922hX3_EF=-LKD_QWZV0DoQmjG0aRQ at mail.gmail.com
[2] https://lkml.kernel.org/r/20180611115240.32606-1-ricardo.ribalda at gmail.com
[3] https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-serial-of

Re: serdev: How to attach serdev devices to USB based tty devices?

[Frank Kunz]

Am 14.08.2018 um 04:28 schrieb Andreas Färber:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.

They need to put an extra eeprom (cents) into their design and program it.

> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)>

There is a mPCIe module (RAK833) available by RAK wireless that uses a
FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
is detected as generic FT2232 device on usb. As far as I understood so
far the serdev does only support uart based communication, is there a
chance to get USB-SPI bridged modules also working?

Br,
Frank

> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: serdev: How to attach serdev devices to USB based tty devices?

[Frank Kunz]

Am 14.08.2018 um 04:28 schrieb Andreas Färber:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.

They need to put an extra eeprom (cents) into their design and program it.

> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)>

There is a mPCIe module (RAK833) available by RAK wireless that uses a
FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
is detected as generic FT2232 device on usb. As far as I understood so
far the serdev does only support uart based communication, is there a
chance to get USB-SPI bridged modules also working?

Br,
Frank

> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 

Re: serdev: How to attach serdev devices to USB based tty devices?

[Frank Kunz]

Am 14.08.2018 um 04:28 schrieb Andreas Färber:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.

They need to put an extra eeprom (cents) into their design and program it.

> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)>

There is a mPCIe module (RAK833) available by RAK wireless that uses a
FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
is detected as generic FT2232 device on usb. As far as I understood so
far the serdev does only support uart based communication, is there a
chance to get USB-SPI bridged modules also working?

Br,
Frank

> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 

serdev: How to attach serdev devices to USB based tty devices?

[Frank Kunz]

Am 14.08.2018 um 04:28 schrieb Andreas F?rber:
> Hi Rob et al.,
> 
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
> 
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
> 
> And in theory it seems serdev has also grown support for ACPI.
> 
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
> 
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
> 
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.

They need to put an extra eeprom (cents) into their design and program it.

> 
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
> 
> All outside my control though.
> 
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
> 
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> 
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
> 
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
> 
> Any other ideas how to cleanly solve this?
> 
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)>

There is a mPCIe module (RAK833) available by RAK wireless that uses a
FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
is detected as generic FT2232 device on usb. As far as I understood so
far the serdev does only support uart based communication, is there a
chance to get USB-SPI bridged modules also working?

Br,
Frank

> Thanks,
> Andreas
> 
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
> 

Re: serdev: How to attach serdev devices to USB based tty devices?

[Rob Herring]

On Tue, Aug 21, 2018 at 11:33 AM Frank Kunz
<mailinglists@kunz-im-inter.net> wrote:
>
> Am 14.08.2018 um 04:28 schrieb Andreas Färber:
> > Hi Rob et al.,
> >
> > For my LoRa network driver project [1] I have found your serdev
> > framework to be a valuable help for dealing with hardware modules
> > exposing some textual or binary UART interface.
> >
> > In particular on arm(64) and mips this allows to define an unlimited
> > number of serdev drivers [2] that are associated via their Device Tree
> > compatible string and can optionally be configured via DT properties.
> >
> > And in theory it seems serdev has also grown support for ACPI.
> >
> > Now, a growing number of vendors are placing such modules on a USB stick
> > for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> > cards using their USB pins. While I do not yet have access to such a
> > device myself, it is my understanding that devices with USB-UART bridge
> > chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> > MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> > will show up as /dev/ttyACMx.
> > On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> > information to on-board devices such as MAC address to Ethernet chipset,
> > but that does not seem all that useful for passing a serdev child node
> > to hot-plugged devices at unpredictable hub/port location (where it
> > should not interfere with regular USB-UART cables for debugging), nor
> > would it help ACPI based platforms such as x86_64.
> >
> > My idea then was that if we had some unique criteria like vendor and
> > product IDs (or whatever is supported in usb_device_id), we could write
> > a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> > could call into the existing tty driver's probe function and afterwards
> > try creating and attaching the appropriate serdev device, i.e. a fixed
> > USB-to-serdev driver mapping. Problem is that most devices don't seem to
> > implement any unique identifier I could make this depend on - either by
> > using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> > virtual com port identifiers in CDC firmware and only differing in the
> > textual description [3] the usb_device_id does not seem to match on.
> >
> > The obvious solution would of course be if hardware vendors could revise
> > their designs to configure FTDI/etc. chips uniquely. I hear that that
> > may involve exchanging the chipset, increasing costs, and may impact
> > existing drivers. Wouldn't help for devices out there today either.
>
> They need to put an extra eeprom (cents) into their design and program it.
>
> >
> > For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> > so it would seem possible to allocate their own product IDs for SX1301
> > and SX1308 respectively to replace the generic STMicroelectronics IDs,
> > which the various vendors could offer as firmware updates.
> >
> > All outside my control though.
> >
> > Oliver therefore suggested to not mess with USB drivers and instead use
> > a line discipline (ldisc). It seems that for example the userspace tool
> > slattach takes a tty device and performs an ioctl to switch the generic
> > tty device into a special N_SLIP protocol mode, implemented in [4].
> >
> > However, the existing number of such ldisc modes appears to be below 30,
> > with hardly any vendor-specific implementation, so polluting its number
> > space seems undesirable? And in some cases I would like to use the same
> > protocol implementation over direct UART and over USB, so would like to
> > avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> >
> > Long story short, has there been any thinking about a userspace
> > interface to attach a given serdev driver to a tty device?
> >
> > Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> > a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> > attach a serdev node with sub-nodes?
> >
> > Any other ideas how to cleanly solve this?
> >
> > In some cases we're talking about a "simple" AT-like command interface;
> > the picoGW implements a semi-generic USB-SPI bridge that may host a
> > choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> > chipset choices (theoretically clk output and rx/tx options etc.) each.
> > (For the latter I'm thinking we'll need a serdev driver exposing a
> > regmap_bus and then implement regmap_bus based versions of the SPI
> > drivers like Ben and I refactored SX1257 in [2] last weekend.)>
>
> There is a mPCIe module (RAK833) available by RAK wireless that uses a
> FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
> is detected as generic FT2232 device on usb. As far as I understood so
> far the serdev does only support uart based communication, is there a
> chance to get USB-SPI bridged modules also working?

That should be somewhat easier than a UART because there's not the
interactions with the tty layer to deal with. You still have the issue
of what is the DT root for the FTDI device.

Rob

serdev: How to attach serdev devices to USB based tty devices?

[Rob Herring]

On Tue, Aug 21, 2018 at 11:33 AM Frank Kunz
<mailinglists@kunz-im-inter.net> wrote:
>
> Am 14.08.2018 um 04:28 schrieb Andreas F?rber:
> > Hi Rob et al.,
> >
> > For my LoRa network driver project [1] I have found your serdev
> > framework to be a valuable help for dealing with hardware modules
> > exposing some textual or binary UART interface.
> >
> > In particular on arm(64) and mips this allows to define an unlimited
> > number of serdev drivers [2] that are associated via their Device Tree
> > compatible string and can optionally be configured via DT properties.
> >
> > And in theory it seems serdev has also grown support for ACPI.
> >
> > Now, a growing number of vendors are placing such modules on a USB stick
> > for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> > cards using their USB pins. While I do not yet have access to such a
> > device myself, it is my understanding that devices with USB-UART bridge
> > chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> > MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> > will show up as /dev/ttyACMx.
> > On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> > information to on-board devices such as MAC address to Ethernet chipset,
> > but that does not seem all that useful for passing a serdev child node
> > to hot-plugged devices at unpredictable hub/port location (where it
> > should not interfere with regular USB-UART cables for debugging), nor
> > would it help ACPI based platforms such as x86_64.
> >
> > My idea then was that if we had some unique criteria like vendor and
> > product IDs (or whatever is supported in usb_device_id), we could write
> > a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> > could call into the existing tty driver's probe function and afterwards
> > try creating and attaching the appropriate serdev device, i.e. a fixed
> > USB-to-serdev driver mapping. Problem is that most devices don't seem to
> > implement any unique identifier I could make this depend on - either by
> > using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> > virtual com port identifiers in CDC firmware and only differing in the
> > textual description [3] the usb_device_id does not seem to match on.
> >
> > The obvious solution would of course be if hardware vendors could revise
> > their designs to configure FTDI/etc. chips uniquely. I hear that that
> > may involve exchanging the chipset, increasing costs, and may impact
> > existing drivers. Wouldn't help for devices out there today either.
>
> They need to put an extra eeprom (cents) into their design and program it.
>
> >
> > For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> > so it would seem possible to allocate their own product IDs for SX1301
> > and SX1308 respectively to replace the generic STMicroelectronics IDs,
> > which the various vendors could offer as firmware updates.
> >
> > All outside my control though.
> >
> > Oliver therefore suggested to not mess with USB drivers and instead use
> > a line discipline (ldisc). It seems that for example the userspace tool
> > slattach takes a tty device and performs an ioctl to switch the generic
> > tty device into a special N_SLIP protocol mode, implemented in [4].
> >
> > However, the existing number of such ldisc modes appears to be below 30,
> > with hardly any vendor-specific implementation, so polluting its number
> > space seems undesirable? And in some cases I would like to use the same
> > protocol implementation over direct UART and over USB, so would like to
> > avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
> >
> > Long story short, has there been any thinking about a userspace
> > interface to attach a given serdev driver to a tty device?
> >
> > Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> > a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> > attach a serdev node with sub-nodes?
> >
> > Any other ideas how to cleanly solve this?
> >
> > In some cases we're talking about a "simple" AT-like command interface;
> > the picoGW implements a semi-generic USB-SPI bridge that may host a
> > choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> > chipset choices (theoretically clk output and rx/tx options etc.) each.
> > (For the latter I'm thinking we'll need a serdev driver exposing a
> > regmap_bus and then implement regmap_bus based versions of the SPI
> > drivers like Ben and I refactored SX1257 in [2] last weekend.)>
>
> There is a mPCIe module (RAK833) available by RAK wireless that uses a
> FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
> is detected as generic FT2232 device on usb. As far as I understood so
> far the serdev does only support uart based communication, is there a
> chance to get USB-SPI bridged modules also working?

That should be somewhat easier than a UART because there's not the
interactions with the tty layer to deal with. You still have the issue
of what is the DT root for the FTDI device.

Rob

Re: serdev: How to attach serdev devices to USB based tty devices?

[Tony Lee]

[-- Attachment #1: Type: text/plain, Size: 6676 bytes --]

Hi Andreas,

We made our gateway card utility for the linux, please see the attached.






Best Regards,

李弘彬
Tony Lee

CN Mobile  +86.135.3778.7870
TW Mobile  +886.939.979.139    

MAXIIOT 深圳市派洛德科技有限公司
TEL: +86.755.2645.9429
FAX: +86.755.2947.6513
信用代碼: 91440300359881668D
Email: tony.lee@maxiiot.com
Web: www.maxiiot.com

深圳市宝安区留仙二路1巷16号南天辉创研中心3楼302室
Room 302, 3F, No. 16, Lane 1, Liuxian No.2 Road, 
Bao an District. 518100 Shenzhen, China 

> Tony Lee <tony.lee@maxiiot.com> 於 2018年8月17日 13:55 寫道：
> 
> Dear Andreas,
> 
> About adding vendor ID our GL5x12, it seems we will need to modify our hardware after investigation.
> So, this hardware modification and schedule will be discuss and plan at Maxiiot. Please wait for further update.
> 
> 
> 
> 
> 
> Best Regards,
> 
> 李弘彬
> Tony Lee
> 
> CN Mobile  +86.135.3778.7870
> TW Mobile  +886.939.979.139    
> 
> MAXIIOT 深圳市派洛德科技有限公司
> TEL: +86.755.2645.9429
> FAX: +86.755.2947.6513
> 信用代碼: 91440300359881668D
> Email: tony.lee@maxiiot.com <mailto:tony.lee@maxiiot.com>
> Web: www.maxiiot.com
> 
> 深圳市宝安区留仙二路1巷16号南天辉创研中心3楼302室
> Room 302, 3F, No. 16, Lane 1, Liuxian No.2 Road, 
> Bao an District. 518100 Shenzhen, China 
> 
>> Andreas Färber <afaerber@suse.de <mailto:afaerber@suse.de>> 於 2018年8月14日 10:28 寫道：
>> 
>> Hi Rob et al.,
>> 
>> For my LoRa network driver project [1] I have found your serdev
>> framework to be a valuable help for dealing with hardware modules
>> exposing some textual or binary UART interface.
>> 
>> In particular on arm(64) and mips this allows to define an unlimited
>> number of serdev drivers [2] that are associated via their Device Tree
>> compatible string and can optionally be configured via DT properties.
>> 
>> And in theory it seems serdev has also grown support for ACPI.
>> 
>> Now, a growing number of vendors are placing such modules on a USB stick
>> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
>> cards using their USB pins. While I do not yet have access to such a
>> device myself, it is my understanding that devices with USB-UART bridge
>> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
>> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
>> will show up as /dev/ttyACMx.
>> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
>> information to on-board devices such as MAC address to Ethernet chipset,
>> but that does not seem all that useful for passing a serdev child node
>> to hot-plugged devices at unpredictable hub/port location (where it
>> should not interfere with regular USB-UART cables for debugging), nor
>> would it help ACPI based platforms such as x86_64.
>> 
>> My idea then was that if we had some unique criteria like vendor and
>> product IDs (or whatever is supported in usb_device_id), we could write
>> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
>> could call into the existing tty driver's probe function and afterwards
>> try creating and attaching the appropriate serdev device, i.e. a fixed
>> USB-to-serdev driver mapping. Problem is that most devices don't seem to
>> implement any unique identifier I could make this depend on - either by
>> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
>> virtual com port identifiers in CDC firmware and only differing in the
>> textual description [3] the usb_device_id does not seem to match on.
>> 
>> The obvious solution would of course be if hardware vendors could revise
>> their designs to configure FTDI/etc. chips uniquely. I hear that that
>> may involve exchanging the chipset, increasing costs, and may impact
>> existing drivers. Wouldn't help for devices out there today either.
>> 
>> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
>> so it would seem possible to allocate their own product IDs for SX1301
>> and SX1308 respectively to replace the generic STMicroelectronics IDs,
>> which the various vendors could offer as firmware updates.
>> 
>> All outside my control though.
>> 
>> Oliver therefore suggested to not mess with USB drivers and instead use
>> a line discipline (ldisc). It seems that for example the userspace tool
>> slattach takes a tty device and performs an ioctl to switch the generic
>> tty device into a special N_SLIP protocol mode, implemented in [4].
>> 
>> However, the existing number of such ldisc modes appears to be below 30,
>> with hardly any vendor-specific implementation, so polluting its number
>> space seems undesirable? And in some cases I would like to use the same
>> protocol implementation over direct UART and over USB, so would like to
>> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>> 
>> Long story short, has there been any thinking about a userspace
>> interface to attach a given serdev driver to a tty device?
>> 
>> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
>> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
>> attach a serdev node with sub-nodes?
>> 
>> Any other ideas how to cleanly solve this?
>> 
>> In some cases we're talking about a "simple" AT-like command interface;
>> the picoGW implements a semi-generic USB-SPI bridge that may host a
>> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
>> chipset choices (theoretically clk output and rx/tx options etc.) each.
>> (For the latter I'm thinking we'll need a serdev driver exposing a
>> regmap_bus and then implement regmap_bus based versions of the SPI
>> drivers like Ben and I refactored SX1257 in [2] last weekend.)
>> 
>> Thanks,
>> Andreas
>> 
>> [1] https://patchwork.ozlabs.org/cover/937545/ <https://patchwork.ozlabs.org/cover/937545/>
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next <https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next>
>> [3]
>> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
>> [4]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
>> 
>> -- 
>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG Nürnberg)
> 


[-- Attachment #2.1: Type: text/html, Size: 11248 bytes --]

[-- Attachment #2.2: 螢幕快照 2018-08-29 14.55.20（2）.png --]
[-- Type: image/png, Size: 166148 bytes --]

[-- Attachment #2.3: 螢幕快照 2018-08-29 14.55.16（2）.png --]
[-- Type: image/png, Size: 237602 bytes --]