[+cc Ben, linuxppc-dev, Grant, Rob, devicetree]
On Tue, Mar 31, 2015 at 07:57:48PM -0700, Yinghai Lu wrote:
> Found "no compatible bridge window" warning in boot log from T5-8.
>
> pci :00:01.0: can't claim BAR 15 [mem 0x1-0x4afff pref]: no
> compatible bridge window
>
> That re
[+cc Sam (commented on previous versions), Russell, linux-arm-kernel, Ralf,
linux-mips, Ben, linuxppc-dev, x86]
On Fri, Apr 03, 2015 at 02:32:34PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 31, 2015 at 07:57:47PM -0700, Yinghai Lu wrote:
> > David Ahern found commit d63e2e1f3df9 ("s
On Fri, Apr 3, 2015 at 10:34 PM, Yinghai Lu wrote:
> On Fri, Apr 3, 2015 at 1:52 PM, Bjorn Helgaas wrote:
>> [+cc Sam (commented on previous versions), Russell, linux-arm-kernel, Ralf,
>> linux-mips, Ben, linuxppc-dev, x86]
>>
>> On Fri, Apr 03, 2015 at 02:32:34PM
On Sat, Apr 4, 2015 at 2:48 PM, Rob Herring wrote:
> On Sat, Apr 4, 2015 at 7:46 AM, Bjorn Helgaas wrote:
>> I think there's still an unresolved question about the OF parsing code.
>
> Got a pointer to what that is? I'll take a guess. Generally, we make
> the par
Hi Gavin,
[Please run "git log --oneline drivers/pci/setup-bus.c" and observe the
capitalization convention.]
On Fri, May 01, 2015 at 04:02:48PM +1000, Gavin Shan wrote:
> Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(),
> which is called for once after PCI probing and resourc
On Wed, Apr 08, 2015 at 03:38:42PM -0700, Yinghai Lu wrote:
> On Wed, Apr 8, 2015 at 1:01 AM, Benjamin Herrenschmidt
> wrote:
>
> > Use a different flag to indicate the BAR policy or temporarily tweak a
> > local copy of the resource flag during BAR assignment or whatever you
> > prefer to fix th
[updated Rafael's email addr; not sure if sisk.pl still works or not]
On Wed, May 27, 2015 at 11:31:21AM -0700, Yinghai Lu wrote:
> On Fri, Jul 26, 2013 at 5:43 AM, Yinghai Lu wrote:
> > On Thu, Jul 25, 2013 at 10:57 AM, Bjorn Helgaas wrote:
> >> Convert pciehp to b
On Tue, May 19, 2015 at 06:50:05PM +0800, Wei Yang wrote:
> As commit ac205b7b ("PCI: make sriov work with hotplug remove") indicates,
The conventional reference is:
ac205b7bb72f ("PCI: make sriov work with hotplug remove")
> VFs, which might be hooked to same PCI bus as their PF should be rem
The subject says "Trace first 7 BARs..." I think maybe you meant "Track
first 7 BARs" or maybe "Cache only BARs, not windows or IOV BARs"
On Tue, May 19, 2015 at 06:50:06PM +0800, Wei Yang wrote:
> EEH address cache, which helps to locate the PCI device according to
> the given (physical) MMIO ad
On Tue, May 19, 2015 at 06:50:08PM +0800, Wei Yang wrote:
> Current EEH recovery code works with the assumption: the PE has primary
> bus. Unfortunately, that's not true to VF PEs, which generally contains
> one or multiple VFs (for VF group case). The patch creates PEs for VFs
> at PCI final fixup
On Tue, May 19, 2015 at 06:50:08PM +0800, Wei Yang wrote:
> Current EEH recovery code works with the assumption: the PE has primary
> bus. Unfortunately, that's not true to VF PEs, which generally contains
"Primary bus" normally means the bus on the upstream side of a PCI bridge.
But a PE is not a
On Tue, May 19, 2015 at 06:50:10PM +0800, Wei Yang wrote:
> After PE reset, OPAL API opal_pci_reinit() is called on all devices
> contained in the PE to reinitialize them. However, VFs can't be seen
> from skiboot firmware. We have to implement the functions, similar
> those in skiboot firmware, to
.
>
> The patch renames virtn_{add,remove}() and exports them so that they
> can be used in PCI hotplug during EEH recovery.
>
> [gwshan: changelog]
> Signed-off-by: Wei Yang
> Reviewed-by: Gavin Shan
Acked-by: Bjorn Helgaas
I assume you'll merge this along
On Wed, Jun 03, 2015 at 03:10:23PM +1000, Gavin Shan wrote:
> On Wed, Jun 03, 2015 at 11:31:42AM +0800, Wei Yang wrote:
> >On Mon, Jun 01, 2015 at 06:46:45PM -0500, Bjorn Helgaas wrote:
> >>On Tue, May 19, 2015 at 06:50:08PM +0800, Wei Yang wrote:
> >>> Current EE
We already include from , so just include
directly.
Signed-off-by: Bjorn Helgaas
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-s...@vger.kernel.org
---
arch/powerpc/platforms/52xx/mpc52xx_pci.c |2 +-
arch/s390/kernel/suspend.c|2 +-
2 files changed, 2 insertions(+), 2
In include/linux/pci.h, we already #include , so we don't need
to include directly.
Remove the unnecessary includes. All the files here already include
.
Signed-off-by: Bjorn Helgaas
CC: linux-al...@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: linuxppc-dev@lists.ozlabs.org
CC:
On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
> Hello,
>
> This is a cleanup effort to get rid of useless arch_msi_check_device().
> I am not sure what were the reasons for its existence in the first place,
> but at the moment it appears totally unnecessary.
>
> Thanks!
>
>
On Fri, Sep 5, 2014 at 3:25 PM, Bjorn Helgaas wrote:
> On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
>> Hello,
>>
>> This is a cleanup effort to get rid of useless arch_msi_check_device().
>> I am not sure what were the reasons for its existence in
tum, setting the SR-IOV page size causes the physical function BARs
to expand to the system page size. Since ppc64 uses 64k pages, when Linux
tries to assign the smaller resource sizes to the now 64k BARs the address
will be truncated and the BARs will overlap.
Force Linux to a
On Wed, Aug 20, 2014 at 12:14 AM, Wei Yang wrote:
> On Tue, Aug 19, 2014 at 09:08:41PM -0600, Bjorn Helgaas wrote:
>>On Thu, Jul 24, 2014 at 02:22:14PM +0800, Wei Yang wrote:
>>> At resource sizing/assigning stage, resources are divided into two lists,
>>> request
only
used to call arch_msi_check_device() and is no longer needed.
[bhelgaas: changelog, split to separate patch]
Signed-off-by: Alexander Gordeev
Signed-off-by: Bjorn Helgaas
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index aff384aea639..a0b623d97ad8 100644
--- a/dri
On Sun, Sep 07, 2014 at 08:57:52PM +0200, Alexander Gordeev wrote:
> Hello,
>
> This is a cleanup effort to get rid of arch_msi_check_device() function.
>
> I am sending v2 series, since kbuild for v1 reports compile errors on
> ppc4xx and Armada 370. Still, I have not checked the fixes on these
On Fri, Sep 05, 2014 at 06:09:45PM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci-next branch + Alexander Gordeev's two patches
> "Remove arch_msi_check_device()" link: https://lkml.org/lkml/2014/7/12/41
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Red
On Wed, Oct 01, 2014 at 12:09:23PM +1000, Benjamin Herrenschmidt wrote:
>
> Some devices have broken 64-bit MSI support which only support some
> address bits (40 to 48 typically). This doesn't work on some platforms
> such as POWER servers, so we need a quirk.
>
> Currently we keep a flag in a p
On Thu, Oct 02, 2014 at 10:34:12AM +1000, Benjamin Herrenschmidt wrote:
>
> Some devices have broken 64-bit MSI support which only support some
> address bits (40 to 48 typically). This doesn't work on some platforms
> such as POWER servers, so we need a quirk.
>
> Currently we keep a flag in a p
On Thu, Oct 02, 2014 at 10:34:22AM +1000, Benjamin Herrenschmidt wrote:
>
> A number of radeon cards have a HW limitation causing them to be
> unable to generate the full 64-bit of address bits for MSIs. This
> breaks MSIs on some platforms such as POWER machines.
>
> We used to have a powerpc sp
On Wed, Aug 20, 2014 at 11:35:46AM +0800, Wei Yang wrote:
> On Tue, Aug 19, 2014 at 10:12:27PM -0500, Bjorn Helgaas wrote:
> >On Tue, Aug 19, 2014 at 9:34 PM, Wei Yang wrote:
> >> On Tue, Aug 19, 2014 at 03:19:42PM -0600, Bjorn Helgaas wrote:
> >>>On Thu, Jul 24,
On Thu, Oct 2, 2014 at 3:02 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2014-10-02 at 09:34 -0600, Bjorn Helgaas wrote:
>> On Thu, Oct 02, 2014 at 10:34:22AM +1000, Benjamin Herrenschmidt wrote:
>> >
>> > A number of radeon cards have a HW limitation causing them to be
On Thu, Oct 2, 2014 at 3:01 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2014-10-02 at 09:31 -0600, Bjorn Helgaas wrote:
>
>> > So this moves the flag to struct pci_dev instead and adjusts the
>> > corresponding arch/powerpc code to look for it there. At this point,
>
On Mon, Oct 13, 2014 at 2:11 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2014-10-08 at 16:28 +1100, Benjamin Herrenschmidt wrote:
>
>> > Further discussion with the hw teams have revealed that this is still
>> > an issue on newer asics so I think your original patch is correct
>> > after all. Jus
On Wed, Oct 15, 2014 at 3:00 AM, Wei Yang wrote:
> On Thu, Oct 02, 2014 at 09:59:43AM -0600, Bjorn Helgaas wrote:
...
>>I haven't seen any more on this series, and I'm assuming you'll post a
>>rebased series (maybe you're waiting for v3.18-rc1?). I'm
ies, I can just pickup my previous
> patch. Takashi, Bjorn, Dave, this series covers your 3 areas of
> maintainership, how do you want to proceed ? I'm happy to merge the
> whole lot via powerpc ASAP (since it's all CC'ed stable) if you guys
> send me the appropriate ac
[+cc Victor, Oleg, David, Srikar, Ananth, Russell, linux-arm-kernel,
Ben, Paul, Michael, linuxppc-dev. arm and powerpc define some of
these functions and are at risk for this issue.]
On Wed, Oct 15, 2014 at 11:06 AM, Bjorn Helgaas wrote:
> For the following interfaces:
>
>
On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
This needs slightly more detail. You're using the MSI chip framework
"instead of arch MSI functi
On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> introduced two __weak arch functions arch_msix_mask_irq() and
> arch_msi_mask_irq() to work around a bug when running xen in x86.
> These two functions made m
On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
> Save msi chip in pci_sys_data instead of assign
> msi chip to every pci bus in .add_bus().
>
> Signed-off-by: Yijing Wang
> ---
> drivers/pci/host/pci-tegra.c | 13 +++--
> 1 files changed, 3 insertions(+), 10 deletions(-)
On Wed, Oct 15, 2014 at 11:06:52AM +0800, Yijing Wang wrote:
> Saving msi chip in pci_sys_data can make pci bus and
> devices don't need to know msi chip detail, it also
> make pci enumeration code be decoupled from msi chip.
> In fact, all pci devices under the same pci hostbridge
> share same msi
On Wed, Oct 15, 2014 at 11:06:57AM +0800, Yijing Wang wrote:
> MSI chip will be saved in pci_sys_data, now we can
> clean up pcibios_add_bus() and pcibios_remove_bus()
> in arm, and use pci_find_msi_chip() to get msi chip
> in core MSI code.
>
> Signed-off-by: Yijing Wang
> ---
> arch/arm/includ
On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote:
> Now msi chip is saved in pci_sys_data in arm,
> we could clean the bus->msi assignment in
> pci core.
>
> Signed-off-by: Yijing Wang
> CC: Thierry Reding
> CC: Thomas Petazzoni
> ---
> drivers/pci/probe.c |1 -
> 1 files change
On Wed, Oct 15, 2014 at 11:06:48AM +0800, Yijing Wang wrote:
> Now there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm,
> that's a better solution than overriding lots of existing weak arch
> functionsin.
> This series u
On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2014-10-15 at 16:19 -0600, Bjorn Helgaas wrote:
> > PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
> >
> > I'd be happy to merge it, but given what I know now, I wou
On Tue, Nov 11, 2014 at 9:06 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2014-11-12 at 13:23 +1100, Michael Ellerman wrote:
>> On Tue, 2014-11-11 at 14:12 -0700, Bjorn Helgaas wrote:
>> > On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote:
>> > &g
On Tue, Nov 18, 2014 at 4:11 PM, Gavin Shan wrote:
> On Sun, Nov 02, 2014 at 11:41:16PM +0800, Wei Yang wrote:
>
> Hello Bjorn,
>
> Did you have available bandwidth to review it? :-)
I'm working on it right now :)
>>This patchset enables the SRIOV on POWER8.
>>
>>The gerneral idea is put each VF
[+cc Don, Myron]
Hi Wei,
On Sun, Nov 02, 2014 at 11:41:19PM +0800, Wei Yang wrote:
> When retrieving VF IOV BAR in virtfn_add(), it will divide the total PF's IOV
> BAR size with the totalVF number. This is true for most cases, while may not
> be correct on some specific platform.
>
> For exampl
On Wed, Nov 19, 2014 at 11:21:00AM +0800, Wei Yang wrote:
> On Wed, Nov 19, 2014 at 01:15:32PM +1100, Benjamin Herrenschmidt wrote:
> >On Tue, 2014-11-18 at 18:12 -0700, Bjorn Helgaas wrote:
> >>
> >> Can you help me understand this?
> >>
> >> We
On Wed, Nov 19, 2014 at 05:27:40PM +0800, Wei Yang wrote:
> On Tue, Nov 18, 2014 at 09:26:01PM -0700, Bjorn Helgaas wrote:
> >On Wed, Nov 19, 2014 at 11:21:00AM +0800, Wei Yang wrote:
> >> On Wed, Nov 19, 2014 at 01:15:32PM +1100, Benjamin Herrenschmidt wrote:
> >> &
On Sun, Nov 02, 2014 at 11:41:24PM +0800, Wei Yang wrote:
> From: Gavin Shan
>
> pci_dn is the extension of PCI device node and it's created from
> device node. Unfortunately, VFs that are enabled dynamically by
> PF's driver and they don't have corresponding device nodes, and
> pci_dn. The patch
On Sun, Nov 02, 2014 at 11:41:17PM +0800, Wei Yang wrote:
> When implementing the SR-IOV on PowerNV platform, some resource reservation is
> needed for VFs which don't exist at the bootup stage. To do the match between
> resources and VFs, the code need to get the VF's BDF in advance.
>
> In this
On Thu, Nov 20, 2014 at 03:20:57PM +0800, Wei Yang wrote:
> On Wed, Nov 19, 2014 at 04:30:24PM -0700, Bjorn Helgaas wrote:
> >On Sun, Nov 02, 2014 at 11:41:24PM +0800, Wei Yang wrote:
> >> From: Gavin Shan
> >>
> >> pci_dn is the extension of PCI device no
On Thu, Dec 04, 2014 at 04:54:46PM +1100, Gavin Shan wrote:
> We might not get some PCI slot information (e.g. power status)
> immediately by OPAL API. Instead, opal_pci_poll() need to be called
> for the required information.
>
> The patch introduces pnv_pci_poll(), which bases on original
> ioda
On Sun, May 5, 2013 at 11:50 PM, Benjamin Herrenschmidt
wrote:
> The PCI core supports an offset per aperture nowadays but our arch
> code still has a single offset per host bridge representing the
> difference betwen CPU memory addresses and PCI MMIO addresses.
>
> This is a problem as new machin
Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think
we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the
generic version of this code, pci_setup_device(), uses PCI_UNKNOWN.
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/kernel/pci_of_scan.c |
Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think
we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the
generic version of this code, pci_setup_device(), uses PCI_UNKNOWN.
Signed-off-by: Bjorn Helgaas
---
arch/sparc/kernel/pci.c |2 +-
1 f
On Mon, May 20, 2013 at 5:19 PM, Bjorn Helgaas wrote:
> Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think
> we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the
> generic version of this code, pci_setup_device(), uses PCI_UNKNOWN.
>
On Mon, May 20, 2013 at 5:42 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2013-05-20 at 17:19 -0600, Bjorn Helgaas wrote:
>> Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think
>> we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the
On Mon, Jul 1, 2013 at 11:30 PM, Thomas Petazzoni
wrote:
> Dear Michael Ellerman,
>
> On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
>> On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
>> > Until now, the MSI architecture-specific functions could be overloaded
>> > using a f
section mismatch warning.
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/platforms/powernv/pci-ioda.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 9c9d15e..dfbb03d 100644
--- a
e during the time. The patch introduces
> hook pcibios_stop_dev() for the purpose.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Gavin Shan
> ---
> drivers/pci/probe.c |4
> drivers/pci/remove.c |2 ++
> include/linux/pci.h |1 +
On Thu, Jul 4, 2013 at 8:57 PM, Gavin Shan wrote:
> Since pci_stop_and_remove_bus_device() has removed the EEH cache,
> we needn't do that again.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Gavin Shan
Acked-by: Bjorn Helgaas
Please merge this
t; Cc: linux-m...@linux-mips.org
> Cc: David S. Miller
> Cc: sparcli...@vger.kernel.org
> Cc: Chris Metcalf
Acked-by: Bjorn Helgaas
> ---
> arch/mips/include/asm/pci.h| 5 -
> arch/powerpc/include/asm/pci.h | 5 -
> arch/s390/include/asm/pc
On Fri, Jul 5, 2013 at 3:32 PM, Bjorn Helgaas wrote:
> Acked-by: Bjorn Helgaas
But please update your subject line to use consistent capitalization, e.g.,
PCI: Use weak ...
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
ht
Baechle
> Cc: linux-m...@linux-mips.org
> Cc: David S. Miller
> Cc: sparcli...@vger.kernel.org
> Cc: Chris Metcalf
Acked-by: Bjorn Helgaas
Again, please update the subject line to "PCI: Remove ..."
I doubt that you'll get explicit acks from all the arches you touched
On Fri, Jul 5, 2013 at 4:36 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2013-07-05 at 12:49 -0600, Bjorn Helgaas wrote:
>> We already have pcibios_release_device() (just merged for v3.11).
>> Would that work for you? I haven't seen your whole series, so I can't
>>
On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper wrote:
> On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
>> Dear Bjorn Helgaas,
>>
>> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
>>
>> > Acked-by: Bjorn Helgaas
>> >
>&
On Mon, Jul 22, 2013 at 12:52 AM, Chen Gang wrote:
> pnv_pci_init_ioda2_phb() is only used during boot up, so need add
> '__init' to save the related memory, and avoid related warning:
>
> The function .pnv_pci_init_ioda2_phb() references
> the function __init .pnv_pci_init_ioda_phb().
> Thi
[+cc linux-pci]
On Tue, Jul 23, 2013 at 8:24 PM, Gavin Shan wrote:
> Since pcibios_release_device() called by pci_stop_and_remove_bus_device()
> has removed the EEH cache, we needn't do that again.
>
> Cc: Bjorn Helgaas
> Acked-by: Bjorn Helgaas
> Signed-off-by: Gavin
FIG_HOTPLUG_PCI=m and
CONFIG_HOTPLUG_PCI_PCIE=y combination was accepted by Kconfig and builds a
kernel, but pciehp doesn't actually work in that case (pointed out by
Yinghai, thanks!)
These are intended for v3.11.
---
Bjorn Helgaas (2):
PCI: hotplug: Convert to be builtin only, n
Convert CONFIG_HOTPLUG_PCI from tristate to bool. This only affects
the hotplug core; several of the hotplug drivers can still be modules.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/configs/generic_defconfig|2 +-
arch/ia64/configs/gensparse_defconfig |2 +-
arch/ia64/configs
Convert pciehp to be builtin only, with no module option.
Signed-off-by: Bjorn Helgaas
Acked-by: Rafael J. Wysocki
---
drivers/pci/pcie/Kconfig |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 569f82f..3b94cfc
t; Cc: linux-m...@linux-mips.org
> Cc: David S. Miller
> Cc: sparcli...@vger.kernel.org
> Cc: Chris Metcalf
Acked-by: Bjorn Helgaas
> ---
> arch/mips/include/asm/pci.h| 5 -
> arch/powerpc/include/asm/pci.h | 5 -
> arch/s390/include/asm/pc
nctions. For this reason, the ARCH_SUPPORTS_MSI
> hidden kconfig boolean becomes useless, and this patch gets rid of it.
>
> Signed-off-by: Thomas Petazzoni
Acked-by: Bjorn Helgaas
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc
[+cc linuxppc-dev]
On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich wrote:
> Hi all ,
> I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu)
> linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 .
> I took the source from freescale git:
> git://git.freescale.c
red resources to newly added PCI devices,
> in order to support PCI hotplug in subsequent patches.
>
> Signed-off-by: Gavin Shan
Acked-by: Bjorn Helgaas
> ---
> v5:
> * Corrected subject as Bjorn suggested
> * pci_setup_bridge() calls pcibios_setup_bridge() and __pc
"Move pcibios_find_pci_bus() from pSeries to generic powerpc code"?
On Thu, Jun 04, 2015 at 04:42:00PM +1000, Gavin Shan wrote:
> The patch moves pcibios_find_pci_bus() to PPC kerenl directory so
s/kerenl/kernel/
> that it can be reused by hotplug code for pSeries and PowerNV
> platform at the s
property "ibm,reset-by-firmware". In
> that case, none of valid PCI slots will be detected from device tree.
> The skiboot firmware doesn't export the capability to access attention
> LEDs yet and it's something for TBD.
>
> Signed-off-by: Gavin Shan
Acked-by
On Tue, Jun 16, 2015 at 3:50 AM, Wei Yang wrote:
> On Wed, Jun 03, 2015 at 10:46:38AM -0500, Bjorn Helgaas wrote:
>>On Wed, Jun 03, 2015 at 03:10:23PM +1000, Gavin Shan wrote:
>>> It's correct. "The following operations" refers to eeh_add_device_late()
>>&
These don't fix anything at all. But they might make code understanding
and debugging slightly easier.
---
Bjorn Helgaas (3):
x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
x86, irq: Clarify "No irq handler" message
IRQ: Print "unex
functional change.
Signed-off-by: Bjorn Helgaas
---
arch/x86/include/asm/hw_irq.h |4 ++--
arch/x86/kernel/apic/vector.c | 14 +++---
arch/x86/kernel/irq.c | 12 ++--
arch/x86/kernel/irqinit.c |4 ++--
4 files changed, 17 insertions(+), 17 deletions(-)
diff
No handler for IRQ -1 (CPU 0 vector 0xf2)
Signed-off-by: Bjorn Helgaas
---
arch/x86/kernel/irq.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 2949c6e..3c6b069 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x
ion, while Linux IRQ
numbers are usually printed in decimal.
Print the same text ("unexpected IRQ %d") across all architectures.
No functional change other than the output text.
Signed-off-by: Bjorn Helgaas
---
arch/alpha/kernel/irq.c|2 +-
arch/blackfin/kernel/irqchip.c
On Sun, Jul 12, 2015 at 10:23 PM, Michael Ellerman wrote:
> On Sun, 2015-12-07 at 22:02:11 UTC, Bjorn Helgaas wrote:
>> Many architectures use a variant of "unexpected IRQ trap at vector %x" to
>> log unexpected IRQs. This is confusing because (a) it prints the Linux I
On Thu, Jun 18, 2015 at 04:06:41PM +0800, Wei Yang wrote:
> Current EEH recovery code works with the assumption: the PE has primary
> bus. Unfortunately, that's not true for VF PEs, which generally contains
> one or multiple VFs (for VF group case).
>
> The patch introduces a weak function pcibios
On Fri, Jul 17, 2015 at 9:06 AM, Thomas Gleixner wrote:
> On Sun, 12 Jul 2015, Bjorn Helgaas wrote:
>
>> The per-cpu vector_irq[] table is indexed by CPU vector numbers, and each
>> entry contains an IRQ number.
>>
>> Rename the special values VECTOR_UNDEF
Hi Marc,
On Fri, Aug 14, 2015 at 03:41:07PM +0100, Marc Zyngier wrote:
> When find_and_init_phbs() looks for the probe-only property, it seems
> to trust the firmware to be correctly written, and assumes that there
> is a parameter to the property.
>
> It is conceivable that the firmware could no
On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware ex
On Fri, Aug 14, 2015 at 11:43 AM, Will Deacon wrote:
> On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
>> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
>> > When pci-host-generic looks for the probe-only property, it seems
>> > to t
On Tue, Aug 6, 2013 at 11:41 PM, Leon Ravich wrote:
> From comparison of pci printout from the two kernel ,
> beside the EDAC errors I noticed other strange differences:
>
> In 3.8.13 I got BAR 7 and BAR 8:
> [ 39.017749] pci :00:00.0: BAR 8: assigned [mem 0xc000-0xdfff]
> [ 39.024
his series, so you can take it through the POWERPC
tree. If you don't want to do that, let me know and I can take it.
If you want it:
Acked-by: Bjorn Helgaas
> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> index 55593ee..6ebbe54 100644
> --- a/arch/powerpc/ke
On Thu, Sep 19, 2013 at 12:59:17PM +0530, Bharat Bhushan wrote:
> This patch adds interface to get following information
> - Number of MSI regions (which is number of MSI banks for powerpc).
> - Get the region address range: Physical page which have the
> address/addresses used for generat
On Fri, Sep 20, 2013 at 07:27:36AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 10:24:59AM +0200, Alexander Gordeev wrote:
> > * Make pci_enable_msix() return 0/-errno
>
> My choice would be this one.
I agree; it sounds like you've identified several bugs related to the
current confusing int
On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777
wrote:
>> I don't know enough about VFIO to understand why these new interfaces are
>> needed. Is this the first VFIO IOMMU driver? I see vfio_iommu_spapr_tce.c
>> and
>> vfio_iommu_type1.c but I don't know if they're comparable to the Fre
[+cc Ben, Paul, linuxppc-dev]
On Mon, Sep 30, 2013 at 04:52:54PM +0800, Minghuan Lian wrote:
> The Freescale's Layerscape series processors will use ARM cores.
> The LS1's PCIe controllers is the same as T4240's. So it's better
> the PCIe controller driver can support PowerPC and ARM
> simultaneou
On Tue, Oct 8, 2013 at 4:46 PM, Scott Wood wrote:
> On Tue, 2013-10-08 at 13:13 -0600, Bjorn Helgaas wrote:
>> [+cc Ben, Paul, linuxppc-dev]
>>
>> On Mon, Sep 30, 2013 at 04:52:54PM +0800, Minghuan Lian wrote:
>> > The Freescale's Layerscape series processors
>> - u32 msiir_offset; /* Offset of MSIIR, relative to start of CCSR */
>> + dma_addr_t msiir; /* MSIIR Address in CCSR */
>
> Are you sure dma_addr_t is right here, versus phys_addr_t? It implies
> that it's the output of the DMA API, but I don't think the DMA API is
> used in the MSI dri
On Wed, Oct 9, 2013 at 4:14 AM, Lian Minghuan-b31939
wrote:
> arch/powerpc/sysdev/fsl_pci.c | 521 +-
> arch/powerpc/sysdev/fsl_pci.h | 89
> .../fsl_pci.c => drivers/pci/host/pci-fsl-common.c | 591
> +
> .../fs
On Fri, Aug 16, 2013 at 4:05 PM, Bjorn Helgaas wrote:
> On Tue, Aug 6, 2013 at 11:41 PM, Leon Ravich wrote:
>> From comparison of pci printout from the two kernel ,
>> beside the EDAC errors I noticed other strange differences:
>>
>> In 3.8.13 I got BAR 7 and BAR 8:
&g
On Sun, Oct 13, 2013 at 02:02:32AM +0530, Varun Sethi wrote:
> Factor out PCI specific code in the PAMU driver.
>
> Signed-off-by: Varun Sethi
> ---
> drivers/iommu/fsl_pamu_domain.c | 81
> +++
> 1 file changed, 40 insertions(+), 41 deletions(-)
>
> diff
On Thu, Dec 6, 2012 at 4:23 AM, Chen Yuanquan-B41889
wrote:
> On 12/06/2012 05:30 AM, Bjorn Helgaas wrote:
>>
>> On Wed, Dec 5, 2012 at 2:29 AM, Chen Yuanquan-B41889
>> wrote:
>>>
>>> On 12/05/2012 04:26 PM, Benjamin Herrenschmidt wrote:
>>>>
&g
On Sun, Jan 27, 2013 at 12:23 PM, Yinghai Lu wrote:
> Now we have pci_root_buses list, and there is lots of iteration with
> list_of_each of it, that is not safe after we add pci root bus hotplug
> support after booting stage.
>
> Add pci_get_next_host_bridge and use bus_find_device in driver core
On Tue, Mar 19, 2013 at 11:24 PM, Lucas Kannebley Tavares
wrote:
> Added function to gather the speed cap for a device and return a mask to
> supported speeds. The function is divided into an interface and a weak
> implementation so that architecture-specific functions can be called.
>
> This is t
1 - 100 of 884 matches
Mail list logo
