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: "Rafael J . Wysocki" <rafael@kernel.org>,
	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>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	LKML <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 <netdev@vger.kernel.org>
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Fri, 13 Oct 2023 11:42:28 -0500	[thread overview]
Message-ID: <20231013164228.GA1117889@bhelgaas> (raw)
In-Reply-To: <aa3386a4-c22d-6d5d-112d-f36b22cda6d3@linux.intel.com>

On Thu, Oct 12, 2023 at 01:56:16PM +0300, Ilpo Järvinen wrote:
> On Wed, 11 Oct 2023, Bjorn Helgaas wrote:
> > 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.
> ...

> > 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.
> 
> This whole trickery is intended for drivers that do not want to have ASPM 
> because the devices are broken with it. So leaving it as-is is not really 
> an option (as demonstrated by the custom workarounds).

Right.

> > 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.
> 
> So you think it's safer to partially disable ASPM (as per driver's 
> request) rather than disable it completely? I got the impression that the 
> latter might be safer from what Rafael said earlier but I suppose I might 
> have misinterpreted him since he didn't exactly say that it might be safer 
> to _completely_ disable it.

My question is whether the state of the device should depend on
CONFIG_PCIEASPM.  If the driver does this:

  pci_disable_link_state(PCIE_LINK_STATE_L0S)

do we want to leave L1 enabled when CONFIG_PCIEASPM=y but disable L1
when CONFIG_PCIEASPM is unset?

I can see arguments both ways.  My thought was that it would be nice
to end up with a single implementation of pci_disable_link_state()
with an #ifdef around the CONFIG_PCIEASPM-enabled stuff because it
makes the code easier to read.

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: "Rafael J . Wysocki" <rafael@kernel.org>,
	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>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	LKML <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 <netdev@vger.kernel.org>
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Fri, 13 Oct 2023 11:42:28 -0500	[thread overview]
Message-ID: <20231013164228.GA1117889@bhelgaas> (raw)
In-Reply-To: <aa3386a4-c22d-6d5d-112d-f36b22cda6d3@linux.intel.com>

On Thu, Oct 12, 2023 at 01:56:16PM +0300, Ilpo Järvinen wrote:
> On Wed, 11 Oct 2023, Bjorn Helgaas wrote:
> > 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.
> ...

> > 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.
> 
> This whole trickery is intended for drivers that do not want to have ASPM 
> because the devices are broken with it. So leaving it as-is is not really 
> an option (as demonstrated by the custom workarounds).

Right.

> > 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.
> 
> So you think it's safer to partially disable ASPM (as per driver's 
> request) rather than disable it completely? I got the impression that the 
> latter might be safer from what Rafael said earlier but I suppose I might 
> have misinterpreted him since he didn't exactly say that it might be safer 
> to _completely_ disable it.

My question is whether the state of the device should depend on
CONFIG_PCIEASPM.  If the driver does this:

  pci_disable_link_state(PCIE_LINK_STATE_L0S)

do we want to leave L1 enabled when CONFIG_PCIEASPM=y but disable L1
when CONFIG_PCIEASPM is unset?

I can see arguments both ways.  My thought was that it would be nice
to end up with a single implementation of pci_disable_link_state()
with an #ifdef around the CONFIG_PCIEASPM-enabled stuff because it
makes the code easier to read.

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: "Rafael J . Wysocki" <rafael@kernel.org>,
	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>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	LKML <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 <netdev@vger.kernel.org>
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Fri, 13 Oct 2023 11:42:28 -0500	[thread overview]
Message-ID: <20231013164228.GA1117889@bhelgaas> (raw)
In-Reply-To: <aa3386a4-c22d-6d5d-112d-f36b22cda6d3@linux.intel.com>

On Thu, Oct 12, 2023 at 01:56:16PM +0300, Ilpo Järvinen wrote:
> On Wed, 11 Oct 2023, Bjorn Helgaas wrote:
> > 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.
> ...

> > 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.
> 
> This whole trickery is intended for drivers that do not want to have ASPM 
> because the devices are broken with it. So leaving it as-is is not really 
> an option (as demonstrated by the custom workarounds).

Right.

> > 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.
> 
> So you think it's safer to partially disable ASPM (as per driver's 
> request) rather than disable it completely? I got the impression that the 
> latter might be safer from what Rafael said earlier but I suppose I might 
> have misinterpreted him since he didn't exactly say that it might be safer 
> to _completely_ disable it.

My question is whether the state of the device should depend on
CONFIG_PCIEASPM.  If the driver does this:

  pci_disable_link_state(PCIE_LINK_STATE_L0S)

do we want to leave L1 enabled when CONFIG_PCIEASPM=y but disable L1
when CONFIG_PCIEASPM is unset?

I can see arguments both ways.  My thought was that it would be nice
to end up with a single implementation of pci_disable_link_state()
with an #ifdef around the CONFIG_PCIEASPM-enabled stuff because it
makes the code easier to read.

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>,
	"Rob Herring" <robh@kernel.org>,
	ath12k@lists.infradead.org, linux-pci@vger.kernel.org,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	linux-wireless@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	ath10k@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 <netdev@vger.kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-mediatek@lists.infradead.org, ath11k@lists.infradead.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: Fri, 13 Oct 2023 11:42:28 -0500	[thread overview]
Message-ID: <20231013164228.GA1117889@bhelgaas> (raw)
In-Reply-To: <aa3386a4-c22d-6d5d-112d-f36b22cda6d3@linux.intel.com>

On Thu, Oct 12, 2023 at 01:56:16PM +0300, Ilpo Järvinen wrote:
> On Wed, 11 Oct 2023, Bjorn Helgaas wrote:
> > 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.
> ...

> > 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.
> 
> This whole trickery is intended for drivers that do not want to have ASPM 
> because the devices are broken with it. So leaving it as-is is not really 
> an option (as demonstrated by the custom workarounds).

Right.

> > 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.
> 
> So you think it's safer to partially disable ASPM (as per driver's 
> request) rather than disable it completely? I got the impression that the 
> latter might be safer from what Rafael said earlier but I suppose I might 
> have misinterpreted him since he didn't exactly say that it might be safer 
> to _completely_ disable it.

My question is whether the state of the device should depend on
CONFIG_PCIEASPM.  If the driver does this:

  pci_disable_link_state(PCIE_LINK_STATE_L0S)

do we want to leave L1 enabled when CONFIG_PCIEASPM=y but disable L1
when CONFIG_PCIEASPM is unset?

I can see arguments both ways.  My thought was that it would be nice
to end up with a single implementation of pci_disable_link_state()
with an #ifdef around the CONFIG_PCIEASPM-enabled stuff because it
makes the code easier to read.

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: "Rafael J . Wysocki" <rafael@kernel.org>,
	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>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	LKML <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 <netdev@vger.kernel.org>
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Fri, 13 Oct 2023 11:42:28 -0500	[thread overview]
Message-ID: <20231013164228.GA1117889@bhelgaas> (raw)
In-Reply-To: <aa3386a4-c22d-6d5d-112d-f36b22cda6d3@linux.intel.com>

On Thu, Oct 12, 2023 at 01:56:16PM +0300, Ilpo Järvinen wrote:
> On Wed, 11 Oct 2023, Bjorn Helgaas wrote:
> > 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.
> ...

> > 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.
> 
> This whole trickery is intended for drivers that do not want to have ASPM 
> because the devices are broken with it. So leaving it as-is is not really 
> an option (as demonstrated by the custom workarounds).

Right.

> > 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.
> 
> So you think it's safer to partially disable ASPM (as per driver's 
> request) rather than disable it completely? I got the impression that the 
> latter might be safer from what Rafael said earlier but I suppose I might 
> have misinterpreted him since he didn't exactly say that it might be safer 
> to _completely_ disable it.

My question is whether the state of the device should depend on
CONFIG_PCIEASPM.  If the driver does this:

  pci_disable_link_state(PCIE_LINK_STATE_L0S)

do we want to leave L1 enabled when CONFIG_PCIEASPM=y but disable L1
when CONFIG_PCIEASPM is unset?

I can see arguments both ways.  My thought was that it would be nice
to end up with a single implementation of pci_disable_link_state()
with an #ifdef around the CONFIG_PCIEASPM-enabled stuff because it
makes the code easier to read.

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: "Rafael J . Wysocki" <rafael@kernel.org>,
	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>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Emmanuel Grumbach" <emmanuel.grumbach@intel.com>,
	LKML <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 <netdev@vger.kernel.org>
Subject: Re: [PATCH v2 03/13] PCI/ASPM: Disable ASPM when driver requests it
Date: Fri, 13 Oct 2023 11:42:28 -0500	[thread overview]
Message-ID: <20231013164228.GA1117889@bhelgaas> (raw)
In-Reply-To: <aa3386a4-c22d-6d5d-112d-f36b22cda6d3@linux.intel.com>

On Thu, Oct 12, 2023 at 01:56:16PM +0300, Ilpo Järvinen wrote:
> On Wed, 11 Oct 2023, Bjorn Helgaas wrote:
> > 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.
> ...

> > 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.
> 
> This whole trickery is intended for drivers that do not want to have ASPM 
> because the devices are broken with it. So leaving it as-is is not really 
> an option (as demonstrated by the custom workarounds).

Right.

> > 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.
> 
> So you think it's safer to partially disable ASPM (as per driver's 
> request) rather than disable it completely? I got the impression that the 
> latter might be safer from what Rafael said earlier but I suppose I might 
> have misinterpreted him since he didn't exactly say that it might be safer 
> to _completely_ disable it.

My question is whether the state of the device should depend on
CONFIG_PCIEASPM.  If the driver does this:

  pci_disable_link_state(PCIE_LINK_STATE_L0S)

do we want to leave L1 enabled when CONFIG_PCIEASPM=y but disable L1
when CONFIG_PCIEASPM is unset?

I can see arguments both ways.  My thought was that it would be nice
to end up with a single implementation of pci_disable_link_state()
with an #ifdef around the CONFIG_PCIEASPM-enabled stuff because it
makes the code easier to read.

Bjorn

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

  reply	other threads:[~2023-10-13 16:42 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
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 [this message]
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=20231013164228.GA1117889@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.