> > > > 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? > > > > No but it can provide information to help user space. In many cases > > the decision isn't about a line discipline but about automatically > > setting permissions or linking ports to the right driver. > > > > The hints need to be generic - they can come from open firmware, from > > pci identifiers, from ACPI and so on. > > Userspace need to know more than a simple type name to match the driver. > For example, > Atheros BT will send wrapped HCI packets from their HSU BT adapters, so they > need to see "ath3000" rather than "bluetooth" to load a kernel hci protocol > module for the device. > As we can see, in the i2c/spi world, there is only "type" field filling w/ chip name, > not 2 fields - "type" filled w/ generic type and "id" filled w/ chip name. > Userspace can figure the generic "type" from the un-generic chip name like > "type". > I just wonder will there be issues caused by following this design? Ying has suggested me to include all of the HID/CIDs as a list into board_info. If OF need this feature, I'll split type into a type and an "ID" list. The module_alias file can export all of the IDs and the device name can be the "type:index". I can make the modifications on this if you think this is better. > > > 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. Best regards -Lv -- 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
