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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > 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-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux