> On Mon, Dec 03, 2012 at 11:39:59AM +0800, Lv Zheng wrote:
> > kobject attribute files:
> > # cat /sys/bus/uart/devices/INTF001:00/modalias
> > uart:INTF001:00
> > # cat /sys/bus/uart/devices/INTF001:00/tty_dev
> > ttyS0
> > # cat /sys/bus/uart/devices/INTF001:00/tty_attrs
> > 115200 8N0 HW
> > # cat /sys/bus/uart/devices/INTF001:00/modem_lines
> > LE:RTS,CTS,
>
> What if instead of exporting these to userspace we just set the defaults based
> on the UartSerialBus() value? This way the user only needs to find the right tty
> to pass to hciattach.
>
> > kobject sysfs links:
> > # ls -l /sys/bus/uart/devices
> > INTF001:00 -> ../../../devices/platform/INTF000:00/INTF001:00
> > # ls -l /sys/devices/platform/INTF000:00/INTF001:00
> > subsystem -> ../../../../bus/uart
> > host_node -> ../tty/ttyS0
> > # ls -l /sys/devices/platform/INTF000:00/tty/ttyS0
> > target_node -> ../../INTF001:00
>
> And if we have enumerated the UART controller from ACPI (it is probably
> attached to the platform bus) we can find the tty device it exports like:
>
> /sys/bus/platform/devices/INTF000:00/tty/ttyS1/dev
>
> Only thing that is missing then is the type of the connected device. That can be
> extracted by following the firmware_node symlink:
>
> # ls /sys/bus/platform/devices/INTF000\:00/firmware_node/
> INTF001:00
> ...
>
> # cat
> /sys/bus/platform/devices/INTF000\:00/firmware_node/INTF001:00/hid
> INTF001
>
> This ACPI ID then can be used to find out what device it is.
>
> Well, this is probably not the simplest solution :-) I'm just trying to understand
> why we need to add a new bus type if only thing it adds is the sysfs files.
In our team, we've been discussing this solution like your suggestion for some times.
ACPI UART enumeration can be done in this way without kernel modifications.
IMO:
1. tty_device is current used as "host" side device, you can find .pm support in most of the serial drivers.
They are always the codes turning off/on the clock of the host controller.
If we want to support PM for a target device, there is no such node in the kernel device hierarchy.
2. firmware_node is based on the "likely deprecated" acpi_device solution, I need to find another one. Maybe this is still a shadow device.
Like dmi-id device, a shadow device exporting attributes and generating uevents for the user space drivers may be helpful.
It would be better if the PM support of the target devices can benefit from the existence of the shadow uart target devices.
> > +/**
> > + * uart_unregister_device - unregister a UART device
> > + * @device: value returned from uart_register_device()
> > + *
> > + * Reverse effect of uart_register_device().
> > + */
> > +void uart_unregister_device(struct uart_device *udev) {
> > + if (udev->adap)
> > + klist_del(&udev->klist_parent);
> > + sysfs_remove_link(&udev->dev.kobj, "host_node");
> > + if (udev->tty)
> > + sysfs_remove_link(&udev->tty->kobj, "target_node");
> > + device_unregister(&udev->dev);
> > +}
> > +EXPORT_SYMBOL_GPL(uart_unreigster_device);
>
> Typo in the function name.
Fixed...
Thanks and best regards/Lv Zheng
--
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
