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
