> > > 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... Is it a good idea to introduce uart_device driver in the kernel to fill a new 'ldisc' member in the uart_device or to load ldisc by default for the corresponding tty_port? One more important thing I should mention is about a design decision for this patch set. My current implementation is for the uart tty devices. Shall we change the uart_bus to the tty_bus, then introduce tty_host / tty_target for the bus? In the Linux world, tty is the only language that the "tty physical devices" will use to talk to each other, thus it make sense to have a tty_bus and enable PM ops for the physical devices on the bus. If we do so, the tty_host or tty_port can be the functional devices on top of the host side physical tty devices (ex. platform device / pcmcia device), and the tty_target can be used instead of the uart_device. We could leave tty_host unimplemented in the first step as there is already a tty_port abstraction. > > 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). When this is ready, someone knowing ACPI GPIO better than me (Heikki or Mathias included) can add additional features on top of this. Best regards/Lv Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
