On Thu, Jul 26, 2018 at 10:17 AM Andreas Färber <afaerber@xxxxxxx> wrote: > > 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? Predates documenting bindings... There's an example in Documentation/devicetree/booting-without-of.txt 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
