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:

quoted

Hi!

Hi,

quoted

Dne ponedeljek, 30. avgust 2021 ob 17:16:45 CEST je Clément Bœsch 

napisal(a):

quoted

quoted

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.

quoted

Other than that, this patch is fine and once fixes tag is fixed, you can add:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.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.

quoted

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-

quoted

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.

quoted

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel