Re: Serdev: USB device and sysdev probing ala i2c

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

 



Hi Johan,

On Thu, May 24, 2018 at 2:07 PM Johan Hovold <johan@xxxxxxxxxx> wrote:

> Hi Ricardo,

> On Wed, May 23, 2018 at 11:17:20AM +0200, Ricardo Ribalda Delgado wrote:
> > Hi
> >
> > I have a flash controller connected to the main computer via a usb to
> > serial. My plan is to expose it to the system as a video4linux
subdevice.
> >
> > With the inclusion of serdev I was expecting that it would be as easy as
> > adding a i2c device, but seems that there are some functionality that
it is
> > still not implemented:
> >
> > 1) Serdev for usb serial devices.

> Right, I didn't want to enable serdev for USB serial before we have
> determined how to handle hotplugging (e.g. in serdev core or by making
> sure every serdev driver can handle devices going away at any time) in
> order to avoid having things crash left and right.

> I have out-of-tree code for USB serial that I use for testing purposes,
> so it's mostly a matter of finding the time to think this through.

Could you share those patches? I would love to test them.
In my setup the system does not support hotplugg and/or power saving.


> > 2) Instatiating via sysfs. Something like
> > echo hci_nokia > /sys/bus/serio/devices/serio0/new_device
> > (inspired in: echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device)

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

What about platform devices? Can it be instatiated like that?


> > 3) Support for probing: Like hwmon for i2c

> What would you probe for (since there is no generic protocol for serial
> devices)?


Just write to the device and expect something in return. I know it can be
dangerous in most cases, but hey, this is how the modems are detected in
userspace and works fine :).


> > -Are these two things in the drawing board?
> > -if not, would it be something worth considering/reviewing for
> > upstream?

> So the first two points have been given some thought and is something
> we'd want to have eventually, while the third point has mostly been
> rejected (I think).

I did not expect the last point to be enabled by default, but it could be
useful for some platforms if you know that your serial devices are tolerant
to some "noise"


Thanks!


> Johan



-- 
Ricardo Ribalda
--
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