On Tue, Apr 14, 2020 at 07:12:44PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> PCIe Active State Power Management (ASPM) is optional and there's no need
> for it to be selected by default.
>
> Remove the "default y" for CONFIG_PCIEASPM.
>
> Signed-o
On Sat, May 30, 2020 at 04:33:44AM -0700, Christoph Hellwig wrote:
> On Sat, May 30, 2020 at 08:14:34AM +0100, Matthew Garrett wrote:
> > On Sat, May 30, 2020 at 08:33:50AM +0200, Heiner Kallweit wrote:
> >
> > > It *was* default y. This changed with a914ff2d78ce ("PCI/ASPM: Don't
> > > select
On Tue, May 26, 2020 at 04:18:27PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> pcie_ports_native is set only if user requests native handling
> of PCIe capabilities via pcie_port_setup command line option.
> User input takes precedence over
| 139 -
> drivers/pci/pcie/dpc.c | 2 +-
> drivers/pci/pcie/portdrv.h | 15 +---
> include/linux/pci.h| 2 +
> 5 files changed, 34 insertions(+), 152 deletions(-)
commit 643a9f8854f9 ("PCI/AER: Use "aer" variable fo
[+cc Matthew]
On Fri, May 29, 2020 at 10:09:08PM +0200, Heiner Kallweit wrote:
> On 29.05.2020 21:40, Heiner Kallweit wrote:
> > On 29.05.2020 21:21, Bjorn Helgaas wrote:
> >> On Fri, May 29, 2020 at 08:50:46PM +0200, Heiner Kallweit wrote:
> >>> On 28.05.202
[+cc Rafael, linux-kernel]
On Fri, May 29, 2020 at 08:50:46PM +0200, Heiner Kallweit wrote:
> On 28.05.2020 23:44, Heiner Kallweit wrote:
> > For whatever reason with this change (and losing ASPM control) I also
> > loose the PCIe PME interrupts. This prevents my network card from
> > resuming
On Thu, May 28, 2020 at 06:38:09PM +0200, Pali Rohár wrote:
> On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
> > On Thu, May 28, 2020 at 04:31:41PM +0200, Pali Rohár wrote:
> > > When there is no PCIe card connected and advk_pcie_rd_conf() or
> > > advk_pcie_wr_c
On Thu, May 28, 2020 at 04:31:41PM +0200, Pali Rohár wrote:
> When there is no PCIe card connected and advk_pcie_rd_conf() or
> advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated
> root bridge, the aardvark driver throws the following error message:
>
> advk-pcie
On Wed, May 27, 2020 at 03:34:26PM -0700, Boris Ostrovsky wrote:
> On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
> > @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
> > offset, int size,
> > u32 value = 0, tmp_val;
> >
> >
On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are actually on the AMBA bus,
> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
> is allocated, instead
From: Bjorn Helgaas
Use dev_printk() when possible to include device and driver information in
the conventional format.
Add "#define dev_fmt" when needed to preserve DRV_NAME or KBUILD_MODNAME in
messages.
No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drive
From: Bjorn Helgaas
Use dev_printk() when possible to include device and driver information in
the conventional format.
Bjorn Helgaas (2):
xen-pciback: Use dev_printk() when possible
xenbus: Use dev_printk() when possible
drivers/xen/xen-pciback/conf_space.c| 16 +
drivers
From: Bjorn Helgaas
Use dev_printk() when possible to include device and driver information in
the conventional format.
Add "#define dev_fmt" to preserve KBUILD_MODNAME in messages.
No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/xen/xenbus/xenbus_pr
On Fri, May 22, 2020 at 05:23:31PM +, Derrick, Jonathan wrote:
> On Fri, 2020-05-01 at 11:35 -0600, Jonathan Derrick wrote:
> > On Fri, 2020-05-01 at 12:16 -0500, Bjorn Helgaas wrote:
> > > On Thu, Apr 30, 2020 at 12:46:07PM -0600, Jon Derrick wrote:
> > &
On Tue, Apr 28, 2020 at 03:36:40PM +, Wei Liu wrote:
> All callers within the same file pass in -1 (no override).
>
> Signed-off-by: Wei Liu
Applied to pci/virtualization for v5.8, thanks!
I don't see anything else in linux-next that touches this file, but if
somebody wants to merge this
From: Bjorn Helgaas
Simplify rtsx_comm_set_aspm() and remove the now-unused
rtsx_pci_enable_aspm().
rtsx_pci_disable_aspm() is still used by rtsx_pci_init_hw().
Signed-off-by: Bjorn Helgaas
---
drivers/misc/cardreader/rtsx_pcr.c | 13 +++--
1 file changed, 3 insertions(+), 10
From: Bjorn Helgaas
rts5249_set_aspm() and rts5260_set_aspm() do nothing more than the default
rtsx_comm_set_aspm() does, so remove them and use the default. No
functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/misc/cardreader/rts5249.c | 15 ---
drivers/misc
From: Bjorn Helgaas
Use ASPM_MASK_NEG instead of hard-coded value, as other callers of
rtsx_pci_update_cfg_byte() do. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/misc/cardreader/rtsx_pcr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Bjorn Helgaas
Instead of using the driver-specific rtsx_pci_update_cfg_byte() to update
the PCIe Link Control Register, use pcie_capability_clear_and_set_word()
like the rest of the kernel does. This makes it easier to maintain ASPM
across the PCI core and drivers.
Remove the now-unused
From: Bjorn Helgaas
The struct rtsx_cr_option.dev_aspm_mode member is never set to anything
other than DEV_ASPM_DYNAMIC (0). Remove it and code that tests it. No
functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/misc/cardreader/rts5249.c | 19
drivers
From: Bjorn Helgaas
These are minor cleanups of the Realtek card reader driver. They shouldn't
fix or break anything by themselves; they're just to make it slightly more
readable and maintainable.
Bjorn Helgaas (6):
misc: rtsx: Remove unused pcr_ops
misc: rtsx: Removed unused dev_aspm_mode
From: Bjorn Helgaas
Remove the following unused function pointers from struct pcr_ops:
int (*set_ltr_latency)(struct rtsx_pcr *pcr, u32 latency);
int (*set_l1off_sub)(struct rtsx_pcr *pcr, u8 val);
void (*full_on)(struct rtsx_pcr *pcr);
void (*power_saving)(struct rtsx_pcr *pcr
[+cc Rafael, linux-pm]
On Thu, May 21, 2020 at 11:13:49AM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
I didn't realize
On Wed, May 20, 2020 at 04:40:12PM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
>
> Also This driver forgets to call
On Wed, May 20, 2020 at 11:59:08AM +0200, Thierry Reding wrote:
> On Wed, May 20, 2020 at 04:52:23PM +0800, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > it returns an error code. Thus a pairing decrement is needed on
>
> s/even it/even when it/
>
On Tue, May 19, 2020 at 04:33:58PM -0400, Jim Quinlan wrote:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi. Other forms of this patchset were submitted by me years
> ago and not accepted;
Hi Paul,
This looks like it might be a bug:
static const int piix4_pm_io_region = PCI_BRIDGE_RESOURCES;
static int piix4_poweroff_probe(struct pci_dev *dev,
const struct pci_device_id *id)
{
...
/* Request access to the PIIX4 PM IO
On Mon, May 18, 2020 at 09:35:23AM -0700, Sean V Kelley wrote:
> With these helpers, a device driver can enable/disable access to
> CXL.mem and CXL.cache. Note that the device driver is responsible for
> managing the memory area.
>
> Signed-off-by: Sean V Kelley
> ---
> drivers/pci/cxl.c | 93
On Mon, May 18, 2020 at 09:35:20AM -0700, Sean V Kelley wrote:
> Changes since v1 [1]:
>
> - Make use pci_info() and FLAG(), as in pcie_init().
> - Wrap new cxl_cap in pci_dev struct within #ifdef PCI_CXL.
> (Bjorn Helgaas)
>
> - Added functionality for some CXL.mem
On Fri, May 15, 2020 at 10:55:28AM -0700, Sean V Kelley wrote:
> Compute eXpress Link is a new CPU interconnect created with
> workload accelerators in mind. The interconnect relies on PCIe Electrical
> and Physical interconnect for communication. CXL devices enumerate to the
> OS as an
Bug]: reg 0x30: invalid BAR (can't size)
Mark these MROM functions as having non-compliant BARs so we don't try to
probe any of them. There are no other BARs on these devices.
See the Intel C620 Series Chipset Platform Controller Hub Datasheet,
May 2019, Document Number 336
peer2peer
> is used in kernel commandline PCIE_BUS_PEER2PEER.
>
> When MPS is configured lower, it could result in reduced performance.
>
> Fixes: 9dae3a97297f ("PCI: Move MPS configuration check to
> pci_configure_device()")
> Signed-off-by: Ashok Raj
> Tested-by: D
On Wed, May 06, 2020 at 08:32:59PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> If there are non-hotplug capable devices connected to a given
> port, then during the fatal error recovery(triggered by DPC or
> AER), after calling reset_link()
[+cc Alan; please cc authors of relevant commits,
updated Andrew's email address]
On Thu, May 14, 2020 at 12:38:55AM +0530, Vidya Sagar wrote:
> commit 9e73fa02aa009 ("PCI: dwc: Warn if MEM resource size exceeds max for
> 32-bits") enables warning for MEM resources of size >4GB but prefetchable
>
On Fri, May 01, 2020 at 05:40:40PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> All callers of platform_get_irq() and related functions interpret a
> negative return value as an error. A few also interpret zero as an error.
>
> platform_get_irq() should return eithe
On Wed, May 13, 2020 at 09:20:08AM +0800, Jiaxun Yang wrote:
> 于 2020年5月13日 GMT+08:00 上午2:06:02, Bjorn Helgaas 写到:
> >On Tue, May 12, 2020 at 03:43:56PM +0800, Jiaxun Yang wrote:
> >> This controller can be found on Loongson-2K SoC, Loongson-3
> >> s
On Tue, May 12, 2020 at 03:43:56PM +0800, Jiaxun Yang wrote:
> This controller can be found on Loongson-2K SoC, Loongson-3
> systems with RS780E/LS7A PCH.
>
> The RS780E part of code was previously located at
> arch/mips/pci/ops-loongson3.c and now it can use generic PCI
> driver implementation.
On Fri, May 08, 2020 at 07:34:05PM +0800, Jiaxun Yang wrote:
> We can now enable generic PCI driver in Kconfig, and remove legacy
> PCI driver code.
>
> Radeon vbios quirk is moved to the platform folder to fit the
> new structure.
> diff --git a/arch/mips/loongson64/vbios_quirk.c
>
On Fri, May 08, 2020 at 02:53:41PM +0800, Kai-Heng Feng wrote:
> Both Pericom OHCI and EHCI devices support PME# from all power states:
> 06:00.0 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB OHCI
> Controller [12d8:400e] (rev 01) (prog-if 10 [OHCI])
> Subsystem: Pericom
On Sat, May 09, 2020 at 01:28:24AM +0800, Jiaxun Yang wrote:
> 于 2020年5月9日 GMT+08:00 上午1:17:30, Bjorn Helgaas 写到:
> >On Fri, May 08, 2020 at 07:34:02PM +0800, Jiaxun Yang wrote:
> >> This controller can be found on Loongson-2K SoC, Loongson-3
> >> s
: Jiaxun Yang
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/probe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 77b8a145c39b..d9c2c3301a8a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
On Fri, May 08, 2020 at 07:34:02PM +0800, Jiaxun Yang wrote:
> This controller can be found on Loongson-2K SoC, Loongson-3
> systems with RS780E/LS7A PCH.
>
> The RS780E part of code was previously located at
> arch/mips/pci/ops-loongson3.c and now it can use generic PCI
> driver implementation.
On Fri, May 08, 2020 at 08:10:29PM +0800, Chen Zhou wrote:
> It is more efficient to use kmemdup_nul() if the size is known exactly.
>
> The doc in kernel:
> "Note: Use kmemdup_nul() instead if the size is known exactly."
If you want to do this, I want to do at least the entire drivers/pci
On Wed, May 06, 2020 at 01:34:21AM +0800, Kai-Heng Feng wrote:
> The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power
> state deeper than PC3 due to disabled ASPM, consumes lots of unnecessary
> power. On Windows ASPM L1 is enabled on the device and its upstream
> bridge, so it can
On Thu, May 07, 2020 at 02:05:44PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced
On Thu, May 07, 2020 at 05:28:36PM +0530, Bharat Kumar Gogada wrote:
> - Add support for Versal CPM as Root Port.
> - The Versal ACAP devices include CCIX-PCIe Module (CPM). The integrated
> block for CPM along with the integrated bridge can function
> as PCIe Root Port.
> - Bridge error and
On Thu, May 07, 2020 at 09:48:30AM +0200, Niklas Schnelle wrote:
> On 5/6/20 11:10 PM, Bjorn Helgaas wrote:
> > On Wed, May 06, 2020 at 05:41:38PM +0200, Niklas Schnelle wrote:
> >> currently pci_iov_add_virtfn() scans the SR-IOV bars, adds the VF to the
> >> bus and a
On Wed, May 06, 2020 at 09:14:38AM +0300, Mika Westerberg wrote:
> On Wed, May 06, 2020 at 01:34:21AM +0800, Kai-Heng Feng wrote:
> > The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power
> > state deeper than PC3 due to disabled ASPM, consumes lots of unnecessary
> > power. On
> the same zbus and test whether they are the parent PF in which case we
> establish the necessary links.
>
> With these links established there is now no more need to fence off
> pci_iov_remove_virtfn() for pdev->no_vf_scan as the common code now
> works fine.
>
> Signe
sysfs links.
This looks like two paragraphs missing the blank line between.
This whole thing is not "introducing" any new functionality; it's
"refactoring" to move existing functionality around and make it
callable separately.
> Signed-off-by: Niklas Schnelle
With the
G website.
> Signed-off-by: David E. Box
Acked-by: Bjorn Helgaas
> ---
> include/uapi/linux/pci_regs.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index f9701410d3b5..c96f08d1e711 100
On Tue, May 05, 2020 at 10:00:44PM +0800, Kai-Heng Feng wrote:
> > On May 5, 2020, at 21:38, Bjorn Helgaas wrote:
> > On Tue, May 05, 2020 at 08:27:59PM +0800, Kai-Heng Feng wrote:
> >> The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power
> >> state d
On Tue, May 05, 2020 at 08:27:59PM +0800, Kai-Heng Feng wrote:
> The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power
> state deeper than PC3 due to disabled ASPM, consumes lots of unnecessary
> power. On Windows ASPM L1 is enabled on the device and its upstream
> bridge, so it can
On Tue, Apr 28, 2020 at 09:14:17AM +0800, Jiaxun Yang wrote:
> This controller can be found on Loongson-2K SoC, Loongson-3
> systems with RS780E/LS7A PCH.
>
> The RS780E part of code was previously located at
> arch/mips/pci/ops-loongson3.c and now it can use generic PCI
> driver implementation.
On Mon, May 04, 2020 at 10:59:29AM +0200, Nicolas Saenz Julienne wrote:
> On Sat, 2020-05-02 at 11:05 +0200, Stefan Wahren wrote:
> > > + pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET, );
> > pci_read_config_dword() can fail, we might want to store the return value?
>
> I planned on
On Mon, May 04, 2020 at 09:07:21PM +0200, Greg Kroah-Hartman wrote:
> On Mon, May 04, 2020 at 01:08:22PM -0500, Bjorn Helgaas wrote:
> > On Sat, May 02, 2020 at 08:15:37AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, May 01, 2020 at 05:40:41PM -0500, Bjorn Helgaas wrote:
&
On Sat, May 02, 2020 at 08:15:37AM +0200, Greg Kroah-Hartman wrote:
> On Fri, May 01, 2020 at 05:40:41PM -0500, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > These interfaces return a negative error number or an IRQ:
> >
> > platform_get_irq(
On Thu, Apr 30, 2020 at 10:06:21AM +0200, Pali Rohár wrote:
> PCI-E capability macros are already defined in linux/pci_regs.h.
> Remove their reimplementation in pcie-aardvark.
s/PCI-E/PCIe/
I mentioned this last time, but I guess you missed it.
> Signed-off-by: Pali Rohár
> ---
>
On Thu, Apr 30, 2020 at 10:06:14AM +0200, Pali Rohár wrote:
> Adding even 100ms (PCI_PM_D3COLD_WAIT) delay between enabling link
> training and starting link training causes detection issues with some
> buggy cards (such as Compex WLE900VX).
>
> Move the code which enables link training
On Thu, Apr 30, 2020 at 10:06:25AM +0200, Pali Rohár wrote:
> Move the max-link-speed property of the PCIe node from board specific
> device tree files to the generic armada-37xx.dtsi.
>
> Armada 37xx supports only PCIe gen2 speed so max-link-speed property
> should be in the genetic
On Mon, May 04, 2020 at 03:02:59PM +0800, Kai-Heng Feng wrote:
> The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power
> state deeper than PC3, consumes lots of unnecessary power.
>
> On Windows ASPM L1 is enabled on the device and its upstream bridge,
> so it can make the Intel
rq*() instead of
making up a new one.
Link: https://lore.kernel.org/r/cover.1583952275.git.amanharitsh...@gmail.com
[bhelgaas: commit log, squash into one patch]
Signed-off-by: Aman Sharma
Signed-off-by: Bjorn Helgaas
Cc: Richard Zhu
Cc: Lucas Stach
Cc: Thierry Reding
Cc: Karthikeyan Mitran
Cc:
From: Bjorn Helgaas
These interfaces return a negative error number or an IRQ:
platform_get_irq()
platform_get_irq_optional()
platform_get_irq_byname()
platform_get_irq_byname_optional()
The function comments suggest checking for error like this:
irq = platform_get_irq
From: Bjorn Helgaas
All callers of platform_get_irq() and related functions interpret a
negative return value as an error. A few also interpret zero as an error.
platform_get_irq() should return either a negative error number or a valid
non-zero IRQ, so there's no need to check for zero
On Thu, Apr 30, 2020 at 12:46:07PM -0600, Jon Derrick wrote:
> Hi Bjorn & Kuppuswamy,
>
> I see a problem in the DPC ECN [1] to _OSC in that it doesn't give us a way to
> determine if firmware supports _OSC DPC negotation, and therefore how to
> handle
> DPC.
>
> Here is the wording of the ECN
On Thu, Apr 30, 2020 at 06:18:26PM +0200, Mauro Carvalho Chehab wrote:
> Convert this file to ReST by adding a proper title to it and
> use the right markups for a table.
>
> While here, add a SPDX header.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Bjorn Helgaas
>
On Fri, May 01, 2020 at 12:06:07AM +0200, Ansuel Smith wrote:
> This contains multiple fix for PCIe qcom driver.
> Some optional reset and clocks were missing.
> Fix a problem with no PARF programming that cause kernel lock on load.
> Add support to force gen 1 speed if needed. (due to hardware
On Thu, Apr 30, 2020 at 05:35:34PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> On 4/30/2020 3:40 PM, Bjorn Helgaas wrote:
> > On Sun, Apr 26, 2020 at 11:30:06AM -0700,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > From: Kuppuswamy Sathyanarayanan
> >
On Fri, May 01, 2020 at 02:40:23PM +, austin.bo...@dell.com wrote:
> On 4/30/2020 6:02 PM, Bjorn Helgaas wrote:
> > [Austin, help us understand the FIRMWARE_FIRST bit! :)]
> >
> > On Thu, Apr 30, 2020 at 05:40:22PM -0500, Bjorn Helgaas wrote:
> >> On Sun, Ap
[Austin, help us understand the FIRMWARE_FIRST bit! :)]
On Thu, Apr 30, 2020 at 05:40:22PM -0500, Bjorn Helgaas wrote:
> On Sun, Apr 26, 2020 at 11:30:06AM -0700,
> sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > From: Kuppuswamy Sathyanarayanan
> >
> >
>
[+cc Austin, Mario, Jon, Alex, Rafael, Keith, Sinan, Tyler]
On Sun, Apr 26, 2020 at 11:30:06AM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Currently PCIe AER driver uses HEST FIRMWARE_FIRST bit to
> determine the PCIe AER Capability ownership
[+cc Keith, Sinan, Tyler]
On Wed, Apr 29, 2020 at 03:24:41PM +, austin.bo...@dell.com wrote:
> On 4/28/2020 3:37 PM, Bjorn Helgaas wrote:
> > [+to Mario, Austin, Rafael; Dell folks, I suspect this commit will
> > break Dell servers but I'd like your opinion]
> >
On Thu, Apr 30, 2020 at 02:55:19PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan
>
> The oubound memory window registers were being referenced
> with an incorrect offset. This probably wasn't noticed
> previously as there was likely only one such outbound window.
If you repost these for any
On Thu, Apr 30, 2020 at 02:55:22PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan
>
> Some informal internal experiments has shown that the BrcmSTB ASPM L0s
> savings may introduce an undesirable noise signal on some customers'
> boards. In addition, L0s was found lacking in realized power
On Thu, Apr 30, 2020 at 02:55:20PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan
>
> Configuration Retry Request Status is off by default on this
> PCIe controller. Turn it on.
Are you talking about CRS itself, i.e., the ability of a Root Port to
deal with Completions with Configuration Retry
On Wed, Apr 29, 2020 at 03:24:41PM +, austin.bo...@dell.com wrote:
> On 4/28/2020 3:37 PM, Bjorn Helgaas wrote:
> > [EXTERNAL EMAIL]
> >
> > [+to Mario, Austin, Rafael; Dell folks, I suspect this commit will
> > break Dell servers but I'd like your opini
[+to Mario, Austin, Rafael; Dell folks, I suspect this commit will
break Dell servers but I'd like your opinion]
On Mon, Apr 27, 2020 at 07:02:13PM -0500, Bjorn Helgaas wrote:
> On Sun, Apr 26, 2020 at 11:30:06AM -0700,
> sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > From
On Tue, Apr 28, 2020 at 08:13:14PM +0530, Vaibhav Gupta wrote:
> Upgrade power management from legacy to generic using dev_pm_ops.
>
> Add "__maybe_unused" attribute to resume() and susend() callbacks
> definition to suppress compiler warnings.
>
> Generic callback requires an argument of type
) callbacks
> definition to suppress compiler warnings.
>
> Generic callback requires an argument of type "struct device*". Hence,
> convert it to "struct net_device*" using "dev_get_drvdata()" to use
> it in the callback.
>
> Sig
On Mon, Apr 27, 2020 at 08:20:07PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> Hi Bjorn,
>
> On 4/27/20 5:02 PM, Bjorn Helgaas wrote:
> > I split this up a bit and applied the first part to pci/error to get
> > it into -next so we can start seeing what breaks. I won't be to
On Tue, Apr 28, 2020 at 10:19:08AM +0800, Yicong Yang wrote:
> On 2020/4/28 2:13, Bjorn Helgaas wrote:
> >
> > I'm starting to think we're approaching this backwards. I searched
> > for PCIBIOS_FUNC_NOT_SUPPORTED, PCIBIOS_BAD_VENDOR_ID, and the other
> > erro
On Wed, Oct 23, 2019 at 12:12:08PM +, Nicholas Johnson wrote:
> ...
> It turns out Outlook is causing my encoding issues with git send-email.
>
> If I get a new email for kernel development, what should it be? Gmail
> works, but looks tackier.
I wish Documentation/process/email-clients.rst
On Wed, Oct 23, 2019 at 04:22:43PM +0800, Yunsheng Lin wrote:
> On 2019/10/23 5:04, Bjorn Helgaas wrote:
> > On Sat, Oct 19, 2019 at 02:45:43PM +0800, Yunsheng Lin wrote:
> > I think the underlying problem you're addressing is that:
> >
> > - NUMA_NO_NODE == -1,
&
On Wed, Oct 23, 2019 at 05:40:20PM +0800, Xiang Zheng wrote:
> Hi Bjorn,
>
> Thanks for your reply!
>
> On 2019/10/18 21:58, Bjorn Helgaas wrote:
> > [+cc Matthew]
> >
> > On Wed, Oct 16, 2019 at 09:36:23PM +0800, Xiang Zheng wrote:
> >> Hi all,
>
On Wed, Oct 23, 2019 at 12:12:29PM +, Nicholas Johnson wrote:
> Add kernel parameter pci=hpmmiosize=nn[KMG] to set MMIO bridge window
> size for hotplug bridges.
>
> Add kernel parameter pci=hpmmioprefsize=nn[KMG] to set MMIO_PREF bridge
> window size for hotplug bridges.
>
> Leave
On Wed, Oct 23, 2019 at 09:08:42AM +, Nicholas Johnson wrote:
> On Tue, Oct 08, 2019 at 02:38:12PM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Fri, Jul 26, 2019 at 12:53:19PM +, Nicholas Johnson wrote:
> > > /*
> > > - * Calculate the total amount of extra resource space we
On Mon, Aug 12, 2019 at 05:31:33PM +0300, Mika Westerberg wrote:
> If there are more than one PCIe switch with hotplug downstream ports
> hot-removing them leads to a following deadlock:
>
> INFO: task irq/126-pciehp:198 blocked for more than 120 seconds.
> "echo 0 >
On Wed, Oct 09, 2019 at 07:42:53AM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 09, 2019 at 02:51:15AM +, George Cherian wrote:
> > Hi Bjorn,
> >
> > Sorry for the late reply I was off for couple of days.
> >
> > On 10/8/19 2:32 PM, Bjorn He
On Sat, Oct 19, 2019 at 02:45:43PM +0800, Yunsheng Lin wrote:
> As the disscusion in [1]:
We need to justify this patch right here in the commit log, not with a
pointer to a 50+ message email thread.
> A PCI device really _MUST_ have a node assigned.
No, it's not really essential. It's *nice*
On Tue, Oct 22, 2019 at 05:07:47PM +0800, Dilip Kota wrote:
> On 10/22/2019 1:17 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 21, 2019 at 02:39:19PM +0800, Dilip Kota wrote:
> > > Add support to PCIe RC controller on Intel Gateway SoCs.
> > > PCIe controller is based of S
[+cc Rafael, linux-pm, beginning of discussion at
https://lore.kernel.org/r/d8574605f8e70f41ce1e88ccfb56b63c8f85e4df.1571638827.git.eswara.k...@linux.intel.com]
On Tue, Oct 22, 2019 at 05:27:38PM +0800, Dilip Kota wrote:
> On 10/22/2019 1:18 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 21, 2
On Mon, Oct 21, 2019 at 02:38:50PM +0100, Andrew Murray wrote:
> On Mon, Oct 21, 2019 at 02:39:20PM +0800, Dilip Kota wrote:
> > PCIe RC driver on Intel Gateway SoCs have a requirement
> > of changing link width and speed on the fly.
Please add more details about why this is needed. Since you're
On Mon, Oct 21, 2019 at 02:39:19PM +0800, Dilip Kota wrote:
> Add support to PCIe RC controller on Intel Gateway SoCs.
> PCIe controller is based of Synopsys DesignWare pci core.
>
> Intel PCIe driver requires Upconfig support, fast training
> sequence configuration and link speed change. So
On Sun, Oct 20, 2019 at 11:08:00AM +0200, Dominik Brodowski wrote:
> On the basis of the additional information (thanks), there might be a
> more specific path to investigate: It is that the PCI code does not
> enumerate the second cardbus bridge PCI function in the more recent 4.19
> kernel
[+cc Matthew]
On Wed, Oct 16, 2019 at 09:36:23PM +0800, Xiang Zheng wrote:
> Hi all,
>
> Recently I encountered a kernel panic while doing vfio-pci hot-plug/unplug
> test repeatly on my Arm-KVM virtual machines.
> See the call stack below:
>
> [66628.697280] vfio-pci :06:03.5: enabling
Hi Nicolas,
I'm hoping Christoph will chime in and one of the x86 guys will merge
this, since I'm not a DMA expert. Trivial comments/questions below.
On Wed, Oct 16, 2019 at 06:51:37PM +0200, Nicolas Saenz Julienne wrote:
> The devices found behind this PCIe chip have unusual DMA mapping
>
From: Bjorn Helgaas
Add and use pci_WARN() wrappers so warnings include device information.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-driver.c | 34 +-
include/linux/pci.h | 8
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git
From: Bjorn Helgaas
Some PM messages, e.g., "PCI PM: Device state not saved by %pS\n", had no
indication of what device was affected. Add pci_WARN() and use it.
Bjorn Helgaas (2):
PCI/PM: Use PCI dev_printk() wrappers for consistency
PCI/PM: Use pci_WARN() to include device i
From: Bjorn Helgaas
Use the PCI dev_printk() wrappers for consistency with the rest of the PCI
core. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-driver.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci
any more.
>
> Signed-off-by: Ben Dooks
Applied to pci/misc for v5.5, thanks a lot, Ben!
> ---
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> fixup - more unused pci bits
> ---
> drivers/pci/pci-sysfs.c | 18 --
701 - 800 of 12007 matches
Mail list logo
