On Tue, Oct 10, 2017 at 10:22:19AM +0200, Marcel Holtmann wrote: > > Some of the above are minor nits that can be addressed by a follow-up > > patch indeed, but the handling of nodes with no child devices needs to > > be correct (or you could end up breaking normal serial-port support). > > that sounds good to me as well. Lets get this feature into the ACPI > tree since I am going to push Hans’ patches into bluetooth-next as > soon as he re-submits the missing ID change. That hopefully gives us > then fully serdev support for ACPI and DT when it comes to Broadcom > Bluetooth controllers. But with Hans's work these devices should continue to function using the platform-device hacks until the ACPI patch eventually lands in Linus's tree (via the acpi tree). > Next step is to convert the Intel driver to also use ACPI based serdev > :) > > And for the brave, I think there are Realtek based systems using ACPI > as well. > > What I was wondering the other day is if we need a lsserdev tool or > some integration in lshw to be able to debug what serdev devices and > ID are present. The lsusb and /sys/kernel/debug/usb/devices is just > super powerful and easy when it comes to figuring out what people have > in their system. Maybe /sys/kernel/debug/serdev/devices could be > helpful as well. Just thinking out loud here. Yeah, maybe. Since you'd typically only have small number of serdev devices (say, max 4), using /sys/bus/serial/devices directly should not be too bad meanwhile. Not that much common information we can expose either, at least not in comparison to USB. But I'll keep it mind. :) Johan -- 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
