| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The patch doesn't apply cleanly anymore because a new quirk flag was
added (NVME_QUIRK_BROKEN_MSI), so I rebased the patch accordingly.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
| |
The patch doesn't apply cleanly anymore because a new quirk flag was
added (NVME_QUIRK_FORCE_NO_SIMPLE_SUSPEND), so I rebased the patch
accordingly.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The nvme-suspend-quirk patch doesn't apply anymore with kernel 6.3
because kernel 6.3 added a new quirk
(NVME_QUIRK_NO_SECONDARY_TEMP_THRESH) to the nvme_quirks enum.
To fix this, I just edited the patch to refer to the newly added quirk
and increase the bitflag by one.
With this, the patch applies, but I haven't yet built the kernel nor did
I actually test this on the target machine.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
After resume from suspend the NVMe does not wake up again when the
device was put into D3cold. This is something that is worked around by
TUXEDO Tomte[1] via udev rules. However, I personally don't like this
approach and it can lead to race conditions when we're going into
suspend before udev is initialised.
Interestingly, the device does even go into NPSS via APST, but if
changing to D3cold while APST is enabled, the device does not wake up
again.
Right now I just added a new quirk to disable D3cold during device
probe for now, but we could maybe find a better workaround eg. by
disabling APST before D3cold and re-enabling it again. Not sure whether
this is feasible, but since I have limited time right now I can't dig
more into this.
[1]: https://github.com/tuxedocomputers/tuxedo-tomte/commit/2c8d71170868a2663705fbea6ac150eecb96e6ce
Signed-off-by: aszlig <aszlig@nix.build>
|
