From: Dimitri Fedrau <dima.fedrau@gmail.com>
To: Stefan Eichenberger <eichest@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
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>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: phy: marvell-88q2xxx: add driver for the Marvell 88Q2220 PHY
Date: Tue, 19 Dec 2023 09:11:17 +0100 [thread overview]
Message-ID: <20231219081117.GA3479@debian> (raw)
In-Reply-To: <ZYAqxPZHICtZO15O@eichest-laptop>
Am Mon, Dec 18, 2023 at 12:19:32PM +0100 schrieb Stefan Eichenberger:
> Hi Dimitri,
>
> On Mon, Dec 18, 2023 at 10:09:32AM +0100, Dimitri Fedrau wrote:
> > Am Sun, Dec 17, 2023 at 02:50:49PM +0100 schrieb Stefan Eichenberger:
> > > I also tried to make the 88Q2221 work but didn't find the time yet to
> > > write a clean version yet. My last minimal patch looks as attached
> > > bellow.
> > >
> > I probably will also get a 88Q2221 PHY, but it could take some time.
> > When looking at the reference code the only difference for the 88Q2220
> > and 88Q2221 seems to be an additional init sequence with 28 register writes.
> > Remaining code seems to be identical. Am I right ? If yes we can use the
> > same code base here. Besides that it seems that both PHYs share the same
> > PHY id and are only distinguished by the "Secondary ID Register".
>
> I think the init sequence is the same for both PHYs. At least they share
> the same reference manual and the API User Guide.
>
I could add the init sequence for the 88Q2221 PHY. Then you could test
it on your side. Would this be helpful to you ? Did you already have the
chance to test the patch ?
> > > I think the main thing to make the PHY work is to call this
> > > sequence to set the master/slave detection threshold:
> > >
> > > /* Set detection threshold slave master */
> > > phy_write_mmd(phydev, MDIO_MMD_AN, 0x8032, 0x2020);
> > > phy_write_mmd(phydev, MDIO_MMD_AN, 0x8031, 0x0a28);
> > > phy_write_mmd(phydev, MDIO_MMD_AN, 0x8031, 0x0c28);
> > >
> > > Without this sequence the PHY does not work. I was also wondering as
> > > Andrew wrote why we write twice to the same register. My assumption is
> > > that 0x8032 is some kind of selector for a subregister while 0x8031 will
> > > set a 32 bit value. Unforunately, I also didn't get that information
> > > from Marvell and it is just a wild guess. Please also note that calling
> > > the sequence in the probe function (as I do it in the example below) is
> > > definitely wrong, it was just a quick and dirty test I did because I
> > > wanted to know if it is enough to call it only once.
> > >
> > You are maybe right about your guess. Without the init sequence at all I
> > was able to get the PHY work with a fixed setting (100Mbit/Master).
> > Maybe it was due to bootstrapping the pins of the PHY. But still I'm not
> > getting the point. What are we going to do ? Do we want to strip down or
> > generalize the init sequence ? There is probably a reason for such an
> > annoying large undocumented series of register writes.
>
> The documentation is really annoying, I agree. I would propose to try to
> keep the driver as minimal as possible. If we see that something is not
> working, we can still add it later on. Maybe this helps to get a better
> understanding of what the registers do. Further, they always do a full
> initialization when they switch e.g. from 100MBit/s to 1GBit/s. This
> definitely seems to be unnecessary.
>
You are right, but I would propose to stick to the reference init
sequence and make sure the PHYs works with our code and then work on
optimizing the code. We still can remove and/or document parts of it.
> > > Further, are you able to verify that autonegotion works? Somehow for me
> > > this never really worked even when using the example sequence from
> > > Marvell.
> > >
> >
> > Autonegotiation works fine, didn't have any problems. I'm using the
> > 88Q2220M rev B0. I test it with a Media Converter, the NETLion1000 C2T and
> > with another 88Q2220M PHY. What do you use for testing ?
>
> I have to try it again. I'm using the Goepel Media Converter (EasyCON)
> and I'm pretty sure autoneg works on the Media Converter but somehow not
> on the PHY side. It could be that this is because of one of this
> undocumented registers.
>
Are you trying with the patch I provided or your own code ? If you use
my patch you should wait until V3, because I found some problems with
it. Switching from 1000Mbit/s to 100Mbit/s in autonegotiation mode doesn't
work. I could fix it but the fix touches some code already upstreamed. So
I tried to push parts of it yesterday. I forgot to cc you, just used the
get_maintainer script. I will add you to the cc list. Until then you can
look it up here: 20231218221814.69304-2-dima.fedrau@gmail.com
> Regards,
> Stefan
Regards,
Dimitri
next prev parent reply other threads:[~2023-12-19 8:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 21:31 [PATCH] net: phy: marvell-88q2xxx: add driver for the Marvell 88Q2220 PHY Dimitri Fedrau
2023-12-16 16:46 ` Andrew Lunn
2023-12-16 22:11 ` Dimitri Fedrau
2023-12-17 9:22 ` Andrew Lunn
2023-12-17 11:15 ` Dimitri Fedrau
2023-12-17 13:50 ` Stefan Eichenberger
2023-12-18 9:09 ` Dimitri Fedrau
2023-12-18 11:19 ` Stefan Eichenberger
2023-12-19 8:11 ` Dimitri Fedrau [this message]
2023-12-19 9:19 ` Stefan Eichenberger
2023-12-19 9:35 ` Dimitri Fedrau
2023-12-21 7:28 ` [PATCH v3 0/4] " Dimitri Fedrau
2023-12-21 7:28 ` [PATCH v3 1/4] net: phy: Add BaseT1 auto-negotiation constants Dimitri Fedrau
2023-12-21 9:45 ` Andrew Lunn
2023-12-21 7:28 ` [PATCH v3 2/4] net: phy: Support 100/1000BT1 linkmode advertisements Dimitri Fedrau
2023-12-21 9:45 ` Andrew Lunn
2023-12-21 7:28 ` [PATCH v3 3/4] net: phy: c45: detect 100/1000BASE-T1 " Dimitri Fedrau
2023-12-21 9:46 ` Andrew Lunn
2023-12-21 7:28 ` [PATCH v3 4/4] net: phy: marvell-88q2xxx: add driver for the Marvell 88Q2220 PHY Dimitri Fedrau
2023-12-21 9:53 ` Andrew Lunn
2023-12-21 11:40 ` Dimitri Fedrau
2023-12-21 13:47 ` Stefan Eichenberger
2023-12-21 14:16 ` Dimitri Fedrau
2023-12-21 14:25 ` Andrew Lunn
2023-12-21 14:45 ` Dimitri Fedrau
2024-01-02 11:36 ` Russell King (Oracle)
2023-12-21 9:44 ` [PATCH v3 0/4] " Andrew Lunn
2023-12-21 11:45 ` Dimitri Fedrau
2023-12-19 15:57 ` [PATCH] " Andrew Lunn
2024-01-05 12:42 ` Dimitri Fedrau
2024-01-05 14:00 ` Andrew Lunn
2024-01-05 15:43 ` Dimitri Fedrau
2024-01-05 16:06 ` Andrew Lunn
2024-01-05 22:20 ` Dimitri Fedrau
2023-12-16 22:41 ` [PATCH v2] " Dimitri Fedrau
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=20231219081117.GA3479@debian \
--to=dima.fedrau@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eichest@gmail.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 \
/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;
as well as URLs for NNTP newsgroup(s).