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

2020-06-24 Thread Robin Murphy
On 2020-06-24 17:50, Russell King - ARM Linux admin wrote: On Wed, Jun 24, 2020 at 09:06:28AM -0700, Florian Fainelli wrote: On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote: I didn't expect to open such a can of worms... This has evolved into several new concepts being proposed vs my use-case

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

2020-06-24 Thread Russell King - ARM Linux admin
On Wed, Jun 24, 2020 at 09:06:28AM -0700, Florian Fainelli wrote: > On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote: > > I didn't expect to open such a can of worms... > > > > This has evolved into several new concepts being proposed vs my > > use-case which is relatively simple. The former will p

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

2020-06-24 Thread Bartosz Golaszewski
On Wed, Jun 24, 2020 at 6:06 PM Florian Fainelli wrote: > [snip!] > > > > This has evolved into several new concepts being proposed vs my > > use-case which is relatively simple. The former will probably take > > several months of development, reviews and discussions and it will > > block suppor

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

2020-06-24 Thread Florian Fainelli
On 6/24/2020 6:48 AM, Bartosz Golaszewski wrote: > śr., 24 cze 2020 o 11:43 Mark Brown napisał(a): >> >> 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 c

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

2020-06-24 Thread Bartosz Golaszewski
śr., 24 cze 2020 o 11:43 Mark Brown napisał(a): > > 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

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

2020-06-24 Thread Mark Brown
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 pro

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

2020-06-23 Thread Florian Fainelli
On 6/22/20 6:51 AM, Mark Brown wrote: > On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote: > >> The PHY subsystem cannot be the first to run into this problem, that >> you need a device structure to make use of the regulator API, but you >> need the regulator API to probe the device. How

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

2020-06-22 Thread Mark Brown
On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote: > The PHY subsystem cannot be the first to run into this problem, that > you need a device structure to make use of the regulator API, but you > need the regulator API to probe the device. How do other subsystems > work around this? If

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

2020-06-22 Thread Andrew Lunn
On Mon, Jun 22, 2020 at 11:37:38AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Currently the PHY ID is read without taking the PHY out of reset. This > can only work if no resets are defined. This change delays the ID read > until we're actually registering the PHY device -

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

2020-06-22 Thread Bartosz Golaszewski
From: Bartosz Golaszewski Currently the PHY ID is read without taking the PHY out of reset. This can only work if no resets are defined. This change delays the ID read until we're actually registering the PHY device - this is needed because earlier (when creating the device) we don't have a struc