Hi Sebastian,

Am 22.08.2016 um 22:39 schrieb Sebastian Reichel [off-list ref]:

Hi,

On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote:

quoted

quoted

Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes [off-list ref]:

quoted

What it is not about are UART/RS232 converters connected through USB or virtual
serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices
connected through USB (even if they also run HCI protocol).

It actually has to be about both because you will find the exact same
device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is
it just about embedded boards.

Not necessarily.

We often have two interface options for exactly the sam sensor chips. They can be connected
either through SPI or I2C. Which means that there is a core driver for the chip and two different
transport glue components (see e.g. iio/accel/bmc150).

This does not require I2C to be able to handle SPI or vice versa or provide a common API.

I don't understand this comparison. I2C and SPI are different
protocols,

Yes, they are different on protocol level, but on both you transfer blocks of data from/to a slave device
which usually can be addressed. And for some chips they are just two slightly alternative serial interfaces.

while native UART and USB-connected UART are both UART.

I see what you mean, but kernel divides between directly connected UART and USB-connected UART.

drivers/usb/serial/ vs. drivers/tty/serial/

to implement two different groups of UARTs. Although on user space level they are harmonized again.
This is why I compare with i2c and spi. But each such comparison is not perfect.

Anyways, to me it looks as if everybody wants to make the solution work for usb-uarts as well
(although I still would like to see a real world use-case).

quoted

And most Bluetooth devices I know have either UART or a direct
USB interface. So in the USB case there is no need to connect
it through some USB-UART bridge and treat it as an UART at all.

I think having support for USB-UART dongles is useful for
driver development and testing on non-embedded HW.

Hm. I assume you mean the Bluetooth situation where both, embedded UART
connected chips and USB dongles are available. I am not a specialist for such things,
but  I think you have three options to connect bluetooth:

a) SoC-UART <-> BT-Chip-UART-port
b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port
c) USB <-> BT-Chip-USB-port (not UART involved at all)

Case c) IMHO means you anyways need a special USB driver for the BT-Chip connected
through USB and plugging it into a non-embedded USB port does not automatically
show it as a tty interface. So you can't use it for testing the UART drivers.

BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and
one for USB. So they are also not exchangeable.

Variant b) is IMHO of no practical relevance (but I may be wrong) because it would
mean to add some costly FT232 or PL2302 chip where a different firmware variant works
with direct USB connection.

So to me it looks as if you need to develop different low-level drivers anyways.

BR,
Nikolaus