On Sun, Jul 22, 2018 at 12:12 PM Andreas Färber <afaerber@xxxxxxx> wrote: > > Hi Rob et al., > > I'm looking at a board with a SPI-UART bridge SC16IS752 (sc16is7xx.c). > The driver exposes two serial ports ttySC0 and ttySC1 from one SPI slave > node, i.e. they have the same dev and thus of_node. > > Am I seeing correctly that serdev currently assumes a 1:1 mapping > between DT node and serial port and can't deal with 1:n yet? Correct. And the binding too. > In particular core.c of_serdev_register_devices() seems to iterate over > all child nodes, checking only for a compatible string but not for a reg > property. I was considering to implement such a check, but it seems the > tty_port that has the line field to distinguish them is abstracted away > into the serdev-ttyport.c implementation, with no clean access from > core.c where all that magic happens. Backwards compatibility with > existing nodes without reg property is another concern. > > Similarly core.c serdev_controller_remove() iterates over all child > devices and in serdev_remove_device() only checks for dev->type before > attemping to remove them. > > Any suggestions what to do here? I think the problem exists in the sc16is7xx binding regardless of serdev. For example, how would you set flow-control or baudrate properties per channel or set stdout-path to one of the channels? So I think it really should have 2 child nodes for each UART channel. This is how other (parallel bus) DUART chip bindings were done. Then you are back to a single slave child per UART and your serdev problem is solved. I think you should be able to extend the binding in a compatible way were you inherit clocks, irq, etc. from the parent node. Another question is whether the driver could use the 8250 driver instead of re-implementing the whole thing. I think the main thing would be having serial_in/serial_out functions using regmap. Rob -- 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
