Re: [PATCH] Revert "tcpm: allow looking for role_sw device in the main node"

[Arnaud Ferraris]

Hi Xu,

Le 05/03/2026 à 10:40, Xu Yang a écrit :
> On Fri, Feb 27, 2026 at 04:45:30PM +0100, Arnaud Ferraris wrote:
> > Hi Xu,
> >
> > Le 25/02/2026 à 03:57, Xu Yang a écrit :
> > > Hi Arnaud,
> > >
> > > On Tue, Feb 24, 2026 at 12:33:33PM +0100, Arnaud Ferraris wrote:
> > > > Hi,
> > > >
> > > > Le 24/02/2026 à 12:01, Xu Yang a écrit :
> > > > > This reverts commit 1366cd228b0c67b60a2c0c26ef37fe9f7cfedb7f.
> > > >
> > > > I believe a plain revert isn't the right solution here, as we'll get to the
> > > > same point as we were before 1366cd228b0c, where some devices stopped
> > > > working properly with newer kernels.
> > >
> > > I don't think 1366cd228b0c fix the real root problem because the description
> > > should be wrong in the commit message. If -EPROBE_DEFER is returned by
> > > fwnode_usb_role_switch_get(), the ports node should be in connector node
> > > instead of tcpc node. However, you get the error when ports in tcpc node.
> > >
> > > Could you double check the issue, so we can find a proper solution and avoid
> > > the further regression?
> >
> > Sure, I'll come up with more details asap, either tomorrow or early next
> > week.
>
> Do you have any updates about this?

I do, sorry it took so long...

So fwnode_usb_role_switch_get() does indeed return -EPROBE_DEFER, then
keeps doing so on later attempts if I revert my patch. However,
usb_role_switch_get() succeeds on first try.

Please note that:
1. I don't understand much (if any) of the Linux typec stack, and only
   noticed 2d8713f807 broke my device, hence my attempted fix
2. said device is the PinePhone Pro, using an out-of-tree dts (and many
   drivers) from https://codeberg.org/megi/linux

The proper solution likely lies somewhere in the "get proper drivers
and upstream dts for this device" land, although I definitely can't
commit to this.

I think saving the fwnode_usb_role_switch_get() return value and
restoring it if usb_role_switch_get() fails would be a decent
workaround, although I'm definitely open to suggestions.

Feel free to let me know if there's any other test I could run, I'll do
my best at replying promptly.

Best regards,
Arnaud

> Thanks,
> Xu Yang