Re: [PATCH RFC v4 17/21] PCI: Calculate boundaries for bridge windows

On Mon, Mar 11, 2019 at 04:31:18PM +0300, Sergey Miroshnichenko wrote: > If a bridge window contains fixed areas (there are PCIe devices with > immovable BARs located on this bus), I think what you mean by "immovable BARs" is "drivers that don't support moving BARs". I want to keep the concept

Re: [PATCH RFC v4 15/21] PCI: Allow the failed resources to be reassigned later

On Mon, Mar 11, 2019 at 04:31:16PM +0300, Sergey Miroshnichenko wrote: > Don't lose the size of the requested EP's BAR if it can't be fit > in a current trial, so this can be retried. s/EP/device/, since this applies equally to conventional PCI. > But a failed bridge window must be dropped and

Re: [PATCH RFC v4 14/21] PCI: Don't reserve memory for hotplug when enabled movable BARs

On Mon, Mar 11, 2019 at 04:31:15PM +0300, Sergey Miroshnichenko wrote: > pbus_size_mem() returns a precise amount of memory required to fit > all the requested BARs and windows of children bridges. Please make the commit log complete in itself, without requiring the subject. > Signed-off-by:

Re: [PATCH RFC v4 12/21] PCI: Don't allow hotplugged devices to steal resources

On Mon, Mar 11, 2019 at 04:31:13PM +0300, Sergey Miroshnichenko wrote: > When movable BARs are enabled, the PCI subsystem at first releases > all the bridge windows and then performs an attempt to assign new > requested resources and re-assign the existing ones. s/performs an attempt/attempts/ I

Re: [PATCH RFC v4 11/21] PCI: Release and reassign the root bridge resources during rescan

On Mon, Mar 11, 2019 at 04:31:12PM +0300, Sergey Miroshnichenko wrote: > When the movable BARs feature is enabled, don't rely on the memory gaps > reserved by the BIOS/bootloader/firmware, but instead rearrange the BARs > and bridge windows starting from the root. > > Endpoint device's BARs,

Re: [PATCH RFC v4 10/21] PCI: Fix assigning of fixed prefetchable resources

On Mon, Mar 11, 2019 at 04:31:11PM +0300, Sergey Miroshnichenko wrote: > Allow matching them to non-prefetchable windows, as it is done for movable > resources. Please make the commit log complete in itself, without requiring the subject. It's OK if you have to repeat the subject. IIUC, this is

Re: [PATCH RFC v4 09/21] PCI: Mark immovable BARs with PCI_FIXED

On Mon, Mar 11, 2019 at 04:31:10PM +0300, Sergey Miroshnichenko wrote: > If a PCIe device driver doesn't yet have support for movable BARs, > mark device's BARs with IORESOURCE_PCI_FIXED. I'm hesitant about using IORESOURCE_PCI_FIXED for this purpose. That was originally added to describe

Re: [PATCH RFC v4 08/21] nvme-pci: Handle movable BARs

[+cc Keith, Jens, Christoph, Sagi, linux-nvme, LKML] On Mon, Mar 11, 2019 at 04:31:09PM +0300, Sergey Miroshnichenko wrote: > Hotplugged devices can affect the existing ones by moving their BARs. > PCI subsystem will inform the NVME driver about this by invoking > reset_prepare()+reset_done(),

Re: [PATCH RFC v4 07/21] PCI: Wake up bridges during rescan when movable BARs enabled

On Mon, Mar 11, 2019 at 04:31:08PM +0300, Sergey Miroshnichenko wrote: > Use the PM runtime methods to wake up the bridges before accessing > their config space. > > Signed-off-by: Sergey Miroshnichenko > --- > drivers/pci/probe.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [PATCH RFC v4 05/21] PCI: hotplug: Add a flag for the movable BARs feature

On Mon, Mar 11, 2019 at 04:31:06PM +0300, Sergey Miroshnichenko wrote: > If a new PCIe device has been hot-plugged between the two active ones > without big enough gap between their BARs, Just to speak precisely here, a hot-added device is not "between" two active ones because the new device has

Re: [PATCH RFC v4 03/21] PCI: Enable bridge's I/O and MEM access for hotplugged devices

On Mon, Mar 11, 2019 at 04:31:04PM +0300, Sergey Miroshnichenko wrote: > After updating the bridge window resources, the PCI_COMMAND_IO and > PCI_COMMAND_MEMORY bits of the bridge must be addressed as well. > > Signed-off-by: Sergey Miroshnichenko > --- > drivers/pci/pci.c | 8 > 1

Re: [PATCH RFC v4 02/21] PCI: Fix race condition in pci_enable/disable_device()

[+cc Srinath, Marta, LKML] On Mon, Mar 11, 2019 at 04:31:03PM +0300, Sergey Miroshnichenko wrote: > CPU0 CPU1 > > pci_enable_device_mem() pci_enable_device_mem() >pci_enable_bridge() pci_enable_bridge() >

Re: [PATCH RFC v4 01/21] PCI: Fix writing invalid BARs during pci_restore_state()

Hi Sergey, Thanks for all your work here. This is a long-standing problem, and I'm glad you're working on it. On Mon, Mar 11, 2019 at 04:31:02PM +0300, Sergey Miroshnichenko wrote: > If BAR movement has happened (due to PCIe hotplug) after pci_save_state(), > the saved addresses will become

Re: [PATCH] hotplug/drc-info: ininitialize fndit to zero

[+cc Michael B (original author)] On Sat, Mar 16, 2019 at 09:40:16PM +, Colin King wrote: > From: Colin Ian King > > Currently variable fndit is not initialized and contains a > garbage value, later it is set to 1 if a drc entry is found. > Ensure fndit is not containing garbage by

Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER

On Thu, Nov 15, 2018 at 05:16:01PM -0600, Alexandru Gagniuc wrote: > Thanks to Keith for pointing out that it doesn't make sense to disable > AER services when only one device has a FIRMWARE_FIRST HEST. > > AER ownership is an interesting issue brought in by FFS (firmware-first) > model. In a

Re: [PATCH v1] PCI/AER: use match_string() helper to simplify the code

On Mon, Jan 28, 2019 at 01:57:28PM +0200, Andy Shevchenko wrote: > match_string() returns the index of an array for a matching string, > which can be used intead of open coded implementation. > > Signed-off-by: Andy Shevchenko Applied to pci/aer for v5.1, thanks! > --- >

Re: [PATCH] PCI: Use of_node_name_eq for node name comparisons

ael Ellerman > Cc: Bjorn Helgaas > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring I applied the pci/of.c change to pci/misc for v5.1, thanks! I dropped the rpaphp_core.c part because there's another patch in-flight [1] that touch

Re: [RFC 5/6] powerpc/pci/hotplug: Use common drcinfo parsing

On Mon, Jan 14, 2019 at 06:28:57PM -0600, Bjorn Helgaas wrote: > On Fri, Dec 14, 2018 at 02:51:31PM -0600, Michael Bringmann wrote: > > The implementation of the pseries-specific drc info properties > > is currently implemented in pseries-specific and non-pseries-specific > &g

Re: [RFC 5/6] powerpc/pci/hotplug: Use common drcinfo parsing

On Fri, Dec 14, 2018 at 02:51:31PM -0600, Michael Bringmann wrote: > The implementation of the pseries-specific drc info properties > is currently implemented in pseries-specific and non-pseries-specific > files. This patch set uses a new implementation of the device-tree > parsing code for the

Kconfig label updates

Hi, I want to update the PCI Kconfig labels so they're more consistent and useful to users, something like the patch below. IIUC, the items below are all IBM-related; please correct me if not. I'd also like to expand (or remove) "RPA" because Google doesn't find anything about "IBM RPA", except

Re: [PATCH 1/2] PCI/IOV: provide flag to skip VF scanning

On Fri, Dec 21, 2018 at 03:19:49PM +0100, Sebastian Ott wrote: > Hello Bjorn, > > On Thu, 20 Dec 2018, Bjorn Helgaas wrote: > > I think the strategy is fine, but can you restructure the patches > > like this: > > > > 1) Factor out sriov_add_vfs()

Re: [PATCH 1/2] PCI/IOV: provide flag to skip VF scanning

Hi Sebastian, On Tue, Dec 18, 2018 at 11:16:49AM +0100, Sebastian Ott wrote: > Provide a flag to skip scanning for new VFs after SRIOV enablement. > This can be set by implementations for which the VFs are already > reported by other means. > > Signed-off-by: Sebastian Ott > --- >

Re: [PATCH] PCI/AER: only insert one element into kfifo

On Wed, Dec 12, 2018 at 04:32:30PM +0800, Yanjiang Jin wrote: > 'commit ecae65e133f2 ("PCI/AER: Use kfifo_in_spinlocked() to > insert locked elements")' replace kfifo_put() with kfifo_in_spinlocked(). > > But as "kfifo_in(fifo, buf, n)" describes: > " * @n: number of elements to be added". > >

Re: [PATCH 0/2] sriov enablement on s390

On Wed, Dec 05, 2018 at 02:45:14PM +0100, Sebastian Ott wrote: > Hello Bjorn, > > On Wed, 10 Oct 2018, Bjorn Helgaas wrote: > > On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote: > > > On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > > > > On W

Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

On Tue, Dec 11, 2018 at 6:38 PM David Gibson wrote: > > On Tue, Dec 11, 2018 at 08:01:43AM -0600, Bjorn Helgaas wrote: > > Hi David, > > > > I see you're still working on this, but if you do end up going this > > direction eventually, would you mind splitting this i

Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

Hi David, I see you're still working on this, but if you do end up going this direction eventually, would you mind splitting this into two patches: 1) rename the quirk to make it more generic (but not changing any behavior), and 2) add the ConnectX devices to the quirk. That way the ConnectX

Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

On Wed, Nov 14, 2018 at 07:22:04PM +, alex_gagn...@dellteam.com wrote: > On 11/14/2018 12:00 AM, Bjorn Helgaas wrote: > > On Tue, Nov 13, 2018 at 10:39:15PM +, alex_gagn...@dellteam.com wrote: > >> On 11/12/2018 11:02 PM, Bjorn Helgaas wrote: > >> ... > &

Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

On Tue, Nov 13, 2018 at 10:39:15PM +, alex_gagn...@dellteam.com wrote: > On 11/12/2018 11:02 PM, Bjorn Helgaas wrote: > > > > [EXTERNAL EMAIL] > > Please report any suspicious attachments, links, or requests for sensitive > > information. It looks like Dell's

Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

[+cc Jon, for related VMD firmware-first error enable issue] On Mon, Nov 12, 2018 at 08:05:41PM +, alex_gagn...@dellteam.com wrote: > On 11/11/2018 11:50 PM, Oliver O'Halloran wrote: > > On Thu, 2018-11-08 at 23:06 +, alex_gagn...@dellteam.com wrote: > >> But it's not the firmware that

Re: [PATCH 6/9] PCI: consolidate PCI config entry in drivers/pci

gt; not compile without PCI enabled. On other architectures with limited > PCI support that wasn't as complicated I've left the selection as-is. > > Signed-off-by: Christoph Hellwig > Acked-by: Max Filippov > Acked-by: Thomas Gleixner > Acked-by: Bjorn Helgaas Sounds like Ma

Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

[+cc Jonathan, Greg, Lukas, Russell, Sam, Oliver for discussion about PCI error recovery in general] On Wed, Nov 07, 2018 at 05:42:57PM -0600, Bjorn Helgaas wrote: > On Tue, Sep 18, 2018 at 05:15:00PM -0500, Alexandru Gagniuc wrote: > > When a PCI device is gone, we don't want t

Re: [PATCH 4/8] pci: consolidate PCI config entry in drivers/pci

, and a lot of code does > not compile without PCI enabled. On other architectures with limited > PCI support that wasn't as complicated I've left the selection as-is. Thanks for doing this. It's a great cleanup. I know you have a few things you're cleaning up, but add my: Acked-by: Bjorn Helgaas when you do that.

Re: [PATCH 1/8] aha152x: rename the PCMCIA define

On Sat, Oct 13, 2018 at 05:10:09PM +0200, Christoph Hellwig wrote: > We plan to enable building the pcmcia core and drivers, and the > non-prefixed PCMCIA name clashes with some arch headers. In the followup PCMCIA patch, you capitalized "PCMCIA core".

Re: [PATCH 0/2] sriov enablement on s390

On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote: > Hello Bjorn, > > On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > > On s390 we currently handle SRIOV within firmware. Which means > > &

Re: [linux-next][bisected e3fbcc7c] build error at drivers/pci/pcie/aer_inject.c:444:6: error: ‘struct pt_regs’ has no member named ‘ip

On Tue, Oct 9, 2018 at 5:40 AM Abdul Haleem wrote: > > On Tue, 2018-10-09 at 20:47 +1100, Michael Ellerman wrote: > > Abdul Haleem writes: > > > Greeting's > > > > > > Today's linux-next fails to build on ppc with below error > > > > > > drivers/pci/pcie/aer_inject.c: In function

Re: [RFC 00/15] PCI: turn some __weak functions into callbacks

On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > Hi Bjorn and others, > > Triggered by Christoph's patches, I had another go at converting > all of the remaining pci host bridge implementations to be based > on pci_alloc_host_bridge and a separate registration function. > > This

Re: [PATCH -next] PCI: hotplug: Use kmemdup rather than duplicating its implementation in pnv_php_add_devtree()

On Thu, Sep 27, 2018 at 06:52:21AM +, YueHaibing wrote: > Use kmemdup rather than duplicating its implementation > > Signed-off-by: YueHaibing Applied with Michael's ack to pci/hotplug for v4.20, thanks! > --- > drivers/pci/hotplug/pnv_php.c | 3 +-- > 1 file changed, 1 insertion(+), 2

Re: [PATCH -next] PCI/AER: Remove duplicated include from err.c

On Wed, Sep 26, 2018 at 11:00:10AM +, YueHaibing wrote: > Remove duplicated include. > > Signed-off-by: YueHaibing Applied to pci/hotplug for v4.20, thanks! > --- > drivers/pci/pcie/err.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/pci/pcie/err.c

Re: [PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling

On Wed, Sep 19, 2018 at 11:49:26AM +1000, Russell Currey wrote: > On Tue, 2018-09-18 at 16:58 -0500, Bjorn Helgaas wrote: > > On Wed, Sep 12, 2018 at 11:55:26AM -0500, Bjorn Helgaas wrote: > > > From: Bjorn Helgaas > > > > > > The original PCI error recove

Re: [PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling

On Wed, Sep 12, 2018 at 11:55:26AM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > The original PCI error recovery functionality was for the powerpc-specific > IBM EEH feature. PCIe subsequently added some similar features, including > AER and DPC, that can be used on a

Re: [PATCH RFC 1/4] PCI: hotplug: Add parameter to put devices to reset during rescan

On Tue, Sep 18, 2018 at 05:01:48PM +0300, Sergey Miroshnichenko wrote: > On 9/18/18 1:59 AM, Bjorn Helgaas wrote: > > On Mon, Sep 17, 2018 at 11:55:43PM +0300, Sergey Miroshnichenko wrote: > >> On 9/17/18 8:28 AM, Sam Bobroff wrote: > >>> On Fri, Sep 14, 20

Re: [PATCH RFC 1/4] PCI: hotplug: Add parameter to put devices to reset during rescan

[+cc Russell, Ben, Oliver, linuxppc-dev] On Mon, Sep 17, 2018 at 11:55:43PM +0300, Sergey Miroshnichenko wrote: > Hello Sam, > > On 9/17/18 8:28 AM, Sam Bobroff wrote: > > Hi Sergey, > > > > On Fri, Sep 14, 2018 at 07:14:01PM +0300, Sergey Miroshnichenko wrote: > >> Introduce a new command line

Re: [PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling

On Wed, Sep 12, 2018 at 11:55:26AM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > The original PCI error recovery functionality was for the powerpc-specific > IBM EEH feature. PCIe subsequently added some similar features, including > AER and DPC, that can be used on a

[PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling

From: Bjorn Helgaas The original PCI error recovery functionality was for the powerpc-specific IBM EEH feature. PCIe subsequently added some similar features, including AER and DPC, that can be used on any architecture. We want the generic PCI core error handling support to work with all

Re: [PATCH 0/2] sriov enablement on s390

[+cc Arnd, powerpc folks] On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > Hello Bjorn, > > On s390 we currently handle SRIOV within firmware. Which means > that the PF is under firmware control and not visible to operating > systems. SRIOV enablement happens within firmware and

Re: [PATCH] MAINTAINERS: add maintainer entries for RPA pci hotplug drivers

On Mon, Aug 20, 2018 at 06:20:31PM -0700, Tyrel Datwyler wrote: > Adding myself as maintiner of the IBM RPA hotplug modules located in > drivers/pci/hotplug directory. These modules provide kernel interfaces > for support of Dynamic Logical Partitioning (DLPAR) of Logical and > Physical IO slots,

Re: [PATCH] PCI: call dma_debug_add_bus for pci_bus_type in common code

On Mon, Jul 30, 2018 at 09:38:42AM +0200, Christoph Hellwig wrote: > There is nothing arch specific about PCI or dma-debug, so move this > call to common code just after registering the bus type. > > Signed-off-by: Christoph Hellwig Applied with acks from Thomas and Michael to pci/misc for

Re: [PATCH v3 1/1] powerpc/pseries: fix EEH recovery of some IOV devices

This is a fix to allow EEH recovery to succeed in a specific situation, > which I've tried to explain in the commit message. > > As with the RFC version, the IOV BARs are disabled by setting the resource > flags to 0 but the other fields are now left as-is because that is what is &

Re: [PATCH] PCI: call dma_debug_add_bus for pci_bus_type in common code

[+cc Joerg] On Mon, Jul 30, 2018 at 09:38:42AM +0200, Christoph Hellwig wrote: > There is nothing arch specific about PCI or dma-debug, so move this > call to common code just after registering the bus type. I assume that previously, even if the user set CONFIG_DMA_API_DEBUG=y we only got PCI

Re: [PATCH v3] PCI: Data corruption happening due to race condition

On Thu, Jul 19, 2018 at 02:18:09PM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-07-18 at 18:29 -0500, Bjorn Helgaas wrote: > > [+cc Paul, Michael, linuxppc-dev] > > > >/... > > > > Debugging revealed a race condition between pcie core d

Re: [PATCH v3] PCI: Data corruption happening due to race condition

[+cc Paul, Michael, linuxppc-dev] On Tue, Jul 03, 2018 at 02:35:41PM +0530, Hari Vyas wrote: > When a pci device is detected, a variable is_added is set to > 1 in pci device structure and proc, sys entries are created. > > When a pci device is removed, first is_added is checked for one > and

Re: [PATCH v2 1/1] powerpc/pseries: fix EEH recovery of some IOV devices

BARs are disabled by setting the resource > flags to 0 but the other fields are now left as-is because that is what is > done > elsewhere (see sriov_init() and __pci_read_base()). > > I've also examined the concern raised by Bjorn Helgaas, that VFs could be > enabled later after th

Re: [patchV2 2/2] pci/shpchp: no claim on pcie port device

On Wed, Jun 13, 2018 at 02:29:57PM +0800, Pingfan Liu wrote: > The Linux Device Driver Model allows a physical device to be handled > by only a single driver. But at present, both shpchp and portdrv_pci > claim PCI_CLASS_BRIDGE_PCI, and touch devices_kset when the drivers are > loaded. This causes

Re: [PATCH 4/5] pci/hotplug/pnv-php: add missing of_node_put

On Wed, May 23, 2018 at 09:07:15PM +0200, Julia Lawall wrote: > The device node iterators perform an of_node_get on each iteration, so a > jump out of the loop requires an of_node_put. > > The semantic patch that fixes this problem is as follows > (http://coccinelle.lip6.fr): > > // > @@ >

Re: [PATCH v17 0/9] Address error and recovery for AER and DPC

[+cc Russell, Sam, Bryant, linuxppc-dev, Sebastian, linux-s390] Sorry, I should have pulled in these new CC's earlier because ppc and s390 both have PCI error handling similar to what Oza is changing here. The basic issue is that the new PCIe DPC (Downstream Port Containment, see PCIe r4.0, sec

Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

When you add the changleog, please also fix the subject typo: - bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus ^^^ + bus: fsl-mc: support dma configure for devices on fsl-mc bus On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote: > Signed-off-by: Nipun

Re: [PATCH v4 2/6] iommu: of: make of_pci_map_rid() available for other devices too

to 'of_map_rid' and there is no > functional change done in the API. > > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> > --- > drivers/iommu/of_iommu.c | 5 +-- > drivers/of/base.c| 102 > +

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

On Tue, Apr 10, 2018 at 02:36:31PM -0500, Bjorn Helgaas wrote: > On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote: > > The disabling informational messages on the PCI subsystem should be deleted > > since they do not represent any real value for

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote: > The disabling informational messages on the PCI subsystem should be deleted > since they do not represent any real value for the system logs. > > These messages are either not presented, or presented for all PCI devices

Re: [PATCH] PCI/IOV: Add missing prototype for powerpc specific

On Thu, Mar 22, 2018 at 09:33:55PM +0100, Mathieu Malaterre wrote: > Some prototypes for weak functions were missing for powerpc specific > functions. Add the missing prototypes to the CONFIG_PCI_IOV block. This > fixes the following three warnings treated as error when using W=1: > >

Re: [PATCH 1/1] PCI set flag PCI_SCAN_ALL_PCIE_DEVS for P.A. Semi boards

On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote: > Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for > Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set by > quirks or the "pci=pcie_scan_all" > kernel parameter

Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem

On Wed, Mar 14, 2018 at 03:22:44PM -0300, Desnes Augusto Nunes do Rosário wrote: > Hello Bjorn, > > On 03/14/2018 03:06 PM, Bjorn Helgaas wrote: > > On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote: > > > Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN

Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem

On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote: > Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to > silent PCI realignment messages if the flag is turned on by a driver. > > Signed-off-by: Desnes A. Nunes do Rosario > ---

Re: [PATCH RFC 1/1] powerpc/pseries: fix EEH recovery of IOV devices

On Thu, Feb 22, 2018 at 11:23:35AM +1100, Sam Bobroff wrote: > Currently EEH recovery will fail on pSeries platforms for > passed-through physical devices that support IOV, when CONFIG_PCI_IOV > is set and the hypervisor doesn't provide a device tree node > "ibm,open-sriov-vf-bar-info" for the

Re: [PATCH] powerpc: Use generic pci_mmap_resource_range()

On Mon, Feb 19, 2018 at 12:59:51PM +, David Woodhouse wrote: > Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for > ARM64") added this generic function with the intent of using it > everywhere and ultimately killing the old arch-specific implementations. > > Let's get on

Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h

On Thu, Feb 08, 2018 at 11:20:35PM +1100, Michael Ellerman wrote: > There's no reason pci_uevent_ers() needs to be inline in pci.h, so > move it out to a C file. > > Given it's used by AER the obvious location would be somewhere in > drivers/pci/pcie/aer, but because it's also used by powerpc EEH

Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h

On Thu, Feb 08, 2018 at 09:05:45AM -0600, Bryant G. Ly wrote: > > On 2/8/18 6:20 AM, Michael Ellerman wrote: > > > There's no reason pci_uevent_ers() needs to be inline in pci.h, so > > move it out to a C file. > > > > Given it's used by AER the obvious location would be somewhere in > >

Re: [PATCH kernel v3] powerpc/pci: Fix broken INTx configuration via OF

On Fri, Feb 09, 2018 at 12:07:41PM -0600, Bjorn Helgaas wrote: > On Fri, Feb 09, 2018 at 05:23:58PM +1100, Alexey Kardashevskiy wrote: > > Commit 59f47eff03a0 ("powerpc/pci: Use of_irq_parse_and_map_pci() helper") > > replaced of_irq_parse_pci(

[GIT PULL] PCI fixes for v4.16

PCI fixes: - fix POWER9/powernv INTx regression from the merge window (Alexey Kardashevskiy) The following changes since commit ab8c609356fbe8dbcd44df11e884ce8cddf3739e: Merge branch 'pci/spdx' into next (2018-02-01 11:40:07 -0600) are available in the Git repository at:

Re: [PATCH v1] PCI: Make PCI_SCAN_ALL_PCIE_DEVS work for Root as well as Downstream Ports

eration branch with what's upstream, and they're identical. So maybe the original patch I applied was wrong? If you have a patch that works, can you post it and maybe I can sort out what's different? > On 2. Dec 2017, at 20:18, Bjorn Helgaas <helg...@kernel.org> wrote: > > On Fri

Re: [PATCH kernel v3] powerpc/pci: Fix broken INTx configuration via OF

On Fri, Feb 09, 2018 at 05:23:58PM +1100, Alexey Kardashevskiy wrote: > Commit 59f47eff03a0 ("powerpc/pci: Use of_irq_parse_and_map_pci() helper") > replaced of_irq_parse_pci() + irq_create_of_mapping() with > of_irq_parse_and_map_pci() but this change lost virq returned by >

Re: [PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF

On Fri, Feb 09, 2018 at 09:21:43AM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2018-02-08 at 15:39 -0600, Bjorn Helgaas wrote: > > I don't understand how this fix works. We used to check the result of > > of_irq_parse_and_map_pci() and entered the block if it was zero. > &g

Re: [PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF

On Thu, Feb 08, 2018 at 01:20:04PM -0600, Bjorn Helgaas wrote: > [+cc linux-pci] > > The original commit was merged via PCI, and I think it's a good idea > to merge fixes to it the same way. I'll try to merge this in time for > v4.16-rc1. > > On Wed, Feb 7, 201

Re: [PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF

[+cc linux-pci] The original commit was merged via PCI, and I think it's a good idea to merge fixes to it the same way. I'll try to merge this in time for v4.16-rc1. On Wed, Feb 7, 2018 at 11:33 PM, Alexey Kardashevskiy wrote: > Commit 59f47eff03a0 ("powerpc/pci: Use

Re: [PATCH 0/3] PCI: move DT PCI functions to PCI core

On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote: > Most subsystem specific functions have been moved into the respective > subsystems. Only PCI and networking remain. This series moves most of the > PCI related code to drivers/pci/of.c. Some bus address functions for PCI > remain in

Re: [PATCH 0/3] PCI: move DT PCI functions to PCI core

On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote: > Most subsystem specific functions have been moved into the respective > subsystems. Only PCI and networking remain. This series moves most of the > PCI related code to drivers/pci/of.c. Some bus address functions for PCI > remain in

Re: [PATCH] PCI: Add #defines for Completion Timeout Disable feature

On Fri, Dec 15, 2017 at 04:57:11PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas <bhelg...@google.com> > > Add #defines for the Completion Timeout Disable feature and use them. No > functional change intended. > > Signed-off-by: Bjorn Helgaas <bhelg...@google.c

Re: [PATCH v4 2/7] linux/pci: Add uevents in AER and EEH error/resume

devices in > all arches. > > Signed-off-by: Bryant G. Ly <bryan...@linux.vnet.ibm.com> > Signed-off-by: Juan J. Alvarez <jjalv...@linux.vnet.ibm.com> > Acked-by: Bjorn Helgaas <bhelg...@google.com> > --- > arch/powerpc/kernel/eeh_driver.c | 6 ++

Re: [PATCH v3 2/7] powerpc/kernel: Add uevents in EEH error/resume

s are better propagated to user > space for devices in powerpc arch. > > Signed-off-by: Bryant G. Ly <bryan...@linux.vnet.ibm.com> > Signed-off-by: Juan J. Alvarez <jjalv...@linux.vnet.ibm.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> Please merge this along with

Re: [PATCH v2 2/7] powerpc/kernel: Add uevents in EEH error/resume

On Wed, Dec 20, 2017 at 09:04:27PM -0600, Juan Alvarez wrote: > On 12/19/17 12:27 AM, Benjamin Herrenschmidt wrote: > > > On Mon, 2017-12-18 at 22:50 -0600, Bjorn Helgaas wrote: > >> [+cc Keith, Gabriele, Dongdong] > >> > >> On Mon, Dec 18, 2017

Re: [PATCH v2 2/7] powerpc/kernel: Add uevents in EEH error/resume

[+cc Keith, Gabriele, Dongdong] On Mon, Dec 18, 2017 at 04:38:03PM -0600, Bryant G. Ly wrote: > Devices can go offline when EEH is reported. This patch adds > a change to the kernel object and lets udev know of error. > When device resumes a change is also set reporting device as > online.

[PATCH] PCI: Add #defines for Completion Timeout Disable feature

From: Bjorn Helgaas <bhelg...@google.com> Add #defines for the Completion Timeout Disable feature and use them. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- arch/powerpc/platforms/powernv/eeh-powernv.c |6 +++--- include/uapi/linu

Re: [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus

On Fri, Dec 15, 2017 at 09:04:51AM +0100, Christian Zigotzky wrote: > On 09 December 2017 at 7:03PM, Christian Zigotzky wrote: > > On 08 December 2017 at 12:59PM, Michael Ellerman wrote: > > > > > >> Darren's idea of doing it at the same time you tweak the SB600 "relax > > >> pci-e" bit is ideal

Re: [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus

On Wed, Dec 06, 2017 at 11:57:03PM +1100, Michael Ellerman wrote: > Christian Zigotzky writes: > ... > > > > Hi Olof, > > > > Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without any > > problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don’t

Re: [PATCH v1] PCI: Make PCI_SCAN_ALL_PCIE_DEVS work for Root as well as Downstream Ports

On Fri, Dec 01, 2017 at 06:27:10PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas <bhelg...@google.com> > > PCIe Downstream Ports normally have only a Device 0 below them. To > optimize enumeration, we don't scan for other devices *unless* the > PCI_SCAN_ALL_PCIE_DE

[PATCH v1] PCI: Make PCI_SCAN_ALL_PCIE_DEVS work for Root as well as Downstream Ports

From: Bjorn Helgaas <bhelg...@google.com> PCIe Downstream Ports normally have only a Device 0 below them. To optimize enumeration, we don't scan for other devices *unless* the PCI_SCAN_ALL_PCIE_DEVS flag is set by set by quirks or the "pci=pcie_scan_all" kernel parame

Re: [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus

On Fri, Dec 01, 2017 at 11:08:46PM +0100, Christian Zigotzky wrote: > On 30.11.2017 23:42, Bjorn Helgaas wrote: > > > > 00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That > > means there's a Link (presumably this A-Link II Express thing), and the > >

Re: [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus

On Thu, Nov 30, 2017 at 12:39:36AM +0100, Christian Zigotzky wrote: > On 29 November 2017 at 11:34PM, Bjorn Helgaas wrote: > > On Wed, Nov 29, 2017 at 2:45 PM, Christian Zigotzky > >> Thank you for your answer. I have tried to boot the kernel 4.15 > >> RC1 (bu

Re: [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus

On Wed, Nov 29, 2017 at 2:45 PM, Christian Zigotzky <chzigot...@xenosoft.de> wrote: > On 29 November 2017 at 8:46PM, Bjorn Helgaas wrote: >> >> On Wed, Nov 29, 2017 at 1:28 PM, Christian Zigotzky >> <chzigot...@xenosoft.de> wrote: >>> >>> On

Re: [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus

On Wed, Nov 29, 2017 at 1:28 PM, Christian Zigotzky wrote: > On 23 November 2017 2:31PM, Michael Ellerman wrote: >> >> Hi Christian, >> >> Thanks for your patch. >> >> Christian Zigotzky writes: >>> >>> Hi All, >>> >>> Just a small patch for the

Re: [PATCH v2 1/2] powerpc/pci: convert to use for_each_pci_bridge() helper

On Thu, Nov 23, 2017 at 11:48:18PM +1100, Michael Ellerman wrote: > Bjorn Helgaas <helg...@kernel.org> writes: > > > On Fri, Nov 10, 2017 at 07:52:29PM +0200, Andy Shevchenko wrote: > >> ...which makes code slightly cleaner. > >> > >> Requires

Re: [PATCH v2 1/2] powerpc/pci: convert to use for_each_pci_bridge() helper

On Fri, Nov 10, 2017 at 07:52:29PM +0200, Andy Shevchenko wrote: > ...which makes code slightly cleaner. > > Requires: d43f59ce6c50 ("PCI: Add for_each_pci_bridge() helper") Requires: 24a0c654d7d6 ("PCI: Add for_each_pci_bridge() helper") (My fault, I rebased that commit before sending it to

Re: [PATCH v1] powerpc/pci: convert to use for_each_pci_bridge() helper

On Tue, Oct 31, 2017 at 10:12 AM, Andy Shevchenko wrote: > On Fri, 2017-10-13 at 19:52 +0300, Andy Shevchenko wrote: >> ...which makes code slightly cleaner. > > +Cc: Bjorn > > Perhaps it makes sense to pass this through PCI if no one objects? Fine with me, but

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On Tue, Oct 17, 2017 at 06:13:35PM -0500, Juan Alvarez wrote: > On 10/17/17 1:52 PM, Bjorn Helgaas wrote: > > I'm suggesting that maybe there should be a generic way to prevent > > binding to VF devices that works for everybody and doesn't require any > > arch-specific code a

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On Tue, Oct 17, 2017 at 12:23:01PM -0500, Juan Alvarez wrote: > On 10/17/17 11:26 AM, Bjorn Helgaas wrote: > > To pop back up to the top of the stack, I think the main point of this > > patch is to keep from binding a driver to the VFs in the kernel that > > set PCI_SRIOV_

Re: [PATCH kernel v2] powerpc/powernv: Reserve a hole which appears after enabling IOV

ources are stored in pci_dn to avoid > kmalloc/free. > > Cc: linux-...@vger.kernel.org > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Cc: Bjorn Helgaas <bhelg...@google.com> > Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru> Looks good

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On Tue, Oct 17, 2017 at 09:33:34AM -0500, Juan Alvarez wrote: > On 10/17/17 8:51 AM, Bjorn Helgaas wrote: > > This is where I get confused. I guess the Linux that sets > > PCI_SRIOV_CTRL_VFE to enable the VFs can also perform config accesses > > to the VFs, since it can enu

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On Fri, Oct 13, 2017 at 02:12:32PM -0500, Bryant G. Ly wrote: > > > On 10/13/17 1:05 PM, Alex Williamson wrote: > >On Fri, 13 Oct 2017 07:01:48 -0500 > >Steven Royer <sero...@linux.vnet.ibm.com> wrote: > > > >>On 2017-10-13 06:53, Steven Royer wrote: >

[PATCH v2 2/2] vgaarb: Factor out EFI and fallback default device selection

, but it untangles the "bridge control possible" checking and messages from the default device selection. Tested-by: Zhou Wang <wangzh...@hisilicon.com> # D05 Hisi Hip07, Hip08 Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/g

[PATCH v2 1/2] vgaarb: Select a default VGA device even if there's no legacy VGA

GA device we find. Link: http://lkml.kernel.org/r/20170901072744.2409-1-...@axtens.net Tested-by: Daniel Axtens <d...@axtens.net> # arm64, ppc64-qemu-tcg Tested-by: Zhou Wang <wangzh...@hisilicon.com> # D05 Hisi Hip07, Hip08 Signed-off-by: Bjorn Helgaas <bhelg...@google.com&

<    1   2   3   4   5   6   7   8   9   >