linux-kernel - Re: Re: [PATCH] arm64: dts: sun50i: h5: NanoPI Neo 2: phy-mode rgmii-id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4192454.QcIURlJl1r@kista>
Date:   Tue, 31 Aug 2021 22:17:56 +0200
From:   Jernej Škrabec <jernej.skrabec@...il.com>
To:     Clément Bœsch <u@....me>
Cc:     Maxime Ripard <mripard@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Willy Liu <willy.liu@...ltek.com>,
        Rob Herring <robh+dt@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Lunn <andrew@...n.ch>,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] arm64: dts: sun50i: h5: NanoPI Neo 2: phy-mode rgmii-id

Hi!

Dne ponedeljek, 30. avgust 2021 ob 23:25:23 CEST je Clément Bœsch napisal(a):
> On Mon, Aug 30, 2021 at 10:49:37PM +0200, Jernej Škrabec wrote:
> > Hi!
> > 
> 
> Hi,
> 
> > Dne ponedeljek, 30. avgust 2021 ob 17:16:45 CEST je Clément Bœsch 
napisal(a):
> > > Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay
> > > config") network is broken on the NanoPi Neo 2.
> > > 
> > > This patch changes the phy-mode to use internal delays both for RX and
> > > TX as has been done for other boards affected by the same commit.
> > > 
> > > Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
> > 
> > This commit fixes DT issue, so "fixes" tag should be:
> > Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
> > 
> > Here, a node with wrong phy-mode property was added to NanoPi Neo 2 board 
DT.  
> 
> Shouldn't I add it instead of replacing? I followed what I observed in
> `git log --grep bbc4d71d63` where all the commits pretty much follow this
> pattern: that commit is the one causing the actual observed regression,
> while 44a94c7ef989 is much older, and while it's wrong, it wasn't causing
> an issue in practice.
> 
> Or did I misunderstand something?

With that grep command you limited yourself only to those commits which 
reference this particular commit. There are others, which also change "rgmii" 
to "rgmii-id" and reference other commits, like:
544cc3f8573b ("arm64: dts: allwinner: h6: orangepi-one-plus: Fix ethernet")
97a38c1c213b ("arm64: dts: allwinner: beelink-gs1: Enable both RGMII RX/TX 
delay")
(there are more).

Anyway, let's continue this discussion in Andrew's thread.

> 
> > Other than that, this patch is fine and once fixes tag is fixed, you can add:
> > Reviewed-by: Jernej Skrabec <jernej.skrabec@...il.com>
> > 
> > For next version, you should:
> > - change fixed tag
> > - add my review-by tag right above your signed-off-by tag
> > - mark patch as v2 (add "-v2" parameter to git format-patch)
> > - describe change right under "---" line
> > 
> 
> Will do.

Please wait until discussion reaches a conclusion.

> 
> > Note, if you borked something when sending, you should mark patch or patch 
> > series as "RESEND", so recipients don't look for changes in two subsequent 
e-
> > mails (--subject-prefix="RESEND PATCH").
> 
> Not sure I follow you so before I disturb everyone with more noise I'd
> just like to confirm: you mean a git send-email in-reply-to=[broken patch
> attempt] (the one where I borked the --cc), right? But with what patch?
> I'm a bit confused here.

That's just for the future reference. No need to do anything now for this 
patch. If you bork any send attempt in the future, recreate same patch(es) 
with this additional tag ("RESEND") and send them again.

> 
> > Thanks for the fix!
> 
> No problem; I really think a scan of all the other boards would be
> meaningful though, it looks like a lot of them got fixed but there are
> many other candidates and the issue feels pretty critical to me
> (regression, and no network at all).

I guess you speak for all boards, not just those with Allwinner SoC? I fixed as 
many boards as I have - testing is very desired. On some boards rgmii was 
changed to rgmii-txid, so it's not as straightforward as search and replace. 
It could be also deducted from schematics, but at least one Allwinner board 
has this configured in HW wrong (SW fix was needed for that board) and other 
boards might not have schematics publicy available.

In short, I wouldn't start mass generating patches for this.

Best regards,
Jernej

> 
> -- 
> Clément B.
>