On 02.03.2018 14:13, Heikki Krogerus wrote: > Hi, > > On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote: >> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed >> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. >> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. >> + >> +ccic: s2mm005@33 { >> + ... >> + usb_con: connector { >> + compatible = "usb-c-connector"; >> + label = "USB-C"; > Is this child node really necessary? There will never be more then > one connector per CC line. But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1]. [1]: http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery > > We should prefer device_graph* functions over of_graph* and I guess you mean fwnode_graph* functions. > acpi_graph* functions in the drivers so we don't have to handle the > same thing multiple times with separate APIs. Is it still possible if > there is that connector child node? Bindings proposed here are OF bindings, I suppose the most important is to follow OF specification and guidelines and these bindings tries to follow it. It looks like it should not be a problem for fwnode framework to handle such bindings, but it is just my guess. I have not seen any fwnode* specification I am not sure what is the real purpose of this framework, but it seems to be just in-kernel abstraction for different firmware standards (OF, ACPI), so even if it lacks at the moment some functionality it should not be a barrier for OF bindings. Regards Andrzej > >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@0 { >> + reg = <0>; >> + usb_con_hs: endpoint { >> + remote-endpoint = <&max77865_usbc_hs>; >> + }; >> + }; >> + port@1 { >> + reg = <1>; >> + usb_con_ss: endpoint { >> + remote-endpoint = <&usbdrd_phy_ss>; >> + }; >> + }; >> + port@2 { >> + reg = <2>; >> + usb_con_sbu: endpoint { >> + remote-endpoint = <&dp_aux>; >> + }; >> + }; >> + }; >> + }; >> +}; > > Thanks, > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel