> On Tue, Dec 04, 2012 at 07:50:30PM +0000, Alan Cox wrote: > > > And if we have enumerated the UART controller from ACPI (it is > > > probably attached to the platform bus) we can find the tty device it > > > exports like: > > > > 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. > > 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. > > 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? IMO, For ACPI enumerated target devices, ACPI can provide GPIO enumeration API by feeding ACPI_HANDLE(tty->target) to obtain the GPIO resources while OF can offer its own implementation. Then there are 2 possible solutions can be found by calling such APIs: 1. implement GPIO enabling in the kernel side N_HCI proto driver. 2. implement GPIO enabling in the kernel side UART driver on TIOCSETD. Same issues can be found for the ACPI enumerated SPI/I2C target devices. Thus the GpioIrq and GpioIo is not handled in this patch set. 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
