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 10:17:20AM -0500, Rob Herring wrote:
> 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.

Right, we may not want to do it, but having too many mechanisms for
doing the same thing can get messy (but so are overlays to begin with, I
guess).

What we have today (and with the USB serial device tree patches) gets us
a long way by covering static setups. And before supporting the generic
hotplug case with sideband signals (where the descriptive power of
device-tree overlays would be handy) it may be better to focus on the
subset where just a compatible string (or equivalent) would do.

The USB CEC device I mentioned above would be a good example; and an
always-on or DTR/RTS power-controlled GPS could be another.

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

Yeah, I remember you mentioning something about that, but I never dared
to look at the code. ;)

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

Ok, then using DT overlays sounds like too much work for too little gain
in any case. The only use case that comes to mind for hotplug + sideband
would be to allow people to tinker with evaluation kits (e.g. for a new
GPS) on a PC, but they would probably be better off using an embedded
system such as the BBB anyway.

Johan
--
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