netdev - Re: [PATCH net-next 4/8] net: phylink: update supported

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: <20211118183301.50dab085@thinkpad>
Date:   Thu, 18 Nov 2021 18:33:01 +0100
From:   Marek Behún <kabel@...nel.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next 4/8] net: phylink: update supported_interfaces
 with modes from fwnode

On Thu, 18 Nov 2021 17:08:10 +0000
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> I'm quite certain that as we try to develop phylink, such as adding
> extra facilities like specifying the interface modes, we're going to
> end up running into these kinds of problems that we can't solve, and
> we are going to have to keep compatibility for the old ways of doing
> stuff going for years to come - which is just going to get more and
> more painful.

One way to move this forward would be to check compatible of the
corresponding MAC in this new function. If it belongs to an unconverted
driver, we can ensure the old behaviour. This would require to add a
comment to the driver saying "if you convert this, please drop the
exception in phylink_update_phy_modes()".

Yes, it is an ugly solution, but it would work and this function
already is meant to be solving backward compatibility problems by such
mechanisms. The comment says:

+	 * Nonetheless it is possible that a device may support only one mode,
+	 * for example 1000base-x, due to strapping pins or some other reasons.
+	 * If a specific device supports only the mode mentioned in DT, the
+	 * exception should be made here with of_machine_is_compatible().

BTW, I now realize that of_machine_is_compatible() is not the best
solution. I will change the comment in v2.

Marek