Re: [RFC PATCH 1/3] UART: Add UART subsystem as a bus.

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> > The property should not be in any ACPI specific form or space - just
> > attach it directly to the tty from ACPI, DT, driver internal knowledge,
> > PCI id, whatever
> 
> The only property that comes into mind is _HID/_CID (referring to the ACPI
> ID) that can be used by userspace to find out type of the device behind the
> UART port. I don't know what name would be generic enough for the property,
> though.

We just need a set of type names for the sysfs node I think
"bluetooth", "ups", "loconet", "serial", "modem", "cir" etc...

> There are other resources as well in addition to the UartSerialBus(). For
> example we might have two GPIO lines connected to the bluetooth chip and
> these are represented as GpioIo ACPI resources.

There was some planning on this some time ago. I think we know how to
deal with GPIOs

> Since the bluetooth is mostly handled by the N_HCI line discipline, should
> the GPIO handling be done there as well? It can distinguish between DT and
> ACPI enumerated devices by comparing dev->of_node and ACPI_HANDLE(dev) so
> it can get the resources from both DT and ACPI but I'm not sure if it
> really belongs there. Or should this be in a separate driver?

The plan was that the tty device would know its gpio lines and also
support a gpio structure giving mappings for extra control lines. It
seems we want that both visible to kernel (N_HCI etc) and visible to user
space (userspace custom handling using the gpio userspace interfaces).

Alan