Am 23.07.2018 um 18:36 schrieb Rob Herring: > 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. Sounds sensible. > This > is how other (parallel bus) DUART chip bindings were done. I have looked through all bindings in serial/ and there is no such dual-node binding, nor is there any parallel/. Can you point to any concrete example where that is being 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. That sounds out of scope for me. :) Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- 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
