Re: [PATCH] usb: typec: mux: Fix typec_switch_match()

Marek Vasut <[email protected]>
Newsgroups org.kernel.vger.linux-usb,org.kernel.vger.linux-kernel,org.kernel.vger.stable
Message-ID <[email protected]>
On 8/18/26 6:24 PM, Sebastian Reichel wrote:

Hello Sebastian,

> On Mon, Aug 17, 2026 at 08:22:39PM +0200, Marek Vasut wrote:
>> The fwnode_typec_switch_get() sporadically returns NULL instead of an
>> -EPROBE_DEFER for orientation-switch described in DT. This makes it
>> impossible to discern whether the DT does describe an orientation-switch
>> which did not probe yet, or whether the DT does not describe the switch.
>> This happens with gpio-sbu-mux connected to an I2C GPIO expander.
>>
>> The class_find_device() on typec_switch_match() may return NULL in case
>> the mux did not probe just yet early on boot. The sw_devs[] array can be
>> empty on boot as well. If these two conditions occur, then the conditional
>> if (to_typec_switch_dev(dev) == sw_devs[i]) evaluates to true and the match
>> function returns NULL, which propagates to fwnode_typec_switch_get() which
>> makes it look as if the orientation-switch was not described in DT.
>>
>> This is incorrect, because the mux driver will probe a bit later on, but
>> at that point, the caller of fwnode_typec_switch_get() already got the
>> NULL return value. The NULL return value also does not trigger IS_ERR(),
>> therefore the caller driver interprets this as if the orientation-switch
>> is not described in DT, and does not return -EPROBE_DEFER to try again,
>> even if it should.
>>
>> Fix this by checking the class_find_device() return value, and return
>> -EPROBE_DEFER if it is NULL right away. If the return value is not NULL,
>> perform the deduplication test, and if that test passes, consider the
>> return value to be already non-NULL.
>>
>> Fixes: a53b4f9c51a9 ("usb: typec: mux: avoid duplicated orientation switches")
>> Cc: [email protected]
>> Signed-off-by: Marek Vasut <[email protected]>
>> ---
>>
>> Cc: Greg Kroah-Hartman <[email protected]>
>> Cc: Heikki Krogerus <[email protected]>
>> Cc: Jens Glathe <[email protected]>
>> Cc: Sebastian Reichel <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> ---
>> NOTE: A similar change was reverted in
>>        f576c75f95a5 ("Revert "usb: typec: mux: avoid duplicated mux switches"")
>>        Maybe the orientation switch commit also needs a revert ?
>>        Or the mux switch revert can be undone and fixed using this NULL check ?
>> ---
> 
> This revert negatively affects Rockchip once my USB-C rework for
> USB-DP lands and I undid it locally. I've just not yet found the
> time to investigate why it regresses the X1E platform to reintroduce
> the feature. Maybe you found the root cause and fix already, but
> investigating with my T14s Gen6 Snapdragon is on my TODO list.
> 
> FWIW this patch is
> 
> Reviewed-by: Sebastian Reichel <[email protected]>
Could you revert f576c75f95a5 ("Revert "usb: typec: mux: avoid 
duplicated mux switches"") and apply the following patch (equivalent to 
this patch, applies to mux instead of switch) and see if that fixes the 
T14s for you too then ? If yes, than, I think this might be the proper 
fix rather than the revert:

diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
index 4a4297f15aad3..afa6fc1813978 100644
--- a/drivers/usb/typec/mux.c
+++ b/drivers/usb/typec/mux.c
@@ -294,6 +294,8 @@ static void *typec_mux_match(const struct 
fwnode_handle *fwnode,

         dev = class_find_device(&typec_mux_class, NULL, fwnode,
                                 mux_fwnode_match);
+       if (!dev)
+               return ERR_PTR(-EPROBE_DEFER);

         /* Skip duplicates */
         for (i = 0; i < TYPEC_MUX_MAX_DEVS; i++)
@@ -303,7 +305,7 @@ static void *typec_mux_match(const struct 
fwnode_handle *fwnode,
                 }


-       return dev ? to_typec_mux_dev(dev) : ERR_PTR(-EPROBE_DEFER);
+       return to_typec_mux_dev(dev);
  }

  /**
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.