[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

When the operating system is booted with the default ASPM policy
(POLICY_DEFAULT), current code is querying the enable/disable
states from ASPM registers to determine the policy.

For example, a BIOS could set the power saving state to performance
and clear all ASPM control registers. A balanced ASPM policy could
enable L0s and disable L1. A power conscious BIOS could enable both
L0s and L1 to trade off latency and performance vs. power.

After hotplug removal, pcie_aspm_exit_link_state() function clears
the ASPM registers. An insertion following hotplug removal reads
incorrect policy as ASPM disabled even though ASPM was enabled
during boot.

This is caused by the fact that same function is used for reconfiguring
ASPM regardless of the power on state.

------------------------
Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
------------------------
- pci_aspm_init(): Fix function comment.  Called for every device we
  enumerate.
	Upstream link partner:  Shouldn't need to check pdev->link_state
        (should always be NULL for a brand-new device).

- pcie_aspm_init_link_state(): Called for bridges (upstream end of
    link) after all children have been enumerated.  No longer needs to
    check aspm_support_enabled or pdev->has_secondary_link or the VIA
    quirk: pci_aspm_init() already checked that stuff, so we only need
    to check pdev->link_state here.

- split the last patch into two
  PCI/ASPM: move link_state cleanup to bridge remove
  PCI/ASPM: save power on values during bridge init

- create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
- add fixes tags

Sinan Kaya (4):
  PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
  PCI/ASPM: add init hook to device_add
  PCI/ASPM: save power on values during bridge init
  PCI/ASPM: move link_state cleanup to bridge remove

 drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
 drivers/pci/probe.c     |  3 ++
 drivers/pci/remove.c    |  3 +-
 include/linux/pci.h     |  2 ++
 4 files changed, 69 insertions(+), 32 deletions(-)

-- 
1.9.1

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

When the operating system is booted with the default ASPM policy
(POLICY_DEFAULT), current code is querying the enable/disable
states from ASPM registers to determine the policy.

For example, a BIOS could set the power saving state to performance
and clear all ASPM control registers. A balanced ASPM policy could
enable L0s and disable L1. A power conscious BIOS could enable both
L0s and L1 to trade off latency and performance vs. power.

After hotplug removal, pcie_aspm_exit_link_state() function clears
the ASPM registers. An insertion following hotplug removal reads
incorrect policy as ASPM disabled even though ASPM was enabled
during boot.

This is caused by the fact that same function is used for reconfiguring
ASPM regardless of the power on state.

------------------------
Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
------------------------
- pci_aspm_init(): Fix function comment.  Called for every device we
  enumerate.
	Upstream link partner:  Shouldn't need to check pdev->link_state
        (should always be NULL for a brand-new device).

- pcie_aspm_init_link_state(): Called for bridges (upstream end of
    link) after all children have been enumerated.  No longer needs to
    check aspm_support_enabled or pdev->has_secondary_link or the VIA
    quirk: pci_aspm_init() already checked that stuff, so we only need
    to check pdev->link_state here.

- split the last patch into two
  PCI/ASPM: move link_state cleanup to bridge remove
  PCI/ASPM: save power on values during bridge init

- create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
- add fixes tags

Sinan Kaya (4):
  PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
  PCI/ASPM: add init hook to device_add
  PCI/ASPM: save power on values during bridge init
  PCI/ASPM: move link_state cleanup to bridge remove

 drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
 drivers/pci/probe.c     |  3 ++
 drivers/pci/remove.c    |  3 +-
 include/linux/pci.h     |  2 ++
 4 files changed, 69 insertions(+), 32 deletions(-)

-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

When the operating system is booted with the default ASPM policy
(POLICY_DEFAULT), current code is querying the enable/disable
states from ASPM registers to determine the policy.

For example, a BIOS could set the power saving state to performance
and clear all ASPM control registers. A balanced ASPM policy could
enable L0s and disable L1. A power conscious BIOS could enable both
L0s and L1 to trade off latency and performance vs. power.

After hotplug removal, pcie_aspm_exit_link_state() function clears
the ASPM registers. An insertion following hotplug removal reads
incorrect policy as ASPM disabled even though ASPM was enabled
during boot.

This is caused by the fact that same function is used for reconfiguring
ASPM regardless of the power on state.

------------------------
Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
------------------------
- pci_aspm_init(): Fix function comment.  Called for every device we
  enumerate.
	Upstream link partner:  Shouldn't need to check pdev->link_state
        (should always be NULL for a brand-new device).

- pcie_aspm_init_link_state(): Called for bridges (upstream end of
    link) after all children have been enumerated.  No longer needs to
    check aspm_support_enabled or pdev->has_secondary_link or the VIA
    quirk: pci_aspm_init() already checked that stuff, so we only need
    to check pdev->link_state here.

- split the last patch into two
  PCI/ASPM: move link_state cleanup to bridge remove
  PCI/ASPM: save power on values during bridge init

- create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
- add fixes tags

Sinan Kaya (4):
  PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
  PCI/ASPM: add init hook to device_add
  PCI/ASPM: save power on values during bridge init
  PCI/ASPM: move link_state cleanup to bridge remove

 drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
 drivers/pci/probe.c     |  3 ++
 drivers/pci/remove.c    |  3 +-
 include/linux/pci.h     |  2 ++
 4 files changed, 69 insertions(+), 32 deletions(-)

-- 
1.9.1

[PATCH V5 1/4] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()

[Sinan Kaya]

We need a callback from pci_init_capabilities function for every
single new PCI device that is currently being added.

pci_aspm_init() will be used to save the power on state of the HW.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 10 ++++++++++
 drivers/pci/probe.c     |  3 +++
 include/linux/pci.h     |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 973472c..74fd7c5 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -828,6 +828,16 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
 }
 
 /*
+ * pci_aspm_init: Initiate PCI express link state.
+ * It is called from device_add for every single pci device.
+ * @pdev: all pci devices
+ */
+int pci_aspm_init(struct pci_dev *pdev)
+{
+	return 0;
+}
+
+/*
  * pcie_aspm_init_link_state: Initiate PCI express link state.
  * It is called after the pcie and its children devices are scanned.
  * @pdev: the root port or switch downstream port
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index dfc9a27..1e19364 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1847,6 +1847,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
 
 	/* Advanced Error Reporting */
 	pci_aer_init(dev);
+
+	/* Active State Power Management */
+	pci_aspm_init(dev);
 }
 
 /*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb3da1a..8828dd7 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1396,8 +1396,10 @@ static inline int pci_irq_get_node(struct pci_dev *pdev, int vec)
 
 #ifdef CONFIG_PCIEASPM
 bool pcie_aspm_support_enabled(void);
+int pci_aspm_init(struct pci_dev *pdev);
 #else
 static inline bool pcie_aspm_support_enabled(void) { return false; }
+static inline int pci_aspm_init(struct pci_dev *pdev) { return -ENODEV; }
 #endif
 
 #ifdef CONFIG_PCIEAER
-- 
1.9.1

[PATCH V5 1/4] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()

[Sinan Kaya]

We need a callback from pci_init_capabilities function for every
single new PCI device that is currently being added.

pci_aspm_init() will be used to save the power on state of the HW.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 10 ++++++++++
 drivers/pci/probe.c     |  3 +++
 include/linux/pci.h     |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 973472c..74fd7c5 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -828,6 +828,16 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
 }
 
 /*
+ * pci_aspm_init: Initiate PCI express link state.
+ * It is called from device_add for every single pci device.
+ * @pdev: all pci devices
+ */
+int pci_aspm_init(struct pci_dev *pdev)
+{
+	return 0;
+}
+
+/*
  * pcie_aspm_init_link_state: Initiate PCI express link state.
  * It is called after the pcie and its children devices are scanned.
  * @pdev: the root port or switch downstream port
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index dfc9a27..1e19364 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1847,6 +1847,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
 
 	/* Advanced Error Reporting */
 	pci_aer_init(dev);
+
+	/* Active State Power Management */
+	pci_aspm_init(dev);
 }
 
 /*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb3da1a..8828dd7 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1396,8 +1396,10 @@ static inline int pci_irq_get_node(struct pci_dev *pdev, int vec)
 
 #ifdef CONFIG_PCIEASPM
 bool pcie_aspm_support_enabled(void);
+int pci_aspm_init(struct pci_dev *pdev);
 #else
 static inline bool pcie_aspm_support_enabled(void) { return false; }
+static inline int pci_aspm_init(struct pci_dev *pdev) { return -ENODEV; }
 #endif
 
 #ifdef CONFIG_PCIEAER
-- 
1.9.1

[PATCH V5 2/4] PCI/ASPM: add init hook to device_add

[Sinan Kaya]

For bridges, have pcie_aspm_init_link_state() allocate a link_state,
regardless of whether it currently has any children.

pcie_aspm_init_link_state(): Called for bridges (upstream end of
link) after all children have been enumerated.  No longer needs to
check aspm_support_enabled or pdev->has_secondary_link or the VIA
quirk: pci_aspm_init() already checked that stuff, so we only need
to check pdev->link_state here.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 41 ++++++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 74fd7c5..f5b1fa0 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -834,6 +834,23 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
  */
 int pci_aspm_init(struct pci_dev *pdev)
 {
+	struct pcie_link_state *link;
+
+	if (!aspm_support_enabled)
+		return 0;
+
+	/* VIA has a strange chipset, root port is under a bridge */
+	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
+	    pdev->bus->self)
+		return 0;
+
+	if (!pdev->has_secondary_link)
+		return 0;
+
+	link = alloc_pcie_link_state(pdev);
+	if (!link)
+		return -ENOMEM;
+
 	return 0;
 }
 
@@ -847,33 +864,16 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
 	struct pcie_link_state *link;
 	int blacklist = !!pcie_aspm_sanity_check(pdev);
 
-	if (!aspm_support_enabled)
-		return;
-
-	if (pdev->link_state)
-		return;
-
-	/*
-	 * We allocate pcie_link_state for the component on the upstream
-	 * end of a Link, so there's nothing to do unless this device has a
-	 * Link on its secondary side.
-	 */
-	if (!pdev->has_secondary_link)
-		return;
-
-	/* VIA has a strange chipset, root port is under a bridge */
-	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
-	    pdev->bus->self)
+	if (!pdev->link_state)
 		return;
 
+	link = pdev->link_state;
 	down_read(&pci_bus_sem);
 	if (list_empty(&pdev->subordinate->devices))
 		goto out;
 
 	mutex_lock(&aspm_lock);
-	link = alloc_pcie_link_state(pdev);
-	if (!link)
-		goto unlock;
+
 	/*
 	 * Setup initial ASPM state. Note that we need to configure
 	 * upstream links also because capable state of them can be
@@ -898,7 +898,6 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
 		pcie_set_clkpm(link, policy_to_clkpm_state(link));
 	}
 
-unlock:
 	mutex_unlock(&aspm_lock);
 out:
 	up_read(&pci_bus_sem);
-- 
1.9.1

[PATCH V5 2/4] PCI/ASPM: add init hook to device_add

[Sinan Kaya]

For bridges, have pcie_aspm_init_link_state() allocate a link_state,
regardless of whether it currently has any children.

pcie_aspm_init_link_state(): Called for bridges (upstream end of
link) after all children have been enumerated.  No longer needs to
check aspm_support_enabled or pdev->has_secondary_link or the VIA
quirk: pci_aspm_init() already checked that stuff, so we only need
to check pdev->link_state here.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 41 ++++++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 74fd7c5..f5b1fa0 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -834,6 +834,23 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
  */
 int pci_aspm_init(struct pci_dev *pdev)
 {
+	struct pcie_link_state *link;
+
+	if (!aspm_support_enabled)
+		return 0;
+
+	/* VIA has a strange chipset, root port is under a bridge */
+	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
+	    pdev->bus->self)
+		return 0;
+
+	if (!pdev->has_secondary_link)
+		return 0;
+
+	link = alloc_pcie_link_state(pdev);
+	if (!link)
+		return -ENOMEM;
+
 	return 0;
 }
 
@@ -847,33 +864,16 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
 	struct pcie_link_state *link;
 	int blacklist = !!pcie_aspm_sanity_check(pdev);
 
-	if (!aspm_support_enabled)
-		return;
-
-	if (pdev->link_state)
-		return;
-
-	/*
-	 * We allocate pcie_link_state for the component on the upstream
-	 * end of a Link, so there's nothing to do unless this device has a
-	 * Link on its secondary side.
-	 */
-	if (!pdev->has_secondary_link)
-		return;
-
-	/* VIA has a strange chipset, root port is under a bridge */
-	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
-	    pdev->bus->self)
+	if (!pdev->link_state)
 		return;
 
+	link = pdev->link_state;
 	down_read(&pci_bus_sem);
 	if (list_empty(&pdev->subordinate->devices))
 		goto out;
 
 	mutex_lock(&aspm_lock);
-	link = alloc_pcie_link_state(pdev);
-	if (!link)
-		goto unlock;
+
 	/*
 	 * Setup initial ASPM state. Note that we need to configure
 	 * upstream links also because capable state of them can be
@@ -898,7 +898,6 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
 		pcie_set_clkpm(link, policy_to_clkpm_state(link));
 	}
 
-unlock:
 	mutex_unlock(&aspm_lock);
 out:
 	up_read(&pci_bus_sem);
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 2/4] PCI/ASPM: add init hook to device_add

[Sinan Kaya]

For bridges, have pcie_aspm_init_link_state() allocate a link_state,
regardless of whether it currently has any children.

pcie_aspm_init_link_state(): Called for bridges (upstream end of
link) after all children have been enumerated.  No longer needs to
check aspm_support_enabled or pdev->has_secondary_link or the VIA
quirk: pci_aspm_init() already checked that stuff, so we only need
to check pdev->link_state here.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 41 ++++++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 74fd7c5..f5b1fa0 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -834,6 +834,23 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
  */
 int pci_aspm_init(struct pci_dev *pdev)
 {
+	struct pcie_link_state *link;
+
+	if (!aspm_support_enabled)
+		return 0;
+
+	/* VIA has a strange chipset, root port is under a bridge */
+	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
+	    pdev->bus->self)
+		return 0;
+
+	if (!pdev->has_secondary_link)
+		return 0;
+
+	link = alloc_pcie_link_state(pdev);
+	if (!link)
+		return -ENOMEM;
+
 	return 0;
 }
 
@@ -847,33 +864,16 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
 	struct pcie_link_state *link;
 	int blacklist = !!pcie_aspm_sanity_check(pdev);
 
-	if (!aspm_support_enabled)
-		return;
-
-	if (pdev->link_state)
-		return;
-
-	/*
-	 * We allocate pcie_link_state for the component on the upstream
-	 * end of a Link, so there's nothing to do unless this device has a
-	 * Link on its secondary side.
-	 */
-	if (!pdev->has_secondary_link)
-		return;
-
-	/* VIA has a strange chipset, root port is under a bridge */
-	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
-	    pdev->bus->self)
+	if (!pdev->link_state)
 		return;
 
+	link = pdev->link_state;
 	down_read(&pci_bus_sem);
 	if (list_empty(&pdev->subordinate->devices))
 		goto out;
 
 	mutex_lock(&aspm_lock);
-	link = alloc_pcie_link_state(pdev);
-	if (!link)
-		goto unlock;
+
 	/*
 	 * Setup initial ASPM state. Note that we need to configure
 	 * upstream links also because capable state of them can be
@@ -898,7 +898,6 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
 		pcie_set_clkpm(link, policy_to_clkpm_state(link));
 	}
 
-unlock:
 	mutex_unlock(&aspm_lock);
 out:
 	up_read(&pci_bus_sem);
-- 
1.9.1

[PATCH V5 3/4] PCI/ASPM: save power on values during bridge init

[Sinan Kaya]

Now that we added a hook to be called from device_add, save the
default values from the HW registers early in the boot for further
reuse during hot device add/remove operations.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f5b1fa0..f48bb29 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -521,8 +521,10 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 	 */
 	if (dwreg.support & upreg.support & PCIE_LINK_STATE_L0S)
 		link->aspm_support |= ASPM_STATE_L0S;
-	if (dwreg.enabled & PCIE_LINK_STATE_L0S)
+	if (dwreg.enabled & PCIE_LINK_STATE_L0S) {
 		link->aspm_enabled |= ASPM_STATE_L0S_UP;
+		link->aspm_default |= ASPM_STATE_L0S_UP;
+	}
 	if (upreg.enabled & PCIE_LINK_STATE_L0S)
 		link->aspm_enabled |= ASPM_STATE_L0S_DW;
 	link->latency_up.l0s = calc_l0s_latency(upreg.latency_encoding_l0s);
@@ -558,9 +560,6 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 	if (link->aspm_support & ASPM_STATE_L1SS)
 		aspm_calc_l1ss_info(link, &upreg, &dwreg);
 
-	/* Save default state */
-	link->aspm_default = link->aspm_enabled;
-
 	/* Setup initial capable state. Will be updated later */
 	link->aspm_capable = link->aspm_support;
 	/*
@@ -835,6 +834,7 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
 int pci_aspm_init(struct pci_dev *pdev)
 {
 	struct pcie_link_state *link;
+	struct aspm_register_info upreg;
 
 	if (!aspm_support_enabled)
 		return 0;
@@ -851,6 +851,20 @@ int pci_aspm_init(struct pci_dev *pdev)
 	if (!link)
 		return -ENOMEM;
 
+	pcie_get_aspm_reg(pdev, &upreg);
+	if (upreg.enabled & PCIE_LINK_STATE_L0S)
+		link->aspm_default |= ASPM_STATE_L0S_DW;
+	if (upreg.enabled & PCIE_LINK_STATE_L1)
+		link->aspm_default |= ASPM_STATE_L1;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_1)
+		link->aspm_default |= ASPM_STATE_L1_1;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_2)
+		link->aspm_default |= ASPM_STATE_L1_2;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_1)
+		link->aspm_default |= ASPM_STATE_L1_1_PCIPM;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_2)
+		link->aspm_default |= ASPM_STATE_L1_2_PCIPM;
+
 	return 0;
 }
 
-- 
1.9.1

[PATCH V5 3/4] PCI/ASPM: save power on values during bridge init

[Sinan Kaya]

Now that we added a hook to be called from device_add, save the
default values from the HW registers early in the boot for further
reuse during hot device add/remove operations.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f5b1fa0..f48bb29 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -521,8 +521,10 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 	 */
 	if (dwreg.support & upreg.support & PCIE_LINK_STATE_L0S)
 		link->aspm_support |= ASPM_STATE_L0S;
-	if (dwreg.enabled & PCIE_LINK_STATE_L0S)
+	if (dwreg.enabled & PCIE_LINK_STATE_L0S) {
 		link->aspm_enabled |= ASPM_STATE_L0S_UP;
+		link->aspm_default |= ASPM_STATE_L0S_UP;
+	}
 	if (upreg.enabled & PCIE_LINK_STATE_L0S)
 		link->aspm_enabled |= ASPM_STATE_L0S_DW;
 	link->latency_up.l0s = calc_l0s_latency(upreg.latency_encoding_l0s);
@@ -558,9 +560,6 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 	if (link->aspm_support & ASPM_STATE_L1SS)
 		aspm_calc_l1ss_info(link, &upreg, &dwreg);
 
-	/* Save default state */
-	link->aspm_default = link->aspm_enabled;
-
 	/* Setup initial capable state. Will be updated later */
 	link->aspm_capable = link->aspm_support;
 	/*
@@ -835,6 +834,7 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
 int pci_aspm_init(struct pci_dev *pdev)
 {
 	struct pcie_link_state *link;
+	struct aspm_register_info upreg;
 
 	if (!aspm_support_enabled)
 		return 0;
@@ -851,6 +851,20 @@ int pci_aspm_init(struct pci_dev *pdev)
 	if (!link)
 		return -ENOMEM;
 
+	pcie_get_aspm_reg(pdev, &upreg);
+	if (upreg.enabled & PCIE_LINK_STATE_L0S)
+		link->aspm_default |= ASPM_STATE_L0S_DW;
+	if (upreg.enabled & PCIE_LINK_STATE_L1)
+		link->aspm_default |= ASPM_STATE_L1;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_1)
+		link->aspm_default |= ASPM_STATE_L1_1;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_2)
+		link->aspm_default |= ASPM_STATE_L1_2;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_1)
+		link->aspm_default |= ASPM_STATE_L1_1_PCIPM;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_2)
+		link->aspm_default |= ASPM_STATE_L1_2_PCIPM;
+
 	return 0;
 }
 
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 3/4] PCI/ASPM: save power on values during bridge init

[Sinan Kaya]

Now that we added a hook to be called from device_add, save the
default values from the HW registers early in the boot for further
reuse during hot device add/remove operations.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f5b1fa0..f48bb29 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -521,8 +521,10 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 	 */
 	if (dwreg.support & upreg.support & PCIE_LINK_STATE_L0S)
 		link->aspm_support |= ASPM_STATE_L0S;
-	if (dwreg.enabled & PCIE_LINK_STATE_L0S)
+	if (dwreg.enabled & PCIE_LINK_STATE_L0S) {
 		link->aspm_enabled |= ASPM_STATE_L0S_UP;
+		link->aspm_default |= ASPM_STATE_L0S_UP;
+	}
 	if (upreg.enabled & PCIE_LINK_STATE_L0S)
 		link->aspm_enabled |= ASPM_STATE_L0S_DW;
 	link->latency_up.l0s = calc_l0s_latency(upreg.latency_encoding_l0s);
@@ -558,9 +560,6 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 	if (link->aspm_support & ASPM_STATE_L1SS)
 		aspm_calc_l1ss_info(link, &upreg, &dwreg);
 
-	/* Save default state */
-	link->aspm_default = link->aspm_enabled;
-
 	/* Setup initial capable state. Will be updated later */
 	link->aspm_capable = link->aspm_support;
 	/*
@@ -835,6 +834,7 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
 int pci_aspm_init(struct pci_dev *pdev)
 {
 	struct pcie_link_state *link;
+	struct aspm_register_info upreg;
 
 	if (!aspm_support_enabled)
 		return 0;
@@ -851,6 +851,20 @@ int pci_aspm_init(struct pci_dev *pdev)
 	if (!link)
 		return -ENOMEM;
 
+	pcie_get_aspm_reg(pdev, &upreg);
+	if (upreg.enabled & PCIE_LINK_STATE_L0S)
+		link->aspm_default |= ASPM_STATE_L0S_DW;
+	if (upreg.enabled & PCIE_LINK_STATE_L1)
+		link->aspm_default |= ASPM_STATE_L1;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_1)
+		link->aspm_default |= ASPM_STATE_L1_1;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_2)
+		link->aspm_default |= ASPM_STATE_L1_2;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_1)
+		link->aspm_default |= ASPM_STATE_L1_1_PCIPM;
+	if (upreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_2)
+		link->aspm_default |= ASPM_STATE_L1_2_PCIPM;
+
 	return 0;
 }
 
-- 
1.9.1

[PATCH V5 4/4] PCI/ASPM: move link_state cleanup to bridge remove

[Sinan Kaya]

For endpoints, change pcie_aspm_exit_link_state() so it cleans up
the device's own state and disables ASPM if necessary, but doesn't
remove the parent's link_state.

For bridges, change pcie_aspm_exit_link_state() so it frees the
bridge's own link_state.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 20 +++++++++++++++-----
 drivers/pci/remove.c    |  3 +--
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f48bb29..db3fbd9 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -947,6 +947,21 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
 	struct pci_dev *parent = pdev->bus->self;
 	struct pcie_link_state *link, *root, *parent_link;
 
+	if (pdev->has_secondary_link) {
+		link = pdev->link_state;
+		down_read(&pci_bus_sem);
+		mutex_lock(&aspm_lock);
+
+		list_del(&link->sibling);
+		list_del(&link->link);
+
+		/* Clock PM is for endpoint device */
+		free_link_state(link);
+		mutex_unlock(&aspm_lock);
+		up_read(&pci_bus_sem);
+		return;
+	}
+
 	if (!parent || !parent->link_state)
 		return;
 
@@ -965,11 +980,6 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
 
 	/* All functions are removed, so just disable ASPM for the link */
 	pcie_config_aspm_link(link, 0);
-	list_del(&link->sibling);
-	list_del(&link->link);
-	/* Clock PM is for endpoint device */
-	free_link_state(link);
-
 	/* Recheck latencies and configure upstream links */
 	if (parent_link) {
 		pcie_update_aspm_capable(root);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 73a03d3..7e14ebd 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -25,8 +25,7 @@ static void pci_stop_dev(struct pci_dev *dev)
 		dev->is_added = 0;
 	}
 
-	if (dev->bus->self)
-		pcie_aspm_exit_link_state(dev);
+	pcie_aspm_exit_link_state(dev);
 }
 
 static void pci_destroy_dev(struct pci_dev *dev)
-- 
1.9.1

[PATCH V5 4/4] PCI/ASPM: move link_state cleanup to bridge remove

[Sinan Kaya]

For endpoints, change pcie_aspm_exit_link_state() so it cleans up
the device's own state and disables ASPM if necessary, but doesn't
remove the parent's link_state.

For bridges, change pcie_aspm_exit_link_state() so it frees the
bridge's own link_state.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 20 +++++++++++++++-----
 drivers/pci/remove.c    |  3 +--
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f48bb29..db3fbd9 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -947,6 +947,21 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
 	struct pci_dev *parent = pdev->bus->self;
 	struct pcie_link_state *link, *root, *parent_link;
 
+	if (pdev->has_secondary_link) {
+		link = pdev->link_state;
+		down_read(&pci_bus_sem);
+		mutex_lock(&aspm_lock);
+
+		list_del(&link->sibling);
+		list_del(&link->link);
+
+		/* Clock PM is for endpoint device */
+		free_link_state(link);
+		mutex_unlock(&aspm_lock);
+		up_read(&pci_bus_sem);
+		return;
+	}
+
 	if (!parent || !parent->link_state)
 		return;
 
@@ -965,11 +980,6 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
 
 	/* All functions are removed, so just disable ASPM for the link */
 	pcie_config_aspm_link(link, 0);
-	list_del(&link->sibling);
-	list_del(&link->link);
-	/* Clock PM is for endpoint device */
-	free_link_state(link);
-
 	/* Recheck latencies and configure upstream links */
 	if (parent_link) {
 		pcie_update_aspm_capable(root);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 73a03d3..7e14ebd 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -25,8 +25,7 @@ static void pci_stop_dev(struct pci_dev *dev)
 		dev->is_added = 0;
 	}
 
-	if (dev->bus->self)
-		pcie_aspm_exit_link_state(dev);
+	pcie_aspm_exit_link_state(dev);
 }
 
 static void pci_destroy_dev(struct pci_dev *dev)
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 4/4] PCI/ASPM: move link_state cleanup to bridge remove

[Sinan Kaya]

For endpoints, change pcie_aspm_exit_link_state() so it cleans up
the device's own state and disables ASPM if necessary, but doesn't
remove the parent's link_state.

For bridges, change pcie_aspm_exit_link_state() so it frees the
bridge's own link_state.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/pci/pcie/aspm.c | 20 +++++++++++++++-----
 drivers/pci/remove.c    |  3 +--
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f48bb29..db3fbd9 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -947,6 +947,21 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
 	struct pci_dev *parent = pdev->bus->self;
 	struct pcie_link_state *link, *root, *parent_link;
 
+	if (pdev->has_secondary_link) {
+		link = pdev->link_state;
+		down_read(&pci_bus_sem);
+		mutex_lock(&aspm_lock);
+
+		list_del(&link->sibling);
+		list_del(&link->link);
+
+		/* Clock PM is for endpoint device */
+		free_link_state(link);
+		mutex_unlock(&aspm_lock);
+		up_read(&pci_bus_sem);
+		return;
+	}
+
 	if (!parent || !parent->link_state)
 		return;
 
@@ -965,11 +980,6 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
 
 	/* All functions are removed, so just disable ASPM for the link */
 	pcie_config_aspm_link(link, 0);
-	list_del(&link->sibling);
-	list_del(&link->link);
-	/* Clock PM is for endpoint device */
-	free_link_state(link);
-
 	/* Recheck latencies and configure upstream links */
 	if (parent_link) {
 		pcie_update_aspm_capable(root);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 73a03d3..7e14ebd 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -25,8 +25,7 @@ static void pci_stop_dev(struct pci_dev *dev)
 		dev->is_added = 0;
 	}
 
-	if (dev->bus->self)
-		pcie_aspm_exit_link_state(dev);
+	pcie_aspm_exit_link_state(dev);
 }
 
 static void pci_destroy_dev(struct pci_dev *dev)
-- 
1.9.1

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

Hi Mayurkumkar,

On 3/25/2017 5:38 PM, Sinan Kaya wrote:
> When the operating system is booted with the default ASPM policy
> (POLICY_DEFAULT), current code is querying the enable/disable
> states from ASPM registers to determine the policy.
> 
> For example, a BIOS could set the power saving state to performance
> and clear all ASPM control registers. A balanced ASPM policy could
> enable L0s and disable L1. A power conscious BIOS could enable both
> L0s and L1 to trade off latency and performance vs. power.
> 
> After hotplug removal, pcie_aspm_exit_link_state() function clears
> the ASPM registers. An insertion following hotplug removal reads
> incorrect policy as ASPM disabled even though ASPM was enabled
> during boot.
> 
> This is caused by the fact that same function is used for reconfiguring
> ASPM regardless of the power on state.
> 
> ------------------------
> Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
> ------------------------
> - pci_aspm_init(): Fix function comment.  Called for every device we
>   enumerate.
> 	Upstream link partner:  Shouldn't need to check pdev->link_state
>         (should always be NULL for a brand-new device).
> 
> - pcie_aspm_init_link_state(): Called for bridges (upstream end of
>     link) after all children have been enumerated.  No longer needs to
>     check aspm_support_enabled or pdev->has_secondary_link or the VIA
>     quirk: pci_aspm_init() already checked that stuff, so we only need
>     to check pdev->link_state here.
> 
> - split the last patch into two
>   PCI/ASPM: move link_state cleanup to bridge remove
>   PCI/ASPM: save power on values during bridge init
> 
> - create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
> - add fixes tags
> 
> Sinan Kaya (4):
>   PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
>   PCI/ASPM: add init hook to device_add
>   PCI/ASPM: save power on values during bridge init
>   PCI/ASPM: move link_state cleanup to bridge remove
> 
>  drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
>  drivers/pci/probe.c     |  3 ++
>  drivers/pci/remove.c    |  3 +-
>  include/linux/pci.h     |  2 ++
>  4 files changed, 69 insertions(+), 32 deletions(-)
> 

Can you test this on your system and provide your tested-by if all good?

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

Hi Mayurkumkar,

On 3/25/2017 5:38 PM, Sinan Kaya wrote:
> When the operating system is booted with the default ASPM policy
> (POLICY_DEFAULT), current code is querying the enable/disable
> states from ASPM registers to determine the policy.
> 
> For example, a BIOS could set the power saving state to performance
> and clear all ASPM control registers. A balanced ASPM policy could
> enable L0s and disable L1. A power conscious BIOS could enable both
> L0s and L1 to trade off latency and performance vs. power.
> 
> After hotplug removal, pcie_aspm_exit_link_state() function clears
> the ASPM registers. An insertion following hotplug removal reads
> incorrect policy as ASPM disabled even though ASPM was enabled
> during boot.
> 
> This is caused by the fact that same function is used for reconfiguring
> ASPM regardless of the power on state.
> 
> ------------------------
> Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
> ------------------------
> - pci_aspm_init(): Fix function comment.  Called for every device we
>   enumerate.
> 	Upstream link partner:  Shouldn't need to check pdev->link_state
>         (should always be NULL for a brand-new device).
> 
> - pcie_aspm_init_link_state(): Called for bridges (upstream end of
>     link) after all children have been enumerated.  No longer needs to
>     check aspm_support_enabled or pdev->has_secondary_link or the VIA
>     quirk: pci_aspm_init() already checked that stuff, so we only need
>     to check pdev->link_state here.
> 
> - split the last patch into two
>   PCI/ASPM: move link_state cleanup to bridge remove
>   PCI/ASPM: save power on values during bridge init
> 
> - create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
> - add fixes tags
> 
> Sinan Kaya (4):
>   PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
>   PCI/ASPM: add init hook to device_add
>   PCI/ASPM: save power on values during bridge init
>   PCI/ASPM: move link_state cleanup to bridge remove
> 
>  drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
>  drivers/pci/probe.c     |  3 ++
>  drivers/pci/remove.c    |  3 +-
>  include/linux/pci.h     |  2 ++
>  4 files changed, 69 insertions(+), 32 deletions(-)
> 

Can you test this on your system and provide your tested-by if all good?

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

Hi Mayurkumkar,

On 3/25/2017 5:38 PM, Sinan Kaya wrote:
> When the operating system is booted with the default ASPM policy
> (POLICY_DEFAULT), current code is querying the enable/disable
> states from ASPM registers to determine the policy.
> 
> For example, a BIOS could set the power saving state to performance
> and clear all ASPM control registers. A balanced ASPM policy could
> enable L0s and disable L1. A power conscious BIOS could enable both
> L0s and L1 to trade off latency and performance vs. power.
> 
> After hotplug removal, pcie_aspm_exit_link_state() function clears
> the ASPM registers. An insertion following hotplug removal reads
> incorrect policy as ASPM disabled even though ASPM was enabled
> during boot.
> 
> This is caused by the fact that same function is used for reconfiguring
> ASPM regardless of the power on state.
> 
> ------------------------
> Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
> ------------------------
> - pci_aspm_init(): Fix function comment.  Called for every device we
>   enumerate.
> 	Upstream link partner:  Shouldn't need to check pdev->link_state
>         (should always be NULL for a brand-new device).
> 
> - pcie_aspm_init_link_state(): Called for bridges (upstream end of
>     link) after all children have been enumerated.  No longer needs to
>     check aspm_support_enabled or pdev->has_secondary_link or the VIA
>     quirk: pci_aspm_init() already checked that stuff, so we only need
>     to check pdev->link_state here.
> 
> - split the last patch into two
>   PCI/ASPM: move link_state cleanup to bridge remove
>   PCI/ASPM: save power on values during bridge init
> 
> - create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
> - add fixes tags
> 
> Sinan Kaya (4):
>   PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
>   PCI/ASPM: add init hook to device_add
>   PCI/ASPM: save power on values during bridge init
>   PCI/ASPM: move link_state cleanup to bridge remove
> 
>  drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
>  drivers/pci/probe.c     |  3 ++
>  drivers/pci/remove.c    |  3 +-
>  include/linux/pci.h     |  2 ++
>  4 files changed, 69 insertions(+), 32 deletions(-)
> 

Can you test this on your system and provide your tested-by if all good?

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

RE: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

Hi Sinan

>Hi Mayurkumkar,
>
>On 3/25/2017 5:38 PM, Sinan Kaya wrote:
>> When the operating system is booted with the default ASPM policy
>> (POLICY_DEFAULT), current code is querying the enable/disable
>> states from ASPM registers to determine the policy.
>>
>> For example, a BIOS could set the power saving state to performance
>> and clear all ASPM control registers. A balanced ASPM policy could
>> enable L0s and disable L1. A power conscious BIOS could enable both
>> L0s and L1 to trade off latency and performance vs. power.
>>
>> After hotplug removal, pcie_aspm_exit_link_state() function clears
>> the ASPM registers. An insertion following hotplug removal reads
>> incorrect policy as ASPM disabled even though ASPM was enabled
>> during boot.
>>
>> This is caused by the fact that same function is used for reconfiguring
>> ASPM regardless of the power on state.
>>
>> ------------------------
>> Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
>> ------------------------
>> - pci_aspm_init(): Fix function comment.  Called for every device we
>>   enumerate.
>> 	Upstream link partner:  Shouldn't need to check pdev->link_state
>>         (should always be NULL for a brand-new device).
>>
>> - pcie_aspm_init_link_state(): Called for bridges (upstream end of
>>     link) after all children have been enumerated.  No longer needs to
>>     check aspm_support_enabled or pdev->has_secondary_link or the VIA
>>     quirk: pci_aspm_init() already checked that stuff, so we only need
>>     to check pdev->link_state here.
>>
>> - split the last patch into two
>>   PCI/ASPM: move link_state cleanup to bridge remove
>>   PCI/ASPM: save power on values during bridge init
>>
>> - create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
>> - add fixes tags
>>
>> Sinan Kaya (4):
>>   PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
>>   PCI/ASPM: add init hook to device_add
>>   PCI/ASPM: save power on values during bridge init
>>   PCI/ASPM: move link_state cleanup to bridge remove
>>
>>  drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
>>  drivers/pci/probe.c     |  3 ++
>>  drivers/pci/remove.c    |  3 +-
>>  include/linux/pci.h     |  2 ++
>>  4 files changed, 69 insertions(+), 32 deletions(-)
>>
>
>Can you test this on your system and provide your tested-by if all good?
>
>Sinan
>

Thanks for your patches. I am seeing kernel panic after applying
these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
Need to check if it's something related to my local setup or it's because of these changes.
For now I don't have more details why it crashes but I will dig in further and I will provide
you more data as soon as I have it.

>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

Hi Sinan

>Hi Mayurkumkar,
>
>On 3/25/2017 5:38 PM, Sinan Kaya wrote:
>> When the operating system is booted with the default ASPM policy
>> (POLICY_DEFAULT), current code is querying the enable/disable
>> states from ASPM registers to determine the policy.
>>
>> For example, a BIOS could set the power saving state to performance
>> and clear all ASPM control registers. A balanced ASPM policy could
>> enable L0s and disable L1. A power conscious BIOS could enable both
>> L0s and L1 to trade off latency and performance vs. power.
>>
>> After hotplug removal, pcie_aspm_exit_link_state() function clears
>> the ASPM registers. An insertion following hotplug removal reads
>> incorrect policy as ASPM disabled even though ASPM was enabled
>> during boot.
>>
>> This is caused by the fact that same function is used for reconfiguring
>> ASPM regardless of the power on state.
>>
>> ------------------------
>> Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
>> ------------------------
>> - pci_aspm_init(): Fix function comment.  Called for every device we
>>   enumerate.
>> 	Upstream link partner:  Shouldn't need to check pdev->link_state
>>         (should always be NULL for a brand-new device).
>>
>> - pcie_aspm_init_link_state(): Called for bridges (upstream end of
>>     link) after all children have been enumerated.  No longer needs to
>>     check aspm_support_enabled or pdev->has_secondary_link or the VIA
>>     quirk: pci_aspm_init() already checked that stuff, so we only need
>>     to check pdev->link_state here.
>>
>> - split the last patch into two
>>   PCI/ASPM: move link_state cleanup to bridge remove
>>   PCI/ASPM: save power on values during bridge init
>>
>> - create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
>> - add fixes tags
>>
>> Sinan Kaya (4):
>>   PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
>>   PCI/ASPM: add init hook to device_add
>>   PCI/ASPM: save power on values during bridge init
>>   PCI/ASPM: move link_state cleanup to bridge remove
>>
>>  drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
>>  drivers/pci/probe.c     |  3 ++
>>  drivers/pci/remove.c    |  3 +-
>>  include/linux/pci.h     |  2 ++
>>  4 files changed, 69 insertions(+), 32 deletions(-)
>>
>
>Can you test this on your system and provide your tested-by if all good?
>
>Sinan
>

Thanks for your patches. I am seeing kernel panic after applying
these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
Need to check if it's something related to my local setup or it's because of these changes.
For now I don't have more details why it crashes but I will dig in further and I will provide
you more data as soon as I have it.

>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

Hi Sinan

>Hi Mayurkumkar,
>
>On 3/25/2017 5:38 PM, Sinan Kaya wrote:
>> When the operating system is booted with the default ASPM policy
>> (POLICY_DEFAULT), current code is querying the enable/disable
>> states from ASPM registers to determine the policy.
>>
>> For example, a BIOS could set the power saving state to performance
>> and clear all ASPM control registers. A balanced ASPM policy could
>> enable L0s and disable L1. A power conscious BIOS could enable both
>> L0s and L1 to trade off latency and performance vs. power.
>>
>> After hotplug removal, pcie_aspm_exit_link_state() function clears
>> the ASPM registers. An insertion following hotplug removal reads
>> incorrect policy as ASPM disabled even though ASPM was enabled
>> during boot.
>>
>> This is caused by the fact that same function is used for reconfiguring
>> ASPM regardless of the power on state.
>>
>> ------------------------
>> Changes from v4 (http://www.spinics.net/lists/linux-pci/msg59245.html)
>> ------------------------
>> - pci_aspm_init(): Fix function comment.  Called for every device we
>>   enumerate.
>> 	Upstream link partner:  Shouldn't need to check pdev->link_state
>>         (should always be NULL for a brand-new device).
>>
>> - pcie_aspm_init_link_state(): Called for bridges (upstream end of
>>     link) after all children have been enumerated.  No longer needs to
>>     check aspm_support_enabled or pdev->has_secondary_link or the VIA
>>     quirk: pci_aspm_init() already checked that stuff, so we only need
>>     to check pdev->link_state here.
>>
>> - split the last patch into two
>>   PCI/ASPM: move link_state cleanup to bridge remove
>>   PCI/ASPM: save power on values during bridge init
>>
>> - create bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=194895)
>> - add fixes tags
>>
>> Sinan Kaya (4):
>>   PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
>>   PCI/ASPM: add init hook to device_add
>>   PCI/ASPM: save power on values during bridge init
>>   PCI/ASPM: move link_state cleanup to bridge remove
>>
>>  drivers/pci/pcie/aspm.c | 93 +++++++++++++++++++++++++++++++++----------------
>>  drivers/pci/probe.c     |  3 ++
>>  drivers/pci/remove.c    |  3 +-
>>  include/linux/pci.h     |  2 ++
>>  4 files changed, 69 insertions(+), 32 deletions(-)
>>
>
>Can you test this on your system and provide your tested-by if all good?
>
>Sinan
>

Thanks for your patches. I am seeing kernel panic after applying
these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
Need to check if it's something related to my local setup or it's because of these changes.
For now I don't have more details why it crashes but I will dig in further and I will provide
you more data as soon as I have it.

>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
> Thanks for your patches. I am seeing kernel panic after applying
> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
> Need to check if it's something related to my local setup or it's because of these changes.
> For now I don't have more details why it crashes but I will dig in further and I will provide
> you more data as soon as I have it.
> 

Interesting, I retested Qemu and I don't see an issue. 
Can you share your bootlog when you see the crash?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
> Thanks for your patches. I am seeing kernel panic after applying
> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
> Need to check if it's something related to my local setup or it's because of these changes.
> For now I don't have more details why it crashes but I will dig in further and I will provide
> you more data as soon as I have it.
> 

Interesting, I retested Qemu and I don't see an issue. 
Can you share your bootlog when you see the crash?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
> Thanks for your patches. I am seeing kernel panic after applying
> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
> Need to check if it's something related to my local setup or it's because of these changes.
> For now I don't have more details why it crashes but I will dig in further and I will provide
> you more data as soon as I have it.
> 

Interesting, I retested Qemu and I don't see an issue. 
Can you share your bootlog when you see the crash?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 8:52 AM, Sinan Kaya wrote:
> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>> Thanks for your patches. I am seeing kernel panic after applying
>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>> Need to check if it's something related to my local setup or it's because of these changes.
>> For now I don't have more details why it crashes but I will dig in further and I will provide
>> you more data as soon as I have it.
>>
> 
> Interesting, I retested Qemu and I don't see an issue. 
> Can you share your bootlog when you see the crash?
> 
Thinking more...

Can you add this to the top of pci_aspm_init() and try again?

if (!pci_is_pcie(pdev))
          return -EINVAL;

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 8:52 AM, Sinan Kaya wrote:
> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>> Thanks for your patches. I am seeing kernel panic after applying
>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>> Need to check if it's something related to my local setup or it's because of these changes.
>> For now I don't have more details why it crashes but I will dig in further and I will provide
>> you more data as soon as I have it.
>>
> 
> Interesting, I retested Qemu and I don't see an issue. 
> Can you share your bootlog when you see the crash?
> 
Thinking more...

Can you add this to the top of pci_aspm_init() and try again?

if (!pci_is_pcie(pdev))
          return -EINVAL;

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 8:52 AM, Sinan Kaya wrote:
> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>> Thanks for your patches. I am seeing kernel panic after applying
>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>> Need to check if it's something related to my local setup or it's because of these changes.
>> For now I don't have more details why it crashes but I will dig in further and I will provide
>> you more data as soon as I have it.
>>
> 
> Interesting, I retested Qemu and I don't see an issue. 
> Can you share your bootlog when you see the crash?
> 
Thinking more...

Can you add this to the top of pci_aspm_init() and try again?

if (!pci_is_pcie(pdev))
          return -EINVAL;

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 9:04 AM, Sinan Kaya wrote:
> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>> Thanks for your patches. I am seeing kernel panic after applying
>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>> Need to check if it's something related to my local setup or it's because of these changes.
>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>> you more data as soon as I have it.
>>>
>>
>> Interesting, I retested Qemu and I don't see an issue. 
>> Can you share your bootlog when you see the crash?
>>
> Thinking more...
> 
> Can you add this to the top of pci_aspm_init() and try again?
> 
> if (!pci_is_pcie(pdev))
>           return -EINVAL;
> 

Did this help?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 9:04 AM, Sinan Kaya wrote:
> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>> Thanks for your patches. I am seeing kernel panic after applying
>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>> Need to check if it's something related to my local setup or it's because of these changes.
>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>> you more data as soon as I have it.
>>>
>>
>> Interesting, I retested Qemu and I don't see an issue. 
>> Can you share your bootlog when you see the crash?
>>
> Thinking more...
> 
> Can you add this to the top of pci_aspm_init() and try again?
> 
> if (!pci_is_pcie(pdev))
>           return -EINVAL;
> 

Did this help?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/28/2017 9:04 AM, Sinan Kaya wrote:
> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>> Thanks for your patches. I am seeing kernel panic after applying
>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>> Need to check if it's something related to my local setup or it's because of these changes.
>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>> you more data as soon as I have it.
>>>
>>
>> Interesting, I retested Qemu and I don't see an issue. 
>> Can you share your bootlog when you see the crash?
>>
> Thinking more...
> 
> Can you add this to the top of pci_aspm_init() and try again?
> 
> if (!pci_is_pcie(pdev))
>           return -EINVAL;
> 

Did this help?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

RE: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

Hi Kaya

>
>On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>> you more data as soon as I have it.
>>>>
>>>
>>> Interesting, I retested Qemu and I don't see an issue.
>>> Can you share your bootlog when you see the crash?
>>>
>> Thinking more...
>>
>> Can you add this to the top of pci_aspm_init() and try again?
>>
>> if (!pci_is_pcie(pdev))
>>           return -EINVAL;
>>
>
>Did this help?

No, It did not helped. I tested without your patches and no panic seen.

I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
pci_function_0().
I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your mind
what this could be I could try that too.

[    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
[    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
[    0.989555] PGD 0
[    0.989556]
[    1.031360] Oops: 0000 [#1] SMP
[    1.068901] Modules linked in:
[    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
[    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
[    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
[    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
[    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
[    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
[    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
[    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
[    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
[    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
[    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
[    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
[    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    2.310150] Call Trace:
[    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
[    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
[    2.444611]  ? pci_device_add+0x20a/0x300
[    2.492554]  pci_scan_slot+0xd7/0x110
[    2.536335]  pci_scan_child_bus+0x30/0x180
[    2.585313]  pci_scan_bridge+0x3f0/0x670
[    2.632215]  ? pci_scan_single_device+0x6d/0xd0
[    2.686394]  pci_scan_child_bus+0x9f/0x180
[    2.735375]  acpi_pci_root_create+0x182/0x1de
[    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
[    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
[    2.886474]  acpi_bus_attach+0xdf/0x18e
[    2.932336]  acpi_bus_attach+0x135/0x18e
[    2.979234]  acpi_bus_attach+0x135/0x18e
[    3.026135]  acpi_bus_scan+0x6e/0x8d
[    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
[    3.120976]  acpi_scan_init+0xda/0x237
[    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
[    3.217895]  acpi_init+0x2be/0x347

>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

Hi Kaya

>
>On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>> you more data as soon as I have it.
>>>>
>>>
>>> Interesting, I retested Qemu and I don't see an issue.
>>> Can you share your bootlog when you see the crash?
>>>
>> Thinking more...
>>
>> Can you add this to the top of pci_aspm_init() and try again?
>>
>> if (!pci_is_pcie(pdev))
>>           return -EINVAL;
>>
>
>Did this help?

No, It did not helped. I tested without your patches and no panic seen.

I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
pci_function_0().
I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your mind
what this could be I could try that too.

[    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
[    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
[    0.989555] PGD 0
[    0.989556]
[    1.031360] Oops: 0000 [#1] SMP
[    1.068901] Modules linked in:
[    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
[    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
[    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
[    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
[    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
[    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
[    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
[    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
[    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
[    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
[    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
[    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
[    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    2.310150] Call Trace:
[    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
[    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
[    2.444611]  ? pci_device_add+0x20a/0x300
[    2.492554]  pci_scan_slot+0xd7/0x110
[    2.536335]  pci_scan_child_bus+0x30/0x180
[    2.585313]  pci_scan_bridge+0x3f0/0x670
[    2.632215]  ? pci_scan_single_device+0x6d/0xd0
[    2.686394]  pci_scan_child_bus+0x9f/0x180
[    2.735375]  acpi_pci_root_create+0x182/0x1de
[    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
[    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
[    2.886474]  acpi_bus_attach+0xdf/0x18e
[    2.932336]  acpi_bus_attach+0x135/0x18e
[    2.979234]  acpi_bus_attach+0x135/0x18e
[    3.026135]  acpi_bus_scan+0x6e/0x8d
[    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
[    3.120976]  acpi_scan_init+0xda/0x237
[    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
[    3.217895]  acpi_init+0x2be/0x347

>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

Hi Kaya

>
>On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>> you more data as soon as I have it.
>>>>
>>>
>>> Interesting, I retested Qemu and I don't see an issue.
>>> Can you share your bootlog when you see the crash?
>>>
>> Thinking more...
>>
>> Can you add this to the top of pci_aspm_init() and try again?
>>
>> if (!pci_is_pcie(pdev))
>>           return -EINVAL;
>>
>
>Did this help?

No, It did not helped. I tested without your patches and no panic seen.

I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
pci_function_0().
I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your mind
what this could be I could try that too.

[    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
[    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
[    0.989555] PGD 0
[    0.989556]
[    1.031360] Oops: 0000 [#1] SMP
[    1.068901] Modules linked in:
[    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
[    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
[    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
[    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
[    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
[    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
[    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
[    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
[    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
[    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
[    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
[    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
[    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    2.310150] Call Trace:
[    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
[    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
[    2.444611]  ? pci_device_add+0x20a/0x300
[    2.492554]  pci_scan_slot+0xd7/0x110
[    2.536335]  pci_scan_child_bus+0x30/0x180
[    2.585313]  pci_scan_bridge+0x3f0/0x670
[    2.632215]  ? pci_scan_single_device+0x6d/0xd0
[    2.686394]  pci_scan_child_bus+0x9f/0x180
[    2.735375]  acpi_pci_root_create+0x182/0x1de
[    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
[    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
[    2.886474]  acpi_bus_attach+0xdf/0x18e
[    2.932336]  acpi_bus_attach+0x135/0x18e
[    2.979234]  acpi_bus_attach+0x135/0x18e
[    3.026135]  acpi_bus_scan+0x6e/0x8d
[    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
[    3.120976]  acpi_scan_init+0xda/0x237
[    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
[    3.217895]  acpi_init+0x2be/0x347

>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 1:27 PM, Patel, Mayurkumar wrote:
> Hi Kaya
> 
>>
>> On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>>> you more data as soon as I have it.
>>>>>
>>>>
>>>> Interesting, I retested Qemu and I don't see an issue.
>>>> Can you share your bootlog when you see the crash?
>>>>
>>> Thinking more...
>>>
>>> Can you add this to the top of pci_aspm_init() and try again?
>>>
>>> if (!pci_is_pcie(pdev))
>>>           return -EINVAL;
>>>
>>
>> Did this help?
> 
> No, It did not helped. I tested without your patches and no panic seen.

I think you have a mixture of old and new patches or a mixture of old/new object files.
pci_function_0() is no longer getting called from pci_aspm_init(). This was done in V4 of the patch.

> 
> I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
> pci_function_0().
> I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
> then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your mind
> what this could be I could try that too.
> 

I think you have a mixture of old and new patches or a mixture of old/new object files.

> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
> [    2.444611]  ? pci_device_add+0x20a/0x300

This was also done in V4 of the patch. This was replaced by pci_aspm_init() in V5 and
there is no call from device_add path into pci_aspm_init() function. The 
pcie_aspm_init_link_state() gets called from the pci_scan_slot() as it used to be.

Can you try it on a clean tree with the following patches?

https://patchwork.codeaurora.org/patch/207667/
https://patchwork.codeaurora.org/patch/207653/
https://patchwork.codeaurora.org/patch/207669/
https://patchwork.codeaurora.org/patch/207651/

The only change you should need on top of this is this.

--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -847,6 +847,9 @@ int pci_aspm_init(struct pci_dev *pdev)
        if (!pdev->has_secondary_link)
                return 0;

+       if (!pci_is_pcie(pdev))
+               return -EINVAL;
+
        link = alloc_pcie_link_state(pdev);
        if (!link)
                return -ENOMEM;



> [    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
> [    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
> [    0.989555] PGD 0
> [    0.989556]
> [    1.031360] Oops: 0000 [#1] SMP
> [    1.068901] Modules linked in:
> [    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
> [    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
> [    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
> [    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
> [    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
> [    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
> [    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
> [    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
> [    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
> [    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
> [    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
> [    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
> [    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [    2.310150] Call Trace:
> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
> [    2.444611]  ? pci_device_add+0x20a/0x300
> [    2.492554]  pci_scan_slot+0xd7/0x110
> [    2.536335]  pci_scan_child_bus+0x30/0x180
> [    2.585313]  pci_scan_bridge+0x3f0/0x670
> [    2.632215]  ? pci_scan_single_device+0x6d/0xd0
> [    2.686394]  pci_scan_child_bus+0x9f/0x180
> [    2.735375]  acpi_pci_root_create+0x182/0x1de
> [    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
> [    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
> [    2.886474]  acpi_bus_attach+0xdf/0x18e
> [    2.932336]  acpi_bus_attach+0x135/0x18e
> [    2.979234]  acpi_bus_attach+0x135/0x18e
> [    3.026135]  acpi_bus_scan+0x6e/0x8d
> [    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
> [    3.120976]  acpi_scan_init+0xda/0x237
> [    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
> [    3.217895]  acpi_init+0x2be/0x347
> 
>>
>> --
>> Sinan Kaya
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 1:27 PM, Patel, Mayurkumar wrote:
> Hi Kaya
> 
>>
>> On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>>> you more data as soon as I have it.
>>>>>
>>>>
>>>> Interesting, I retested Qemu and I don't see an issue.
>>>> Can you share your bootlog when you see the crash?
>>>>
>>> Thinking more...
>>>
>>> Can you add this to the top of pci_aspm_init() and try again?
>>>
>>> if (!pci_is_pcie(pdev))
>>>           return -EINVAL;
>>>
>>
>> Did this help?
> 
> No, It did not helped. I tested without your patches and no panic seen.

I think you have a mixture of old and new patches or a mixture of old/new object files.
pci_function_0() is no longer getting called from pci_aspm_init(). This was done in V4 of the patch.

> 
> I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
> pci_function_0().
> I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
> then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your mind
> what this could be I could try that too.
> 

I think you have a mixture of old and new patches or a mixture of old/new object files.

> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
> [    2.444611]  ? pci_device_add+0x20a/0x300

This was also done in V4 of the patch. This was replaced by pci_aspm_init() in V5 and
there is no call from device_add path into pci_aspm_init() function. The 
pcie_aspm_init_link_state() gets called from the pci_scan_slot() as it used to be.

Can you try it on a clean tree with the following patches?

https://patchwork.codeaurora.org/patch/207667/
https://patchwork.codeaurora.org/patch/207653/
https://patchwork.codeaurora.org/patch/207669/
https://patchwork.codeaurora.org/patch/207651/

The only change you should need on top of this is this.

--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -847,6 +847,9 @@ int pci_aspm_init(struct pci_dev *pdev)
        if (!pdev->has_secondary_link)
                return 0;

+       if (!pci_is_pcie(pdev))
+               return -EINVAL;
+
        link = alloc_pcie_link_state(pdev);
        if (!link)
                return -ENOMEM;



> [    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
> [    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
> [    0.989555] PGD 0
> [    0.989556]
> [    1.031360] Oops: 0000 [#1] SMP
> [    1.068901] Modules linked in:
> [    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
> [    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
> [    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
> [    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
> [    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
> [    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
> [    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
> [    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
> [    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
> [    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
> [    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
> [    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
> [    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [    2.310150] Call Trace:
> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
> [    2.444611]  ? pci_device_add+0x20a/0x300
> [    2.492554]  pci_scan_slot+0xd7/0x110
> [    2.536335]  pci_scan_child_bus+0x30/0x180
> [    2.585313]  pci_scan_bridge+0x3f0/0x670
> [    2.632215]  ? pci_scan_single_device+0x6d/0xd0
> [    2.686394]  pci_scan_child_bus+0x9f/0x180
> [    2.735375]  acpi_pci_root_create+0x182/0x1de
> [    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
> [    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
> [    2.886474]  acpi_bus_attach+0xdf/0x18e
> [    2.932336]  acpi_bus_attach+0x135/0x18e
> [    2.979234]  acpi_bus_attach+0x135/0x18e
> [    3.026135]  acpi_bus_scan+0x6e/0x8d
> [    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
> [    3.120976]  acpi_scan_init+0xda/0x237
> [    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
> [    3.217895]  acpi_init+0x2be/0x347
> 
>>
>> --
>> Sinan Kaya
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 1:27 PM, Patel, Mayurkumar wrote:
> Hi Kaya
> 
>>
>> On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>>> you more data as soon as I have it.
>>>>>
>>>>
>>>> Interesting, I retested Qemu and I don't see an issue.
>>>> Can you share your bootlog when you see the crash?
>>>>
>>> Thinking more...
>>>
>>> Can you add this to the top of pci_aspm_init() and try again?
>>>
>>> if (!pci_is_pcie(pdev))
>>>           return -EINVAL;
>>>
>>
>> Did this help?
> 
> No, It did not helped. I tested without your patches and no panic seen.

I think you have a mixture of old and new patches or a mixture of old/new object files.
pci_function_0() is no longer getting called from pci_aspm_init(). This was done in V4 of the patch.

> 
> I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
> pci_function_0().
> I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
> then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your mind
> what this could be I could try that too.
> 

I think you have a mixture of old and new patches or a mixture of old/new object files.

> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
> [    2.444611]  ? pci_device_add+0x20a/0x300

This was also done in V4 of the patch. This was replaced by pci_aspm_init() in V5 and
there is no call from device_add path into pci_aspm_init() function. The 
pcie_aspm_init_link_state() gets called from the pci_scan_slot() as it used to be.

Can you try it on a clean tree with the following patches?

https://patchwork.codeaurora.org/patch/207667/
https://patchwork.codeaurora.org/patch/207653/
https://patchwork.codeaurora.org/patch/207669/
https://patchwork.codeaurora.org/patch/207651/

The only change you should need on top of this is this.

--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -847,6 +847,9 @@ int pci_aspm_init(struct pci_dev *pdev)
        if (!pdev->has_secondary_link)
                return 0;

+       if (!pci_is_pcie(pdev))
+               return -EINVAL;
+
        link = alloc_pcie_link_state(pdev);
        if (!link)
                return -ENOMEM;



> [    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
> [    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
> [    0.989555] PGD 0
> [    0.989556]
> [    1.031360] Oops: 0000 [#1] SMP
> [    1.068901] Modules linked in:
> [    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
> [    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
> [    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
> [    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
> [    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
> [    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
> [    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
> [    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
> [    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
> [    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
> [    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
> [    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
> [    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [    2.310150] Call Trace:
> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
> [    2.444611]  ? pci_device_add+0x20a/0x300
> [    2.492554]  pci_scan_slot+0xd7/0x110
> [    2.536335]  pci_scan_child_bus+0x30/0x180
> [    2.585313]  pci_scan_bridge+0x3f0/0x670
> [    2.632215]  ? pci_scan_single_device+0x6d/0xd0
> [    2.686394]  pci_scan_child_bus+0x9f/0x180
> [    2.735375]  acpi_pci_root_create+0x182/0x1de
> [    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
> [    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
> [    2.886474]  acpi_bus_attach+0xdf/0x18e
> [    2.932336]  acpi_bus_attach+0x135/0x18e
> [    2.979234]  acpi_bus_attach+0x135/0x18e
> [    3.026135]  acpi_bus_scan+0x6e/0x8d
> [    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
> [    3.120976]  acpi_scan_init+0xda/0x237
> [    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
> [    3.217895]  acpi_init+0x2be/0x347
> 
>>
>> --
>> Sinan Kaya
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

RE: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

>On 3/29/2017 1:27 PM, Patel, Mayurkumar wrote:
>> Hi Kaya
>>
>>>
>>> On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>>>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>>>> you more data as soon as I have it.
>>>>>>
>>>>>
>>>>> Interesting, I retested Qemu and I don't see an issue.
>>>>> Can you share your bootlog when you see the crash?
>>>>>
>>>> Thinking more...
>>>>
>>>> Can you add this to the top of pci_aspm_init() and try again?
>>>>
>>>> if (!pci_is_pcie(pdev))
>>>>           return -EINVAL;
>>>>
>>>
>>> Did this help?
>>
>> No, It did not helped. I tested without your patches and no panic seen.
>
>I think you have a mixture of old and new patches or a mixture of old/new object files.
>pci_function_0() is no longer getting called from pci_aspm_init(). This was done in V4 of the patch.
>


>>
>> I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
>> pci_function_0().
>> I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
>> then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your
>mind
>> what this could be I could try that too.
>>
>
>I think you have a mixture of old and new patches or a mixture of old/new object files.
>
>> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
>> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
>> [    2.444611]  ? pci_device_add+0x20a/0x300
>
>This was also done in V4 of the patch. This was replaced by pci_aspm_init() in V5 and
>there is no call from device_add path into pci_aspm_init() function. The
>pcie_aspm_init_link_state() gets called from the pci_scan_slot() as it used to be.
>
>Can you try it on a clean tree with the following patches?
>
>https://patchwork.codeaurora.org/patch/207667/
>https://patchwork.codeaurora.org/patch/207653/
>https://patchwork.codeaurora.org/patch/207669/
>https://patchwork.codeaurora.org/patch/207651/
>
>The only change you should need on top of this is this.
>
>--- a/drivers/pci/pcie/aspm.c
>+++ b/drivers/pci/pcie/aspm.c
>@@ -847,6 +847,9 @@ int pci_aspm_init(struct pci_dev *pdev)
>        if (!pdev->has_secondary_link)
>                return 0;
>
>+       if (!pci_is_pcie(pdev))
>+               return -EINVAL;
>+
>        link = alloc_pcie_link_state(pdev);
>        if (!link)
>                return -ENOMEM;
>
>

Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
build if that helps.

But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 

We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.

To mitigate that I included following code in it.

@@ -430,8 +439,11 @@ static struct pci_dev *pci_function_0(struct pci_bus *linkbus)
 {
 	struct pci_dev *child;
 
+	if (!linkbus)
+		return NULL;
+
 	list_for_each_entry(child, &linkbus->devices, bus_list)
		if (PCI_FUNC(child->devfn) == 0)
			return child;
 	return NULL;


Then I start seeing following error as pdev-> downstream stays NULL.

>
>> [    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
>> [    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
>> [    0.989555] PGD 0
>> [    0.989556]
>> [    1.031360] Oops: 0000 [#1] SMP
>> [    1.068901] Modules linked in:
>> [    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
>> [    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
>> [    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
>> [    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
>> [    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
>> [    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
>> [    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
>> [    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
>> [    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
>> [    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
>> [    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
>> [    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
>> [    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [    2.310150] Call Trace:
>> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
>> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
>> [    2.444611]  ? pci_device_add+0x20a/0x300
>> [    2.492554]  pci_scan_slot+0xd7/0x110
>> [    2.536335]  pci_scan_child_bus+0x30/0x180
>> [    2.585313]  pci_scan_bridge+0x3f0/0x670
>> [    2.632215]  ? pci_scan_single_device+0x6d/0xd0
>> [    2.686394]  pci_scan_child_bus+0x9f/0x180
>> [    2.735375]  acpi_pci_root_create+0x182/0x1de
>> [    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
>> [    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
>> [    2.886474]  acpi_bus_attach+0xdf/0x18e
>> [    2.932336]  acpi_bus_attach+0x135/0x18e
>> [    2.979234]  acpi_bus_attach+0x135/0x18e
>> [    3.026135]  acpi_bus_scan+0x6e/0x8d
>> [    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
>> [    3.120976]  acpi_scan_init+0xda/0x237
>> [    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
>> [    3.217895]  acpi_init+0x2be/0x347
>>
>>>
>>> --
>>> Sinan Kaya
>>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>> Intel Deutschland GmbH
>> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
>> Tel: +49 89 99 8853-0, www.intel.de
>> Managing Directors: Christin Eisenschmid, Christian Lamprechter
>> Chairperson of the Supervisory Board: Nicole Lau
>> Registered Office: Munich
>> Commercial Register: Amtsgericht Muenchen HRB 186928
>>
>>
>
>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

>On 3/29/2017 1:27 PM, Patel, Mayurkumar wrote:
>> Hi Kaya
>>
>>>
>>> On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>>>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>>>> you more data as soon as I have it.
>>>>>>
>>>>>
>>>>> Interesting, I retested Qemu and I don't see an issue.
>>>>> Can you share your bootlog when you see the crash?
>>>>>
>>>> Thinking more...
>>>>
>>>> Can you add this to the top of pci_aspm_init() and try again?
>>>>
>>>> if (!pci_is_pcie(pdev))
>>>>           return -EINVAL;
>>>>
>>>
>>> Did this help?
>>
>> No, It did not helped. I tested without your patches and no panic seen.
>
>I think you have a mixture of old and new patches or a mixture of old/new object files.
>pci_function_0() is no longer getting called from pci_aspm_init(). This was done in V4 of the patch.
>


>>
>> I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
>> pci_function_0().
>> I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
>> then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your
>mind
>> what this could be I could try that too.
>>
>
>I think you have a mixture of old and new patches or a mixture of old/new object files.
>
>> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
>> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
>> [    2.444611]  ? pci_device_add+0x20a/0x300
>
>This was also done in V4 of the patch. This was replaced by pci_aspm_init() in V5 and
>there is no call from device_add path into pci_aspm_init() function. The
>pcie_aspm_init_link_state() gets called from the pci_scan_slot() as it used to be.
>
>Can you try it on a clean tree with the following patches?
>
>https://patchwork.codeaurora.org/patch/207667/
>https://patchwork.codeaurora.org/patch/207653/
>https://patchwork.codeaurora.org/patch/207669/
>https://patchwork.codeaurora.org/patch/207651/
>
>The only change you should need on top of this is this.
>
>--- a/drivers/pci/pcie/aspm.c
>+++ b/drivers/pci/pcie/aspm.c
>@@ -847,6 +847,9 @@ int pci_aspm_init(struct pci_dev *pdev)
>        if (!pdev->has_secondary_link)
>                return 0;
>
>+       if (!pci_is_pcie(pdev))
>+               return -EINVAL;
>+
>        link = alloc_pcie_link_state(pdev);
>        if (!link)
>                return -ENOMEM;
>
>

Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
build if that helps.

But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 

We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.

To mitigate that I included following code in it.

@@ -430,8 +439,11 @@ static struct pci_dev *pci_function_0(struct pci_bus *linkbus)
 {
 	struct pci_dev *child;
 
+	if (!linkbus)
+		return NULL;
+
 	list_for_each_entry(child, &linkbus->devices, bus_list)
		if (PCI_FUNC(child->devfn) == 0)
			return child;
 	return NULL;


Then I start seeing following error as pdev-> downstream stays NULL.

>
>> [    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
>> [    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
>> [    0.989555] PGD 0
>> [    0.989556]
>> [    1.031360] Oops: 0000 [#1] SMP
>> [    1.068901] Modules linked in:
>> [    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
>> [    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
>> [    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
>> [    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
>> [    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
>> [    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
>> [    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
>> [    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
>> [    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
>> [    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
>> [    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
>> [    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
>> [    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [    2.310150] Call Trace:
>> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
>> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
>> [    2.444611]  ? pci_device_add+0x20a/0x300
>> [    2.492554]  pci_scan_slot+0xd7/0x110
>> [    2.536335]  pci_scan_child_bus+0x30/0x180
>> [    2.585313]  pci_scan_bridge+0x3f0/0x670
>> [    2.632215]  ? pci_scan_single_device+0x6d/0xd0
>> [    2.686394]  pci_scan_child_bus+0x9f/0x180
>> [    2.735375]  acpi_pci_root_create+0x182/0x1de
>> [    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
>> [    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
>> [    2.886474]  acpi_bus_attach+0xdf/0x18e
>> [    2.932336]  acpi_bus_attach+0x135/0x18e
>> [    2.979234]  acpi_bus_attach+0x135/0x18e
>> [    3.026135]  acpi_bus_scan+0x6e/0x8d
>> [    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
>> [    3.120976]  acpi_scan_init+0xda/0x237
>> [    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
>> [    3.217895]  acpi_init+0x2be/0x347
>>
>>>
>>> --
>>> Sinan Kaya
>>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>> Intel Deutschland GmbH
>> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
>> Tel: +49 89 99 8853-0, www.intel.de
>> Managing Directors: Christin Eisenschmid, Christian Lamprechter
>> Chairperson of the Supervisory Board: Nicole Lau
>> Registered Office: Munich
>> Commercial Register: Amtsgericht Muenchen HRB 186928
>>
>>
>
>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Patel, Mayurkumar]

>On 3/29/2017 1:27 PM, Patel, Mayurkumar wrote:
>> Hi Kaya
>>
>>>
>>> On 3/28/2017 9:04 AM, Sinan Kaya wrote:
>>>> On 3/28/2017 8:52 AM, Sinan Kaya wrote:
>>>>> On 3/28/2017 2:02 AM, Patel, Mayurkumar wrote:
>>>>>> Thanks for your patches. I am seeing kernel panic after applying
>>>>>> these patches (on top of latest kernel) each time during early boot in pci_aspm_init() (any hints already?) function.
>>>>>> Need to check if it's something related to my local setup or it's because of these changes.
>>>>>> For now I don't have more details why it crashes but I will dig in further and I will provide
>>>>>> you more data as soon as I have it.
>>>>>>
>>>>>
>>>>> Interesting, I retested Qemu and I don't see an issue.
>>>>> Can you share your bootlog when you see the crash?
>>>>>
>>>> Thinking more...
>>>>
>>>> Can you add this to the top of pci_aspm_init() and try again?
>>>>
>>>> if (!pci_is_pcie(pdev))
>>>>           return -EINVAL;
>>>>
>>>
>>> Did this help?
>>
>> No, It did not helped. I tested without your patches and no panic seen.
>
>I think you have a mixture of old and new patches or a mixture of old/new object files.
>pci_function_0() is no longer getting called from pci_aspm_init(). This was done in V4 of the patch.
>


>>
>> I found with your patch in pci_aspm_init() call, pdev->subordinate is not valid which causes a crash in
>> pci_function_0().
>> I tentatively started validating pdev->subordinate pointer and proceeding pci_aspm_init()  without allocating link->downstream pointer,
>> then I got another following issue during boot. I will further debug it but if you have any other suggestion or some other clicks in your
>mind
>> what this could be I could try that too.
>>
>
>I think you have a mixture of old and new patches or a mixture of old/new object files.
>
>> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
>> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
>> [    2.444611]  ? pci_device_add+0x20a/0x300
>
>This was also done in V4 of the patch. This was replaced by pci_aspm_init() in V5 and
>there is no call from device_add path into pci_aspm_init() function. The
>pcie_aspm_init_link_state() gets called from the pci_scan_slot() as it used to be.
>
>Can you try it on a clean tree with the following patches?
>
>https://patchwork.codeaurora.org/patch/207667/
>https://patchwork.codeaurora.org/patch/207653/
>https://patchwork.codeaurora.org/patch/207669/
>https://patchwork.codeaurora.org/patch/207651/
>
>The only change you should need on top of this is this.
>
>--- a/drivers/pci/pcie/aspm.c
>+++ b/drivers/pci/pcie/aspm.c
>@@ -847,6 +847,9 @@ int pci_aspm_init(struct pci_dev *pdev)
>        if (!pdev->has_secondary_link)
>                return 0;
>
>+       if (!pci_is_pcie(pdev))
>+               return -EINVAL;
>+
>        link = alloc_pcie_link_state(pdev);
>        if (!link)
>                return -ENOMEM;
>
>

Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
build if that helps.

But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 

We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.

To mitigate that I included following code in it.

@@ -430,8 +439,11 @@ static struct pci_dev *pci_function_0(struct pci_bus *linkbus)
 {
 	struct pci_dev *child;
 
+	if (!linkbus)
+		return NULL;
+
 	list_for_each_entry(child, &linkbus->devices, bus_list)
		if (PCI_FUNC(child->devfn) == 0)
			return child;
 	return NULL;


Then I start seeing following error as pdev-> downstream stays NULL.

>
>> [    0.835443] BUG: unable to handle kernel NULL pointer dereference at 000000000000003e
>> [    0.929138] IP: pcie_capability_read_dword+0x82/0x1a0
>> [    0.989555] PGD 0
>> [    0.989556]
>> [    1.031360] Oops: 0000 [#1] SMP
>> [    1.068901] Modules linked in:
>> [    1.105403] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc4-aspmtestv6 #24
>> [    1.192861] Hardware name:    /IC97, BIOS IV97R903 02/25/2016
>> [    1.261600] task: ffff9141435c8000 task.stack: ffffa6b8418c0000
>> [    1.332419] RIP: 0010:pcie_capability_read_dword+0x82/0x1a0
>> [    1.399077] RSP: 0000:ffffa6b8418c39b0 EFLAGS: 00010246
>> [    1.461575] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffffffff85e5be08
>> [    1.546954] RDX: ffffa6b8418c39ec RSI: 000000000000000c RDI: 0000000000000000
>> [    1.632332] RBP: ffffa6b8418c39d8 R08: 0000000000000001 R09: 0000000000000171
>> [    1.717707] R10: 0000000000000000 R11: 0000000000000170 R12: 0000000000000000
>> [    1.803085] R13: ffffa6b8418c39ec R14: ffff914142e370c0 R15: 0000000000000000
>> [    1.888462] FS:  0000000000000000(0000) GS:ffff914155c80000(0000) knlGS:0000000000000000
>> [    1.985278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [    2.054017] CR2: 000000000000003e CR3: 0000000300e09000 CR4: 00000000003406e0
>> [    2.139396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [    2.224772] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [    2.310150] Call Trace:
>> [    2.339374]  pcie_get_aspm_reg+0x39/0x1a0
>> [    2.387312]  pcie_aspm_init_link_state+0x2aa/0x900
>> [    2.444611]  ? pci_device_add+0x20a/0x300
>> [    2.492554]  pci_scan_slot+0xd7/0x110
>> [    2.536335]  pci_scan_child_bus+0x30/0x180
>> [    2.585313]  pci_scan_bridge+0x3f0/0x670
>> [    2.632215]  ? pci_scan_single_device+0x6d/0xd0
>> [    2.686394]  pci_scan_child_bus+0x9f/0x180
>> [    2.735375]  acpi_pci_root_create+0x182/0x1de
>> [    2.787475]  pci_acpi_scan_root+0x15f/0x1b0
>> [    2.837493]  acpi_pci_root_add+0x3bf/0x4c4
>> [    2.886474]  acpi_bus_attach+0xdf/0x18e
>> [    2.932336]  acpi_bus_attach+0x135/0x18e
>> [    2.979234]  acpi_bus_attach+0x135/0x18e
>> [    3.026135]  acpi_bus_scan+0x6e/0x8d
>> [    3.068877]  ? acpi_sleep_proc_init+0x28/0x28
>> [    3.120976]  acpi_scan_init+0xda/0x237
>> [    3.165795]  ? acpi_sleep_proc_init+0x28/0x28
>> [    3.217895]  acpi_init+0x2be/0x347
>>
>>>
>>> --
>>> Sinan Kaya
>>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>> Intel Deutschland GmbH
>> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
>> Tel: +49 89 99 8853-0, www.intel.de
>> Managing Directors: Christin Eisenschmid, Christian Lamprechter
>> Chairperson of the Supervisory Board: Nicole Lau
>> Registered Office: Munich
>> Commercial Register: Amtsgericht Muenchen HRB 186928
>>
>>
>
>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 4:16 PM, Patel, Mayurkumar wrote:
> Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
> build if that helps.
> 
> But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 
> 
> We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
> Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.

OK. It looks like somebody moved function_0 call around. I was looking at 4.11-rc1.

3bd7db63a841e8c5297bb18ad801df67d5e38ad2 (PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove)

I see the change in 4.11-rc3 now. 

Let me see what's going on.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 4:16 PM, Patel, Mayurkumar wrote:
> Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
> build if that helps.
> 
> But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 
> 
> We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
> Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.

OK. It looks like somebody moved function_0 call around. I was looking at 4.11-rc1.

3bd7db63a841e8c5297bb18ad801df67d5e38ad2 (PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove)

I see the change in 4.11-rc3 now. 

Let me see what's going on.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 4:16 PM, Patel, Mayurkumar wrote:
> Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
> build if that helps.
> 
> But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 
> 
> We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
> Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.

OK. It looks like somebody moved function_0 call around. I was looking at 4.11-rc1.

3bd7db63a841e8c5297bb18ad801df67d5e38ad2 (PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove)

I see the change in 4.11-rc3 now. 

Let me see what's going on.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 4:36 PM, Sinan Kaya wrote:
> On 3/29/2017 4:16 PM, Patel, Mayurkumar wrote:
>> Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
>> build if that helps.
>>
>> But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 
>>
>> We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
>> Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.
> 
> OK. It looks like somebody moved function_0 call around. I was looking at 4.11-rc1.
> 
> 3bd7db63a841e8c5297bb18ad801df67d5e38ad2 (PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove)
> 
> I see the change in 4.11-rc3 now. 
> 
> Let me see what's going on.
> 

I posted V6 a minute ago with the bugfix. Let me know how that works for you.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 4:36 PM, Sinan Kaya wrote:
> On 3/29/2017 4:16 PM, Patel, Mayurkumar wrote:
>> Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
>> build if that helps.
>>
>> But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 
>>
>> We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
>> Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.
> 
> OK. It looks like somebody moved function_0 call around. I was looking at 4.11-rc1.
> 
> 3bd7db63a841e8c5297bb18ad801df67d5e38ad2 (PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove)
> 
> I see the change in 4.11-rc3 now. 
> 
> Let me see what's going on.
> 

I posted V6 a minute ago with the bugfix. Let me know how that works for you.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5 0/4] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

[Sinan Kaya]

On 3/29/2017 4:36 PM, Sinan Kaya wrote:
> On 3/29/2017 4:16 PM, Patel, Mayurkumar wrote:
>> Actually, I have taken same patches of yours which proposed and applied it correctly. Will try it with clean
>> build if that helps.
>>
>> But what I could understand from following patch is https://patchwork.codeaurora.org/patch/207653/ 
>>
>> We still have a flow of pci_aspm_init() -> alloc_pcie_link_state() -> pci_function_0()
>> Where I see the first Kernel NULL pointer crash while accessing pdev->subordinate in pci_function_0() function.
> 
> OK. It looks like somebody moved function_0 call around. I was looking at 4.11-rc1.
> 
> 3bd7db63a841e8c5297bb18ad801df67d5e38ad2 (PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove)
> 
> I see the change in 4.11-rc3 now. 
> 
> Let me see what's going on.
> 

I posted V6 a minute ago with the bugfix. Let me know how that works for you.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.