Re: Serdev: USB device and sysdev probing ala i2c

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

 



On Fri, May 25, 2018 at 7:08 AM, Johan Hovold <johan@xxxxxxxxxx> wrote:
> On Thu, May 24, 2018 at 11:49:24AM -0500, Rob Herring wrote:
>> On Thu, May 24, 2018 at 7:18 AM, Ricardo Ribalda Delgado
>> <ricardo.ribalda@xxxxxxxxx> wrote:
>> > Hi Johan,
>> >
>> > On Thu, May 24, 2018 at 2:07 PM Johan Hovold <johan@xxxxxxxxxx> wrote:
>
>> >> Serdev currently only supports device tree and ACPI. Using out-of-tree
>> >> code, you could load a device tree fragment during runtime to describe
>> >> your serial bus (or you just amend the device tree).
>> >
>> >> Using device tree overlays would have the benefit of being able to
>> >> describe associated resources (e.g. reset gpios) which a simple
>> >> compatible string (or equivalent) would not.
>> >
>> >> But there are examples where a simple compatible string would do, for
>> >> example an existing CEC device presenting itself as a generic USB CDC
>> >> device (hopefully with a dedicated VID/PID so that no user-space
>> >> configuration is needed at all).
>
>> The fundamental problem here is you need a parent device node to apply
>> a DT overlay to and a USB device hotplugged has no DT device node. The
>> system you are running on may not even have a DT (like a PC). If you
>> have an overlay of the downstream devices, they have to be a child of
>> something for the overlay to apply to. We could just create virtual
>> device nodes for the purposes of applying overlays to. Another option
>> would be allowing multiple DTs. Then you aren't even using overlays
>> (what's the point of an overlay when a system has no real DT to begin
>> with). That also would mean they are completely independent from any
>> real DT or other instances (you may want to plug in multiple of the
>> same device).
>
> Right, there's more (than just a DT overlay loader) that needs to be in
> place before this could be used for the generic hotplug case (and even
> more than that if this was to be usable for ACPI systems).
>
> I think generating DT nodes during enumeration is preferable to having
> detached trees, if only to deal with the case where a loaded overlay do
> overlap with the "real" static tree.

Generating nodes effectively means we're implementing the full USB
tree as defined for OpenFirmware[1]. I'd prefer to not go there. That
seems a bit pointless as for most of the devices we don't care and
there's really nothing related to USB we care about. We just need to
describe downstream functions. The USB device (or interface) just
happens to be the controller/provider for those functions.

There should only be overlap with a real tree if devices are soldered
onto a board or use a custom connector and you have other sideband
signals.

>
> Another problem is that we need to deregister any tty device and
> essentially reprobe the underlying serial controller whenever user space
> tells us what can be found on the other end of wire in order to register
> a serdev controller and device instead. IIRC this is something we would
> get for free if using DT overlays (i.e. any device with a modified DT
> node would get removed and readded, or at least notified that something
> changed).

I did some experiments in this area. Marcel wanted to make all BT
drivers serdev only and then make the BT ldisc just create serdev
devices. And all this would be transparent to existing BT userspace.
As part of this I modified registration to register both serdev ctrlr
and tty char device and allow adding slave devices later. It's up on
my serdev-ldisc-v2 branch in all its hacky glory.

I don't think we get anything for free with overlays. I think we only
handle platform devices and only new nodes added. There are notifiers
for modifications, but if no one is listening modifications won't have
any effect.

Rob


[1] https://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux