All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	ath12k@lists.infradead.org, intel-wired-lan@lists.osuosl.org,
	linux-arm-kernel@lists.infradead.org,
	linux-bluetooth@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Wed, 11 Oct 2023 16:22:06 -0500	[thread overview]
Message-ID: <20231011212206.GA1043224@bhelgaas> (raw)
In-Reply-To: <20230918131103.24119-4-ilpo.jarvinen@linux.intel.com>

On Mon, Sep 18, 2023 at 04:10:53PM +0300, Ilpo Järvinen wrote:
> PCI core/ASPM service driver allows controlling ASPM state through
> pci_disable_link_state() and pci_enable_link_state() API. It was
> decided earlier (see the Link below), to not allow ASPM changes when OS
> does not have control over it but only log a warning about the problem
> (commit 2add0ec14c25 ("PCI/ASPM: Warn when driver asks to disable ASPM,
> but we can't do it")). Similarly, if ASPM is not enabled through
> config, ASPM cannot be disabled.
> ...

> +#ifndef CONFIG_PCIEASPM
> +/*
> + * Always disable ASPM when requested, even when CONFIG_PCIEASPM is
> + * not build to avoid drivers adding code to do it on their own
> + * which caused issues when core does not know about the out-of-band
> + * ASPM state changes.
> + */
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +{
> +	struct pci_dev *parent = pdev->bus->self;
> +	struct pci_bus *linkbus = pdev->bus;
> +	struct pci_dev *child;
> +	u16 aspm_enabled, linkctl;
> +	int ret;
> +
> +	if (!parent)
> +		return -ENODEV;

P.S. I think this should look the same to the user (same dmesg log and
same taint, if we do that) as the CONFIG_PCIEASPM=y case.

> +	ret = pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled = linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	ret = pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled |= linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	/* If no states need to be disabled, don't touch LNKCTL */
> +	if (state & aspm_enabled)
> +		return 0;
> +
> +	ret = pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	list_for_each_entry(child, &linkbus->devices, bus_list)
> +		pcie_capability_clear_word(child, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);

This disables *all* ASPM states, unlike the version when
CONFIG_PCIEASPM is enabled.  I suppose there's a reason, and maybe a
comment could elaborate on it?

When CONFIG_PCIEASPM is not enabled, I don't think we actively
*disable* ASPM in the hardware; we just leave it as-is, so firmware
might have left it enabled.

> +
> +	return 0;
> +}

Conceptually it seems like the LNKCTL updates here should be the same
whether CONFIG_PCIEASPM is enabled or not (subject to the question
above).

When CONFIG_PCIEASPM is enabled, we might need to do more stuff, but
it seems like the core should be the same.

Bjorn

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	ath12k@lists.infradead.org, intel-wired-lan@lists.osuosl.org,
	linux-arm-kernel@lists.infradead.org,
	linux-bluetooth@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Wed, 11 Oct 2023 16:22:06 -0500	[thread overview]
Message-ID: <20231011212206.GA1043224@bhelgaas> (raw)
In-Reply-To: <20230918131103.24119-4-ilpo.jarvinen@linux.intel.com>

On Mon, Sep 18, 2023 at 04:10:53PM +0300, Ilpo Järvinen wrote:
> PCI core/ASPM service driver allows controlling ASPM state through
> pci_disable_link_state() and pci_enable_link_state() API. It was
> decided earlier (see the Link below), to not allow ASPM changes when OS
> does not have control over it but only log a warning about the problem
> (commit 2add0ec14c25 ("PCI/ASPM: Warn when driver asks to disable ASPM,
> but we can't do it")). Similarly, if ASPM is not enabled through
> config, ASPM cannot be disabled.
> ...

> +#ifndef CONFIG_PCIEASPM
> +/*
> + * Always disable ASPM when requested, even when CONFIG_PCIEASPM is
> + * not build to avoid drivers adding code to do it on their own
> + * which caused issues when core does not know about the out-of-band
> + * ASPM state changes.
> + */
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +{
> +	struct pci_dev *parent = pdev->bus->self;
> +	struct pci_bus *linkbus = pdev->bus;
> +	struct pci_dev *child;
> +	u16 aspm_enabled, linkctl;
> +	int ret;
> +
> +	if (!parent)
> +		return -ENODEV;

P.S. I think this should look the same to the user (same dmesg log and
same taint, if we do that) as the CONFIG_PCIEASPM=y case.

> +	ret = pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled = linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	ret = pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled |= linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	/* If no states need to be disabled, don't touch LNKCTL */
> +	if (state & aspm_enabled)
> +		return 0;
> +
> +	ret = pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	list_for_each_entry(child, &linkbus->devices, bus_list)
> +		pcie_capability_clear_word(child, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);

This disables *all* ASPM states, unlike the version when
CONFIG_PCIEASPM is enabled.  I suppose there's a reason, and maybe a
comment could elaborate on it?

When CONFIG_PCIEASPM is not enabled, I don't think we actively
*disable* ASPM in the hardware; we just leave it as-is, so firmware
might have left it enabled.

> +
> +	return 0;
> +}

Conceptually it seems like the LNKCTL updates here should be the same
whether CONFIG_PCIEASPM is enabled or not (subject to the question
above).

When CONFIG_PCIEASPM is enabled, we might need to do more stuff, but
it seems like the core should be the same.

Bjorn

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	ath12k@lists.infradead.org, intel-wired-lan@lists.osuosl.org,
	linux-arm-kernel@lists.infradead.org,
	linux-bluetooth@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Wed, 11 Oct 2023 16:22:06 -0500	[thread overview]
Message-ID: <20231011212206.GA1043224@bhelgaas> (raw)
In-Reply-To: <20230918131103.24119-4-ilpo.jarvinen@linux.intel.com>

On Mon, Sep 18, 2023 at 04:10:53PM +0300, Ilpo Järvinen wrote:
> PCI core/ASPM service driver allows controlling ASPM state through
> pci_disable_link_state() and pci_enable_link_state() API. It was
> decided earlier (see the Link below), to not allow ASPM changes when OS
> does not have control over it but only log a warning about the problem
> (commit 2add0ec14c25 ("PCI/ASPM: Warn when driver asks to disable ASPM,
> but we can't do it")). Similarly, if ASPM is not enabled through
> config, ASPM cannot be disabled.
> ...

> +#ifndef CONFIG_PCIEASPM
> +/*
> + * Always disable ASPM when requested, even when CONFIG_PCIEASPM is
> + * not build to avoid drivers adding code to do it on their own
> + * which caused issues when core does not know about the out-of-band
> + * ASPM state changes.
> + */
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +{
> +	struct pci_dev *parent = pdev->bus->self;
> +	struct pci_bus *linkbus = pdev->bus;
> +	struct pci_dev *child;
> +	u16 aspm_enabled, linkctl;
> +	int ret;
> +
> +	if (!parent)
> +		return -ENODEV;

P.S. I think this should look the same to the user (same dmesg log and
same taint, if we do that) as the CONFIG_PCIEASPM=y case.

> +	ret = pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled = linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	ret = pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled |= linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	/* If no states need to be disabled, don't touch LNKCTL */
> +	if (state & aspm_enabled)
> +		return 0;
> +
> +	ret = pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	list_for_each_entry(child, &linkbus->devices, bus_list)
> +		pcie_capability_clear_word(child, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);

This disables *all* ASPM states, unlike the version when
CONFIG_PCIEASPM is enabled.  I suppose there's a reason, and maybe a
comment could elaborate on it?

When CONFIG_PCIEASPM is not enabled, I don't think we actively
*disable* ASPM in the hardware; we just leave it as-is, so firmware
might have left it enabled.

> +
> +	return 0;
> +}

Conceptually it seems like the LNKCTL updates here should be the same
whether CONFIG_PCIEASPM is enabled or not (subject to the question
above).

When CONFIG_PCIEASPM is enabled, we might need to do more stuff, but
it seems like the core should be the same.

Bjorn

-- 
ath12k mailing list
ath12k@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/ath12k

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
	linux-rdma@vger.kernel.org,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	ath12k@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	linux-bluetooth@vger.kernel.org, "Lukas Wunner" <lukas@wunner.de>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-mediatek@lists.infradead.org,
	"Rob Herring" <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	"Heiner Kallweit" <hkallweit1@gmail.com>
Subject: Re: [Intel-wired-lan] [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Wed, 11 Oct 2023 16:22:06 -0500	[thread overview]
Message-ID: <20231011212206.GA1043224@bhelgaas> (raw)
In-Reply-To: <20230918131103.24119-4-ilpo.jarvinen@linux.intel.com>

On Mon, Sep 18, 2023 at 04:10:53PM +0300, Ilpo Järvinen wrote:
> PCI core/ASPM service driver allows controlling ASPM state through
> pci_disable_link_state() and pci_enable_link_state() API. It was
> decided earlier (see the Link below), to not allow ASPM changes when OS
> does not have control over it but only log a warning about the problem
> (commit 2add0ec14c25 ("PCI/ASPM: Warn when driver asks to disable ASPM,
> but we can't do it")). Similarly, if ASPM is not enabled through
> config, ASPM cannot be disabled.
> ...

> +#ifndef CONFIG_PCIEASPM
> +/*
> + * Always disable ASPM when requested, even when CONFIG_PCIEASPM is
> + * not build to avoid drivers adding code to do it on their own
> + * which caused issues when core does not know about the out-of-band
> + * ASPM state changes.
> + */
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +{
> +	struct pci_dev *parent = pdev->bus->self;
> +	struct pci_bus *linkbus = pdev->bus;
> +	struct pci_dev *child;
> +	u16 aspm_enabled, linkctl;
> +	int ret;
> +
> +	if (!parent)
> +		return -ENODEV;

P.S. I think this should look the same to the user (same dmesg log and
same taint, if we do that) as the CONFIG_PCIEASPM=y case.

> +	ret = pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled = linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	ret = pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled |= linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	/* If no states need to be disabled, don't touch LNKCTL */
> +	if (state & aspm_enabled)
> +		return 0;
> +
> +	ret = pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	list_for_each_entry(child, &linkbus->devices, bus_list)
> +		pcie_capability_clear_word(child, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);

This disables *all* ASPM states, unlike the version when
CONFIG_PCIEASPM is enabled.  I suppose there's a reason, and maybe a
comment could elaborate on it?

When CONFIG_PCIEASPM is not enabled, I don't think we actively
*disable* ASPM in the hardware; we just leave it as-is, so firmware
might have left it enabled.

> +
> +	return 0;
> +}

Conceptually it seems like the LNKCTL updates here should be the same
whether CONFIG_PCIEASPM is enabled or not (subject to the question
above).

When CONFIG_PCIEASPM is enabled, we might need to do more stuff, but
it seems like the core should be the same.

Bjorn
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	ath12k@lists.infradead.org, intel-wired-lan@lists.osuosl.org,
	linux-arm-kernel@lists.infradead.org,
	linux-bluetooth@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Wed, 11 Oct 2023 16:22:06 -0500	[thread overview]
Message-ID: <20231011212206.GA1043224@bhelgaas> (raw)
In-Reply-To: <20230918131103.24119-4-ilpo.jarvinen@linux.intel.com>

On Mon, Sep 18, 2023 at 04:10:53PM +0300, Ilpo Järvinen wrote:
> PCI core/ASPM service driver allows controlling ASPM state through
> pci_disable_link_state() and pci_enable_link_state() API. It was
> decided earlier (see the Link below), to not allow ASPM changes when OS
> does not have control over it but only log a warning about the problem
> (commit 2add0ec14c25 ("PCI/ASPM: Warn when driver asks to disable ASPM,
> but we can't do it")). Similarly, if ASPM is not enabled through
> config, ASPM cannot be disabled.
> ...

> +#ifndef CONFIG_PCIEASPM
> +/*
> + * Always disable ASPM when requested, even when CONFIG_PCIEASPM is
> + * not build to avoid drivers adding code to do it on their own
> + * which caused issues when core does not know about the out-of-band
> + * ASPM state changes.
> + */
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +{
> +	struct pci_dev *parent = pdev->bus->self;
> +	struct pci_bus *linkbus = pdev->bus;
> +	struct pci_dev *child;
> +	u16 aspm_enabled, linkctl;
> +	int ret;
> +
> +	if (!parent)
> +		return -ENODEV;

P.S. I think this should look the same to the user (same dmesg log and
same taint, if we do that) as the CONFIG_PCIEASPM=y case.

> +	ret = pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled = linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	ret = pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled |= linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	/* If no states need to be disabled, don't touch LNKCTL */
> +	if (state & aspm_enabled)
> +		return 0;
> +
> +	ret = pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	list_for_each_entry(child, &linkbus->devices, bus_list)
> +		pcie_capability_clear_word(child, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);

This disables *all* ASPM states, unlike the version when
CONFIG_PCIEASPM is enabled.  I suppose there's a reason, and maybe a
comment could elaborate on it?

When CONFIG_PCIEASPM is not enabled, I don't think we actively
*disable* ASPM in the hardware; we just leave it as-is, so firmware
might have left it enabled.

> +
> +	return 0;
> +}

Conceptually it seems like the LNKCTL updates here should be the same
whether CONFIG_PCIEASPM is enabled or not (subject to the question
above).

When CONFIG_PCIEASPM is enabled, we might need to do more stuff, but
it seems like the core should be the same.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	ath12k@lists.infradead.org, intel-wired-lan@lists.osuosl.org,
	linux-arm-kernel@lists.infradead.org,
	linux-bluetooth@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Wed, 11 Oct 2023 16:22:06 -0500	[thread overview]
Message-ID: <20231011212206.GA1043224@bhelgaas> (raw)
In-Reply-To: <20230918131103.24119-4-ilpo.jarvinen@linux.intel.com>

On Mon, Sep 18, 2023 at 04:10:53PM +0300, Ilpo Järvinen wrote:
> PCI core/ASPM service driver allows controlling ASPM state through
> pci_disable_link_state() and pci_enable_link_state() API. It was
> decided earlier (see the Link below), to not allow ASPM changes when OS
> does not have control over it but only log a warning about the problem
> (commit 2add0ec14c25 ("PCI/ASPM: Warn when driver asks to disable ASPM,
> but we can't do it")). Similarly, if ASPM is not enabled through
> config, ASPM cannot be disabled.
> ...

> +#ifndef CONFIG_PCIEASPM
> +/*
> + * Always disable ASPM when requested, even when CONFIG_PCIEASPM is
> + * not build to avoid drivers adding code to do it on their own
> + * which caused issues when core does not know about the out-of-band
> + * ASPM state changes.
> + */
> +int pci_disable_link_state_locked(struct pci_dev *pdev, int state)
> +{
> +	struct pci_dev *parent = pdev->bus->self;
> +	struct pci_bus *linkbus = pdev->bus;
> +	struct pci_dev *child;
> +	u16 aspm_enabled, linkctl;
> +	int ret;
> +
> +	if (!parent)
> +		return -ENODEV;

P.S. I think this should look the same to the user (same dmesg log and
same taint, if we do that) as the CONFIG_PCIEASPM=y case.

> +	ret = pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled = linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	ret = pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &linkctl);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	aspm_enabled |= linkctl & PCI_EXP_LNKCTL_ASPMC;
> +
> +	/* If no states need to be disabled, don't touch LNKCTL */
> +	if (state & aspm_enabled)
> +		return 0;
> +
> +	ret = pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
> +	if (ret != PCIBIOS_SUCCESSFUL)
> +		return pcibios_err_to_errno(ret);
> +	list_for_each_entry(child, &linkbus->devices, bus_list)
> +		pcie_capability_clear_word(child, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);

This disables *all* ASPM states, unlike the version when
CONFIG_PCIEASPM is enabled.  I suppose there's a reason, and maybe a
comment could elaborate on it?

When CONFIG_PCIEASPM is not enabled, I don't think we actively
*disable* ASPM in the hardware; we just leave it as-is, so firmware
might have left it enabled.

> +
> +	return 0;
> +}

Conceptually it seems like the LNKCTL updates here should be the same
whether CONFIG_PCIEASPM is enabled or not (subject to the question
above).

When CONFIG_PCIEASPM is enabled, we might need to do more stuff, but
it seems like the core should be the same.

Bjorn

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

  parent reply	other threads:[~2023-10-11 21:22 UTC|newest]

Thread overview: 187+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 13:10 [PATCH v2 00/13] PCI/ASPM: Make ASPM in core robust and remove driver workarounds Ilpo Järvinen
2023-09-18 13:10 ` Ilpo Järvinen
2023-09-18 13:10 ` Ilpo Järvinen
2023-09-18 13:10 ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10 ` Ilpo Järvinen
2023-09-18 13:10 ` Ilpo Järvinen
2023-09-18 13:10 ` [PATCH v2 01/13] PCI/ASPM: Rename pci_enable_link_state() to pci_set_default_link_state() Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 16:41   ` PCI/ASPM: Make ASPM in core robust and remove driver workarounds bluez.test.bot
2023-09-18 13:10 ` [PATCH v2 02/13] PCI/ASPM: Improve pci_set_default_link_state() kerneldoc Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10 ` [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-10-11 20:04   ` Bjorn Helgaas
2023-10-11 20:04     ` Bjorn Helgaas
2023-10-11 20:04     ` Bjorn Helgaas
2023-10-11 20:04     ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-11 20:04     ` Bjorn Helgaas
2023-10-11 20:04     ` Bjorn Helgaas
2023-10-12 10:47     ` Ilpo Järvinen
2023-10-12 10:47       ` Ilpo Järvinen
2023-10-12 10:47       ` Ilpo Järvinen
2023-10-12 10:47       ` [Intel-wired-lan] " Ilpo Järvinen
2023-10-12 10:47       ` Ilpo Järvinen
2023-10-12 10:47       ` Ilpo Järvinen
2023-10-11 21:22   ` Bjorn Helgaas [this message]
2023-10-11 21:22     ` Bjorn Helgaas
2023-10-11 21:22     ` Bjorn Helgaas
2023-10-11 21:22     ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-11 21:22     ` Bjorn Helgaas
2023-10-11 21:22     ` Bjorn Helgaas
2023-10-12 10:56     ` Ilpo Järvinen
2023-10-12 10:56       ` Ilpo Järvinen
2023-10-12 10:56       ` Ilpo Järvinen
2023-10-12 10:56       ` [Intel-wired-lan] " Ilpo Järvinen
2023-10-12 10:56       ` Ilpo Järvinen
2023-10-12 10:56       ` Ilpo Järvinen
2023-10-13 16:42       ` Bjorn Helgaas
2023-10-13 16:42         ` Bjorn Helgaas
2023-10-13 16:42         ` Bjorn Helgaas
2023-10-13 16:42         ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-13 16:42         ` Bjorn Helgaas
2023-10-13 16:42         ` Bjorn Helgaas
2023-10-16 14:27         ` Ilpo Järvinen
2023-10-16 14:27           ` Ilpo Järvinen
2023-10-16 14:27           ` Ilpo Järvinen
2023-10-16 14:27           ` [Intel-wired-lan] " Ilpo Järvinen
2023-10-16 14:27           ` Ilpo Järvinen
2023-10-16 14:27           ` Ilpo Järvinen
2023-10-26 22:02           ` Bjorn Helgaas
2023-10-26 22:02             ` Bjorn Helgaas
2023-10-26 22:02             ` Bjorn Helgaas
2023-10-26 22:02             ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-26 22:02             ` Bjorn Helgaas
2023-10-26 22:02             ` Bjorn Helgaas
2023-09-18 13:10 ` [PATCH v2 04/13] PCI/ASPM: Move L0S/L1/sub states mask calculation into a helper Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-10-11 19:32   ` Bjorn Helgaas
2023-10-11 19:32     ` Bjorn Helgaas
2023-10-11 19:32     ` Bjorn Helgaas
2023-10-11 19:32     ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-11 19:32     ` Bjorn Helgaas
2023-10-11 19:32     ` Bjorn Helgaas
2023-10-12 10:29     ` Ilpo Järvinen
2023-10-12 10:29       ` Ilpo Järvinen
2023-10-12 10:29       ` Ilpo Järvinen
2023-10-12 10:29       ` [Intel-wired-lan] " Ilpo Järvinen
2023-10-12 10:29       ` Ilpo Järvinen
2023-10-12 10:29       ` Ilpo Järvinen
2023-09-18 13:10 ` [PATCH v2 05/13] PCI/ASPM: Add pci_enable_link_state() Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-10-11 21:53   ` Bjorn Helgaas
2023-10-11 21:53     ` Bjorn Helgaas
2023-10-11 21:53     ` Bjorn Helgaas
2023-10-11 21:53     ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-11 21:53     ` Bjorn Helgaas
2023-10-11 21:53     ` Bjorn Helgaas
2023-10-12 12:53     ` Ilpo Järvinen
2023-10-12 12:53       ` Ilpo Järvinen
2023-10-12 12:53       ` Ilpo Järvinen
2023-10-12 12:53       ` [Intel-wired-lan] " Ilpo Järvinen
2023-10-12 12:53       ` Ilpo Järvinen
2023-10-12 12:53       ` Ilpo Järvinen
2023-10-13 16:48       ` Bjorn Helgaas
2023-10-13 16:48         ` Bjorn Helgaas
2023-10-13 16:48         ` Bjorn Helgaas
2023-10-13 16:48         ` [Intel-wired-lan] " Bjorn Helgaas
2023-10-13 16:48         ` Bjorn Helgaas
2023-10-13 16:48         ` Bjorn Helgaas
2023-10-16 12:57         ` Ilpo Järvinen
2023-10-16 12:57           ` Ilpo Järvinen
2023-10-16 12:57           ` Ilpo Järvinen
2023-10-16 12:57           ` [Intel-wired-lan] " Ilpo Järvinen
2023-10-16 12:57           ` Ilpo Järvinen
2023-10-16 12:57           ` Ilpo Järvinen
2023-09-18 13:10 ` [PATCH v2 06/13] Bluetooth: hci_bcm4377: Convert aspm disable to quirk Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-19 13:36   ` Sven Peter
2023-09-19 13:36     ` Sven Peter
2023-09-19 13:36     ` [Intel-wired-lan] " Sven Peter
2023-09-19 13:36     ` Sven Peter
2023-09-19 13:36     ` Sven Peter
2023-09-19 13:36     ` Sven Peter
2023-09-18 13:10 ` [PATCH v2 07/13] mt76: Remove unreliable pci_disable_link_state() workaround Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10 ` [PATCH v2 08/13] e1000e: Remove unreliable pci_disable_link_state{,_locked}() workaround Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] [PATCH v2 08/13] e1000e: Remove unreliable pci_disable_link_state{, _locked}() workaround Ilpo Järvinen
2023-09-18 13:10   ` [PATCH v2 08/13] e1000e: Remove unreliable pci_disable_link_state{,_locked}() workaround Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10 ` [PATCH v2 09/13] wifi: ath10k: Use pci_disable/enable_link_state() Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-18 13:10   ` Ilpo Järvinen
2023-09-19  9:39   ` Kalle Valo
2023-09-19  9:39     ` Kalle Valo
2023-09-19  9:39     ` Kalle Valo
2023-09-19  9:39     ` [Intel-wired-lan] " Kalle Valo
2023-09-19  9:39     ` Kalle Valo
2023-09-19  9:39     ` Kalle Valo
2023-09-18 13:11 ` [PATCH v2 10/13] wifi: ath11k: " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-19  9:40   ` Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-19  9:40     ` [Intel-wired-lan] " Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-18 13:11 ` [PATCH v2 11/13] wifi: ath12k: " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-19  9:40   ` Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-19  9:40     ` [Intel-wired-lan] " Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-19  9:40     ` Kalle Valo
2023-09-18 13:11 ` [PATCH v2 12/13] RDMA/hfi1: " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11 ` [PATCH v2 13/13] misc: rtsx: " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` [Intel-wired-lan] " Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen
2023-09-18 13:11   ` Ilpo Järvinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231011212206.GA1043224@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=ath10k@lists.infradead.org \
    --cc=ath11k@lists.infradead.org \
    --cc=ath12k@lists.infradead.org \
    --cc=bhelgaas@google.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=hkallweit1@gmail.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lukas@wunner.de \
    --cc=netdev@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.