On Mon, Jul 09, 2018 at 12:03:10PM -0700, Guenter Roeck wrote:

On Thu, Jun 28, 2018 at 02:34:27PM +0300, Heikki Krogerus wrote:

quoted

On Thu, Jun 28, 2018 at 07:51:55PM +0900, Greg Kroah-Hartman wrote:

quoted

On Wed, Jun 27, 2018 at 06:19:48PM +0300, Heikki Krogerus wrote:

quoted

In order for the muxes to be usable with alternate modes,
the alternate mode devices will need also to be able to get
a handle to the muxes on top of the port devices. To make
that possible, the muxes need to be possible to request with
an identifier.

This will change the API so that the mux identifier is given
as a function parameter to typec_mux_get(), and the hard-coded
"typec-mux" is replaced with that value.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
 drivers/usb/typec/class.c     | 2 +-
 drivers/usb/typec/mux.c       | 6 +++---
 include/linux/usb/typec_mux.h | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 2b3eaa969f3b..b860bd3a0acb 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c

@@ -1357,7 +1357,7 @@ struct typec_port *typec_register_port(struct device *parent,
 		goto err_switch;
 	}
 
-	port->mux = typec_mux_get(cap->fwnode ? &port->dev : parent);
+	port->mux = typec_mux_get(parent, "typec-mux");

This changes the first parameter for this call, is that ok?  Doesn't
that change the functionality here?

No, I noticed that cap->fwnode is set after we call that function, so
we always ended up using parent.

This needs to be fixed properly of course, but I choose not to propose
anything in this series. We don't yet use the fwnode handle with the
muxes in any case, as the device connection API does not support
anything else except build-in connections descriptions for now.

Seems to me that would be better handled in a separate patch or patch
series. With this patch, the code ends up always using parent here but
there is still
	port->sw = typec_switch_get(cap->fwnode ? &port->dev : parent);
a couple of lines above. This is at the very least confusing to the
reader.

True. I'll refactor this function a little in a separate patch. But
not right away. I still have one week of vacation.


Thanks,