Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode

[Jernej Škrabec]

Dne ponedeljek, 08. februar 2021 ob 12:24:57 CET je B.R. Oake napisal(a):
> Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), Ethernet no longer works on the Orange Pi Plus,
> because that commit sets the RX/TX delay according to the phy-mode
> property in the device tree, which is "rgmii", the wrong setting
> for this board.
>
> Following the example of others who fixed the same problem for
> many other boards, this patch changes the phy-mode to "rgmii-id"
> which gets Ethernet working again on this board.
>
> Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Fixes: 1dcd0095019a ("ARM: sun8i: orangepi-plus: Enable dwmac-sun8i")
> Signed-off-by: B.R. Oake <bro...@mailfence.com>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Jernej Skrabec <jernej....@siol.net>

Thanks!

Best regards,
Jernej

> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/
dts/sun8i-h3-orangepi-plus.dts
> index 97f497854e..d05fa679dc 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> @@ -85,7 +85,7 @@
> pinctrl-0 = <&emac_rgmii_pins>;
> phy-supply = <&reg_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
>
> status = "okay";
> };
> --
> 2.20.1
>
>

[B.R. Oake]

Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), Ethernet no longer works on the Orange Pi Plus,
because that commit sets the RX/TX delay according to the phy-mode
property in the device tree, which is "rgmii", the wrong setting
for this board.

Following the example of others who fixed the same problem for
many other boards, this patch changes the phy-mode to "rgmii-id"
which gets Ethernet working again on this board.

Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
Fixes: 1dcd0095019a ("ARM: sun8i: orangepi-plus: Enable dwmac-sun8i")
Signed-off-by: B.R. Oake <bro...@mailfence.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts

[Maxime Ripard]

Hi,

On Mon, Feb 08, 2021 at 12:24:57PM +0100, B.R. Oake wrote:
> Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), Ethernet no longer works on the Orange Pi Plus,
> because that commit sets the RX/TX delay according to the phy-mode
> property in the device tree, which is "rgmii", the wrong setting
> for this board.
>
> Following the example of others who fixed the same problem for
> many other boards, this patch changes the phy-mode to "rgmii-id"
> which gets Ethernet working again on this board.
>
> Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Fixes: 1dcd0095019a ("ARM: sun8i: orangepi-plus: Enable dwmac-sun8i")
> Signed-off-by: B.R. Oake <bro...@mailfence.com>

Unfortunately we can't take this patch as is, this needs to be your real name, see:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

Maxime

[Jernej Škrabec]

Hi!

Let me first explain that it was oversight on my side not noticing initials in
your SoB tag. But since the issue was raised by Maxime, I didn't follow up.

Dne sobota, 13. februar 2021 ob 07:51:32 CET je B.R. Oake napisal(a):

> On Wed Feb 10 at 16:01:18 CET 2021, Maxime Ripard wrote:
> > Unfortunately we can't take this patch as is, this needs to be your real
> > name, see:
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#de
> > veloper-s-certificate-of-origin-1-1

> Dear Maxime,
>
> Thank you very much for considering my contribution and for all your
> work on supporting sunxi-based hardware; I appreciate it.
>
> Thank you for referring me to the Developer's Certificate of Origin, but
> I had already read it before submitting (I had to do so in order to know
> what I was saying by "Signed-off-by:") and I do certify what it says.
>
> Looking through recent entries in the commit log of the mainline kernel,
> I see several patches from authors such as:
>
> H.J. Lu <hjl....@gmail.com>
> B K Karthik <karthik...@live.com>
> JC Kuo <jc...@nvidia.com>
> EJ Hsu <e...@nvidia.com>
> LH Lin <lh....@mediatek.com>
> KP Singh <kps...@kernel.org>
> Karthik B S <karth...@intel.com>
> Shreyas NC <shrey...@intel.com>
> Vandana BN <bnva...@gmail.com>
>
> so I believe names of this form are in fact acceptable, even if the
> style might seem a little old-fashioned to some.

Speaking generally, not only for this case, prior art arguments rarely hold,
because:
- it might be oversight,
- it might be a bad practice, which should not be followed in new
contributions,
- different maintainers have different point of view on same thing,
- maintainer wants to adapt new practice or steer subsystem in new direction

>
> I would like to add that I have met many people with names such as C.J.,
> A A, TC, MG, etc. That is what everybody calls them and it would be
> natural for them to sign themselves that way. Some of them might want to
> contribute to Linux some day, and I think it would be a great shame and
> a loss to all of us if they were discouraged from doing so by reading
> our conversation in the archives and concluding that any contribution
> from them, however small, would be summarily refused simply because of
> their name. Please could you ensure that does not happen?

The link you posted says following:
"using your real name (sorry, no pseudonyms or anonymous contributions.)"

I believe that real name means no initials, no matter what people are
accustomed to. From my point of view, CJ is pseudonym derived from real name.

This is not the first time that fix of SoB tag was requested, you can find such
requests in ML archives.

Best regards,
Jernej

>
> Thank you again for your consideration.
>
> Yours sincerely,
> B.R. Oake.

[B.R. Oake]

On Wed Feb 10 at 16:01:18 CET 2021, Maxime Ripard wrote:

> Unfortunately we can't take this patch as is, this needs to be your real name, see:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

Dear Maxime,

Thank you very much for considering my contribution and for all your
work on supporting sunxi-based hardware; I appreciate it.

Thank you for referring me to the Developer's Certificate of Origin, but
I had already read it before submitting (I had to do so in order to know
what I was saying by "Signed-off-by:") and I do certify what it says.

Looking through recent entries in the commit log of the mainline kernel,
I see several patches from authors such as:

H.J. Lu <hjl....@gmail.com>
B K Karthik <karthik...@live.com>
JC Kuo <jc...@nvidia.com>
EJ Hsu <e...@nvidia.com>
LH Lin <lh....@mediatek.com>
KP Singh <kps...@kernel.org>
Karthik B S <karth...@intel.com>
Shreyas NC <shrey...@intel.com>
Vandana BN <bnva...@gmail.com>

so I believe names of this form are in fact acceptable, even if the
style might seem a little old-fashioned to some.

I would like to add that I have met many people with names such as C.J.,
A A, TC, MG, etc. That is what everybody calls them and it would be
natural for them to sign themselves that way. Some of them might want to
contribute to Linux some day, and I think it would be a great shame and
a loss to all of us if they were discouraged from doing so by reading
our conversation in the archives and concluding that any contribution
from them, however small, would be summarily refused simply because of
their name. Please could you ensure that does not happen?

[Maxime Ripard]

On Sun, May 16, 2021 at 01:18:44PM -0700, Vagrant Cascadian wrote:
> On 2021-05-16, Salvatore Bonaccorso wrote:

> I'm sure this isn't the first time this sort of thing has been brought
> up on this subject, but I feel obliged to mention:
>
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
>
> This seems to be blocked on culturally dependent perception of what
> looks like a "real name" as opposed to any technical grounds.
>
> What is the goal of the "real name" in Signed-off-by actually trying to
> achieve?

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

I'm not the one making the rules, sorry

Maxime

[Maxime Ripard]

Hi,

On Thu, May 20, 2021 at 08:50:01PM +0200, Salvatore Bonaccorso wrote:
> Hi,
>
> On Thu, May 20, 2021 at 11:24:18AM -0700, Vagrant Cascadian wrote:
> > On 2021-05-18, Salvatore Bonaccorso wrote:
> > > On Tue, May 18, 2021 at 10:25:40PM +0200, Salvatore Bonaccorso wrote:

> > >> Would it be technically possible to do the following: Based on the
> > >> downstream report we receved in Debian in
> > >> https://bugs.debian.org/988574 wrap up the same patch (I guess I will
> > >> need to use another commit message wording) and resubmit with my own
> > >> SoB with my downstream hat on and say a Tested-by from Vagrant? So we
> > >> are not blocked on the SoB issue from this original post of the change
> > >> to apply to arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts ?
> > >
> > > Here is an attempt to do that and coming from
> > > https://bugs.debian.org/988574 for the change change submission.
> > >
> > > Regards,
> > > Salvatore
> > >
> > > From 93c335c997d6386fc5cb7b9c5621b9b9725de20e Mon Sep 17 00:00:00 2001
> > > From: Salvatore Bonaccorso <car...@debian.org>
> > > Date: Tue, 18 May 2021 22:33:49 +0200
> > > Subject: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix ethernet phy-mode
> > >
> > > Commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay
> > > config") sets the RX/TX delay according to the phy-mode property in the
> > > device tree. For the Orange Pi Plus board this is "rgmii", which is the
> > > wrong setting.
> > >
> > > Following the example of a900cac3750b ("ARM: dts: sun7i: a20: bananapro:
> > > Fix ethernet phy-mode") the phy-mode is changed to "rgmii-id" which gets
> > > the Ethernet working again on this board.
> > >
> > > Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
> > > Reported-by: Vagrant Cascadian <vag...@reproducible-builds.org>
> > > Link: https://bugs.debian.org/988574
> > > Signed-off-by: Salvatore Bonaccorso <car...@debian.org>
> >
> > Seems worth crediting the original reporter "B.R. Oake"
> > <bro...@mailfence.com> with a Reported-by as well?
>
> Right, very good point, attached a revisited patch.
>
> Regards,
> Salvatore
>
> From 886f1e5cf477f5e2b5a88718b47d11a9d78325d2 Mon Sep 17 00:00:00 2001
> From: Salvatore Bonaccorso <car...@debian.org>
> Date: Tue, 18 May 2021 22:33:49 +0200
> Subject: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix ethernet phy-mode
>
> Commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay
> config") sets the RX/TX delay according to the phy-mode property in the
> device tree. For the Orange Pi Plus board this is "rgmii", which is the
> wrong setting.
>
> Following the example of a900cac3750b ("ARM: dts: sun7i: a20: bananapro:
> Fix ethernet phy-mode") the phy-mode is changed to "rgmii-id" which gets
> the Ethernet working again on this board.
>
> Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
> Reported-by: "B.R. Oake" <bro...@mailfence.com>
> Reported-by: Vagrant Cascadian <vag...@reproducible-builds.org>
> Link: https://bugs.debian.org/988574
> Signed-off-by: Salvatore Bonaccorso <car...@debian.org>
> ---
>
> v2:
> - Add a Reported-by for "B.R. Oake" <bro...@mailfence.com>

It looks good to me, can you resend it using git send-email?

Thanks!
Maxime

[B.R. Oake]

On Sat Feb 13 09:51:17 CET 2021, Jernej Škrabec wrote:
> Let me first explain that it was oversight on my side not noticing initials in
> your SoB tag. But since the issue was raised by Maxime, I didn't follow up.

> [...]

Dear Jernej,

First of all, thank you very much for all your linux-sunxi work: I
especially appreciate the video support you've provided.

Thank you for initially approving my patch. Although I first posted a
patch to the linux-sunxi list about seven years ago, this patch was my
first formal submission to LKML, so it meant a lot to me to see it
accepted by a kernel developer, even if only briefly.

I'm sorry for taking a long time to reply. I wanted to wait for the
maintainers to respond to my last mail because I thought it would be
best for them to speak for themselves on this issue. Sadly I haven't
yet received a response from them.

> I believe that real name means no initials, no matter what people are
> accustomed to. From my point of view, CJ is pseudonym derived from real name.

I don't think that's a widely held belief though. For example, I think
most people consider "J.R.R. Tolkien" to be a real name, even though it
contains initials. Also, a first name like CJ isn't necessarily derived
from some longer name like Cathy Jane, it can simply be the person's
given name. I'm grateful to Vagrant Cascadian for drawing our attention
to Patrick McKenzie's essay "Falsehoods Programmers Believe About Names".
I believe we harm Linux development when we exclude people whose names
don't fit our assumptions.

Another reason for signing with initials is to ensure that other people
cannot infer anything about the author's gender. Women especially might
choose to do this to avoid the harassment that a female name can attract,
as shown in these studies for example:

https://ece.umd.edu/news/story/study-finds-femalename-chat-users-get-25-times-more-malicious-messages
https://www.reach3insights.com/women-gaming-study

If we forbid people from contributing in a gender-neutral way, many may
feel they cannot contribute at all. Again, I think that when we exclude
these people we are all worse off as a result.

> Speaking generally, not only for this case, prior art arguments rarely hold,

> [...]

> This is not the first time that fix of SoB tag was requested, you can find such
> requests in ML archives.

Isn't that a prior art argument? ;-)

Best wishes,
B.R.


--
Mailfence.com
Private and secure email

[Julian Calaby]

Hi,

While I completely sympathise with your points here, the issue isn't a
technical or social issue, but a legal one.

The DCO was introduced to provide a mechanism to trace the origin of a
piece of code for legal purposes, so my understanding is that the name
supplied needs to be your legal name.

Whilst, as you've pointed out, there are a lot of ways that names
don't match up to the normal "Firstname I. N. I. T. I. A. L. S.
Lastname" format, that is the case for the vast majority of people and
exceptions to that are rare. Your arguments against providing that
name haven't exactly helped your case either as they are similar to
the arguments someone trying to hide behind a pseudonym might use.

Your points about previous instances of this happening also don't hold
water either as we don't know the circumstances behind those cases.
Git's history is considered immutable once it makes it to an
"official" repository (generally one published publicly) so it's
likely they were oversights that weren't caught until it was too late.

Thanks,

--
Julian Calaby

Email: julian...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[Julian Calaby]

Hi,

You're veering dangerously close to troll territory, but I'll give you
one last response on this.

On Mon, Jul 5, 2021 at 10:18 AM B.R. Oake <bro...@mailfence.com> wrote:

>
> On Fri Jun 04 08:49:28 CEST 2021, Julian Calaby wrote:
> > While I completely sympathise with your points here, the issue isn't a
> > technical or social issue, but a legal one.

> > [...]
>
> Dear Julian,
>
> Thank you for giving your point of view on this issue, and sorry for not
> replying sooner. Thanks also for your work on the Atheros wifi driver,
> which I've used a lot. I think it's a particularly important one since
> it's one of the few wireless chipsets with open firmware.

>
>
> > The DCO was introduced to provide a mechanism to trace the origin of a
> > piece of code for legal purposes, so my understanding is that the name
> > supplied needs to be your legal name.
>

> Please could you say what you mean by "legal name"? For example, do you
> consider "J.R.R. Tolkien" to be a legal name?

Nope, I'd be surprised if that was his legal name. I'd expect it would
have been "John Tolkien" or "John Ronald Reuel Tolkien".

> Can you give an example of a legal purpose for which the DCO was
> intended and which fails when the DCO is signed with a name like
> G. Robinson or C.J. Newton?

https://lkml.org/lkml/2004/5/23/10 is the rationale behind the DCO.
The TL;DR is that SCO was claiming that code was written by them and
suing people over that. The DCO was developed as a method to assign a
legal origin to contributions to Linux.

My understanding is that there needs to be some way to link up a piece
of code with an actual physical person, so "real" / "legal" name +
email was chosen as the simplest solution. My understanding is that if
your name on your passport / drivers license / official id card is
"B.R. Oake" then we're good, otherwise use the name that would be used
in a legal document.

> > Whilst, as you've pointed out, there are a lot of ways that names
> > don't match up to the normal "Firstname I. N. I. T. I. A. L. S.
> > Lastname" format, that is the case for the vast majority of people and
> > exceptions to that are rare.
>

> I'm not sure about that - for example, Mandarin names don't really fit
> that template. But even if exceptions were rare, would that mean those
> people and their contributions didn't matter?

Here's an example of someone who I believe is a Chinese national using
a anglicised chinese name as their name in a patch:
https://lore.kernel.org/linux-wireless/20210517050141.6...@huawei.com/

Here's another example:
https://lore.kernel.org/linux-wireless/2e938041399b47ae04c6c339c6cd5cdb...@mediatek.com/

> > Your arguments against providing that

> > name haven't exactly helped your case [...]
>
> Well I didn't actually argue against providing a name of the form you've
> specified - I have no objection to authors doing that if they want to. I
> just gave some reasons why an author might sign with a name of the form
> J.K. Smith. When a practice is contested I believe it does help to show
> that it has legitimate reasons.

The first link above was found on the third search result on Bing.
It's not difficult to find out why this practice has been adopted and
what the reasoning behind it is.

> > Your points about previous instances of this happening also don't hold
> > water either as we don't know the circumstances behind those cases.
> > Git's history is considered immutable once it makes it to an
> > "official" repository (generally one published publicly) so it's
> > likely they were oversights that weren't caught until it was too late.
>

> Although the history might be immutable, offending commits can still be
> reverted. However, I have not found any examples of this happening to
> the commits by the authors I mentioned, which suggests there is no
> problem with having them.

Reverting doesn't eliminate history, it just puts things back to how
they were. Kinda like tidying a room the day after you messed it up
instead of changing history to not mess it up at all.

I don't believe that reverting is a strong enough act to fix these
sorts of issues.

> And I think we do know a bit about their circumstances. To take one
> example, over an 18-month period I can see 72 commits authored by KP
> Singh which were variously committed, signed off, acknowledged and
> reviewed by Daniel Borkmann, Yonghong Song, Mimi Zohar, Alexei
> Starovoitov, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Florent
> Revest, James Morris, Andrew Morton, Linus Torvalds, Brendan Jackman,
> Thomas Garnier, Kees Cook, Casey Schaufler and Randy Dunlap.
>
> It doesn't seem very likely that these approvals were all oversights. It
> seems a lot more likely that there is actually no problem with names of
> this form.

Or perhaps KP is that person's legal name and they've proven that
sufficiently to the various people involved. Perhaps the changes they
make are considered minor enough that it's not likely to be a problem
in the future. Or perhaps the maintainer who accepted the patches has
lower standards than Maxime. Generally subsystem maintainers assume
that driver maintainers do the right thing. So It's possible that most
of those people assumed that everything was fine and whoever accepted
the patch initially (Probably the second Signed-off-by line) was fine
with this.

[B.R. Oake]

On Fri Jun 04 08:49:28 CEST 2021, Julian Calaby wrote:

> While I completely sympathise with your points here, the issue isn't a
> technical or social issue, but a legal one.

> [...]

Dear Julian,

Thank you for giving your point of view on this issue, and sorry for not
replying sooner. Thanks also for your work on the Atheros wifi driver,
which I've used a lot. I think it's a particularly important one since
it's one of the few wireless chipsets with open firmware.

> The DCO was introduced to provide a mechanism to trace the origin of a
> piece of code for legal purposes, so my understanding is that the name
> supplied needs to be your legal name.

Please could you say what you mean by "legal name"? For example, do you

consider "J.R.R. Tolkien" to be a legal name?

Can you give an example of a legal purpose for which the DCO was
intended and which fails when the DCO is signed with a name like
G. Robinson or C.J. Newton?

> Whilst, as you've pointed out, there are a lot of ways that names
> don't match up to the normal "Firstname I. N. I. T. I. A. L. S.
> Lastname" format, that is the case for the vast majority of people and
> exceptions to that are rare.

I'm not sure about that - for example, Mandarin names don't really fit
that template. But even if exceptions were rare, would that mean those
people and their contributions didn't matter?

> Your arguments against providing that

> name haven't exactly helped your case [...]

Well I didn't actually argue against providing a name of the form you've
specified - I have no objection to authors doing that if they want to. I
just gave some reasons why an author might sign with a name of the form
J.K. Smith. When a practice is contested I believe it does help to show
that it has legitimate reasons.

> Your points about previous instances of this happening also don't hold
> water either as we don't know the circumstances behind those cases.
> Git's history is considered immutable once it makes it to an
> "official" repository (generally one published publicly) so it's
> likely they were oversights that weren't caught until it was too late.

Although the history might be immutable, offending commits can still be
reverted. However, I have not found any examples of this happening to
the commits by the authors I mentioned, which suggests there is no
problem with having them.

And I think we do know a bit about their circumstances. To take one
example, over an 18-month period I can see 72 commits authored by KP
Singh which were variously committed, signed off, acknowledged and
reviewed by Daniel Borkmann, Yonghong Song, Mimi Zohar, Alexei
Starovoitov, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Florent
Revest, James Morris, Andrew Morton, Linus Torvalds, Brendan Jackman,
Thomas Garnier, Kees Cook, Casey Schaufler and Randy Dunlap.

It doesn't seem very likely that these approvals were all oversights. It
seems a lot more likely that there is actually no problem with names of
this form.