Hi,

On Mon, Aug 22, 2016 at 11:23:26PM +0200, H. Nikolaus Schaller wrote:

quoted

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.

quoted

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

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.

No. I mean I have some serial device, which is connected to the
embedded UART, but I also have a standalone version. For driver
development I can just use my standalone serial device, connect
it to an USB-UART and develop the driver on non embedded HW.
Then I can use the same driver on my embedded platform and it
works, since it uses the same API.

For e.g. I2C this works perfectly fine. I already did this with
the I2C interface exposed on my notebook's VGA port.

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.

Yes, let's ignore option c). I'm talking about UART only. If the
chip has native USB support, then that's a different driver. Note,
that for more complex drivers it may become possible to use the same
high-level driver via regmap at some point. Not sure if this kind of
HW exists, though.

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.

Well for some chips there is not native USB support. But my scenario
was about development. Let's say I have a serial-chip and I want to
develop a driver for it. It would be nice if I can develop the
driver with a USB-UART and then use it on my embedded system.

There are usb-serial devices, which could benefit from support
btw. I would find it really useful, if the Dangerous Prototype's
Bus Pirate would expose native /dev/i2c and /dev/spi and it's
based on FT232.

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

No. You say, that option b) is irrelevant and assume, that every
serial chip also has native USB support.

-- Sebastian