Thread (11 messages) 11 messages, 4 authors, 2022-08-30

Re: [PATCH v2 3/4] usb: typec: mux: add typec orientation switch support via mux controller

From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date: 2022-08-24 14:39:22
Also in: linux-devicetree, linux-usb

Hi,

On Wed, Aug 24, 2022 at 03:54:28AM +0800, Xu Yang wrote:
Some dedicated mux block can use existing mux controller as a mux
provider, typec port as a consumer to select channel for orientation
switch, this can be an alternate way to control typec orientation switch.
Also, one mux controller could cover highspeed, superspeed and sideband
use case one time in this implementation.

Reported-by: kernel test robot <redacted>
Drop that Reported-by tag.
quoted hunk ↗ jump to hunk
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes since v1:
- add build dependence (select MULTIPLEXER)
- improve Multiplexer control logic

 drivers/usb/typec/Kconfig     |  1 +
 drivers/usb/typec/mux.c       | 76 ++++++++++++++++++++++++++++++++++-
 include/linux/usb/typec_mux.h |  7 +---
 3 files changed, 78 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 5defdfead653..73d4976d8148 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -2,6 +2,7 @@
 
 menuconfig TYPEC
 	tristate "USB Type-C Support"
+	select MULTIPLEXER
Whoa, do not tie TYPEC to another subsystem like that! You probable
want to make your driver depend on that instead.
quoted hunk ↗ jump to hunk
 	help
 	  USB Type-C Specification defines a cable and connector for USB where
 	  only one type of plug is supported on both ends, i.e. there will not
diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
index 464330776cd6..05e6ed217620 100644
--- a/drivers/usb/typec/mux.c
+++ b/drivers/usb/typec/mux.c
@@ -13,6 +13,7 @@
 #include <linux/mutex.h>
 #include <linux/property.h>
 #include <linux/slab.h>
+#include <linux/mux/consumer.h>
 
 #include "class.h"
 #include "mux.h"
@@ -22,6 +23,11 @@
 struct typec_switch {
 	struct typec_switch_dev *sw_devs[TYPEC_MUX_MAX_DEVS];
 	unsigned int num_sw_devs;
+
+	/* Could handle HighSpeed, SuperSpeed, Sideband switch one time */
+	struct mux_control *mux_switch;
That does not belong here...
quoted hunk ↗ jump to hunk
+	/* 3 state correspond to NONE, NORMAL, REVERSE for all switches */
+	int mux_states[3];
 };
 
 static int switch_fwnode_match(struct device *dev, const void *fwnode)
@@ -117,6 +123,58 @@ struct typec_switch *fwnode_typec_switch_get(struct fwnode_handle *fwnode)
 }
 EXPORT_SYMBOL_GPL(fwnode_typec_switch_get);
 
+static struct typec_switch *mux_control_typec_switch_get(struct device *dev)
+{
+	struct typec_switch *sw;
+	struct mux_control *mux;
+	int ret;
+
+	if (!device_property_present(dev, "mux-controls"))
+		return NULL;
+
+	sw = kzalloc(sizeof(*sw), GFP_KERNEL);
+	if (!sw)
+		return ERR_PTR(-ENOMEM);
+
+	mux = mux_control_get(dev, NULL);
+	if (!IS_ERR(mux)) {
+		sw->mux_switch = mux;
+		ret = device_property_read_u32_array(dev,
+			"typec-switch-states", sw->mux_states, 3);
+		if (ret) {
+			kfree(sw);
+			return ERR_PTR(ret);
+		}
+	} else {
+		kfree(sw);
+		return ERR_CAST(mux);
+	}
+
+	return sw;
+}
That code is broken - you return a switch that has never been
registered - but never mind that...

You need to register the switch from the place/driver that actually
handles the orientation. If you really think that you have to have a
generic multiplexer class wrapper layer for these switches, then you
need to propose a multiplexer class wrapper driver for that. Though,
I'm not sure you need that.

There is a GPIO driver proposal for these switches, so can you take a
look if that covers your case as well:
https://lore.kernel.org/linux-usb/20220810204750.3672362-3-bjorn.andersson@linaro.org/#t (local)

In any case, you can't mix that code into the device class code itself
like you do above. That kind of coupling is always going to be fragile
(as we can see above), but more importantly, it forces the dependency
on every Type-C driver, and that is completely wrong.

So please keep the subsystems themselves independent of each other and
handle things in the device drivers.

thanks,

-- 
heikki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help