netdev - Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY

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]

Date:   Mon, 3 Aug 2020 17:00:51 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Vikas Singh <vikas.singh@...esoftware.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Calvin Johnson (OSS)" <calvin.johnson@....nxp.com>,
        kuldip dwivedi <kuldip.dwivedi@...esoftware.com>,
        Vikas Singh <vikas.singh@....com>
Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY

On Mon, Aug 03, 2020 at 02:33:56PM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: 03 August 2020 15:58
> > To: Madalin Bucur (OSS) <madalin.bucur@....nxp.com>
> > Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>; Vikas Singh
> > <vikas.singh@...esoftware.com>; f.fainelli@...il.com; hkallweit1@...il.com;
> > netdev@...r.kernel.org; Calvin Johnson (OSS) <calvin.johnson@....nxp.com>;
> > kuldip dwivedi <kuldip.dwivedi@...esoftware.com>; Vikas Singh
> > <vikas.singh@....com>
> > Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
> > 
> > > I see you agree that there were and there will be many changes for a
> > while,
> > > It's not a complaint, I know hot it works, it's just a decision based on
> > > required effort vs features offered vs user requirements. Lately it's
> > been
> > > time consuming to try to fix things in this area.
> > 
> > So the conclusion to all this that you are unwilling to use the
> > correct API for this, which would be phylink, and the SFP code.  So:
> > 
> > NACK
> > 
> > 	Andrew
> 
> You've rejected a generic change - ACPI support for fixed link.
> The discussion above is just an example of how it could have been (mis-)used.
> Are you rejecting the general case or just the particular one?

So far, nobody has corrected me that the MAC is not connected to an
SFP socket. So i see two sorts of abuse going on here:

1) Using a fixed link with a hack to allow 10G. phylink allows 10G
   fixed links without an hacks.

2) Using a fixed link when not even appropriate since phylink should
   be used to control the SFP.

Now, you can do whatever you want in your Vendor Crap tree. But there
is no reason mainline should help you support your vendor crap tree.

To make progress here, you need to add an in tree user of this generic
change. And since that means an ACPI user, you need to follow what has
been set out in the other thread. You need an ACPI maintainer to ACK
it. And to get an ACPI maintainer to ACK it, you need a specification,
and proof it is being used. And to get my ACK, it needs to be valid
use of it as well.

	Andrew