On Thu, May 24, 2018 at 02:18:57PM +0200, Ricardo Ribalda Delgado wrote: > 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. My serdev patches for USB serial amounts to adding device tree support to USB serial and relying on the device tree support already in serdev. So this will probably be of limited use to you who seems to be on an ACPI system. I've pushed a branch here nonetheless: https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-serial-of in case anyone is interested. USB serial device tree support is strictly separate from serdev so I should probably finish that bit up without the final step to enable serdev. I'll post the patches as an RFC as well, for Rob and others to comment on. Note that this has been a low-intensity on-going effort where most prerequisites are already upstream including USB device tree support (4.15), device-tree node sharing (4.13), musb device-node propagation (linux-next) and various fixes along the way (driver core, usb core, musb). But again, serdev does not support hotplugging and specifically tty hangups so you'll get some warnings if you disconnect a device when the various open counts fails to add up as the port is shut down twice (hangup + serdev close). > > > 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? Not sure I understand what you are after here. > > > 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 :). Yeah, IIRC there's a long-standing open bug against those user space daemons (ModemManager?) which try to mess with random ports that way. I really don't think this is something we want to have in the kernel either way. 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
