[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BN8PR12MB32661430AED6693B860EBCC0D3FC0@BN8PR12MB3266.namprd12.prod.outlook.com>
Date: Fri, 28 Jun 2019 07:27:31 +0000
From: Jose Abreu <Jose.Abreu@...opsys.com>
To: Andrew Lunn <andrew@...n.ch>, Jose Abreu <Jose.Abreu@...opsys.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Joao Pinto <Joao.Pinto@...opsys.com>,
"David S . Miller" <davem@...emloft.net>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>
Subject: RE: [PATCH net-next 10/10] net: stmmac: Try to get C45 PHY if
everything else fails
From: Andrew Lunn <andrew@...n.ch>
> On Thu, Jun 27, 2019 at 01:33:59PM +0000, Jose Abreu wrote:
> > From: Andrew Lunn <andrew@...n.ch>
> >
> > > There have been some drivers gaining patches for ACPI. That is
> > > probably the better long term solution, ask ACPI where is the PHY and
> > > what MDIO protocol to use to talk to it.
> >
> > Hmmm, I'm not sure this is going to work that way ...
> >
> > My setup is a PCI EP which is hot-pluggable and as far as I know ACPI
> > has only static content (????)
>
> I've wanted to improve the PHY probe code for a while. I was thinking
> we should add a flag to the MDIO bus driver structure indicating it
> can do C45. When that flag is present, we should also scan the bus for
> C45 devices, and register them as well.
>
> With that in place, i think your problem goes away. Architecturally, i
> think it is wrong that a MAC driver is registering PHY devices. The
> MDIO core should do this.
Ok, I will drop this patch from the series until we come up with a
better solution.
Powered by blists - more mailing lists