Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20210421055047.22858-1-ms@dev.tdt.de> <CAJ+vNU1=4sDmGXEzPwp0SCq4_p0J-odw-GLM=Qyi7zQnVHwQRA@mail.gmail.com>
 <YfspazpWoKuHEwPU@lunn.ch> <CAJ+vNU2v9WD2kzB9uTD5j6DqnBBKhv-XOttKLoZ-VzkwdzwjXw@mail.gmail.com>
 <YfwEvgerYddIUp1V@lunn.ch> <CAJ+vNU1qY1VJgw1QRsbmED6-TLQP2wwxSYb+bXfqZ3wiObLgHg@mail.gmail.com>
 <YfxtglvVDx2JJM9w@lunn.ch> <CAJ+vNU1td9aizbws-uZ-p-fEzsD8rJVS-mZn4TT2YFn9PY2n_w@mail.gmail.com>
 <Yf2usAHGZSUDvLln@lunn.ch> <CAJ+vNU3EY0qp-6oQ6Bjd4mZCKv9AeqiaJp=FSrN84P=8atKLrw@mail.gmail.com>
 <YgRWl5ykcjPW0xvx@lunn.ch>
In-Reply-To: <YgRWl5ykcjPW0xvx@lunn.ch>
From:   Tim Harvey <tharvey@gateworks.com>
Date:   Thu, 10 Feb 2022 07:52:49 -0800
Message-ID: <CAJ+vNU1kmxgFjX2HeTok-6FcnCAApvzszhh2dbNnDgFD7ZsAiQ@mail.gmail.com>
Subject: Re: [PATCH net v3] net: phy: intel-xway: enable integrated led functions
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Martin Schiller <ms@dev.tdt.de>, Hauke Mehrtens <hauke@hauke-m.de>,
        martin.blumenstingl@googlemail.com,
        Florian Fainelli <f.fainelli@gmail.com>, hkallweit1@gmail.com,
        Russell King - ARM Linux <linux@armlinux.org.uk>,
        David Miller <davem@davemloft.net>, kuba@kernel.org,
        netdev <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Feb 9, 2022 at 4:04 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > The errata can be summarized as:
> > - 1 out of 100 boots or cable plug events RGMII GbE link will end up
> > going down and up 3 to 4 times then resort to a 100m link; workaround
> > has been found to require a pin level reset
>
> So that sounds like it is downshifting because it thinks there is a
> broken pair. Can you disable downshift? Problem is, that might just
> result in link down.

Its a bad situation. The actual errata is that the device latches into
a bad state where there is some noise on an ADC or something like that
that cause a high packet error rate. The firmware baked into the PHY
has a detection mechanism looking at these errors (SSD errors) and if
there are enough of them it takes the link down and up again and if
that doesn't resolve in 3 times it shifts down to 100mbs. They call
this 'ADS' or 'auto-down-speed' and you can disable it but it would
just result in leaving your bad gbe link up. It's unclear yet if it's
better to just detect the ADS event and reset or to disable ADS and
look for the SSD errors myself (which I can do).

>
> > - 1 out of 100 boots or cable plug events (varies per board) SGMII
> > will fail link between the MAC and PHY; workaround has been found to
> > require a pin level reset
>
> I don't suppose there is a register to restart SGMII sync?  Sometimes
> there is.

Not that I see but I haven't really investigated too much into
mitigating that issue yet. The errata for that issue says you need to
assert reset but then it also says it can occur on a cable plug event
which makes me think an MDI ANEG restart may be sufficient.

>
> Anyway, shared reset makes this messy, as you said. Unfortunate
> design. But i don't see how you can work around this in the
> bootloader, especially the cable plug events.
>

Ya, in hindsight the shared reset was a really bad idea, of course the
last PHY we used on this particular board for years before the supply
chain crashed didn't have any issues like this.

I agree that I can't do anything in boot firmware. I was planning on
having some static code that registered a PHY fixup to get a call when
these PHYs were detected and I could then kick off a polling thread to
watch for errors and trigger a reset. The reset could have knowledge
of the PHY devices that called the fixup handler so that I can at
least setup each PHY again.

Regardless of how I go about this the end result may be unreliable
networking for up to a couple of minutes after board power-up or cable
plug event.

Best Regards,

Tim