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 notdiff --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