Hi, Alan and Lv, On Thu, 2012-12-06 at 22:41 -0700, Zheng, Lv wrote: [snip] > > > > Shall we change the uart_bus to the tty_bus, then introduce tty_host > > > > / > > > tty_target for the bus? > > > > > > We have a tty class - is that not sufficient ? > > > > As I mentioned in the previous mail, I'll keep the current naming rule until I see > > some objections strong enough. > > This statement is confusing in English, let me clarify this. > If the reasons for the uart_bus in the previous email are not correct, I'll change everything named as uart_xxx to tty_xxx, then the tty_bus is probably not needed, and I can use tty class after the decision. If my understanding were correct, the point is not about name it as uart_bus or tty_bus, but why do we need a bus instead of just use tty class for that. If we use tty class to export tty target device information, it can be something as follow: $ cd /sys/devices/platform/serial8250/tty/ttyS0 $ ls slave_type slave_id slave_compat_ids slave_attr modem_lines If we use uart or tty bus to export tty target device information, it can be something as follow: $ cd /sys/devices/platform/serial8250/bluetooth:00 $ ls type id compt_ids attr modem_lines ... $ cd /sys/bus/(uart|tty)/devices $ ls bluetooth:00 Both works. But IMHO, the second one appears more natural and consistent, just like other hardware devices in system. And create struct device for each target devices make it easier to do power management etc, for example, user can enable/disable runtime power management via bluetooth:00/power/control, just like other hardware devices. Best Regards, Huang Ying -- 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
