On Mon, Dec 06, 2021 at 11:27:34PM +0100, Thomas Gleixner wrote:
> Last user is gone long ago.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c |8
> in
Gunthorpe
Acked-by: Bjorn Helgaas# PCI
> ---
> drivers/irqchip/irq-gic-v2m.c|1 -
> drivers/irqchip/irq-gic-v3-its-pci-msi.c |1 -
> drivers/irqchip/irq-gic-v3-mbi.c |1 -
> drivers/pci/msi.c|2 +-
> include/linux/msi.
I: Provide sensible IRQ vector alloc/free routines")
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> V2: Fix typo in subject - Jason
> ---
> drivers/pci/msi.c | 26 ++---
On Thu, Nov 18, 2021 at 07:33:10PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> This patch series adds PCI_ERROR_RESPONSE
ONSE definition for that and use it where
> appropriate to make these checks consistent and easier to find.
>
> Also add helper definitions SET_PCI_ERROR_RESPONSE and
> RESPONSE_IS_PCI_ERROR to make the code more readable.
>
> Suggested-by: Bjorn Helgaas
> Signed-off-by: Naveen Nai
On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:
> On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
> > Hello,
> >
> > The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16
> updates [2].
> >
> > Error messages:
> >
> > ata4.00: gc timeout cmd 0xec
> >
On Tue, Nov 09, 2021 at 04:10:14PM +0100, Christian Zigotzky wrote:
> On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
> > Hello,
> >
> > The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16
> updates [2].
> >
> > Error messages:
> >
> > ata4.00: gc timeout cmd 0xec
> >
On Thu, Oct 21, 2021 at 10:23:30PM +0530, Naveen Naidu wrote:
> On 20/10, Bjorn Helgaas wrote:
> > On Tue, Oct 05, 2021 at 10:48:12PM +0530, Naveen Naidu wrote:
> > > In EDR path, AER status registers are cleared irrespective of whether
> > > the error was an RP PI
On Thu, Oct 21, 2021 at 10:06:11PM +0530, Naveen Naidu wrote:
> On 20/10, Bjorn Helgaas wrote:
> > On Tue, Oct 05, 2021 at 10:48:11PM +0530, Naveen Naidu wrote:
> > > dpc_process_error() clears both AER fatal and non fatal status
> > > registers. Instead of clearin
On Thu, Oct 21, 2021 at 10:00:21PM +0530, Naveen Naidu wrote:
> On 20/10, Bjorn Helgaas wrote:
> > On Tue, Oct 05, 2021 at 10:48:08PM +0530, Naveen Naidu wrote:
> > > Currently, we do not print the "id" field in the AER error logs. Yet the
> > > aer_agent_stri
[+cc Keith, Sinan, Oza]
On Tue, Oct 05, 2021 at 10:48:12PM +0530, Naveen Naidu wrote:
> In the EDR path, AER registers are cleared *after* DPC error event is
> processed. The process stack in EDR is:
>
> edr_handle_event()
> dpc_process_error()
> pci_aer_raw_clear_status()
>
On Tue, Oct 05, 2021 at 10:48:11PM +0530, Naveen Naidu wrote:
> dpc_process_error() clears both AER fatal and non fatal status
> registers. Instead of clearing each status registers via a different
> function call use pci_aer_clear_status().
>
> This helps clean up the code a bit.
>
>
On Tue, Oct 05, 2021 at 10:48:08PM +0530, Naveen Naidu wrote:
> Currently, we do not print the "id" field in the AER error logs. Yet the
> aer_agent_string[] has the word "id" in it. The AER error log looks
> like:
>
> pcieport :00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link
>
On Tue, Oct 05, 2021 at 10:48:10PM +0530, Naveen Naidu wrote:
> In the dpc_process_error() path, info->id isn't initialized before being
> passed to aer_print_error(). In the corresponding AER path, it is
> initialized in aer_isr_one_error().
>
> The error message shown during Coverity Scan is:
>
On Mon, Oct 04, 2021 at 11:29:27PM +0530, Naveen Naidu wrote:
> The (PCIe r5.0, sec 7.6.4.3, Table 7-101) and (PCIe r5.0, sec 7.8.4.6,
> Table 7-104)
s/7.6.4.3/7.8.4.3/
Cite it like this:
Per PCIe r5.0, sec 7.8.4.3 and sec 7.8.4.6, the default values ...
> states that the default values
On Wed, Oct 13, 2021 at 04:23:09PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 13, 2021 at 06:33:56AM -0500, Bjorn Helgaas wrote:
> > On Wed, Oct 13, 2021 at 12:26:42PM +0300, Andy Shevchenko wrote:
> > > On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> > > >
On Wed, Oct 13, 2021 at 12:26:42PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
>
> > I split some of the bigger patches apart so they only touched one
> > drive
On Wed, Oct 13, 2021 at 10:51:31AM +0200, Uwe Kleine-König wrote:
> On Tue, Oct 12, 2021 at 06:32:12PM -0500, Bjorn Helgaas wrote:
> > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > this is v6 of the quest to drop the
On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this is v6 of the quest to drop the "driver" member from struct pci_dev
> which tracks the same data (apart from a constant offset) as dev.driver.
I like this a lot and applied it to pci/driver for v5.16, thanks!
I
On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> includes
On Tue, Sep 28, 2021 at 09:29:36PM +0200, Uwe Kleine-König wrote:
> On Tue, Sep 28, 2021 at 12:17:59PM -0500, Bjorn Helgaas wrote:
> > [+to Oliver, Russell for eeh_driver_name() question below]
> >
> > On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
> &g
[+to Oliver, Russell for eeh_driver_name() question below]
On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> struct pci_dev::driver holds (apart from a constant offset) the same
> data as struct pci_dev::dev->driver. With the goal to remove struct
>
s the driver for OpenCAPI coherent accelerator (OCXL).
Strictly speaking, not really relevant for the commit log.
> Cc: David E. Box
> Cc: Jonathan Cameron
> Cc: Bjorn Helgaas
> Cc: Dan Williams
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: An
On Tue, Sep 14, 2021 at 01:27:08AM +1000, Oliver O'Halloran wrote:
> The general convention for pcibios_* hooks is that they're named after
> the corresponding pci_* function they provide a hook for. The exception
> is pcibios_add_device() which provides a hook for pci_device_add(). This
> has
>
> Now pci_dev_assign_added() is called in pci_bus_add_device() which is
> only called after scanning the device. Thus pci_dev_is_added() is always
> false and can be dropped.
>
> Signed-off-by: Niklas Schnelle
Reviewed-by: Bjorn Helgaas
This doesn't touch the PCI core, so maybe makes sense
Make your subject line follow the previous convention.
Figure out if this is a "probable" or a real double put. If it's a
real double put, we should fix it. If it's only "probable," that
means we don't understand the problem yet.
On Tue, Sep 07, 2021 at 08:59:46AM +, Xu Wang wrote:
>
On Mon, Aug 23, 2021 at 12:53:39PM +0200, Niklas Schnelle wrote:
> On Fri, 2021-08-20 at 17:37 -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> > > The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> >
On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> includes
On Sat, Aug 07, 2021 at 11:26:45AM +0200, Uwe Kleine-König wrote:
> On Fri, Aug 06, 2021 at 04:24:52PM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> > > On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> >
On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> > I looked at all the bus_type.probe() methods, it looks like pci_dev is
> > not the only offender here. At least the following also have a dri
On Tue, Aug 03, 2021 at 12:01:44PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> changes since v1
> (https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
>
> - New patch to simplify drivers/pci/xen-pcifront.c, spotted and
> suggested by Boris Ostrovsky
> -
On Fri, Feb 05, 2021 at 11:17:32PM +0800, Kai-Heng Feng wrote:
> On Fri, Feb 5, 2021 at 7:28 AM Bjorn Helgaas wrote:
> >
> > [+cc Alex]
> >
> > On Thu, Jan 28, 2021 at 12:09:37PM +0800, Kai-Heng Feng wrote:
> > > On Thu, Jan 28, 2021 at 4:51 AM Bjorn Helgaas
Please make the subject a little more specific. "rearrange the
general sequence" doesn't say anything about what was affected.
On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng wrote:
> Reset_link() callback function was called before mmio_enabled() in
> pcie_do_recovery() function
ources are stored in pci_dn to avoid
> kmalloc/free.
>
> Cc: linux-...@vger.kernel.org
> Cc: Benjamin Herrenschmidt
> Cc: Bjorn Helgaas
> Signed-off-by: Alexey Kardashevskiy
> ---
>
> I assume this goes to powerpc next branch but before this I'd like to
> ge
On Thu, Apr 15, 2021 at 01:59:52PM -0500, Rob Herring wrote:
> On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras wrote:
> >
> > Many other resource flag parsers already add this flag when the input
> > has bits 24 & 25 set, so update this one to do the same.
[Adding this to the thread for
On Mon, May 31, 2021 at 04:12:15PM +0800, Wesley Sheng wrote:
> Replace "It" with "If", since it is a conditional statement.
>
> Signed-off-by: Wesley Sheng
Applied to pci/error for v5.14 with Krzysztof's reviewed-by and
subject "Documentation: PCI: Fix typo in pci-error-recovery.rst" to
match
On Mon, Mar 29, 2021 at 04:47:59PM +0800, Kai-Heng Feng wrote:
> Built-in grahpics on HP EliteDesk 805 G6 doesn't work because graphics
> can't get the BAR it needs:
> [0.611504] pci_bus :00: root bus resource [mem
> 0x1002020-0x100303f window]
> [0.611505] pci_bus :00:
[+cc Alex]
On Thu, Jan 28, 2021 at 12:09:37PM +0800, Kai-Heng Feng wrote:
> On Thu, Jan 28, 2021 at 4:51 AM Bjorn Helgaas wrote:
> > On Thu, Jan 28, 2021 at 01:31:00AM +0800, Kai-Heng Feng wrote:
> > > Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
&
On Thu, Jan 28, 2021 at 01:31:00AM +0800, Kai-Heng Feng wrote:
> Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
> hint") enables ACS, and some platforms lose its NVMe after resume from
> firmware:
> [ 50.947816] pcieport :00:1b.0: DPC: containment event, status:0x1f01
On Wed, Dec 16, 2020 at 09:19:44PM +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
Looks like a good fix, but read this about the changelog title:
https://lore.kernel.org/r/20171026223701.ga25...@bhelgaas-glaptop.roam.corp.google.com
> Signed-off-by:
On Wed, Dec 09, 2020 at 10:29:04PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 04:40:52PM +0100, Michael Walle wrote:
> > Hopefully my mail client won't mess up the output that much.
>
> I can reproduce on my LS1028A as well. The following fixes the bug for
> me. I did not follow the
On Wed, Dec 09, 2020 at 11:43:59PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 03:34:49PM -0600, Bjorn Helgaas wrote:
> > On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> > > On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > &g
On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > Yep, that's the theory. Thanks for testing it!
>
> Testing what? I'm not following.
You posted a patch that you said fixed the bug for you. The
On Wed, Dec 09, 2020 at 10:29:04PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 04:40:52PM +0100, Michael Walle wrote:
> > Hopefully my mail client won't mess up the output that much.
>
> I can reproduce on my LS1028A as well. The following fixes the bug for
> me. I did not follow the
On Wed, Dec 09, 2020 at 02:08:00PM +0100, Michael Walle wrote:
> [+ Vladimir and Alex]
>
> Am 2020-12-09 13:36, schrieb Bjorn Helgaas:
> > On Tue, Dec 08, 2020 at 04:41:50PM +0100, Michael Walle wrote:
> > > >On Sun, 29 Nov 2020 23:07:38 +, Krzysztof Wilczyński
On Tue, Dec 08, 2020 at 04:41:50PM +0100, Michael Walle wrote:
> >On Sun, 29 Nov 2020 23:07:38 +, Krzysztof Wilczyński wrote:
> >> Unify ECAM-related constants into a single set of standard constants
> >> defining memory address shift values for the byte-level address that can
> >> be used
[+cc Qian]
On Tue, Dec 08, 2020 at 04:41:50PM +0100, Michael Walle wrote:
> Hi Lorenzo, Krzysztof,
>
> >On Sun, 29 Nov 2020 23:07:38 +, Krzysztof Wilczyński wrote:
> >> Unify ECAM-related constants into a single set of standard constants
> >> defining memory address shift values for the
On Mon, Nov 30, 2020 at 09:06:56AM +, David Laight wrote:
> From: Krzysztof Wilczynski
> > Sent: 29 November 2020 23:08
> >
> > Use "void __iomem" instead "char __iomem" pointer type when working with
> > the accessor functions (with names like readb() or writel(), etc.) to
> > better match a
g", p. 677).
>
> There is no change to functionality.
>
> Suggested-by: Bjorn Helgaas
> Signed-off-by: Krzysztof Wilczyński
Beautiful. This should probably go via Lorenzo's tree, so he may have
comments, too. Could apply this as-is; I had a few trivial notes
below.
It's ir
g", p. 677).
>
> There is no change to functionality.
>
> Suggested-by: Bjorn Helgaas
> Signed-off-by: Krzysztof Wilczyński
I think this is a nice cleanup. PCIE_ECAM_DEV_SHIFT is unused, so I'd
probably remove it and maybe rename PCIE_ECAM_FUN_SHIFT to
PCIE_ECAM_DEVFN_SHIF
On Thu, Sep 24, 2020 at 04:41:39PM +1000, Oliver O'Halloran wrote:
> On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar
> wrote:
> >
> > This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
> > (descriptions taken from Kconfig file)
> >
> > Signed-off-by: Mamatha Inamdar
> > ---
s/MSIX/MSI-X/ (subject and below)
On Sat, Mar 14, 2020 at 11:30:31AM +0800, Xiaowei Bao wrote:
> Each PF of EP device should have it's own MSI or MSIX capabitily
> struct, so create a dw_pcie_ep_func struct and remove the msi_cap
> and msix_cap to this struct from dw_pcie_ep, and manage the PFs
>
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, Jul 21, 2020 at 11:17:35PM +0800, Wei Yongjun wrote:
> The sparse tool report build warnings as follows:
>
> drivers/pci/hotplug/rpadlpar_core.c:355:5: warning:
> symbol 'dlpar_remove_pci_slot' was not declared. Should it be static?
> drivers/pci/hotplug/rpadlpar_core.c:461:12: warning:
On Wed, Jul 15, 2020 at 02:38:29PM +, David Laight wrote:
> From: Oliver O'Halloran
> > Sent: 15 July 2020 05:19
> >
> > On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote:
> ...
> > > - config space accesses are very rare compared to memory
> > > space access and on the hardware side the
On Wed, Jul 15, 2020 at 02:24:21PM +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 15 July 2020 07:47
> > On Wed, Jul 15, 2020 at 1:46 AM Bjorn Helgaas wrote:
> >
> > So something like:
> > >
> > > void pci_read_config_
[+cc Kjetil]
On Wed, Jul 15, 2020 at 12:01:56AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 14, 2020 at 8:45 PM Bjorn Helgaas wrote:
> > On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote:
> > > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
> > >
[trimmed the cc list; it's still too large but maybe arch folks care]
On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote:
> On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
> wrote:
> > This goal of these series is to move the definition of *all*
> > PCIBIOS* from
On Mon, Jul 13, 2020 at 02:22:12PM +0200, Saheed O. Bolarinwa wrote:
> This goal of these series is to move the definition of *all* PCIBIOS* from
> include/linux/pci.h to arch/x86 and limit their use within there.
> All other tree specific definition will be left for intact. Maybe they can
> be
On Tue, Jul 07, 2020 at 07:14:01PM -0500, Bjorn Helgaas wrote:
> From: Matt Jolly
>
> PCIe correctable errors are recovered by hardware with no need for software
> intervention (PCIe r5.0, sec 6.2.2.1).
>
> Reduce the log level of correctable errors from KERN_ERR to KERN_WAR
-Kangie@footclan.ninja
Signed-off-by: Matt Jolly
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pcie/aer.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 9176c8a968b9..ca886bf91fd9 100644
--- a/drivers
From: Bjorn Helgaas
aer_correctable_error_string[] and aer_uncorrectable_error_string[] have
descriptions of AER error status bits. Add NULL entries to these tables so
all entries for bits 0-31 are defined. Then we don't have to check for
ARRAY_SIZE() when decoding a status word, which
On Fri, Jun 19, 2020 at 01:55:11AM +1000, Matt Jolly wrote:
> The AER documentation indicates that correctable (severity=Corrected)
> errors should be output as a warning so that users can filter these
> errors if they choose to; This functionality does not appear to have been
> implemented.
>
>
rd
pcie_capability_clear_and_set_word
pcie_capability_clear_and_set_dword
that check the return code for anything other than zero.
[bhelgaas: commit log, squash together]
Suggested-by: Bjorn Helgaas
Link:
https://lore.kernel.org/r/20200615073225.24061-1-refactormy
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 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 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 Mon, Apr 27, 2020 at 04:11:07PM +, Derrick, Jonathan wrote:
> On Fri, 2020-04-24 at 18:30 -0500, Bjorn Helgaas wrote:
> > I'm glad you raised this because I think the way we handle
> > FIRMWARE_FIRST is really screwed up.
> >
> > On Mon, Apr 20, 2020 at 03:37:09
MIPS and powerpc folks to CC: just as FYI because you're the
biggest users of PCIBIOS_*. The intent is that this would be zero
functional change.
]
On Sun, Apr 26, 2020 at 11:51:30AM +0200, Saheed Bolarinwa wrote:
> On 4/25/20 12:30 AM, Bjorn Helgaas wrote:
> > On Fri, Apr 24, 2020 at 0
Hi Jon,
I'm glad you raised this because I think the way we handle
FIRMWARE_FIRST is really screwed up.
On Mon, Apr 20, 2020 at 03:37:09PM -0600, Jon Derrick wrote:
> Some platforms have a mix of ports whose capabilities can be negotiated
> by _OSC, and some ports which are not described by ACPI
On Thu, Apr 16, 2020 at 04:51:14PM -0500, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
&
d-off-by: Sebastian Andrzej Siewior
> Acked-by: Peter Zijlstra (Intel)
> Cc: Kurt Schwemmer
> Cc: Logan Gunthorpe
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
But please tweak the subject so it matches the other:
- pci/switchtec: Replace completion
ff-by: Thomas Gleixner
> Link: https://lkml.kernel.org/r/20200313183608.2646-1-log...@deltatee.com
Acked-by: Bjorn Helgaas
Not because I understand and have reviewed this, but because I trust
you to do the right thing and it belongs with the rest of the series.
> ---
> drivers/pci/sw
On Thu, Mar 12, 2020 at 09:38:02AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 12, 2020 at 10:04:12PM +0800, Chen Zhou wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/pci/hotplug/rpaphp_core.c: In function is_php_type:
> > drivers/pci/hotplug/rp
ut-set-variable]
>
> Reported-by: Hulk Robot
> Signed-off-by: Chen Zhou
Michael, if you want this:
Acked-by: Bjorn Helgaas
If you don't mind, edit the subject to follow the convention, e.g.,
PCI: rpaphp: Remove unused variable 'value'
Apparently simple_strtoul() is deprecated a
On Fri, Nov 15, 2019 at 12:34:50AM +1100, Oliver O'Halloran wrote:
> On Thu, Nov 14, 2019 at 1:31 AM Bjorn Helgaas wrote:
> >
> > This is fine, but it feels like sort of a blunt instrument. Is there
> > any practical way to clear pci_host_bridge.native_pcie_hotplu
On Wed, Nov 13, 2019 at 08:40:35PM +1100, Oliver O'Halloran wrote:
> On PowerNV the PCIe topology is (currently) managed the powernv platform
> code in cooperation with firmware. The PCIe-native service drivers bypass
> both and this can cause problems.
>
> Historically this hasn't been a big
| 2 +-
> arch/powerpc/platforms/pseries/hotplug-cpu.c| 127
> +---
> arch/powerpc/platforms/pseries/of_helpers.c | 8 +-
> arch/powerpc/platforms/pseries/pseries_energy.c | 23 ++---
> drivers/pci/hotplug/rpaphp_core.c | 127
> +
On Fri, Oct 25, 2019 at 08:10:36AM +0200, Michal Simek wrote:
> Hi,
>
> these two patches come from discussion with Christoph, Bjorn, Palmer and
> Waiman. The first patch was suggestion by Christoph here
> https://lore.kernel.org/linux-riscv/20191008154604.ga7...@infradead.org/
> The second part
On Fri, Oct 25, 2019 at 04:33:13PM +0200, Carlo Pisani wrote:
> pci_bus :00: root bus resource [mem 0x5000-0x5fff]
> pci_bus :00: root bus resource [io 0x1880-0x188f]
> pci_bus :00: root bus resource [??? 0x flags 0x0]
> pci_bus :00: No busn resource found
On Wed, Oct 16, 2019 at 06:50:30PM +0300, Sergey Miroshnichenko wrote:
> On 10/16/19 1:14 AM, Bjorn Helgaas wrote:
> > On Mon, Sep 30, 2019 at 03:59:25PM +0300, Sergey Miroshnichenko wrote:
> > > On 9/28/19 1:02 AM, Bjorn Helgaas wrote:
> > > > It's possib
On Mon, Sep 30, 2019 at 03:59:25PM +0300, Sergey Miroshnichenko wrote:
> Hello Bjorn,
>
> On 9/28/19 1:02 AM, Bjorn Helgaas wrote:
> > On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote:
> > > When hot-adding a device, the bridge may hav
On Tue, Oct 01, 2019 at 01:12:05AM -0500, Tyrel Datwyler wrote:
> There was an initial previous effort yo add support for the PAPR
> architected ibm,drc-info property. This property provides a more
> memory compact representation of a paritions Dynamic Reconfig
> Connectors (DRC). These can
On Mon, Sep 30, 2019 at 12:08:46PM +1000, Oliver O'Halloran wrote:
This is all powerpc, so I assume Michael will handle this. Just
random things I noticed; ignore if they don't make sense:
> On PowerNV we use the pcibios_sriov_enable() hook to do two things:
>
> 1. Create a pci_dn structure
On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote:
> When hot-adding a device, the bridge may have windows not big enough (or
> fragmented too much) for newly requested BARs to fit in. And expanding
> these bridge windows may be impossible because blocked by "neighboring"
>
On Fri, Aug 16, 2019 at 07:50:40PM +0300, Sergey Miroshnichenko wrote:
> The PCI_COMMAND_IO and PCI_COMMAND_MEMORY bits of the bridge must be
> updated not only when enabling the bridge for the first time, but also if a
> hotplugged device requests these types of resources.
Yeah, this assumption
On Fri, Aug 16, 2019 at 07:50:39PM +0300, Sergey Miroshnichenko wrote:
> This is a yet another approach to fix an old [1-2] concurrency issue, when:
> - two or more devices are being hot-added into a bridge which was
>initially empty;
> - a bridge with two or more devices is being hot-added;
On Tue, Aug 27, 2019 at 06:18:22PM +0300, Andy Shevchenko wrote:
> This simplifies and standardizes slot manipulation code
> by using for_each_set_bit() library function.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/pci/pcie/aer.c | 19 ---
> 1 file changed, 8
On Tue, Aug 27, 2019 at 06:18:22PM +0300, Andy Shevchenko wrote:
> This simplifies and standardizes slot manipulation code
> by using for_each_set_bit() library function.
>
> Signed-off-by: Andy Shevchenko
Applied both with Kuppuswamy's reviewed-by to pci/aer for v5.5,
thanks!
> ---
>
On Mon, Aug 26, 2019 at 11:51:43AM +0200, Krzysztof Wilczynski wrote:
> Remove unnecessary empty return statement at the end of a void
> function in the following:
>
> - drivers/pci/hotplug/cpci_hotplug_core.c: cleanup_slots()
> - drivers/pci/hotplug/cpqphp_core.c: pci_print_IRQ_route()
> -
On Mon, Jul 22, 2019 at 02:05:12PM +1000, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > On Mon, Jun 03, 2019 at 03:11:58PM -0700, Nathan Chancellor wrote:
> >> When building with -Wsometimes-uninitialized, clang warns:
> >>
> >> drivers/pci/hotplug/rpaphp_core.c:243:14: warning:
On Mon, Jul 29, 2019 at 01:13:56PM +0300, Denis Efremov wrote:
> Architectures currently define HAVE_ARCH_PCI_RESOURCE_TO_USER if they want
> to provide their own pci_resource_to_user() implementation. This could be
> simplified if we make the generic version a weak function. Thus,
> architecture
If you post another revision for any reason, please change the subject
so it's worded as a command and mentions the new config options, e.g.,
PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
On Wed, Jun 26, 2019 at 07:11:39PM +0800, Xiaowei Bao wrote:
> Compile the EP
On Fri, Jun 14, 2019 at 02:36:35PM -0600, Jonathan Corbet wrote:
> On Wed, 12 Jun 2019 14:52:55 -0300
> Mauro Carvalho Chehab wrote:
>
> > Convert docs to ReST and add them to the arch-specific
> > book.
> >
> > The conversion here was trivial, as almost every file there
> > was already using
On Mon, May 27, 2019 at 11:03:13PM -0500, Shawn Anastasio wrote:
> On pseries, custom PCI resource alignment specified with the commandline
> argument pci=resource_alignment is disabled due to PCI resources being
> managed by the firmware. However, in the case of PCI hotplug the
> resources are
On Tue, May 28, 2019 at 03:36:34PM +1000, Oliver wrote:
> On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
> >
> > Introduce a new pcibios function pcibios_ignore_alignment_request
> > which allows the PCI core to defer to platform-specific code to
> > determine whether or not to ignore
On Tue, Apr 23, 2019 at 06:39:47PM +0200, Rafael J. Wysocki wrote:
> On Tue, Apr 23, 2019 at 6:30 PM Changbin Du wrote:
> > Hi Corbet and All,
> > The kernel now uses Sphinx to generate intelligent and beautiful
> > documentation from reStructuredText files. I converted all of the Linux
> >
On Fri, Mar 22, 2019 at 01:27:21PM -0500, Tyrel Datwyler wrote:
> The find_dlpar_node() helper returns a device node with its reference
> incremented. Both the add and remove paths use this helper for find the
> appropriate node, but fail to release the reference when done.
>
> Annotate the
Hi Sergey,
Since this doesn't touch drivers/pci, I assume powerpc folks will
handle this series. Let me know if otherwise.
On Mon, Mar 11, 2019 at 02:52:25PM +0300, Sergey Miroshnichenko wrote:
> This patchset allows switching from the pnv_php module to the standard
> pciehp driver for PCIe
On Mon, Mar 11, 2019 at 04:31:21PM +0300, Sergey Miroshnichenko wrote:
> With movable BARs, adding a hotplugged device may affect all the PCIe
> domain starting from the root, so use a pci_rescan_bus() function which
> handles the rearrangement of existing BARs and bridge windows.
>
>
201 - 300 of 857 matches
Mail list logo
