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