From: Christian Marangi <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Robert Marko <robimarko@gmail.com>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next RFC PATCH 0/2] net: phy: aquantia: fix system interface provision
Date: Tue, 13 Feb 2024 22:03:05 +0100 [thread overview]
Message-ID: <65cbd90d.050a0220.7cc10.ef02@mx.google.com> (raw)
In-Reply-To: <a71e473e-bb92-4769-9f52-53de63f6a4ae@lunn.ch>
On Tue, Feb 13, 2024 at 09:58:59PM +0100, Andrew Lunn wrote:
> > > So in effect, the driver needs to write every single register it
> > > depends on.
> > >
> >
> > Well if that's the case then this RFC patch is a must. With a
> > misconfigured System Interface configuration, the PHY can't comunicate
> > with the MAC.
> >
> > > > This might be the safest change but again would not give us 100% idea that
> > > > the thing provision by the FW are correct.
> > >
> > > I would say, we have to assume provision is 100% wrong. Write every
> > > single register with the needed value.
> > >
> > > Is the provisioning information available? Can it be read from the
> > > flash? Can it be dumped from firmware we have on disk? Dumping it for
> > > a number of devices could give a list of register values which are
> > > highly suspect, ones that OEMs typically mess with. We could start by
> > > always setting those registers.
> > >
> >
> > We know where they are stored in the FW but it's not documented how the
> > provision values are stored in the FW. (the format, how they are
> > organized...) I can waste some time trying to reverse it and produce a
> > tool to parse them if needed.
>
> It might be worth it. How complex could it be? The obvious format is a
> C45 mmd.reg pair and a value.
>
Working on it. I already confirmed the FW have actually a provision part
and is not empty.
The format looks to be u16 reg 16 value but I need to understand it
better as not everything about provision is in mmd 1e so there must be
some magic values to signal where the section has to be appled.
> > Would love also some comments by Russell about this, there was a patch
> > adding support for WoL where another user was messing with these regs
> > and he was with the idea of being careful with overwriting the provision
> > values.
>
> I expect the SERDES eye configuration is in there somewhere, and we
> should not touch that. That was one of the arguments Aquantia made at
> the time, that needs to be stored somewhere, and is board specific.
>
> But knowing what standard 802.3 registers are commonly changed would
> be useful, and could help track down silly problems like the
> transmitter being disabled by default by provisioning.
>
Yes having a tool to parse them would probably be useful and eventually
even apply fixup in the firmware loading (if we really want)
--
Ansuel
next prev parent reply other threads:[~2024-02-13 21:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-13 18:24 [net-next RFC PATCH 0/2] net: phy: aquantia: fix system interface provision Christian Marangi
2024-02-13 18:24 ` [net-next RFC PATCH 1/2] net: phy: aquantia: setup interface protocols for AQR112 Christian Marangi
2024-02-13 18:24 ` [net-next RFC PATCH 2/2] net: phy: aquantia: add AQR112C and AQR112R PHY ID Christian Marangi
2024-02-13 18:46 ` [net-next RFC PATCH 0/2] net: phy: aquantia: fix system interface provision Andrew Lunn
2024-02-13 18:53 ` Christian Marangi
2024-02-13 20:58 ` Andrew Lunn
2024-02-13 21:03 ` Christian Marangi [this message]
2024-02-16 23:26 ` Christian Marangi
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=65cbd90d.050a0220.7cc10.ef02@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robimarko@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.