netdev - Re: [EXT] Re: [PATCH net 3/4] ARM: dts: imx6: update fec gpr property to match new format

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: <CANh8QzwxfnQ1cACz=6dhYujEVtQoTCw8kTgkHi9BnxESptL=xQ@mail.gmail.com>
Date:   Fri, 22 May 2020 20:02:49 +0200
From:   "Fuzzey, Martin" <martin.fuzzey@...wbird.group>
To:     Andy Duan <fugang.duan@....com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [EXT] Re: [PATCH net 3/4] ARM: dts: imx6: update fec gpr property
 to match new format

Hi Andy,

On Fri, 22 May 2020, 03:01 Andy Duan, <fugang.duan@....com> wrote:
>
> Andrew, many customers require the wol feature, NXP NPI release always support
> the wol feature to match customers requirement.
>
> And some customers' board only design one ethernet instance based on imx6sx/imx7d/
> Imx8 serial, but which instance we never know, maybe enet1, maybe enet2. So we should
> supply different values for gpr.
>
> So, it is very necessary to support wol feature for multiple instances.
>

Yes, I don't think anyone is saying otherwise.

The problem is just that there are already .dtsi files for i.MX chips
having multiple ethernet interfaces
in the mainline kernel (at least imx6ui.dtsi, imx6sx.dts, imx7d.dtsi)
but that this patch series does not
modify those files to use the new DT format.

It currently only modifies the dts files that are already supported by
hardcoded values in the driver.

As to not knowing which instance it shouldn't matter.
The base dtsi can declare both/all ethernet interfaces with the
appropriate GPR bits.
Both set to status = "disabled".

Then the board specific dts file sets status="okay" and activates wol
by adding "
"fsl,magic-packet" if the hardaware supports it
(because that depends on things beyond the SoC, like how the ethernet
PHY is clocked and powered.)

Martin