On Fri, Sep 17, 2021 at 9:59 AM Florian Fainelli [off-list ref] wrote:

On 9/16/21 7:27 PM, Saravana Kannan wrote:

quoted

On Thu, Sep 16, 2021 at 7:21 PM Florian Fainelli [off-list ref] wrote:

quoted

On 9/15/2021 1:19 AM, Saravana Kannan wrote:

quoted

This reverts commit cf4b94c8530d14017fbddae26aad064ddc42edd4.

Some PHYs pointed to by "phy-handle" will never bind to a driver until a
consumer attaches to it. And when the consumer attaches to it, they get
forcefully bound to a generic PHY driver. In such cases, parsing the
phy-handle property and creating a device link will prevent the consumer
from ever probing. We don't want that. So revert support for
"phy-handle" property until we come up with a better mechanism for
binding PHYs to generic drivers before a consumer tries to attach to it.

Signed-off-by: Saravana Kannan <redacted>

Thanks for getting this revert submitted, I just ran a bisection this
afternoon that pointed to this offending commit. It would cause the dead
lock

Dead lock in the kernel? Or do you mean just a hang waiting forever for network?

It locks up since we try to acquire __device_driver_lock() while we are
in the main driver's probe function.

Off the top of my head that sounds weird, but I'll look into the
logs/code later. Bunch of other stuff and some LPC prep comes first :)

quoted

quoted

on boot with drivers/net/dsa/bcm_sf2.c pasted below.

The log is too jumbled up to be readable (word wrap I suppose) and
maybe even multiple thread printing at the same time.

Re-attached (thunderbird is not really helping me).

Thanks!

quoted

quoted

Saravana, can
you CC on me on your fix or what you would want me to be testing?

By fix, I assume you mean when I bring back phy-handle with a proper
fix to handle the case in the commit text? Yeah, that's going to take
a while. It's brewing in my head and there are some issues that's not
fully resolved. But I haven't had time to code it up or dig into the
net code to make sure it'll work. But yes, I'll CC you when I do so
you can test it with this case.

Well by fix, I meant something that does not lock up on my system,

Hold on. Now I'm confused. Are you still hitting hangs/issues after
the phy-handle patch is reverted?

it is
a different problem from supporting 'phy-handle', but it should not
regress an existing system, no matter how quirky that system behaves in
its probe function. For history and reference, the "offending" change
and background can be found here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=771089c2a485958e423f305e974303760167b45c

So that is the change that's interacting with the phy-handle patch to
cause the deadlock?

I'm a bit confused on what needs debugging now.

-Saravana

Thanks for your patience working on the quirky MDIO/PHY subsystem :)

No worries. Thanks for your patience with me accidentally breaking stuff :)

-Saravana