From: Andrew Lunn <andrew@lunn.ch>
To: Andreas Svensson <andreas.svensson@axis.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
kernel@axis.com, Baruch Siach <baruch@tkos.co.il>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset deactivation
Date: Tue, 30 May 2023 19:28:19 +0200 [thread overview]
Message-ID: <be44dfe3-b4cb-4fd5-b4bd-23eec4bd401c@lunn.ch> (raw)
In-Reply-To: <20230530145223.1223993-1-andreas.svensson@axis.com>
On Tue, May 30, 2023 at 04:52:23PM +0200, Andreas Svensson wrote:
> A switch held in reset by default needs to wait longer until we can
> reliably detect it.
>
> An issue was observed when testing on the Marvell 88E6393X (Link Street).
> The driver failed to detect the switch on some upstarts. Increasing the
> wait time after reset deactivation solves this issue.
>
> The updated wait time is now also the same as the wait time in the
> mv88e6xxx_hardware_reset function.
Do you have an EEPROM attached and content in it?
It is not necessarily the reset itself which is the problem, but how
long it takes after the reset to read the contents of the
EEPROM. While it is doing that, is does not respond on the MDIO
bus. Which is why mv88e6xxx_hardware_reset() polls for that to
complete.
I know there are some users who want the switch to boot as fast as
possible, and don't really want the additional 9ms delay. But this is
also a legitimate change. I'm just wondering if we need to consider a
DT property here for those with EEPROM content. Or, if there is an
interrupt line, wait for the EEPROM complete interrupt. We just have
tricky chicken and egg problems. At this point in time, we don't
actually know if the devices exists or not.
Andrew
next prev parent reply other threads:[~2023-05-30 17:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 14:52 Andreas Svensson
2023-05-30 17:28 ` Andrew Lunn [this message]
2023-06-01 9:10 ` Andreas Svensson
2023-06-01 10:32 ` Paolo Abeni
2023-06-01 12:01 ` Andrew Lunn
2023-06-01 13:42 ` Paolo Abeni
2023-06-01 14:30 ` patchwork-bot+netdevbpf
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=be44dfe3-b4cb-4fd5-b4bd-23eec4bd401c@lunn.ch \
--to=andrew@lunn.ch \
--cc=andreas.svensson@axis.com \
--cc=baruch@tkos.co.il \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kernel@axis.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/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
all inboxes | Powered by JetHome®