Hi Hans, On Mon, Jan 28, 2019 at 11:44:29AM +0100, Hans de Goede wrote: > Hi, > > On 28-01-19 10:45, Andy Shevchenko wrote: > > On Fri, Jan 25, 2019 at 3:17 PM Heikki Krogerus > > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > > > > > > Driver for fusb302 does not support alternate modes, so the > > > connection is not really needed for now. Removing that > > > connection description allows us to improve the USB Type-C > > > mux API. > > > > > > > Acked-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > > supposed to go via USB tree. > > I missed the original posting of this, so let me reply here: > > Nack to this change, I've a patch-set in the works to > make display-port over type-c work with 2 devices with a fusb302 > mux and that needs this connection. I can add the connections back in this series after the API modification patches, but should the connections be added back only after we actually support the alt mode in the driver? Btw. I'm preparing patches where I remove struct tcpc_config completely. We can do that by taking advantage of the software fwnodes (I'll send the patches RFC to give you an idea what I'm talking about). That's related as we don't need struct tcpc_config for anything else except for alternate modes (which no driver supports currently) after that series, and even with the alt modes, it's only a question of supplying DT bindings that define the appropriate device properties. Also, as a "heads-up": As I explained in the cover-letter, my plan is to take advantage of the software fwnodes also with the connections. By adding support for reference handling to the software nodes, we don't need to maintain the list of connections as we do today. And more importantly, we don't need to match using device names, which is always fragile. That means we will change the connection registration, actually, remove connection registration :-). The connections after that can always be described in the fwnode for the device. thanks, -- heikki
