Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration

From: Mark Brown <broonie@kernel.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	devicetree@vger.kernel.org,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	linux-kernel@vger.kernel.org,
	Fabien Parent <fparent@baylibre.com>,
	Iyappan Subramanian <iyappan@os.amperecomputing.com>,
	Quan Nguyen <quan@os.amperecomputing.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Russell King <linux@armlinux.org.uk>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Andrew Perepech <andrew.perepech@mediatek.com>,
	Stephane Le Provost <stephane.leprovost@mediatek.com>,
	Keyur Chudgar <keyur@os.amperecomputing.com>,
	Jassi Brar <jaswinder.singh@linaro.org>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	Salil Mehta <salil.mehta@huawei.com>,
	netdev@vger.kernel.org,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Pedro Tsai <pedro.tsai@mediatek.com>,
	"David S . Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration
Date: Wed, 24 Jun 2020 10:43:02 +0100	[thread overview]
Message-ID: <20200624094302.GA5472@sirena.org.uk> (raw)
In-Reply-To: <dca54c57-a3bd-1147-63b2-4631194963f0@gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --]

On Tue, Jun 23, 2020 at 12:49:15PM -0700, Florian Fainelli wrote:
> On 6/22/20 6:51 AM, Mark Brown wrote:

> > If the bus includes power management for the devices on the bus the
> > controller is generally responsible for that rather than the devices,
> > the devices access this via facilities provided by the bus if needed.
> > If the device is enumerated by firmware prior to being physically
> > enumerable then the bus will generally instantiate the device model
> > device and then arrange to wait for the physical device to appear and
> > get joined up with the device model device, typically in such situations
> > the physical device might appear and disappear dynamically at runtime
> > based on what the driver is doing anyway.

> In premise there is nothing that prevents the MDIO bus from taking care
> of the regulators, resets, prior to probing the PHY driver, what is
> complicated here is that we do need to issue a read of the actual PHY to
> know its 32-bit unique identifier and match it with an appropriate
> driver. The way that we have worked around this with if you do not wish
> such a hardware access to be made, is to provide an Ethernet PHY node
> compatible string that encodes that 32-bit OUI directly. In premise the
> same challenges exist with PCI devices/endpoints as well as USB, would
> they have reset or regulator typically attached to them.

That all sounds very normal and is covered by both cases I describe?

> > We could use a pre-probe stage in the device model for hotpluggable
> > buses in embedded contexts where you might need to bring things out of
> > reset or power them up before they'll appear on the bus for enumeration
> > but buses have mostly handled that at their level.

> That sounds like a better solution, are there any subsystems currently
> implementing that, or would this be a generic Linux device driver model
> addition that needs to be done?

Like I say I'm suggesting doing something at the device model level.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel