> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
