On Thu, Dec 06, 2012 at 07:36:35AM +0000, Zheng, Lv wrote: > > > > 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... > > Hi, Mika > > How is this handled in the i2c? We match the I2C device to the driver using _HID/_CID in the kernel. There is no userpace involved (except maybe loading the correct driver module). > I think for OF, type can be filled as "bluetooth", "ups" and etc. > But for ACPI, the type field of the i2c_board_info is filled as hid in your patches. > Is this right? Yes. > Maybe I just need to add struct acpi_dev_node to the uart_board_info and > let OF guys add of_node to it. What's your opinion? Well, in order to use any ACPI functions and PM you need to have ACPI_HANDLE(dev) != NULL. If the best place to pass that handle is uart_board_info (in analogy to i2c_board_info), then yes you should add it there. -- 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
