On Thu, Sep 10, 2020 at 07:51:05PM +, Derrick, Jonathan wrote:
> On Thu, 2020-09-10 at 14:17 -0500, Bjorn Helgaas wrote:
> > On Thu, Sep 10, 2020 at 06:52:48PM +, Derrick, Jonathan wrote:
> > > On Thu, 2020-09-10 at 12:38 -0500, Bjorn Helgaas wrote:
> > > >
On Thu, Sep 17, 2020 at 10:19:13AM -0700, Alexander Duyck wrote:
> On Thu, Sep 17, 2020 at 9:56 AM Bjorn Helgaas wrote:
> >
> > [+cc Alexander]
> >
> > On Thu, Sep 17, 2020 at 03:10:42PM +0800, Liu Shixin wrote:
> > > Use the module_pci_driver() macro to make t
On Thu, Sep 17, 2020 at 09:25:38AM -0700, Sean V Kelley wrote:
> Changes since v3 [1]:
This series claims "V4 00/10", i.e., there should be this cover letter
plus 10 patches, but I only got 3 patches. I don't know if some got
lost, or if only those 3 patches were updated, or what? If it's the
On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> From: Jiang Biao
>
> pci_read_config() could block several ms in kernel space, mainly
> caused by the while loop to call pci_user_read_config_dword().
> Singel pci_user_read_config_dword() loop could consume 130us+,
> |
On Thu, Aug 06, 2020 at 02:57:34PM -0700, Tuan Phan wrote:
> Ampere Altra SOC supports only 32-bit ECAM reading. Therefore,
> add an MCFG quirk for the platform.
>
> Signed-off-by: Tuan Phan
Applied to pci/enumeration for v5.10, thanks!
> ---
> drivers/acpi/pci_mcfg.c | 20
On Fri, Aug 21, 2020 at 03:51:21PM +, Clint Sbisa wrote:
> The else/endif comments for pci_{create,remove}_resource_files were
> not updated in commit f719582435afe9c7985206e42d804ea6aa315d33 ("PCI:
> Add pci_mmap_resource_range() and use it for ARM64").
>
> Signed-off-by: Clint Sbisa
[+cc Alexander]
On Thu, Sep 17, 2020 at 03:10:42PM +0800, Liu Shixin wrote:
> Use the module_pci_driver() macro to make the code simpler
> by eliminating module_init and module_exit calls.
>
> Signed-off-by: Liu Shixin
Applied to pci/misc for v5.10, thanks!
> ---
> drivers/pci/pci-pf-stub.c
On Wed, Sep 16, 2020 at 02:21:28PM +0800, Qinglang Miao wrote:
> Use for_each_child_of_node() and for_each_node_by_name macro
> instead of open coding it.
>
> Signed-off-by: Qinglang Miao
Applied to pci/hotplug for v5.10, thanks!
> ---
> drivers/pci/hotplug/rpadlpar_core.c | 8
> 1
On Tue, Sep 15, 2020 at 09:09:20AM -0700, Sean V Kelley wrote:
> Walking the bus with an RCEC as it is probed in the portdrv_pci.c can be
> done with both its own bus (bitmap) and with supported associated bus
> ranges. In that walk I’m able to find all the associated endpoints via both
> bitmap
On Mon, Sep 14, 2020 at 09:55:53AM -0700, Sean V Kelley wrote:
> On 11 Sep 2020, at 17:50, Bjorn Helgaas wrote:
> > On Fri, Sep 11, 2020 at 04:16:03PM -0700, Sean V Kelley wrote:
> > > I’ve done some experimenting with this approach, and I think
> > > there may b
MMIO
> accesses.
>
> Signed-off-by: Matthew Rosato
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/iov.c | 1 +
> include/linux/pci.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index b37e08c..4afd4ee 100644
On Tue, Sep 15, 2020 at 07:15:38PM +0530, Srinath Mannam wrote:
> This patch series contains fixes and improvements to pcie iproc driver.
>
> This patch set is based on Linux-5.9.0-rc2.
>
> Changes from v1:
> - Addressed Bjorn's review comments
> - pcie_print_link_status is used to print
s/Harcode/Hardcode/ (in subject)
Also fix subject format as for 4/5.
On Wed, Sep 16, 2020 at 06:50:00PM +0530, Manivannan Sadhasivam wrote:
> Hardcode the PCIe config SID table value. This is needed to avoid random
> MHI failure observed during reboot on SM8250.
>
> Signed-off-by: Jonathan
On Tue, Jul 14, 2020 at 01:15:40PM -0700, Rajat Jain wrote:
> The ACS "Translation Blocking" bit blocks the translated addresses from
> the devices. We don't expect such traffic from devices unless ATS is
> enabled on them. A device sending such traffic without ATS enabled,
> indicates malicious
On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote:
> When enabling ACS, enable translation blocking for external facing ports
> and untrusted devices.
>
> Signed-off-by: Rajat Jain
Applied (slightly modified) to pci/acs for v5.10, thanks!
I think the warning is superfluous because
On Wed, Sep 16, 2020 at 06:49:59PM +0530, Manivannan Sadhasivam wrote:
> The PCIe IP on SM8250 SoC is similar to the one used on SDM845. Hence
> the support is added reusing the 2.7.0 ops. Only difference is the need
> of ATU base, which will be fetched opionally if provided by DT/ACPI.
>
>
On Wed, Sep 16, 2020 at 02:30:20PM +0200, gre...@linuxfoundation.org wrote:
> On Tue, Sep 15, 2020 at 10:28:11AM -0500, Bjorn Helgaas wrote:
> > On Tue, Sep 15, 2020 at 08:24:50AM +, 吳昊澄 Ricky wrote:
> > > > -Original Message-
> > > > From: Bjorn H
On Sun, Sep 13, 2020 at 12:27:09PM +0800, Jiang Biao wrote:
> On Thu, 10 Sep 2020 at 09:59, Bjorn Helgaas wrote:
> > On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> > > On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> > > > On Mon, Aug 24, 2020 a
On Sun, Sep 13, 2020 at 01:54:38PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> On 9/10/20 1:14 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 24, 2020 at 08:58:53PM -0700,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > From: Kuppuswamy Sathyanarayanan
> > >
On Sun, Sep 13, 2020 at 01:49:26PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> On 9/10/20 2:00 PM, Kuppuswamy, Sathyanarayanan wrote:
> > On 9/10/20 12:49 PM, Bjorn Helgaas wrote:
> > > On Fri, Jul 24, 2020 at 08:58:52PM -0700,
> > > sathyanarayanan.kuppusw...@linux.in
On Tue, Sep 15, 2020 at 09:36:13AM +0800, Huacai Chen wrote:
> Hi, Tiezhu,
>
> On Mon, Sep 14, 2020 at 7:25 PM Tiezhu Yang wrote:
> >
> > On 09/14/2020 05:46 PM, Huacai Chen wrote:
> > > Hi, Tiezhu,
> > >
> > > On Mon, Sep 14, 2020 at 5:30 PM Tiezhu Yang
> > > wrote:
> > >> On 09/14/2020 04:52
On Tue, Sep 15, 2020 at 08:11:01AM -0700, Ming Qiao wrote:
> Some of the Juniper FPGAs do not report correct PCI class ID, which
> would confuse kernel APIs accessing the specific class of devices.
> Change them to PCI_CLASS_SYSTEM_OTHER << 8.
Please include a note about the consequence of the
On Tue, Sep 15, 2020 at 11:53:26AM +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 15, 2020 at 01:47:21PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Wed, 9 Sep 2020 10:06:20 -0600 Rob Herring wrote:
> > >
> > > On Tue, Sep 8, 2020 at 8:37 PM Stephen Rothwell
> > > wrote:
> > > >
> > >
On Tue, Sep 15, 2020 at 07:31:50PM +0200, Rafael J. Wysocki wrote:
> On Mon, Sep 14, 2020 at 2:34 PM Shiju Jose wrote:
> >
> > Hello,
> >
> > Can you help to merge this series?
>
> Do you want this series to go in through the ACPI tree?
It crosses ACPI and vendor-specific PCI, but the bulk of
On Tue, Sep 15, 2020 at 08:24:50AM +, 吳昊澄 Ricky wrote:
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Friday, September 11, 2020 10:56 PM
> > To: 吳昊澄 Ricky
> > Cc: a...@arndb.de; gre...@linuxfoundation.org; bhe
On Sun, Sep 13, 2020 at 09:40:56AM +0100, Chris Clayton wrote:
> Hi Greg and Arnd,
>
> On 24/08/2020 04:00, ricky...@realtek.com wrote:
> > From: Ricky Wu
> >
> > this power saving action in rtsx_pci_init_ocp() cause INTEL-NUC6 platform
> > missing card reader
>
> In his changelog above, Ricky
On Fri, Sep 11, 2020 at 04:16:03PM -0700, Sean V Kelley wrote:
> On 4 Sep 2020, at 19:23, Bjorn Helgaas wrote:
> > On Fri, Sep 04, 2020 at 10:18:30PM +, Kelley, Sean V wrote:
> > > Hi Bjorn,
> > >
> > > Quick question below...
> > >
> >
On Fri, Sep 11, 2020 at 08:18:22AM +, 吳昊澄 Ricky wrote:
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Thursday, September 10, 2020 1:44 AM
> > To: 吳昊澄 Ricky
> > Cc: a...@arndb.de; gre...@linuxfoundation.org; bhe
On Fri, Sep 11, 2020 at 03:55:34PM +0530, Srinath Mannam wrote:
> Fix IOVA reserve failure in the case when address of first memory region
> listed in dma-ranges is equal to 0x0.
>
> Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
> address")
> Signed-off-by: Srinath
On Thu, Sep 10, 2020 at 08:57:10AM -0400, Jim Quinlan wrote:
> Hi Bjorn,
>
> On Wed, Sep 9, 2020 at 10:25 PM Bjorn Helgaas wrote:
> >
> > On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote:
> > > The Kconfig is modified so that the pcie_bus_config setting c
[+cc Huacai]
On Thu, Sep 10, 2020 at 02:41:39PM -0500, Bjorn Helgaas wrote:
> On Sat, Sep 05, 2020 at 04:33:26PM +0800, Tiezhu Yang wrote:
> > After commit 745be2e700cd ("PCIe: portdrv: call pci_disable_device
> > during remove") and commit cc27b735ad3a ("PCI/portd
On Fri, Jul 24, 2020 at 08:58:53PM -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
On Fri, Jul 24, 2020 at 08:58:52PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
> struct pci_host_bridge PCIe specific native_* members to "1" is
> incorrect. So protect the PCIe
On Sat, Sep 05, 2020 at 04:33:26PM +0800, Tiezhu Yang wrote:
> After commit 745be2e700cd ("PCIe: portdrv: call pci_disable_device
> during remove") and commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe
> services during shutdown"), it also calls pci_disable_device() during
> shutdown, this seems
On Wed, Sep 09, 2020 at 09:42:34PM +0800, YueHaibing wrote:
> This function has been made static, which causes warning:
>
> WARNING: modpost: "dw_pcie_link_set_max_speed" [vmlinux] is a static
> EXPORT_SYMBOL_GPL
>
> Fixes: 3af45d34d30c ("PCI: dwc: Centralize link gen setting")
This commit is
On Thu, Sep 10, 2020 at 11:50:07AM -0700, Florian Fainelli wrote:
> On 9/10/2020 11:46 AM, Bjorn Helgaas wrote:
> > On Thu, Sep 10, 2020 at 08:21:06AM -0600, Rob Herring wrote:
> > > On Wed, Sep 9, 2020 at 8:07 PM Bjorn Helgaas wrote:
> > > >
> >
On Thu, Sep 10, 2020 at 06:52:48PM +, Derrick, Jonathan wrote:
> On Thu, 2020-09-10 at 12:38 -0500, Bjorn Helgaas wrote:
> > On Thu, Sep 10, 2020 at 04:33:39PM +, Derrick, Jonathan wrote:
> > > On Wed, 2020-09-09 at 20:55 -0500, Bjorn Helgaas wrote:
> > > >
On Thu, Sep 10, 2020 at 08:21:06AM -0600, Rob Herring wrote:
> On Wed, Sep 9, 2020 at 8:07 PM Bjorn Helgaas wrote:
> >
> > [+cc Mark, Florian, Rob, Scott]
> >
> > On Sat, Aug 01, 2020 at 09:25:49AM +0800, Xingxing Su wrote:
> > > Do not use printk in ra
On Thu, Sep 10, 2020 at 04:33:39PM +, Derrick, Jonathan wrote:
> On Wed, 2020-09-09 at 20:55 -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 21, 2020 at 08:32:20PM +0800, Kai-Heng Feng wrote:
> > > New Intel laptops with VMD cannot reach deeper power saving state,
> > >
On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> Hi,
>
> On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> >
> > On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> > > From: Jiang Biao
> > >
> > > pci_read_config(
[+cc Mark, Florian, Rob, Scott]
On Sat, Aug 01, 2020 at 09:25:49AM +0800, Xingxing Su wrote:
> Do not use printk in raw_spinlocks,
> it will cause BUG: Invalid wait context.
>
> The trace reported by lockdep follows.
>
> [2.986113] =
> [2.986115] [ BUG:
On Thu, Sep 03, 2020 at 01:10:02PM -0400, Matthew Rosato wrote:
> On 9/3/20 12:41 PM, Bjorn Helgaas wrote:
> >- How do we decide whether to use dev_flags vs a bitfield like
> > dev->is_virtfn? The latter seems simpler unless there's a reason
> > to us
On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote:
> The Kconfig is modified so that the pcie_bus_config setting can be done at
> build time in the same manner as the CONFIG_PCIEASPM_ choice. The
> pci_bus_config setting may still be overridden by the bootline param.
I guess... I
[+cc Saheed]
On Fri, Aug 21, 2020 at 08:32:20PM +0800, Kai-Heng Feng wrote:
> New Intel laptops with VMD cannot reach deeper power saving state,
> renders very short battery time.
>
> As BIOS may not be able to program the config space for devices under
> VMD domain, ASPM needs to be programmed
On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> From: Jiang Biao
>
> pci_read_config() could block several ms in kernel space, mainly
> caused by the while loop to call pci_user_read_config_dword().
> Singel pci_user_read_config_dword() loop could consume 130us+,
> |
On Thu, Jul 23, 2020 at 11:51:52AM +0200, Lukas Wunner wrote:
> On Thu, Jul 23, 2020 at 05:13:06PM +0800, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-9):
> [...]
> > commit: 3233e41d3e8ebcd44e92da47ffed97fd49b84278 ("[PATCH] PCI: pciehp: Fix
> > AB-BA
On Wed, Sep 09, 2020 at 07:10:19AM +, 吳昊澄 Ricky wrote:
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Wednesday, September 09, 2020 6:29 AM
> > To: 吳昊澄 Ricky
> > Cc: a...@arndb.de; gre...@linuxfoundation.org; bhe
From: Bjorn Helgaas
Every post to megaraidlinux@broadcom.com seems to generate a bounce, so
I think the list is defunct. Remove it from MAINTAINERS.
Signed-off-by: Bjorn Helgaas
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On Wed, Sep 09, 2020 at 08:50:58PM +0530, Vaibhav Gupta wrote:
> On Wed, Sep 09, 2020 at 08:23:32AM -0500, Bjorn Helgaas wrote:
> > On Wed, Sep 09, 2020 at 03:33:15PM +0530, Vaibhav Gupta wrote:
> > > On Tue, Sep 08, 2020 at 12:32:09PM -0500, Bjorn Helgaas wrote:
> > > &
On Wed, Sep 09, 2020 at 03:33:15PM +0530, Vaibhav Gupta wrote:
> On Tue, Sep 08, 2020 at 12:32:09PM -0500, Bjorn Helgaas wrote:
> > On Mon, Jul 20, 2020 at 07:04:14PM +0530, Vaibhav Gupta wrote:
> > > With legacy PM hooks, it was the responsibility of a driver to manage PCI
>
On Tue, Sep 08, 2020 at 09:47:21PM +0800, Hongtao Wu wrote:
> From: Billows Wu
>
> This series adds PCIe controller driver for Unisoc SoCs.
> This controller is based on DesignWare PCIe IP.
>
> Signed-off-by: Billows Wu
Last signed-off must be from developer submitting the patch, i.e.,
On Mon, Sep 07, 2020 at 06:07:31PM +0800, ricky...@realtek.com wrote:
> From: Ricky Wu
>
> v4:
> split power down flow and power saving function to two patch
>
> v5:
> fix up modified change under the --- line
Hehe, this came out *above* the "---" line :)
> Add rts522a L1 sub-state support
>
On Mon, Sep 07, 2020 at 06:07:18PM +0800, ricky...@realtek.com wrote:
> From: Ricky Wu
>
> Fix and sort out rtsx driver power down flow
It would be nice to say what's changing here, but it's a great
improvement to have this split out.
For example, this drops the "pm_state == HOST_ENTER_S3"
On Mon, Sep 07, 2020 at 08:08:50PM +0800, Jianjun Wang wrote:
> Add YAML schemas documentation for Gen3 PCIe controller on
> MediaTek SoCs.
Please mention "mediatek" in the subject line so "git log --oneline"
is more useful.
The convention (not universally observed) seems to be something like:
On Tue, Sep 08, 2020 at 02:26:01PM -0500, Bjorn Helgaas wrote:
> On Fri, Sep 04, 2020 at 11:38:49AM +0100, Lad Prabhakar wrote:
> > Document the support for R-Car PCIe EP on R8A774E1 SoC device.
> >
> > Signed-off-by: Lad Prabhakar
> > Reviewed-by: Biju Das
> >
On Fri, Sep 04, 2020 at 11:38:49AM +0100, Lad Prabhakar wrote:
> Document the support for R-Car PCIe EP on R8A774E1 SoC device.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Biju Das
> ---
> Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
>
On Mon, Jul 20, 2020 at 07:04:14PM +0530, Vaibhav Gupta wrote:
> With legacy PM hooks, it was the responsibility of a driver to manage PCI
> states and also the device's power state. The generic approach is to let
> the PCI core handle the work.
>
> PCI core passes "struct device*" as an argument
On Fri, Sep 04, 2020 at 10:18:30PM +, Kelley, Sean V wrote:
> Hi Bjorn,
>
> Quick question below...
>
> On Wed, 2020-09-02 at 14:55 -0700, Sean V Kelley wrote:
> > Hi Bjorn,
> >
> > On Wed, 2020-09-02 at 14:00 -0500, Bjorn Helgaas wrote:
> > > On W
On Wed, Sep 02, 2020 at 03:46:34PM -0400, Matthew Rosato wrote:
> Per the PCIe spec, VFs cannot implement the MSE bit
> AKA PCI_COMMAND_MEMORY, and it must be hard-wired to 0.
> Use a dev_flags bit to signify this requirement.
This approach seems sensible to me, but
- This is confusing because
On Wed, Aug 12, 2020 at 09:46:53AM -0700, Sean V Kelley wrote:
> From: Qiuxu Zhuo
>
> When an RCEC device signals error(s) to a CPU core, the CPU core
> needs to walk all the RCiEPs associated with that RCEC to check
> errors. So add the function pcie_walk_rcec() to walk all RCiEPs
> associated
On Wed, Aug 12, 2020 at 09:46:56AM -0700, Sean V Kelley wrote:
> From: Qiuxu Zhuo
>
> When attempting error recovery for an RCiEP associated with an RCEC device,
> there needs to be a way to update the Root Error Status, the Uncorrectable
> Error Status and the Uncorrectable Error Severity of
On Wed, Sep 02, 2020 at 11:07:43AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the pci tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/pci/pci-driver.c: In function 'pci_pm_thaw_noirq':
> drivers/pci/pci-driver.c:1037:6: warning: unused
> > > From: Ricky Wu
> > >
> > > Added rts5227 rts5249 rts5260 rts5228 power saving functions,
> > > added BIOS guide MMC funciton and U_d3_en register support and
> > > fixed rts5260 driving parameter
> >
> > This should be split into small logical pieces. I can't really tell
> > what those
d rts5260 driving parameter
>
> Signed-off-by: Ricky Wu
I'm attaching the same response I sent you yesterday, since it doesn't
look like you read any of it (except adding to the cc list).
>From helg...@kernel.org Mon Aug 31 16:21:53 2020
Date: Mon, 31 Aug 2020 16:21:53 -0500
From: Bjorn Helg
On Fri, Aug 28, 2020 at 06:11:50PM -0700, Atish Patra wrote:
> On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas wrote:
> > On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> > > On Fri, 14 Aug 2020 14:47:22 -0700
> > > Atish Patra wrote:
> > >
[+cc Vaibhav]
On Wed, Jun 27, 2018 at 04:23:40PM -0500, Bjorn Helgaas wrote:
> [+cc Rafael, linux-pm, linux-kernel]
>
> On Wed, Jun 27, 2018 at 10:15:50PM +0200, Jean Delvare wrote:
> > Hi Jarkko,
> >
> > On Tue, 26 Jun 2018 17:39:12 +0300, Jarkko Nikula wrote:
>
On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> On Fri, 14 Aug 2020 14:47:22 -0700
> Atish Patra wrote:
>
> > pcibus_to_node is used only when numa is enabled and does not depend
> > on ISA. Thus, it can be moved the generic numa implementation.
> >
> > Signed-off-by: Atish
[+cc George]
On Fri, Aug 28, 2020 at 02:34:01PM +0800, Yang Yingliang wrote:
> config GENERIC_IOMAP is not selected on some arch, pci_iounmap()
> don't implement, when we using pci_iomap/pci_iounmap, it will
> lead to memory leak.
> This patch set moves the implemention of pci_iounmap() to
>
On Thu, Aug 27, 2020 at 01:17:48PM -0600, Alex Williamson wrote:
> On Thu, 27 Aug 2020 13:31:38 -0500
> Bjorn Helgaas wrote:
>
> > Re the subject line, this patch does a lot more than just "introduce a
> > flag"; AFAICT it actually enables important VFIO function
mid: Move PCI initialization to
> arch_init()")
> Signed-off-by: Randy Dunlap
> Cc: sta...@vger.kernel.org # v4.16+
> Cc: Jacob Pan
> Cc: Len Brown
> To: Bjorn Helgaas
> Cc: Jesse Barnes
> Cc: Arjan van de Ven
> Cc: linux-...@vger.kernel.org
> Reviewed-by: Andy
Re the subject line, this patch does a lot more than just "introduce a
flag"; AFAICT it actually enables important VFIO functionality, e.g.,
something like:
vfio/pci: Enable MMIO access for s390 detached VFs
On Thu, Aug 13, 2020 at 11:40:43AM -0400, Matthew Rosato wrote:
> s390x has the notion
[+cc Rob,
cover https://lore.kernel.org/r/20200826111628.794979...@linutronix.de/
this https://lore.kernel.org/r/20200826112333.992429...@linutronix.de/]
On Wed, Aug 26, 2020 at 01:17:02PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled
On Tue, Aug 25, 2020 at 11:30:41PM +0200, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 15:24, Bjorn Helgaas wrote:
> > On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
> >> Rename it to x86_msi_prepare() and handle the allocation type setup
> >> d
On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 15:07, Bjorn Helgaas wrote:
> >> + * The arch hooks to setup up msi irqs. Default functions are implemented
> >> + * as weak symbols so that they /can/ be overriden by archit
On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
> Rename it to x86_msi_prepare() and handle the allocation type setup
> depending on the device type.
I see what you're doing, but the subject reads a little strangely
("pci_msi_prepare() handling non-PCI" stuff) since it doesn't
e #ifdeffery to the header file where it is
> not in the way.
>
> Signed-off-by: Thomas Gleixner
> Cc: linux-...@vger.kernel.org
Nice cleanup, thanks. Glad to get rid of the useless initializer,
too.
Acked-by: Bjorn Helgaas
> ---
> arch/x86/include/asm/pci_x86.h | 11
gt; override in irq remapping.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
s|PCI: MSI:|PCI/MSI:| in the subject if feasible.
> ---
> drivers/pci/msi.c | 22 ++
> include/linux/msi.
On Fri, Aug 21, 2020 at 02:24:54AM +0200, Thomas Gleixner wrote:
> If an architecture does not require the MSI setup/teardown fallback
> functions, then allow them to be replaced by stub functions which emit a
> warning.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn He
pt remapping.
>
> Override the default bus token.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn Helgaas
> Cc: Lorenzo Pieralisi
> Cc: Jonathan Derrick
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/controller/vmd.c |
ot; here in the commit log,
but nice cleanup and:
Acked-by: Bjorn Helgaas
Minor comments below.
> Signed-off-by: Thomas Gleixner
> Cc: linux-...@vger.kernel.org
> ---
> arch/x86/kernel/apic/msi.c |2 +-
> drivers/pci/msi.c | 13 ++---
> include/linux/m
On Mon, Aug 24, 2020 at 11:23:11AM +0100, Marc Zyngier wrote:
> Signed-off-by: Marc Zyngier
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 30ae4ffda5c1
On Tue, Aug 25, 2020 at 11:53:42AM +0200, Jean Delvare wrote:
> Hi Bjorn, Vaibhav,
>
> On Fri, 07 Aug 2020 15:23:21 -0500, Bjorn Helgaas wrote:
> > Also, i801_suspend() looks suspicious because it writes SMBHSTCFG, but
> > I don't see anything corresponding in i801_resume
On Fri, Aug 21, 2020 at 05:37:18PM +0100, Jonathan Cameron wrote:
> On Fri, 21 Aug 2020 08:46:22 -0500
> Bjorn Helgaas wrote:
>
> > On Fri, Aug 21, 2020 at 01:59:01PM +0100, Jonathan Cameron wrote:
> > > On Fri, 21 Aug 2020 07:13:56 -0500
> > > Bjorn Helgaas w
On Fri, Aug 21, 2020 at 08:46:22AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 21, 2020 at 01:59:01PM +0100, Jonathan Cameron wrote:
> > On Fri, 21 Aug 2020 07:13:56 -0500
> > Bjorn Helgaas wrote:
> >
> > > [+cc Keith, author of 3accf7ae37a9 ("acpi/hmat: Parse an
On Fri, Aug 21, 2020 at 01:59:01PM +0100, Jonathan Cameron wrote:
> On Fri, 21 Aug 2020 07:13:56 -0500
> Bjorn Helgaas wrote:
>
> > [+cc Keith, author of 3accf7ae37a9 ("acpi/hmat: Parse and report
> > heterogeneous memory")]
> >
> > On Fri, Aug 21,
[+cc Keith, author of 3accf7ae37a9 ("acpi/hmat: Parse and report
heterogeneous memory")]
On Fri, Aug 21, 2020 at 09:42:58AM +0100, Jonathan Cameron wrote:
> On Thu, 20 Aug 2020 17:21:29 -0500
> Bjorn Helgaas wrote:
>
> > On Wed, Aug 19, 2020 at 10:51:09PM +080
On Wed, Aug 19, 2020 at 10:51:07PM +0800, Jonathan Cameron wrote:
> In common with memoryless domains we only register GI domains
> if the proximity node is not online. If a domain is already
> a memory containing domain, or a memoryless domain there is
> nothing to do just because it also
On Wed, Aug 19, 2020 at 10:51:09PM +0800, Jonathan Cameron wrote:
> In ACPI 6.3, the Memory Proximity Domain Attributes Structure
> changed substantially. One of those changes was that the flag
> for "Memory Proximity Domain field is valid" was deprecated.
>
> This was because the field
bus. This
> ensures no bus is 'starved' of emitting a warning and also that there
> isn't a continuous stream of warnings. It would be preferable to have a
> warning per device, but the pci_dev structure is not available here, and
> a lookup from devfn would be far too slow.
>
> Sugge
[+cc Michael, author of 66eab4df288a ("lib: add GENERIC_PCI_IOMAP")]
On Thu, Aug 20, 2020 at 10:33:06AM +0530, George Cherian wrote:
> In case if any architecture selects CONFIG_GENERIC_PCI_IOMAP and not
> CONFIG_GENERIC_IOMAP, then the pci_iounmap function is reduced to a NULL
> function. Due to
PCI fixes:
- Fix P2PDMA build issue (Christoph Hellwig)
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
removed, then it
> > can later be made to return void.
> >
> > Remove all uses of the return value of pci_read_config_*().
> > Check the actual value read for ~0. In this case, ~0 is an invalid
> > value thus it indicates some kind of error.
> >
> > Suggested-by:
On Mon, Aug 10, 2020 at 10:32:52AM +0100, Jonathan Cameron wrote:
> On Fri, 7 Aug 2020 17:55:17 -0700
> Sean V Kelley wrote:
> > On 7 Aug 2020, at 15:53, Bjorn Helgaas wrote:
> > > On Tue, Aug 04, 2020 at 12:40:47PM -0700, Sean V Kelley wrote:
> > >>
On Mon, Aug 17, 2020 at 4:59 PM Stephen Rothwell wrote:
>
> Hi all,
>
> In commit
>
> 35150fc886a0 ("PCI/P2PDMA: Fix build without DMA ops")
>
> Fixes tag
>
> Fixes: 2f9237d4f6d ("dma-mapping: make support for dma ops optional")
>
> has these problem(s):
>
> - SHA1 should be at least 12
nd
> reasonable to remove even that.
>
> Reported-by: Bjorn Helgaas
> Signed-off-by: Vaibhav Gupta
Applied to pci/pm for v5.10, thanks!
> ---
> drivers/pci/pci-driver.c | 24
> include/linux/pci.h | 4
> 2 files changed, 28 deletions(-)
>
On Tue, Aug 04, 2020 at 01:44:15PM +0100, Alex Bennée wrote:
> For a pure VirtIO guest bringing in all the PCI quirk handling adds a
> significant amount of bloat to kernel we don't need. Solve this by
> adding a CONFIG symbol for the ThunderX PCI devices and allowing it to
> be turned off. Saving
On Sat, Aug 15, 2020 at 01:51:11PM +0100, Marc Zyngier wrote:
> Recent changes to the DT PCI bus parsing made it mandatory for
> device tree nodes describing a PCI controller to have the
> 'device_type = "pci"' property for the node to be matched.
>
> Although this follows the letter of the
Move PCI initialization to
arch_init()")
Possibly
Cc: sta...@vger.kernel.org # v4.16+
> Signed-off-by: Randy Dunlap
> Cc: Jacob Pan
> Cc: Len Brown
> Cc: Bjorn Helgaas
> Cc: Jesse Barnes
> Cc: Arjan van de Ven
> Cc: linux-...@vger.kernel.org
>
On Tue, Aug 04, 2020 at 12:40:47PM -0700, Sean V Kelley wrote:
> From: Jonathan Cameron
>
> Currently the kernel does not handle AER errors for Root Complex integrated
> End Points (RCiEPs)[0]. These devices sit on a root bus within the Root
> Complex
> (RC). AER handling is performed by a Root
_channel_state state)
++pci_channel_state_t state)
+{
Enumeration:
- Fix pci_cfg_wait queue locking problem (Bjorn Helgaas)
- Convert PCIe capability PCIBIOS errors to errno (Bolarinwa Olayemi
401 - 500 of 12007 matches
Mail list logo
