On Thu, Apr 20, 2017 at 12:52:50PM -0500, Rob Herring wrote: > On Tue, Apr 11, 2017 at 12:07 PM, Johan Hovold <johan@xxxxxxxxxx> wrote: > > Add a new interface for registering a serdev controller and clients, and > > a helper function to deregister serdev devices (or a tty device) that > > were previously registered using the new interface. > > > > Once every driver currently using the tty_port_register_device() helpers > > have been vetted and converted to use the new serdev registration > > interface (at least for deregistration), we can move serdev registration > > to the current helpers and get rid of the serdev-specific functions. > > I don't really think this is necessary. While in theory any tty port > can work with serdev, the reality is it only ever going to be used > with a few. There's about 31 possible drivers. Of those, there's a > fair number that an attached device is not going to make sense (e.g. > ISDN CAPI, rfcomm?, goldfish, etc.). Second, right now serdev only > works with DT binding. There are only 3 drivers supporting DT: > serial_core, goldfish, and ehv_bytechan. There are also about ten PCI-based drivers (e.g. rocket.c), which, if I'm not mistaken, could have an associated DT-node already today. And so could the SPI-based ifx6x60 driver (modem). > Likely drivers I'm aware of to use serdev in addition to serial_core > are USB serial and greybus. But for those, we currently only could > support them if the whole bus topology is described in DT. Otherwise, > we first have to figure out how to apply DT overlays to arbitrary > devices not described in DT. There's also cdc-acm and possibly fw-serial (in staging). And while our current USB device-tree implementation is limited to describing USB devices, extending this to interfaces, which our USB drivers bind to, should be easily done (I'm looking into it now). There's also a comment in serdev about adding support for "ACPI and platform" descriptions, and you mentioned being able to switch between cdev and serdev as a possible future extension. The point is that serdev currently hooks into the tty layer through a generic function, and if and how a client can be described is just an implementation detail. Rather than using such a large hammer, it seems to me that enabling serdev on a per-driver basis after making sure that nothing breaks (e.g. resources are released on deregistration) is preferred. > OTOH, we are at least explicit with what tty ports support serdev. That would be another benefit. 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
