From: Vladimir Oltean <olteanv@gmail.com>
To: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, f.fainelli@gmail.com,
jonas.gorski@gmail.com, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] net: dsa: b53: mmap: register MDIO Mux bus controller
Date: Fri, 17 Mar 2023 15:04:34 +0200 [thread overview]
Message-ID: <20230317130434.7cbzk5gxx5guarcz@skbuf> (raw)
In-Reply-To: <CAKR-sGe3xHkN-1+aLn0ixnskctPK4GTzfXu8O_dkFhHyY1nTeg@mail.gmail.com>
On Fri, Mar 17, 2023 at 01:06:43PM +0100, Álvaro Fernández Rojas wrote:
> Hi Vladimir,
>
> El vie, 17 mar 2023 a las 12:51, Vladimir Oltean (<olteanv@gmail.com>) escribió:
> >
> > On Fri, Mar 17, 2023 at 12:34:26PM +0100, Álvaro Fernández Rojas wrote:
> > > b53 MMAP devices have a MDIO Mux bus controller that must be registered after
> > > properly initializing the switch. If the MDIO Mux controller is registered
> > > from a separate driver and the device has an external switch present, it will
> > > cause a race condition which will hang the device.
> >
> > Could you describe the race in more details? Why does it hang the device?
>
> I didn't perform a full analysis on the problem, but what I think is
> going on is that both b53 switches are probed and both of them fail
> due to the ethernet device not being probed yet.
> At some point, the internal switch is reset and not fully configured
> and the external switch is probed again, but since the internal switch
> isn't ready, the MDIO accesses for the external switch fail due to the
> internal switch not being ready and this hangs the device because the
> access to the external switch is done through the same registers from
> the internal switch.
The proposed solution is too radical for a problem that was not properly
characterized yet, so this patch set has my temporary NACK.
> But maybe Florian or Jonas can give some more details about the issue...
I think you also have the tools necessary to investigate this further.
We need to know what resource belonging to the switch is it that the
MDIO mux needs. Where is the earliest place you can add the call to
b53_mmap_mdiomux_init() such that your board works reliably? Note that
b53_switch_register() indirectly calls b53_setup(). By placing this
function where you have, the entirety of b53_setup() has finished
execution, and we don't know exactly what is it from there that is
needed.
next prev parent reply other threads:[~2023-03-17 13:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 11:34 [PATCH 0/3] net: dsa: b53: mmap: add MDIO Mux bus controller Álvaro Fernández Rojas
2023-03-17 11:34 ` [PATCH 1/3] dt-bindings: net: move bcm6368-mdio-mux bindings to b53 Álvaro Fernández Rojas
2023-03-19 11:35 ` Krzysztof Kozlowski
2023-03-17 11:34 ` [PATCH 2/3] net: dsa: b53: mmap: register MDIO Mux bus controller Álvaro Fernández Rojas
2023-03-17 11:51 ` Vladimir Oltean
2023-03-17 12:06 ` Álvaro Fernández Rojas
2023-03-17 13:04 ` Vladimir Oltean [this message]
2023-03-17 14:17 ` Álvaro Fernández Rojas
2023-03-17 14:29 ` Vladimir Oltean
2023-03-17 16:23 ` Álvaro Fernández Rojas
2023-03-17 16:41 ` Florian Fainelli
2023-03-17 16:44 ` Álvaro Fernández Rojas
2023-03-19 9:45 ` Álvaro Fernández Rojas
2023-03-20 10:27 ` Jonas Gorski
2023-03-20 15:21 ` Álvaro Fernández Rojas
2023-03-17 16:26 ` Andrew Lunn
2023-03-17 16:30 ` Álvaro Fernández Rojas
2023-03-17 16:37 ` Andrew Lunn
2023-03-17 11:34 ` [PATCH 3/3] net: mdio: remove BCM6368 MDIO mux bus driver Álvaro Fernández Rojas
2023-03-19 11:36 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230317130434.7cbzk5gxx5guarcz@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=jonas.gorski@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=noltari@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox