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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Dec 05, 2012 at 07:07:52AM +0000, Zheng, Lv wrote:
> > 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.

OK.

> 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.

Yeah, I wasn't expecting that this series addresses that :-) However, this
is something we need to solve at some point - we probably don't want that
userspace deals with the GPIOs.