netif_device_present() and Runtime PM / PCI D3

netif_device_present() and Runtime PM / PCI D3

[Heiner Kallweit]

I just wonder about the semantics of netif_device_present().
If a device is in PCI D3 (e.g. being runtime-suspended), then it's
not accessible. So is it present or not?
The description of the function just mentions the obvious case that
the device has been removed from the system.

Related is the following regarding ethtool:
dev_ethtool() returns an error if device isn't marked as present.
If device is runtime-suspended and in PCI D3, then the driver
may still be able to provide quite some (cached) info about the
device. Same applies for settings: Even if device is sleeping,
the driver may store new settings and apply them once the device
is awake again.

Re: netif_device_present() and Runtime PM / PCI D3

[Andrew Lunn]

On Sun, May 31, 2020 at 02:07:46PM +0200, Heiner Kallweit wrote:
> I just wonder about the semantics of netif_device_present().
> If a device is in PCI D3 (e.g. being runtime-suspended), then it's
> not accessible. So is it present or not?
> The description of the function just mentions the obvious case that
> the device has been removed from the system.

Hi Heiner

Looking at the code, there is no directly link to runtime suspend.  If
the drivers suspend code has detached the device then it won't be
present, but that tends to be not runtime PM, but WOL etc.

> Related is the following regarding ethtool:
> dev_ethtool() returns an error if device isn't marked as present.
> If device is runtime-suspended and in PCI D3, then the driver
> may still be able to provide quite some (cached) info about the
> device. Same applies for settings: Even if device is sleeping,
> the driver may store new settings and apply them once the device
> is awake again.

I think playing with cached state of a device is going to be a sources
of hard to find bugs. I would want to see a compelling use case for
this.

	Andrew

Re: netif_device_present() and Runtime PM / PCI D3

[Heiner Kallweit]

On 31.05.2020 17:05, Andrew Lunn wrote:
> On Sun, May 31, 2020 at 02:07:46PM +0200, Heiner Kallweit wrote:
>> I just wonder about the semantics of netif_device_present().
>> If a device is in PCI D3 (e.g. being runtime-suspended), then it's
>> not accessible. So is it present or not?
>> The description of the function just mentions the obvious case that
>> the device has been removed from the system.
> 
> Hi Heiner
> 
> Looking at the code, there is no directly link to runtime suspend.  If
> the drivers suspend code has detached the device then it won't be
> present, but that tends to be not runtime PM, but WOL etc.
> 
Thanks, Andrew. To rephrase the question, should a driver always mark
the device as not present when it's not accessible, e.g. in PCI D3?
I think there are good reasons for it.

>> Related is the following regarding ethtool:
>> dev_ethtool() returns an error if device isn't marked as present.
>> If device is runtime-suspended and in PCI D3, then the driver
>> may still be able to provide quite some (cached) info about the
>> device. Same applies for settings: Even if device is sleeping,
>> the driver may store new settings and apply them once the device
>> is awake again.
> 
> I think playing with cached state of a device is going to be a sources
> of hard to find bugs. I would want to see a compelling use case for
> this.
> 
One example I'm aware of: r8169 allows to change WoL settings even if
device is in D3 (runtime-suspended after removing cable). Driver
stores new settings and updates device once it's resuming.

> 	Andrew
> 
Heiner