On Mon, Jun 19, 2023 at 05:45:06PM +0300, Ilpo Järvinen wrote:
On Fri, 16 Jun 2023, Lukas Wunner wrote:
On Wed, May 17, 2023 at 01:52:29PM +0300, Ilpo Järvinen wrote:
Don't assume that the device is fully under the control of ASPM and use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register values.
If configuration fails in pcie_aspm_configure_common_clock(), the function attempts to restore the old PCI_EXP_LNKCTL_CCC settings. Store only the old PCI_EXP_LNKCTL_CCC bit for the relevant devices rather than the content of the whole LNKCTL registers. It aligns better with how pcie_lnkctl_clear_and_set() expects its parameter and makes the code more obvious to understand.
[...]
@@ -224,17 +223,14 @@ static bool pcie_retrain_link(struct pcie_link_state *link) if (!pcie_wait_for_retrain(parent)) return false;
- pcie_capability_read_word(parent, PCI_EXP_LNKCTL, ®16);
- reg16 |= PCI_EXP_LNKCTL_RL;
- pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16);
- pcie_capability_set_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_RL); if (parent->clear_retrain_link) {
This and several other RMW operations in drivers/pci/pcie/aspm.c are touched by commit b1689799772a ("PCI/ASPM: Use distinct local vars in pcie_retrain_link()") which got applied to pci/enumeration this week:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=enumer...
As a result the $SUBJECT_PATCH no longer applies cleanly and needs to be respun.
Okay but I'm a bit lost which commit/head in pci repo I should now base this series because there's a conflict between pci/aspm and pci/enumeration which is not resolved in the repo because pci/enumeration hasn't advanced into pci/next yet. Any suggestion?
Generally speaking I prefer patches based on the PCI "main" branch (usually -rc1) because I base topic branches on that. If there are conflicts with other pending material, it's great if you can mention them, but I can resolve them when applying, so no need to repost just for that.
Bjorn