On Thu, Sep 03, 2015 at 03:18:02PM +1000, Michael Ellerman wrote:
> On Wed, 2015-09-02 at 10:02 +0900, Simon Horman wrote:
> > [CC linuxppc-dev]
> >
> > On Fri, Aug 21, 2015 at 12:51:16PM +1000, Samuel Mendoza-Jonas wrote:
> > > Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
On Thu, 2015-09-03 at 08:59 -0700, Nishanth Aravamudan wrote:
> On 03.09.2015 [19:58:53 +1000], Michael Ellerman wrote:
> > On Wed, 2015-09-02 at 08:39 -0700, Nishanth Aravamudan wrote:
> > > On 02.09.2015 [19:00:31 +1000], Alexey Kardashevskiy wrote:
> > > > On 09/02/2015 11:11 AM, Nishanth Aravam
On Fri, 2015-09-04 at 13:41 +1000, Alexey Kardashevskiy wrote:
> On 09/03/2015 07:58 PM, Michael Ellerman wrote:
> > On Wed, 2015-09-02 at 08:39 -0700, Nishanth Aravamudan wrote:
> >> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> >> b/arch/powerpc/platforms/powernv/pci-ioda.c
> >> index
From: Bharata B Rao
dlpar_cpu_probe() should release the acquired DRC if configure_connector
call fails.
Signed-off-by: Bharata B Rao
Cc: Nathan Fontenot
---
arch/powerpc/platforms/pseries/dlpar.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/ps
On Thu, 2015-09-03 at 20:07 -0700, Sukadev Bhattiprolu wrote:
> Currently, the PMU interface allows reading only one counter at a time.
> But some PMUs like the 24x7 counters in Power, support reading several
> counters at once. To leveage this functionality, extend the transaction
> interface to s
Le 04/09/2015 15:33, Michal Sojka a écrit :
Dear Christophe,
my MPC5200-based system stopped booting recently. I bisected the problem
to your commit below. If I revert that commit (on top of
807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my
system boots again.
Do you use ma
On 09/04/2015 05:04 AM, Bharata B Rao wrote:
> From: Bharata B Rao
>
> dlpar_cpu_probe() should release the acquired DRC if configure_connector
> call fails.
>
> Signed-off-by: Bharata B Rao
> Cc: Nathan Fontenot
Reviewed-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/dlpar.c |
On Thu, Sep 03, 2015 at 11:27:03AM +0200, Christophe Leroy wrote:
> On PPC832x, perf record/report reports martian addresses
>
> 2.62% perf_reseau4 libpthread-2.18.so [.] __libc_send
> 2.56% perf_reseau4 [kernel.kallsyms] [k] __ip_make_skb
> 1.62% perf_reseau4 [kernel.kalls
The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.
Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad ha
Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
property to engage the PCI_PROBE_ONLY mode, and both have a subtle
bug that can be triggered if the property has no parameter.
Provide a generic, safe implementation that can be used by both.
Signed-off-by: Marc Zyngier
---
driv
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 expose
this property naked. The driver ends up making a decision based on
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 not be that perfect, and it
could expose this property naked (at least one arm64 pla
The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.
Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.
Acked-by
The 32-bit TCE table initialization relies on the DMA window having a
size equal to a power of 2 (and checks for it explicitly). But
crashkernel= has no constraint that requires a power-of-2 be specified.
This causes the kdump kernel to fail to boot as none of the PCI devices
(including the disk co
Le 04/09/2015 18:43, Scott Wood a écrit :
On Thu, Sep 03, 2015 at 11:27:03AM +0200, Christophe Leroy wrote:
On PPC832x, perf record/report reports martian addresses
2.62% perf_reseau4 libpthread-2.18.so [.] __libc_send
2.56% perf_reseau4 [kernel.kallsyms] [k] __ip_make_skb
On Fri, Sep 04, 2015 at 09:59:38AM -0700, Nishanth Aravamudan wrote:
> The 32-bit TCE table initialization relies on the DMA window having a
> size equal to a power of 2 (and checks for it explicitly). But
> crashkernel= has no constraint that requires a power-of-2 be specified.
> This causes the k
Le 04/09/2015 16:35, Michal Sojka a écrit :
On Fri, Sep 04 2015, Christophe LEROY wrote:
Le 04/09/2015 15:33, Michal Sojka a écrit :
Dear Christophe,
my MPC5200-based system stopped booting recently. I bisected the problem
to your commit below. If I revert that commit (on top of
807249d3ada1
On 04.09.2015 [20:01:22 +0200], Jan Stancek wrote:
> On Fri, Sep 04, 2015 at 09:59:38AM -0700, Nishanth Aravamudan wrote:
> > The 32-bit TCE table initialization relies on the DMA window having a
> > size equal to a power of 2 (and checks for it explicitly). But
> > crashkernel= has no constraint t
The 32-bit TCE table initialization relies on the DMA window having a
size equal to a power of 2 (and checks for it explicitly). But
crashkernel= has no constraint that requires a power-of-2 be specified.
This causes the kdump kernel to fail to boot as none of the PCI devices
(including the disk co
On Fri, Sep 4, 2015 at 11:50 AM, Marc Zyngier wrote:
> The pci-host-generic driver parses the linux,pci-probe-only property,
> and assumes that it will have a boolean parameter.
>
> Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
> property, which leads to the driver derefer
On Fri, Sep 4, 2015 at 11:50 AM, Marc Zyngier wrote:
> Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
> property to engage the PCI_PROBE_ONLY mode, and both have a subtle
> bug that can be triggered if the property has no parameter.
>
> Provide a generic, safe implementation th
- Original Message -
> From: "Nishanth Aravamudan"
> To: "Michael Ellerman"
> Cc: "Hari Bathini" , "Gavin Shan"
> , "Alexey Kardashevskiy"
> , "Ben Herrenschmidt" , "Paul
> Mackerras" , "David Gibson"
> , "Wei Yang" ,
> linuxppc-dev@lists.ozlabs.org, "Jan Stancek"
>
> Sent: Friday
On Fri, Sep 04, 2015 at 08:00:59PM +0200, christophe leroy wrote:
> >Plus, it's e300, not e600, that is the exception among 6xx-style cores.
> Is it ? I've been looking for special register SIAR (spr 955) in several
> 6xx reference manuals.
> 82xx doesn't have it, 52xx and 512x don't have it.
> I
[ it seems my previous mail disappeared down the void ]
On Fri, Sep 04, 2015 at 08:00:59PM +0200, christophe leroy wrote:
> >Plus, it's e300, not e600, that is the exception among 6xx-style cores.
> Is it ? I've been looking for special register SIAR (spr 955) in several
> 6xx reference manuals.
Em Tue, Sep 01, 2015 at 12:18:47PM +0530, Hemant Kumar escreveu:
> >Should I try to process the 5 together, applying thest two first?
> Yes, this patchset needs to be applied before applying the other patchset,
> since there is a direct dependency on these two for the tooling part to
> work.
>
Hello Bjorn,
of_create_pci_dev() already has a lot of code that duplicates
pci_setup_device(), and it's a shame to add more. There's also a sparc
version of of_create_pci_dev() that presumably has the same problem you're
fixing for powerpc.
Thanks for the information!
Michael originally cal
26 matches
Mail list logo
