> A single one is already difficult... And some scenarios need to shield the UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). That bit is already covered and one or two devices support this because they have things like 3 serial ports but one cannot be used if some other feature is enabled. You simply keep a private counter and return -EBUSY in the port->activate() method if needed. That is sufficient to share a UART with the tty layer when you have a contended resource, but not to borrow the UART and re-use the stack which is what is needed in this case. (You can even steal a UART this way by doing a hangup on it and then once it drops out of use taking it over and ensuring the EBUSY behaviour) > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C slave devices > * it potentially could help to better implement IrDA (although that is mostly legacy) > > 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. A current PC class device will usually have bluetooth connected via a UART where both components are on board. The same for GPS (or more accurately location services as it's usually more than just a GPS nowdays). There may also be onboard WWAN modems and other widgets wired this way. In the PC case the power relationship and connectivity is usually described via ACPI and that often means the kernel simply doesn't know how to manage the power states besides telling the modem, GPS. etc to turn itself on and off via normal ACPI power descriptions. Those may well call OpRegion handlers so it's all abstracted nicely and generic, but rather more invisible to the OS than DT describing pmic and/or gpio setings for the device. Todays low end Intel x86 PC has multiple DMA accelerated low power 16x50 compatible UARTS on die along with multiple channels of I2C and SPI. Things like Android and PC tablet devices with sensors have pretty much converged the old divide between a desktop/laptop/tablet PC and an 'embedded' board. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
