Hi Lukas,
On Mon, Sep 18, 2023 at 02:48:01PM +0200, Lukas Wunner wrote:
> struct pci_dev contains two flags which govern whether the device may
> suspend to D3cold:
>
> * no_d3cold provides an opt-out for drivers (e.g. if a device is known
> to not wake from D3cold)
>
> * d3cold_allowed provides an opt-out for user space (default is true,
> user space may set to false)
>
> Since commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend"),
> the user space setting overwrites the driver setting. Essentially user
> space is trusted to know better than the driver whether D3cold is
> working.
>
> That feels unsafe and wrong. Assume that the change was introduced
> inadvertently and do not overwrite no_d3cold when d3cold_allowed is
> modified. Instead, consider d3cold_allowed in addition to no_d3cold
> when choosing a suspend state for the device.
>
> That way, user space may opt out of D3cold if the driver hasn't, but it
> may no longer force an opt in if the driver has opted out.
Makes sense. I just wonder should the sysfs write fail from userspace
perspective if the driver has opted out and userspace tries to force it?
Or it does that already?
