Re: [PATCH] cxl: sparse: add __iomem annotations in vphb.c

[Andrew Donnellan]

Finally looking at this patch again for the first time in a couple of 
months...


On 04/11/15 17:17, Andrew Donnellan wrote:

On 03/11/15 20:09, Michael Ellerman wrote:

Part of your problem is you're storing afu->crs_len which is not
__iomem in
cfg_data which is, and so that's leading to some of your casts.

I don't really see why you're using cfg_data like that, you have the
afu in
phb->private_data. But maybe cfg_data needs to hold that value for
some other
code I'm not seeing.


I can't see any obvious reason why we need to use cfg_data either.


Ian/Mikey - do you happen to know why we're using cfg_data? I've taken 
another look and I can't see anything obvious.


--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] PCI: designware: bail out if host_init failed

[Jisheng Zhang]

Dear Bjorn,

On Wed, 25 Nov 2015 14:01:03 -0600
Bjorn Helgaas wrote:

> Hi Jisheng,
> 
> On Thu, Nov 12, 2015 at 09:48:45PM +0800, Jisheng Zhang wrote:
> > There's no reason to continue the initialization such as configure
> > register, scan root bus etc. if customized host_init() failed. This
> > patch tries to check the host_init result, bail out if failed.  
> 
> This patch changes the (*host_init) return type and adds "return 0" to
> the host_init() implementations of ten different drivers, all to
> support a possible error in one driver.
> 
> Is there any way to detect and handle the error in
> ls1021_pcie_host_init() earlier, maybe by doing the syscon_regmap
> lookup in ls_pcie_probe() instead of in the host_init() function?
> 
> That would be even better because you wouldn't have to touch any of
> the other drivers, and you'd detect the error even earlier, before
> we've done any of the designware setup.

Sorry for being late. Got your point. The reason I made this patch is that:
I want to clk gate the pcie host to save power if the customized host_init()
report link training failure etc. For example: there's no pcie device in the
slot at all. But today, I have a different idea: the PCIE support hotplug,
so link training failure doesn't mean we should bail out, in fact we should
continue the initialization as current code does. So I think Jingoo made the
correct decision when implement the pcie designware interface. I want to drop
this patch.

Only one problem need your suggestions: how to save power when there's no device
, I.E clk gate the host, shutdown the pcie phy etc.

Any suggestions are appreciated!

Thanks in advance,
Jisheng


> 
> Bjorn
> 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/pci/host/pci-dra7xx.c  |  4 +++-
> >  drivers/pci/host/pci-exynos.c  |  4 +++-
> >  drivers/pci/host/pci-imx6.c|  4 +++-
> >  drivers/pci/host/pci-keystone.c|  4 +++-
> >  drivers/pci/host/pci-layerscape.c  | 25 -
> >  drivers/pci/host/pcie-designware.c |  7 +--
> >  drivers/pci/host/pcie-designware.h |  2 +-
> >  drivers/pci/host/pcie-spear13xx.c  |  4 +++-
> >  8 files changed, 37 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> > index 8c36880..b3160a1 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -149,7 +149,7 @@ static void dra7xx_pcie_enable_interrupts(struct 
> > pcie_port *pp)
> >LEG_EP_INTERRUPTS);
> >  }
> >  
> > -static void dra7xx_pcie_host_init(struct pcie_port *pp)
> > +static int dra7xx_pcie_host_init(struct pcie_port *pp)
> >  {
> > dw_pcie_setup_rc(pp);
> >  
> > @@ -162,6 +162,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
> > if (IS_ENABLED(CONFIG_PCI_MSI))
> > dw_pcie_msi_init(pp);
> > dra7xx_pcie_enable_interrupts(pp);
> > +
> > +   return 0;
> >  }
> >  
> >  static struct pcie_host_ops dra7xx_pcie_host_ops = {
> > diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> > index 01095e1..57f370b 100644
> > --- a/drivers/pci/host/pci-exynos.c
> > +++ b/drivers/pci/host/pci-exynos.c
> > @@ -481,10 +481,12 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
> > return 0;
> >  }
> >  
> > -static void exynos_pcie_host_init(struct pcie_port *pp)
> > +static int exynos_pcie_host_init(struct pcie_port *pp)
> >  {
> > exynos_pcie_establish_link(pp);
> > exynos_pcie_enable_interrupts(pp);
> > +
> > +   return 0;
> >  }
> >  
> >  static struct pcie_host_ops exynos_pcie_host_ops = {
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> > index 22e8224..9a46680 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -425,7 +425,7 @@ static int imx6_pcie_establish_link(struct pcie_port 
> > *pp)
> > return 0;
> >  }
> >  
> > -static void imx6_pcie_host_init(struct pcie_port *pp)
> > +static int imx6_pcie_host_init(struct pcie_port *pp)
> >  {
> > imx6_pcie_assert_core_reset(pp);
> >  
> > @@ -439,6 +439,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> >  
> > if (IS_ENABLED(CONFIG_PCI_MSI))
> > dw_pcie_msi_init(pp);
> > +
> > +   return 0;
> >  }
> >  
> >  static void imx6_pcie_reset_phy(struct pcie_port *pp)
> > diff --git a/drivers/pci/host/pci-keystone.c 
> > b/drivers/pci/host/pci-keystone.c
> > index 0aa81bd..2604571 100644
> > --- a/drivers/pci/host/pci-keystone.c
> > +++ b/drivers/pci/host/pci-keystone.c
> > @@ -250,7 +250,7 @@ static int keystone_pcie_fault(unsigned long addr, 
> > unsigned int fsr,
> > return 0;
> >  }
> >  
> > -static void __init ks_pcie_host_init(struct pcie_port *pp)
> > +static int __init ks_pcie_host_init(struct pcie_port *pp)
> >  {
> > struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
> > u32 val;
> > @@ -277,6 +277,8 @@ static void __init 

Re: [PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

[Simon Horman]

On Tue, Dec 08, 2015 at 02:46:17PM +1100, Michael Ellerman wrote:
> On Mon, 2015-12-07 at 14:42 -0600, Scott Wood wrote:
> > On Tue, 2015-10-06 at 17:55 -0500, Scott Wood wrote:
> > > It needs to know this because the SMP release mechanism for Freescale
> > > book3e is different from when booting with normal hardware.  In theory
> > > we could simulate the normal spin table mechanism, but not (easily) at
> > > the addresses U-Boot put in the device tree -- so there'd need to be
> > > even more communication between the kernel and kexec to set that up.
> > > 
> > > Signed-off-by: Scott Wood 
> > > ---
> > > v2: Use a device tree property rather than setting a flag in the kernel
> > > image, as requested by Michael Ellerman.
> > 
> > ping?
> > 
> > Michael, can you review this?  Simon is waiting for another PPC person to
> > review it.
> 
> Oh sorry I thought it'd been merged already, but I see now only 1 & 2 went in.
> 
> Horms this looks fine to me:
> 
> Acked-by: Michael Ellerman 

Thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] Revert "powerpc/eeh: Don't unfreeze PHB PE after reset"

[Andrew Donnellan]

This reverts commit 527d10ef3a315d3cb9dc098dacd61889a6c26439.

The reverted commit breaks cxlflash devices following an EEH reset (and
possibly other cxl devices, however this has not been tested).

The reverted commit changed the behaviour of eeh_reset_device() so that PHB
PEs are not unfrozen following the completion of the reset. This should not
be problematic, as no device resources should have been associated with the
PHB PE.

However, when attempting to load the cxlflash driver after a reset, the
driver attempts to read Vital Product Data through a call to
pci_read_vpd() (which is called on the physical cxl device, not on the
virtual AFU device). pci_read_vpd() in turn attempts to read from the cxl
device's config space. This fails, as the PE it's trying to read from is
still frozen. In turn, the driver gets an -ENODEV and fails to initialise.

It appears this issue only affects some parts of the VPD area, as "lspci
-vvv", which only reads a subset of the VPD bytes, is not broken by the
original patch.

At this stage, we don't fully understand why we're trying to read a frozen
PE, and we don't know how this affects other cxl devices. It is possible
that there is an underlying bug in the cxl driver or the powerpc CAPI
support code, or alternatively a bug in the PCI resource allocation/mapping
code that is incorrectly mapping resources to PE#0.

As such, this fix is incomplete, however it is necessary to prevent a
serious regression in CAPI support.

In the meantime, revert the commit, especially as it was intended to be a
non-functional change.

Cc: Gavin Shan 
Cc: Ian Munsie 
Cc: Daniel Axtens 
Signed-off-by: Andrew Donnellan 

---

Changes from V1:
 - Updated commit message to incorporate comments from Daniel Axtens

We would like to get this fix pushed as soon as possible - I'm on leave for
the rest of this week, so I'll volunteer Daniel to answer any remaining
questions, and I'm happy for him to revise this patch further if needed.
---
 arch/powerpc/kernel/eeh_driver.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 80dfe89..8d14feb 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -590,16 +590,10 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
pci_bus *bus)
eeh_ops->configure_bridge(pe);
eeh_pe_restore_bars(pe);
 
-   /*
-* If it's PHB PE, the frozen state on all available PEs should have
-* been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
-* child PEs because they might be in frozen state.
-*/
-   if (!(pe->type & EEH_PE_PHB)) {
-   rc = eeh_clear_pe_frozen_state(pe, false);
-   if (rc)
-   return rc;
-   }
+   /* Clear frozen state */
+   rc = eeh_clear_pe_frozen_state(pe, false);
+   if (rc)
+   return rc;
 
/* Give the system 5 seconds to finish running the user-space
 * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
-- 
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [P.A. Semi] Does the ethernet interface work on your Electra, Chitra, Nemo, and Athena board?

[Denis Kirjanov]

On 12/7/15, Christian Zigotzky  wrote:
> Hi all,
>
> I have some good news for you. I was able to fix the issue with the P.A.
> Semi Ethernet. It was a problem with the new DMA handling. The patch '
> [RFC/PATCH,v2] powerpc/iommu: Support "hybrid" iommu/direct DMA ops for
> coherent_mask < dma_mask (https://patchwork.ozlabs.org/patch/472535/)'
> is the problem.
>
> I had patched the following files before I compiled a kernel.
>
> arch/powerpc/Kconfig
> arch/powerpc/include/asm/device.h
> arch/powerpc/include/asm/dma-mapping.h
> arch/powerpc/include/asm/iommu.h
> arch/powerpc/kernel/dma-iommu.c
> arch/powerpc/kernel/dma-swiotlb.c
> arch/powerpc/kernel/dma.c
> arch/powerpc/platforms/powernv/pci-ioda.c
> arch/powerpc/platforms/pseries/iommu.c
> arch/powerpc/sysdev/dart_iommu.c
> include/asm-generic/dma-mapping-common.h
>
> The P.A. Semi Ethernet works again with the patched kernel.

Hi Ben,

Could you please take a look..

Thanks!

>
> I am happy. :-)
>
> Please fix the issue in the kernel source code.
>
> Thanks in advance,
>
> Christian
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] cxl: Set endianess of kernel contexts

[Frederic Barrat]

A process element (defined in CAIA) keeps track of the endianess of
contexts through the Little Endian (LE) bit of the State Register. It
is currently set for user contexts, but was somehow forgotten for
kernel contexts, so this patch fixes it.
It could lead to erratic behavior from an AFU when the context is
attached through the kernel API.

Signed-off-by: Frederic Barrat 
Suggested-by: Michael Neuling 
Cc:  # 4.3+
---
cxl kernel API is supported starting with 4.3 (for cxlflash)

 drivers/misc/cxl/native.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
index d2e75c8..f409097 100644
--- a/drivers/misc/cxl/native.c
+++ b/drivers/misc/cxl/native.c
@@ -497,6 +497,7 @@ static u64 calculate_sr(struct cxl_context *ctx)
 {
u64 sr = 0;
 
+   set_endian(sr);
if (ctx->master)
sr |= CXL_PSL_SR_An_MP;
if (mfspr(SPRN_LPCR) & LPCR_TC)
@@ -506,7 +507,6 @@ static u64 calculate_sr(struct cxl_context *ctx)
sr |= CXL_PSL_SR_An_HV;
} else {
sr |= CXL_PSL_SR_An_PR | CXL_PSL_SR_An_R;
-   set_endian(sr);
sr &= ~(CXL_PSL_SR_An_HV);
if (!test_tsk_thread_flag(current, TIF_32BIT))
sr |= CXL_PSL_SR_An_SF;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] tracing: introduce TRACE_EVENT_FN_COND macro

[Steven Rostedt]

On Mon, 7 Dec 2015 17:42:42 +0300
Denis Kirjanov  wrote:

> On 11/24/15, Denis Kirjanov  wrote:
> > TRACE_EVENT_FN can't be used in some circumstances
> > like invoking trace functions from offlined CPU due
> > to RCU usage.
> >
> > This patch adds the TRACE_EVENT_FN_COND macro
> > to make such trace points conditional.
> >
> > Signed-off-by: Denis Kirjanov   
> 
> Hi Steven,
> are you going to take this series through your tree?
> 

Yeah, thanks for the reminder!

-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[P.A. Semi] Does the ethernet interface work on your Electra, Chitra, Nemo, and Athena board?

[Christian Zigotzky]

Hi all,

I have some good news for you. I was able to fix the issue with the P.A. 
Semi Ethernet. It was a problem with the new DMA handling. The patch ' 
[RFC/PATCH,v2] powerpc/iommu: Support "hybrid" iommu/direct DMA ops for 
coherent_mask < dma_mask (https://patchwork.ozlabs.org/patch/472535/)' 
is the problem.


I had patched the following files before I compiled a kernel.

arch/powerpc/Kconfig
arch/powerpc/include/asm/device.h
arch/powerpc/include/asm/dma-mapping.h
arch/powerpc/include/asm/iommu.h
arch/powerpc/kernel/dma-iommu.c
arch/powerpc/kernel/dma-swiotlb.c
arch/powerpc/kernel/dma.c
arch/powerpc/platforms/powernv/pci-ioda.c
arch/powerpc/platforms/pseries/iommu.c
arch/powerpc/sysdev/dart_iommu.c
include/asm-generic/dma-mapping-common.h

The P.A. Semi Ethernet works again with the patched kernel.

I am happy. :-)

Please fix the issue in the kernel source code.

Thanks in advance,

Christian


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 5/5] printk/nmi: Increase the size of the temporary buffer

[Petr Mladek]

On Mon 2015-11-30 08:42:04, yalin wang wrote:
> 
> > On Nov 27, 2015, at 19:09, Petr Mladek  wrote:
> > 
> > Testing has shown that the backtrace sometimes does not fit
> > into the 4kB temporary buffer that is used in NMI context.
> > 
> > The warnings are gone when I double the temporary buffer size.
> > 
> > Note that this problem existed even in the x86-specific
> > implementation that was added by the commit a9edc8809328
> > ("x86/nmi: Perform a safe NMI stack trace on all CPUs").
> > Nobody noticed it because it did not print any warnings.
> > 
> > Signed-off-by: Petr Mladek 
> > ---
> > kernel/printk/nmi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/printk/nmi.c b/kernel/printk/nmi.c
> > index 8af1e4016719..6111644d5f01 100644
> > --- a/kernel/printk/nmi.c
> > +++ b/kernel/printk/nmi.c
> > @@ -42,7 +42,7 @@ atomic_t nmi_message_lost;
> > struct nmi_seq_buf {
> > atomic_tlen;/* length of written data */
> > struct irq_work work;   /* IRQ work that flushes the buffer */
> > -   unsigned char   buffer[PAGE_SIZE - sizeof(atomic_t) -
> > +   unsigned char   buffer[2 * PAGE_SIZE - sizeof(atomic_t) -
> >sizeof(struct irq_work)];
> > };
> > 
> 
> why not define like this:
> 
> union {
> struct {atomic_t  len;
>   struct irq_work work;
> }
> unsigned char buffer[PAGE_SIZE * 2] ;
> }
> 
> we can make sure the union is 2 PAGE_SIZE .

IMHO, this would add more confusion. It would just move the
computation somewhere else. The union will have 2*PAGE_SIZE
but the beginning of "buffer" will be shared with "len"
and "work". Therefore, we would need to skip the beginning
of the buffer when storing the data. By other words, we still
will be able to use only (sizeof(buffer) - sizeof(atomic_t) -
sizeof(struct irq_work)] of the "buffer".

Or did I miss something, please?

Best Regards,
Petr
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 3/5] printk/nmi: Try hard to print Oops message in NMI context

[David Laight]

From: Russell King - ARM Linux
> Sent: 04 December 2015 17:13
...
> I have a slightly different view...
> 
> > > I don't see bust_spinlocks() dealing with any of these locks, so IMHO
> > > trying to make this work in NMI context strikes me as making the
> > > existing solution more unreliable on ARM systems.
> >
> > bust_spinlocks() calls printk_nmi_flush() that would call printk()
> > that would zap "lockbuf_lock" and "console_sem" when in Oops and NMI.
> > Yes, there might be more locks blocked but we try to break at least
> > the first two walls. Also zapping is allowed only once per 30 seconds,
> > see zap_locks(). Why do you think that it might make things more
> > unreliable, please?
> 
> Take the scenario where CPU1 is in the middle of a printk(), and is
> holding its lock.
> 
> CPU0 comes along and decides to trigger a NMI backtrace.  This sends
> a NMI to CPU1, which takes it in the middle of the serial console
> output.
> 
> With the existing solution, the NMI output will be written to the
> temporary buffer, and CPU1 has finished handling the NMI it resumes
> the serial console output, eventually dropping the lock.  That then
> allows CPU0 to print the contents of all buffers, and we get NMI
> printk output.

Is the traceback from inside printk() or serial console code
likely to be useful?
If not then why not get the stacktrace generated when the relevant
lock is released?
That should save any faffing with a special buffer.

David

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] tracing: introduce TRACE_EVENT_FN_COND macro

[Denis Kirjanov]

On 11/24/15, Denis Kirjanov  wrote:
> TRACE_EVENT_FN can't be used in some circumstances
> like invoking trace functions from offlined CPU due
> to RCU usage.
>
> This patch adds the TRACE_EVENT_FN_COND macro
> to make such trace points conditional.
>
> Signed-off-by: Denis Kirjanov 

Hi Steven,
are you going to take this series through your tree?

Thanks!

> ---
>  include/linux/tracepoint.h   | 4 
>  include/trace/define_trace.h | 6 ++
>  include/trace/trace_events.h | 6 ++
>  3 files changed, 16 insertions(+)
>
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 696a339c..45b3fcf 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -493,6 +493,10 @@ extern void syscall_unregfunc(void);
>  #define TRACE_EVENT_FN(name, proto, args, struct,\
>   assign, print, reg, unreg)  \
>   DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
> +#define TRACE_EVENT_FN_COND(name, proto, args, cond, struct, \
> + assign, print, reg, unreg)  \
> + DECLARE_TRACE_CONDITION(name, PARAMS(proto),\
> + PARAMS(args), PARAMS(cond))
>  #define TRACE_EVENT_CONDITION(name, proto, args, cond,   \
> struct, assign, print)\
>   DECLARE_TRACE_CONDITION(name, PARAMS(proto),\
> diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
> index 2d8639e..6e3945f 100644
> --- a/include/trace/define_trace.h
> +++ b/include/trace/define_trace.h
> @@ -40,6 +40,11 @@
>   assign, print, reg, unreg)  \
>   DEFINE_TRACE_FN(name, reg, unreg)
>
> +#undef TRACE_EVENT_FN_COND
> +#define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct,
> \
> + assign, print, reg, unreg)  \
> + DEFINE_TRACE_FN(name, reg, unreg)
> +
>  #undef DEFINE_EVENT
>  #define DEFINE_EVENT(template, name, proto, args) \
>   DEFINE_TRACE(name)
> @@ -93,6 +98,7 @@
>
>  #undef TRACE_EVENT
>  #undef TRACE_EVENT_FN
> +#undef TRACE_EVENT_FN_COND
>  #undef TRACE_EVENT_CONDITION
>  #undef DECLARE_EVENT_CLASS
>  #undef DEFINE_EVENT
> diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
> index de996cf..170c93b 100644
> --- a/include/trace/trace_events.h
> +++ b/include/trace/trace_events.h
> @@ -123,6 +123,12 @@ TRACE_MAKE_SYSTEM_STR();
>   TRACE_EVENT(name, PARAMS(proto), PARAMS(args),  \
>   PARAMS(tstruct), PARAMS(assign), PARAMS(print)) \
>
> +#undef TRACE_EVENT_FN_COND
> +#define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct,\
> + assign, print, reg, unreg)  \
> + TRACE_EVENT_CONDITION(name, PARAMS(proto), PARAMS(args), PARAMS(cond),  
> \
> + PARAMS(tstruct), PARAMS(assign), PARAMS(print)) \
> +
>  #undef TRACE_EVENT_FLAGS
>  #define TRACE_EVENT_FLAGS(name, value)   
> \
>   __TRACE_EVENT_FLAGS(name, value)
> --
> 2.4.0
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver

[Madalin-Cristian Bucur]

Hi Timur,

I've managed somehow to make got send-email to move the From: line in the body 
instead of the header, probably typed something wrong when asked to confirm the 
sender. I've resent the series.

Regards,
Madalin

From: Timur Tabi 
Sent: Saturday, December 5, 2015 6:40:11 AM
To: Bucur Madalin-Cristian-B32716
Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; lkml; David Miller; 
Wood Scott-B07421; Liberman Igal-B31950; p...@mindchasers.com; Joe Perches; 
pebo...@tiscali.nl; Joakim Tjernlund; Greg Kroah-Hartman
Subject: Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver

On Thu, Dec 3, 2015 at 6:08 AM,  <> wrote:
> From: Madalin Bucur 
>
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).

Please fix your git-send-email configuration, so that your emails are
formatted properly.  This is the From: header:

From: <>

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [01/19] powerpc: Don't disable kernel FP/VMX/VSX MSR bits on context switch

[Michael Ellerman]

On Thu, 2015-29-10 at 00:43:53 UTC, Anton Blanchard wrote:
> Writing the MSR is slow, so we want to avoid it whenever possible.
> 
> A subsequent patch will add a debug option that strictly manages the
> FP/VMX/VSX unavailable bits. For now just remove it, matching what
> we do in other areas of the kernel (eg enable_kernel_altivec()).
> 
> A context switch microbenchmark using yield():
> 
> http://ozlabs.org/~anton/junkcode/context_switch2.c
> 
> ./context_switch2 --test=yield --fp 0 0
> 
> shows an improvement of almost 3% on POWER8.
> 
> Signed-off-by: Anton Blanchard 

Applied all 19 patches to powerpc next, thanks.

http://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/log/?h=next

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc/64: Include KVM guest test in all interrupt vectors

[Michael Ellerman]

On Thu, 2015-12-11 at 05:44:42 UTC, Paul Mackerras wrote:
> Currently, if HV KVM is configured but PR KVM isn't, we don't include
> a test to see whether we were interrupted in KVM guest context for the
> set of interrupts which get delivered directly to the guest by hardware
> if they occur in the guest.  This includes things like program
> interrupts.
> 
> However, the recent bug where userspace could set the MSR for a VCPU
> to have an illegal value in the TS field, and thus cause a TM Bad Thing
> type of program interrupt on the hrfid that enters the guest, showed that
> we can never be completely sure that these interrupts can never occur
> in the guest entry/exit code.  If one of these interrupts does happen
> and we have HV KVM configured but not PR KVM, then we end up trying to
> run the handler in the host with the MMU set to the guest MMU context,
> which generally ends badly.
> 
> Thus, for robustness it is better to have the test in every interrupt
> vector, so that if some way is found to trigger some interrupt in the
> guest entry/exit path, we can handle it without immediately crashing
> the host.
> 
> This means that the distinction between KVMTEST and KVMTEST_PR goes
> away.  Thus we delete KVMTEST_PR and associated macros and use KVMTEST
> everywhere that we previously used either KVMTEST_PR or KVMTEST.  It
> also means that SOFTEN_TEST_HV_201 becomes the same as SOFTEN_TEST_PR,
> so we deleted SOFTEN_TEST_HV_201 and use SOFTEN_TEST_PR instead.
> 
> Signed-off-by: Paul Mackerras 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/31a40e2b052c0f2b80df7b56

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[P.A. Semi] Does the ethernet interface work on your Electra, Chitra, Nemo, and Athena board?

[Christian Zigotzky]

Michael,

Maybe a DMA issue. Please find attached an output of strace.

Cheers,

Christian

On 03 December 2015 1:37 PM, Christian Zigotzky wrote:

Hi Michael,

I checked out the Linux git till the commit 'powerpc-4.3-1'

git checkout ff474e8ca8547d09cb82ebab56d4c96f9eea01ce

Output:

Checking out files: 100% (13843/13843), done.
Note: checking out 'ff474e8ca8547d09cb82ebab56d4c96f9eea01ce'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. 
Example:


  git checkout -b new_branch_name

HEAD ist jetzt bei ff474e8... Merge tag 'powerpc-4.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux


---

The P.A. Semi Ethernet doesn't work with the powerpc-4.3-1 merge. I 
reverted this merge with:


git revert ff474e8ca8547d09cb82ebab56d4c96f9eea01ce -m 1

Output:

 Committer: christian 
Ihr Name und E-Mail Adresse wurden automatisch auf Basis
Ihres Benutzer- und Rechnernamens konfiguriert. Bitte prüfen Sie, dass
diese zutreffend sind. Sie können diese Meldung unterdrücken, indem Sie
diese explizit setzen:

git config --global user.name "Ihr Name"
git config --global user.email i...@emailadresse.de

Nachdem Sie das getan hast, können Sie Ihre Identität für diesen 
Commit ändern mit:


git commit --amend --reset-author

 146 files changed, 2047 insertions(+), 3609 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/leds/leds-powernv.txt
 delete mode 100644 
Documentation/devicetree/bindings/powerpc/fsl/scfg.txt

 delete mode 100644 arch/powerpc/boot/dts/t1040d4rdb.dts
 delete mode 100644 arch/powerpc/boot/dts/t1042d4rdb.dts
 delete mode 100644 arch/powerpc/boot/dts/t104xd4rdb.dtsi
 delete mode 100644 arch/powerpc/configs/85xx-32bit.config
 delete mode 100644 arch/powerpc/configs/85xx-64bit.config
 delete mode 100644 arch/powerpc/configs/85xx-hw.config
 delete mode 100644 arch/powerpc/configs/85xx-smp.config
 delete mode 100644 arch/powerpc/configs/altivec.config
 create mode 100644 arch/powerpc/configs/corenet32_smp_defconfig
 rename arch/powerpc/configs/{fsl-emb-nonhw.config => 
corenet64_smp_defconfig} (50%)

 delete mode 100644 arch/powerpc/configs/corenet_basic_defconfig
 delete mode 100644 arch/powerpc/configs/mpc85xx_basic_defconfig
 create mode 100644 arch/powerpc/configs/mpc85xx_defconfig
 create mode 100644 arch/powerpc/configs/mpc85xx_smp_defconfig
 delete mode 100644 arch/powerpc/include/asm/trace_clock.h
 delete mode 100644 arch/powerpc/kernel/trace_clock.c
 rewrite arch/powerpc/platforms/powernv/opal-power.c (76%)
 delete mode 100644 drivers/leds/leds-powernv.c

---

After that the P.A. Semi Ethernet works without any problems.

Cheers,

Christian



execve("/sbin/ifconfig", ["ifconfig", "eth0", "up"], [/* 33 vars */]) = 0
brk(0)  = 0x10022000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7dff000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=155410, ...}) = 0
mmap(NULL, 155410, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7da9000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/powerpc-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0025\240\0\0\0004"..., 512) 
= 512
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7dfe000
fstat64(3, {st_mode=S_IFREG|0755, st_size=1565776, ...}) = 0
mmap(0xfe6, 1635768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xfe6
mprotect(0xffd8000, 61440, PROT_NONE)   = 0
mmap(0xffe7000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x177000) = 0xffe7000
mmap(0xffed000, 9656, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7dfd000
mprotect(0xffe7000, 20480, PROT_READ)   = 0
mprotect(0x1001f000, 4096, PROT_READ)   = 0
mprotect(0xf7e0, 4096, PROT_READ)   = 0
munmap(0xf7da9000, 155410)  = 0
brk(0)  = 0x10022000
brk(0x10043000) = 0x10043000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/locale/de_DE.UTF-8/LC_IDENTIFICATION", 

Re: [PATCH kernel 1/9] rcu: Define notrace version of list_for_each_entry_rcu

[David Gibson]

On Tue, Sep 15, 2015 at 08:49:31PM +1000, Alexey Kardashevskiy wrote:
> This defines list_for_each_entry_rcu_notrace and list_entry_rcu_notrace
> which use rcu_dereference_raw_notrace instead of rcu_dereference_raw.
> This allows using list_for_each_entry_rcu_notrace in real mode (MMU is off).
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 

> ---
>  include/linux/rculist.h | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> index 17c6b1f..439c4d7 100644
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -253,6 +253,25 @@ static inline void list_splice_init_rcu(struct list_head 
> *list,
>  })
>  
>  /**
> + * list_entry_rcu_notrace - get the struct for this entry
> + * @ptr:the  list_head pointer.
> + * @type:   the type of the struct this is embedded in.
> + * @member: the name of the list_struct within the struct.
> + *
> + * This primitive may safely run concurrently with the _rcu list-mutation
> + * primitives such as list_add_rcu() as long as it's guarded by 
> rcu_read_lock().
> + *
> + * This is the same as list_entry_rcu() except that it does
> + * not do any RCU debugging or tracing.
> + */
> +#define list_entry_rcu_notrace(ptr, type, member) \
> +({ \
> + typeof(*ptr) __rcu *__ptr = (typeof(*ptr) __rcu __force *)ptr; \
> + container_of((typeof(ptr))rcu_dereference_raw_notrace(__ptr), \
> + type, member); \
> +})
> +
> +/**
>   * Where are list_empty_rcu() and list_first_entry_rcu()?
>   *
>   * Implementing those functions following their counterparts list_empty() and
> @@ -308,6 +327,25 @@ static inline void list_splice_init_rcu(struct list_head 
> *list,
>   pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
>  
>  /**
> + * list_for_each_entry_rcu_notrace - iterate over rcu list of given type
> + * @pos: the type * to use as a loop cursor.
> + * @head:the head for your list.
> + * @member:  the name of the list_struct within the struct.
> + *
> + * This list-traversal primitive may safely run concurrently with
> + * the _rcu list-mutation primitives such as list_add_rcu()
> + * as long as the traversal is guarded by rcu_read_lock().
> + *
> + * This is the same as list_for_each_entry_rcu() except that it does
> + * not do any RCU debugging or tracing.
> + */
> +#define list_for_each_entry_rcu_notrace(pos, head, member) \
> + for (pos = list_entry_rcu_notrace((head)->next, typeof(*pos), member); \
> + >member != (head); \
> + pos = list_entry_rcu_notrace(pos->member.next, typeof(*pos), \
> + member))
> +
> +/**
>   * list_for_each_entry_continue_rcu - continue iteration over list of given 
> type
>   * @pos: the type * to use as a loop cursor.
>   * @head:the head for your list.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH kernel 3/9] KVM: PPC: Rework H_PUT_TCE/H_GET_TCE handlers

[David Gibson]

On Tue, Sep 15, 2015 at 08:49:33PM +1000, Alexey Kardashevskiy wrote:
> This reworks the existing H_PUT_TCE/H_GET_TCE handlers to have one
> exit path. This allows next patch to add locks nicely.

I don't see a problem with the actual code, but it doesn't seem to
match this description: I still see multiple return statements for
h_put_tce at least.

> This moves the ioba boundaries check to a helper and adds a check for
> least bits which have to be zeros.
> 
> The patch is pretty mechanical (only check for least ioba bits is added)
> so no change in behaviour is expected.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  arch/powerpc/kvm/book3s_64_vio_hv.c | 102 
> +++-
>  1 file changed, 66 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c 
> b/arch/powerpc/kvm/book3s_64_vio_hv.c
> index 89e96b3..8ae12ac 100644
> --- a/arch/powerpc/kvm/book3s_64_vio_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
> @@ -35,71 +35,101 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define TCES_PER_PAGE(PAGE_SIZE / sizeof(u64))
>  
> +/*
> + * Finds a TCE table descriptor by LIOBN.
> + *
> + * WARNING: This will be called in real or virtual mode on HV KVM and virtual
> + *  mode on PR KVM
> + */
> +static struct kvmppc_spapr_tce_table *kvmppc_find_table(struct kvm_vcpu 
> *vcpu,
> + unsigned long liobn)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct kvmppc_spapr_tce_table *stt;
> +
> + list_for_each_entry_rcu_notrace(stt, >arch.spapr_tce_tables, list)
> + if (stt->liobn == liobn)
> + return stt;
> +
> + return NULL;
> +}
> +
> +/*
> + * Validates IO address.
> + *
> + * WARNING: This will be called in real-mode on HV KVM and virtual
> + *  mode on PR KVM
> + */
> +static long kvmppc_ioba_validate(struct kvmppc_spapr_tce_table *stt,
> + unsigned long ioba, unsigned long npages)
> +{
> + unsigned long mask = (1ULL << IOMMU_PAGE_SHIFT_4K) - 1;
> + unsigned long idx = ioba >> IOMMU_PAGE_SHIFT_4K;
> + unsigned long size = stt->window_size >> IOMMU_PAGE_SHIFT_4K;
> +
> + if ((ioba & mask) || (size + npages <= idx))
> + return H_PARAMETER;

Not sure if it's worth a check for overflow in (size+npages) there.

> +
> + return H_SUCCESS;
> +}
> +
>  /* WARNING: This will be called in real-mode on HV KVM and virtual
>   *  mode on PR KVM
>   */
>  long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> unsigned long ioba, unsigned long tce)
>  {
> - struct kvm *kvm = vcpu->kvm;
> - struct kvmppc_spapr_tce_table *stt;
> + struct kvmppc_spapr_tce_table *stt = kvmppc_find_table(vcpu, liobn);
> + long ret = H_TOO_HARD;
> + unsigned long idx;
> + struct page *page;
> + u64 *tbl;
>  
>   /* udbg_printf("H_PUT_TCE(): liobn=0x%lx ioba=0x%lx, tce=0x%lx\n", */
>   /*  liobn, ioba, tce); */
>  
> - list_for_each_entry(stt, >arch.spapr_tce_tables, list) {
> - if (stt->liobn == liobn) {
> - unsigned long idx = ioba >> SPAPR_TCE_SHIFT;
> - struct page *page;
> - u64 *tbl;
> + if (!stt)
> + return ret;
>  
> - /* udbg_printf("H_PUT_TCE: liobn 0x%lx => stt=%p  
> window_size=0x%x\n", */
> - /*  liobn, stt, stt->window_size); */
> - if (ioba >= stt->window_size)
> - return H_PARAMETER;
> + ret = kvmppc_ioba_validate(stt, ioba, 1);
> + if (ret)
> + return ret;
>  
> - page = stt->pages[idx / TCES_PER_PAGE];
> - tbl = (u64 *)page_address(page);
> + idx = ioba >> SPAPR_TCE_SHIFT;
> + page = stt->pages[idx / TCES_PER_PAGE];
> + tbl = (u64 *)page_address(page);
>  
> - /* FIXME: Need to validate the TCE itself */
> - /* udbg_printf("tce @ %p\n", [idx % 
> TCES_PER_PAGE]); */
> - tbl[idx % TCES_PER_PAGE] = tce;
> - return H_SUCCESS;
> - }
> - }
> + /* FIXME: Need to validate the TCE itself */
> + /* udbg_printf("tce @ %p\n", [idx % TCES_PER_PAGE]); */
> + tbl[idx % TCES_PER_PAGE] = tce;
>  
> - /* Didn't find the liobn, punt it to userspace */
> - return H_TOO_HARD;
> + return ret;

So, this relies on the fact that kvmppc_ioba_validate() would have
returned H_SUCCESS some distance above.  This seems rather fragile if
you insert anything else which alters ret in between.  Since this is
the success path, I think it's clearer to explicitly return H_SUCCESS.

>  }
>  EXPORT_SYMBOL_GPL(kvmppc_h_put_tce);
>  
>  long kvmppc_h_get_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> unsigned long ioba)
>  {
> - struct kvm *kvm = vcpu->kvm;
> - struct 

Re: [PATCH kernel 2/9] KVM: PPC: Make real_vmalloc_addr() public

[David Gibson]

On Tue, Sep 15, 2015 at 08:49:32PM +1000, Alexey Kardashevskiy wrote:
> This helper translates vmalloc'd addresses to linear addresses.
> It is only used by the KVM MMU code now and resides in the HV KVM code.
> We will need it further in the TCE code and the DMA memory preregistration
> code called in real mode.
> 
> This makes real_vmalloc_addr() public and moves it to the powerpc code as
> it does not do anything special for KVM.
> 
> Signed-off-by: Alexey Kardashevskiy 

Hmm, I have a couple of small concerns.

First, I'm not sure if the name is clear enough for a public function.

Second, I'm not sure if mmu-hash64.h is the right place for it.  This
is still a function with very specific and limited usage, I wonder if
we should have somewhere else for such special real mode helpers.

Paulus, thoughts?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH kernel 4/9] KVM: PPC: Use RCU for arch.spapr_tce_tables

[David Gibson]

On Tue, Sep 15, 2015 at 08:49:34PM +1000, Alexey Kardashevskiy wrote:
> At the moment spapr_tce_tables is not protected against races. This makes
> use of RCU-variants of list helpers. As some bits are executed in real
> mode, this makes use of just introduced list_for_each_entry_rcu_notrace().
> 
> This converts release_spapr_tce_table() to a RCU scheduled handler.
> 
> Signed-off-by: Alexey Kardashevskiy 

Looks correct on my limited knowledge of RCU

Reviewed-by: David Gibson 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: FCC driver for Motorola MPC82xx - an error found

[Scott Wood]

On Tue, 2015-11-24 at 05:19 -0700, Martin Roth wrote:
> I was looking for an error on MPC8270 processor 100 Mbps Ethernet FCC port. 
> The port may become locked if it is set to AUTO, while the peer is forced to
> 100 Mbs full duplex (non AUTO).
> I was looking for an error in the area of collision handling of the driver.
> It looks like I found the problem.
> 
> The error is at line 555:
> http://lxr.free-electrons.com/source/drivers/net/ethernet/freescale/fs_enet/
> mac-fcc.c#L555
> 
> The problem is that the last descriptor address is not calculated correctly.
> 
> Instead of
>last_tx_bd = fep->tx_bd_base + (fpi->tx_ring * sizeof(cbd_t)); 
> The fix should be:
>last_tx_bd = fep->tx_bd_base + ((fpi->tx_ring-1)* sizeof(cbd_t));
> 
> Is it a bug? 
> Thanks,
> Martin Roth

Yes, it looks like a bug.  Could you send a patch to the netdev list and
maintainer?

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: crypto/nx842: Ignore queue overflow informative error

[Dan Streetman]

On Sun, Dec 6, 2015 at 2:46 AM, Haren Myneni  wrote:
>
> NX842 coprocessor sets bit 3 if queue is overflow. It is just for
> information to the user. So the driver prints this informative message
> and ignores it.
>
> Signed-off-by: Haren Myneni 
>
> diff --git a/arch/powerpc/include/asm/icswx.h 
> b/arch/powerpc/include/asm/icswx.h
> index 9f8402b..d1a2a2d 100644
> --- a/arch/powerpc/include/asm/icswx.h
> +++ b/arch/powerpc/include/asm/icswx.h
> @@ -164,6 +164,7 @@ struct coprocessor_request_block {
>  #define ICSWX_INITIATED(0x8)
>  #define ICSWX_BUSY (0x4)
>  #define ICSWX_REJECTED (0x2)
> +#define ICSWX_BIT3 (0x1)   /* undefined or set from XERSO. */

Since this isn't defined by the icswx rfc workbook, it probably
shouldn't go here, it would make more sense to put it into nx-842.h
and call it something like "ICSWX_NX_QUEUE_OVERFLOW" or similar
NX-specific meaningful name.

>
>  static inline int icswx(__be32 ccw, struct coprocessor_request_block *crb)
>  {
> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
> b/drivers/crypto/nx/nx-842-powernv.c
> index 9ef51fa..321b8e8 100644
> --- a/drivers/crypto/nx/nx-842-powernv.c
> +++ b/drivers/crypto/nx/nx-842-powernv.c
> @@ -442,6 +442,15 @@ static int nx842_powernv_function(const unsigned char 
> *in, unsigned int inlen,
>  (unsigned int)ccw,
>  (unsigned int)be32_to_cpu(crb->ccw));
>
> +   /*
> +* NX842 coprocessor uses 3rd bit to report queue overflow which is
> +* not an error, just for information to user. So, ignore this bit.
> +*/

a meaningfully named bit define means you don't need to explain it
with a comment :-)

However, I suggest that you do explain *why* a queue overflow isn't an
error - either here or (probably better) at the #define of the bit -
because that isn't obvious.

> +   if (ret & ICSWX_BIT3) {
> +   pr_info_ratelimited("842 coprocessor queue overflow\n");

if it's not an error, should this be pr_debug_ratelimited instead?
What is an end user expected to do if they see this msg in the log?

> +   ret &= ~ICSWX_BIT3;
> +   }
> +
> switch (ret) {
> case ICSWX_INITIATED:
> ret = wait_for_csb(wmem, csb);
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: crypto/nx842: Ignore queue overflow informative error

[Dan Streetman]

On Sun, Dec 6, 2015 at 5:57 PM, Daniel Axtens  wrote:
> Haren Myneni  writes:
>
>> NX842 coprocessor sets bit 3 if queue is overflow. It is just for
>> information to the user. So the driver prints this informative message
>> and ignores it.
>
> What queue, and what happens when the queue overflows? It seems like
> *something* would need to be done, somewhere, by someone?
>
> I realise that as a piece of IBM hardware this is probably an incredibly
> optimistic question, but is this behaviour documented publically anywhere?
> (As a distant second best, is it documented internally anywhere that I
> can read?)

When I worked there, it unfortunately wasn't public and there was no
future plan to make it public, but things might have changed since I
left.  Maybe it will be included in future openpower documentation...?

>
>> --- a/drivers/crypto/nx/nx-842-powernv.c
>> +++ b/drivers/crypto/nx/nx-842-powernv.c
>> @@ -442,6 +442,15 @@ static int nx842_powernv_function(const unsigned char 
>> *in, unsigned int inlen,
>>(unsigned int)ccw,
>>(unsigned int)be32_to_cpu(crb->ccw));
>>
>> + /*
>> +  * NX842 coprocessor uses 3rd bit to report queue overflow which is
>> +  * not an error, just for information to user. So, ignore this bit.
>> +  */
>> + if (ret & ICSWX_BIT3) {
>> + pr_info_ratelimited("842 coprocessor queue overflow\n");
> It doesn't look like this is done anywhere else in the file, but should
> this be prefixed with something? Something like "nx-842: Coprocessor
> queue overflow"?

it defines pr_fmt at the top of the file so it will be prefixed with
the module name.

>
> Regards,
> Daniel
>
>> + ret &= ~ICSWX_BIT3;
>> + }
>> +
>>   switch (ret) {
>>   case ICSWX_INITIATED:
>>   ret = wait_for_csb(wmem, csb);
>>
>>
>> ___
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH net-next] Driver for IBM System i/p VNIC protocol

[David Miller]

From: Thomas Falcon 
Date: Mon, 7 Dec 2015 12:50:00 -0600

> Hi. Thanks for you feedback.  Could you clarify on what constitutes
> basic operation?  I just want to be sure if we should remove the
> other module parameters or just this one in particular?

With very minute exceptions, there should be no driver modules.

If a facility does not exist for run time configuration via ethtool
or similar, extend those facilities to suit your needs.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

[Scott Wood]

On Tue, 2015-10-06 at 17:55 -0500, Scott Wood wrote:
> It needs to know this because the SMP release mechanism for Freescale
> book3e is different from when booting with normal hardware.  In theory
> we could simulate the normal spin table mechanism, but not (easily) at
> the addresses U-Boot put in the device tree -- so there'd need to be
> even more communication between the kernel and kexec to set that up.
> 
> Signed-off-by: Scott Wood 
> ---
> v2: Use a device tree property rather than setting a flag in the kernel
> image, as requested by Michael Ellerman.

ping?

Michael, can you review this?  Simon is waiting for another PPC person to
review it.

-Scott

> ---
>  kexec/arch/ppc64/Makefile   |  6 +++
>  kexec/arch/ppc64/fdt.c  | 78
> +
>  kexec/arch/ppc64/include/arch/fdt.h |  9 +
>  kexec/arch/ppc64/kexec-elf-ppc64.c  |  7 
>  4 files changed, 100 insertions(+)
>  create mode 100644 kexec/arch/ppc64/fdt.c
>  create mode 100644 kexec/arch/ppc64/include/arch/fdt.h
> 
> diff --git a/kexec/arch/ppc64/Makefile b/kexec/arch/ppc64/Makefile
> index 9a6e475..37cd233 100644
> --- a/kexec/arch/ppc64/Makefile
> +++ b/kexec/arch/ppc64/Makefile
> @@ -1,11 +1,15 @@
>  #
>  # kexec ppc64 (linux booting linux)
>  #
> +include $(srcdir)/kexec/libfdt/Makefile.libfdt
> +
>  ppc64_KEXEC_SRCS =  kexec/arch/ppc64/kexec-elf-rel-ppc64.c
>  ppc64_KEXEC_SRCS += kexec/arch/ppc64/kexec-zImage-ppc64.c
>  ppc64_KEXEC_SRCS += kexec/arch/ppc64/kexec-elf-ppc64.c
>  ppc64_KEXEC_SRCS += kexec/arch/ppc64/kexec-ppc64.c
>  ppc64_KEXEC_SRCS += kexec/arch/ppc64/crashdump-ppc64.c
> +ppc64_KEXEC_SRCS += kexec/arch/ppc64/fdt.c
> +ppc64_KEXEC_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
>  
>  ppc64_ARCH_REUSE_INITRD =
>  
> @@ -13,6 +17,8 @@ ppc64_FS2DT = kexec/fs2dt.c
>  ppc64_FS2DT_INCLUDE = -include $(srcdir)/kexec/arch/ppc64/crashdump-ppc64.h
> \
>-include $(srcdir)/kexec/arch/ppc64/kexec-ppc64.h
>  
> +ppc64_CPPFLAGS = -I$(srcdir)/kexec/libfdt
> +
>  dist += kexec/arch/ppc64/Makefile $(ppc64_KEXEC_SRCS)
> \
>   kexec/arch/ppc64/kexec-ppc64.h kexec/arch/ppc64/crashdump-ppc64.h \
>   kexec/arch/ppc64/include/arch/options.h
> diff --git a/kexec/arch/ppc64/fdt.c b/kexec/arch/ppc64/fdt.c
> new file mode 100644
> index 000..8bc6d2d
> --- /dev/null
> +++ b/kexec/arch/ppc64/fdt.c
> @@ -0,0 +1,78 @@
> +/*
> + * ppc64 fdt fixups
> + *
> + * Copyright 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation (version 2 of the License).
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Let the kernel know it booted from kexec, as some things (e.g.
> + * secondary CPU release) may work differently.
> + */
> +static int fixup_kexec_prop(void *fdt)
> +{
> + int err, nodeoffset;
> +
> + nodeoffset = fdt_subnode_offset(fdt, 0, "chosen");
> + if (nodeoffset < 0)
> + nodeoffset = fdt_add_subnode(fdt, 0, "chosen");
> + if (nodeoffset < 0) {
> + printf("%s: add /chosen %s\n", __func__,
> +fdt_strerror(nodeoffset));
> + return -1;
> + }
> +
> + err = fdt_setprop(fdt, nodeoffset, "linux,booted-from-kexec",
> +   NULL, 0);
> + if (err < 0) {
> + printf("%s: couldn't write linux,booted-from-kexec: %s\n",
> +__func__, fdt_strerror(err));
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +
> +/*
> + * For now, assume that the added content fits in the file.
> + * This should be the case when flattening from /proc/device-tree,
> + * and when passing in a dtb, dtc can be told to add padding.
> + */
> +int fixup_dt(char **fdt, off_t *size)
> +{
> + int ret;
> +
> + *size += 4096;
> + *fdt = realloc(*fdt, *size);
> + if (!*fdt) {
> + fprintf(stderr, "%s: out of memory\n", __func__);
> + return -1;
> + }
> +
> + ret = fdt_open_into(*fdt, *fdt, *size);
> + if (ret < 0) {
> + fprintf(stderr, "%s: fdt_open_into: %s\n", __func__,
> + fdt_strerror(ret));
> + return -1;
> + }
> +
> + ret = fixup_kexec_prop(*fdt);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> diff --git a/kexec/arch/ppc64/include/arch/fdt.h
> b/kexec/arch/ppc64/include/arch/fdt.h
> new file mode 100644
> index 000..14f8be2
> --- /dev/null
> +++ b/kexec/arch/ppc64/include/arch/fdt.h
> @@ -0,0 +1,9 @@
> +#ifndef 

Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs

[Steven Rostedt]

I can take this series through my tree, but I need a acked-by from a
PPC maintainer for this patch.

-- Steve


On Tue, 24 Nov 2015 21:23:39 +0300
Denis Kirjanov  wrote:

> ./drmgr -c cpu -a -r gives the following warning:
> 
> [ 2327.035563]
> RCU used illegally from offline CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> [ 2327.035564] no locks held by swapper/12/0.
> [ 2327.035565]
> stack backtrace:
> [ 2327.035567] CPU: 12 PID: 0 Comm: swapper/12 Tainted: G S
>   4.3.0-rc3-00060-g353169a #5
>   [ 2327.035568] Call Trace:
>   [ 2327.035573] [c001d62578e0] [c08977fc]
>   .dump_stack+0x98/0xd4 (unreliable)
>   [ 2327.035577] [c001d6257960] [c0109bd8]
>   .lockdep_rcu_suspicious+0x108/0x170
>   [ 2327.035580] [c001d62579f0] [c006a1d0]
>   .__trace_hcall_exit+0x2b0/0x2c0
>   [ 2327.035584] [c001d6257ab0] [c006a2e8]
>   plpar_hcall_norets_trace+0x70/0x8c
>   [ 2327.035588] [c001d6257b20] [c0067a14]
>   .icp_hv_set_cpu_priority+0x54/0xc0
>   [ 2327.035592] [c001d6257ba0] [c0066c5c]
>   .xics_teardown_cpu+0x5c/0xa0
>   [ 2327.035595] [c001d6257c20] [c00747ac]
>   .pseries_mach_cpu_die+0x6c/0x320
>   [ 2327.035598] [c001d6257cd0] [c00439cc]
>   .cpu_die+0x3c/0x60
>   [ 2327.035602] [c001d6257d40] [c00183d8]
>   .arch_cpu_idle_dead+0x28/0x40
>   [ 2327.035606] [c001d6257db0] [c00ff1dc]
>   .cpu_startup_entry+0x4fc/0x560
>   [ 2327.035610] [c001d6257ed0] [c0043728]
>   .start_secondary+0x328/0x360
>   [ 2327.035614] [c001d6257f90] [c0008a6c]
>   start_secondary_prolog+0x10/0x14
>   [ 2327.035620] cpu 12 (hwid 12) Ready to die...
>   [ 2327.144463] cpu 13 (hwid 13) Ready to die...
>   [ 2327.294180] cpu 14 (hwid 14) Ready to die...
>   [ 2327.403599] cpu 15 (hwid 15) Ready to die...
> 
>   Make the hypervisor tracepoints conditional by using
>   TRACE_EVENT_FN_COND
> 
> Signed-off-by: Denis Kirjanov 
> ---
>  arch/powerpc/include/asm/trace.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/trace.h 
> b/arch/powerpc/include/asm/trace.h
> index 8e86b48..3dc5803 100644
> --- a/arch/powerpc/include/asm/trace.h
> +++ b/arch/powerpc/include/asm/trace.h
> @@ -57,12 +57,14 @@ DEFINE_EVENT(ppc64_interrupt_class, timer_interrupt_exit,
>  extern void hcall_tracepoint_regfunc(void);
>  extern void hcall_tracepoint_unregfunc(void);
>  
> -TRACE_EVENT_FN(hcall_entry,
> +TRACE_EVENT_FN_COND(hcall_entry,
>  
>   TP_PROTO(unsigned long opcode, unsigned long *args),
>  
>   TP_ARGS(opcode, args),
>  
> + TP_CONDITION(cpu_online(smp_processor_id())),
> +
>   TP_STRUCT__entry(
>   __field(unsigned long, opcode)
>   ),
> @@ -76,13 +78,15 @@ TRACE_EVENT_FN(hcall_entry,
>   hcall_tracepoint_regfunc, hcall_tracepoint_unregfunc
>  );
>  
> -TRACE_EVENT_FN(hcall_exit,
> +TRACE_EVENT_FN_COND(hcall_exit,
>  
>   TP_PROTO(unsigned long opcode, unsigned long retval,
>   unsigned long *retbuf),
>  
>   TP_ARGS(opcode, retval, retbuf),
>  
> + TP_CONDITION(cpu_online(smp_processor_id())),
> +
>   TP_STRUCT__entry(
>   __field(unsigned long, opcode)
>   __field(unsigned long, retval)

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs

[Benjamin Herrenschmidt]

On Mon, 2015-12-07 at 15:52 -0500, Steven Rostedt wrote:
> > + TP_CONDITION(cpu_online(smp_processor_id())),
> > +

This should probably be some kind of __raw version though, hcalls can
be called in contexts where the debug stuff in smp_processor_id() isn't
safe (or preempt enabled).

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs

[Steven Rostedt]

On Tue, 08 Dec 2015 08:02:15 +1100
Benjamin Herrenschmidt  wrote:

> On Mon, 2015-12-07 at 15:52 -0500, Steven Rostedt wrote:
> > > + TP_CONDITION(cpu_online(smp_processor_id())),
> > > +  
> 
> This should probably be some kind of __raw version though, hcalls can
> be called in contexts where the debug stuff in smp_processor_id() isn't
> safe (or preempt enabled).
> 

OK, then that needs to be updated.

-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH part3 v12 00/10] Cleanup platform pci_domain_nr()

[Bjorn Helgaas]

On Mon, Jul 20, 2015 at 08:01:08PM +0800, Yijing Wang wrote:
> This series is splitted out from previous patchset
> "Refine PCI scan interfaces and make generic pci host bridge".
> It try to clean up all platform pci_domain_nr(), save domain
> in pci_host_bridge, so we could get domain number from the
> common interface. 
> 
> v11->v12:
>   Introduce wrap function pci_create_root_bus_generic()
>   and pci_create_root_bus_generic() for arm/arm64 which
>   enable CONFIG_PCI_DOMAINS_GENERIC.
>   Rebased this series based 4.2-rc1
> 
> Yijing Wang (10):
>   PCI: Save domain in pci_host_bridge
>   PCI: Move pci_bus_assign_domain_nr() declaration into
> drivers/pci/pci.h
>   PCI: Remove declaration for pci_get_new_domain_nr()
>   PCI: Introduce pci_host_assign_domain_nr() to assign domain
>   powerpc/PCI: Rename pcibios_root_bridge_prepare() to
> pcibios_root_bus_prepare()
>   PCI: Make pci_host_bridge hold sysdata in drvdata
>   PCI: Create pci host bridge prior to root bus
>   PCI: Introduce common pci_domain_nr() and remove platform specific
> code
>   PCI: Remove pci_bus_assign_domain_nr()
>   IA64/PCI: Fix build warning found by kbuild test
> 
>  arch/alpha/include/asm/pci.h |2 -
>  arch/alpha/kernel/pci.c  |4 +-
>  arch/alpha/kernel/sys_nautilus.c |2 +-
>  arch/arm/kernel/bios32.c |2 +-
>  arch/arm/mach-dove/pcie.c|2 +-
>  arch/arm/mach-iop13xx/pci.c  |4 +-
>  arch/arm/mach-mv78xx0/pcie.c |2 +-
>  arch/arm/mach-orion5x/pci.c  |4 +-
>  arch/frv/mb93090-mb00/pci-vdk.c  |3 +-
>  arch/ia64/include/asm/pci.h  |1 -
>  arch/ia64/pci/pci.c  |6 +-
>  arch/ia64/sn/kernel/io_acpi_init.c   |6 +-
>  arch/ia64/sn/kernel/io_init.c|6 +-
>  arch/m68k/coldfire/pci.c |2 +-
>  arch/microblaze/include/asm/pci.h|2 -
>  arch/microblaze/pci/pci-common.c |   15 +
>  arch/mips/include/asm/pci.h  |2 -
>  arch/mips/pci/pci.c  |4 +-
>  arch/mn10300/unit-asb2305/pci.c  |3 +-
>  arch/powerpc/include/asm/machdep.h   |2 +-
>  arch/powerpc/include/asm/pci.h   |2 -
>  arch/powerpc/kernel/pci-common.c |   21 ++-
>  arch/powerpc/platforms/pseries/pci.c |2 +-
>  arch/powerpc/platforms/pseries/pseries.h |2 +-
>  arch/powerpc/platforms/pseries/setup.c   |2 +-
>  arch/s390/include/asm/pci.h  |1 -
>  arch/s390/pci/pci.c  |   10 +---
>  arch/sh/drivers/pci/pci.c|4 +-
>  arch/sh/include/asm/pci.h|2 -
>  arch/sparc/include/asm/pci_64.h  |1 -
>  arch/sparc/kernel/leon_pci.c |2 +-
>  arch/sparc/kernel/pci.c  |   21 +--
>  arch/sparc/kernel/pcic.c |2 +-
>  arch/tile/include/asm/pci.h  |2 -
>  arch/tile/kernel/pci.c   |4 +-
>  arch/tile/kernel/pci_gx.c|4 +-
>  arch/unicore32/kernel/pci.c  |2 +-
>  arch/x86/include/asm/pci.h   |6 --
>  arch/x86/pci/acpi.c  |6 +-
>  arch/x86/pci/common.c|2 +-
>  arch/xtensa/kernel/pci.c |2 +-
>  drivers/parisc/dino.c|2 +-
>  drivers/parisc/lba_pci.c |2 +-
>  drivers/pci/host/pci-versatile.c |3 +-
>  drivers/pci/host/pci-xgene.c |2 +-
>  drivers/pci/host/pcie-designware.c   |2 +-
>  drivers/pci/host/pcie-iproc.c|2 +-
>  drivers/pci/host/pcie-xilinx.c   |2 +-
>  drivers/pci/hotplug/ibmphp_core.c|2 +-
>  drivers/pci/pci.c|   31 --
>  drivers/pci/pci.h|1 +
>  drivers/pci/probe.c  |   92 
> +-
>  drivers/pci/xen-pcifront.c   |2 +-
>  include/linux/pci.h  |   39 ++---
>  54 files changed, 161 insertions(+), 195 deletions(-)

Doesn't apply to v4.4-rc2.  Please refresh and repost if this is still
relevant.

Bjorn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powernv/opal-irqchip: Fix double endian conversion

[Michael Ellerman]

Subject should start "powerpc/", so probably "powerpc/opal-irqchip:", I can fix
it up here.

On Mon, 2015-07-12 at 00:28:28 UTC, Alistair Popple wrote:
> The OPAL event calls return a mask of events that are active in big
> endian format. This is checked when unmasking the events in the
> irqchip by comparison with a cached value. The cached value was stored
> in big endian format but should've been converted to CPU endian
> first. This bug leads to OPAL event delivery being delayed or dropped
> on some systems.
> 
> The bug is fixed by calling opal_handle_events(...) instead of
> duplicating code in opal_event_unmask(...).
> 
> Signed-off-by: Alistair Popple 
> Reported-by: Douglas L Lehr 
> Cc: sta...@vger.kernel.org

Which commit does it fix? Looks like:

Fixes: 9f0fd0499d30 ("powerpc/powernv: Add a virtual irqchip for opal events")

> diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c 
> b/arch/powerpc/platforms/powernv/opal-irqchip.c
> index 2c91ee7..a387d18 100644
> --- a/arch/powerpc/platforms/powernv/opal-irqchip.c
> +++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
> @@ -43,11 +43,34 @@ static unsigned int opal_irq_count;
>  static unsigned int *opal_irqs;
>  
>  static void opal_handle_irq_work(struct irq_work *work);
> -static __be64 last_outstanding_events;
> +static u64 last_outstanding_events;
>  static struct irq_work opal_event_irq_work = {
>   .func = opal_handle_irq_work,
>  };
>  
> +void opal_handle_events(uint64_t events)
> +{
> + int virq, hwirq = 0;
> + u64 mask = opal_event_irqchip.mask;
> +
> + if (!in_irq() && (events & mask)) {
> + last_outstanding_events = events;
> + irq_work_queue(_event_irq_work);
> + return;
> + }
> +
> + while (events & mask) {
> + hwirq = fls64(events) - 1;
> + if (BIT_ULL(hwirq) & mask) {
> + virq = irq_find_mapping(opal_event_irqchip.domain,
> + hwirq);
> + if (virq)
> + generic_handle_irq(virq);
> + }
> + events &= ~BIT_ULL(hwirq);
> + }
> +}

So this is 100% just a move of the code from down below right?

> @@ -55,12 +78,12 @@ static void opal_event_mask(struct irq_data *d)
>  
>  static void opal_event_unmask(struct irq_data *d)
>  {
> + __be64 events;
> +
>   set_bit(d->hwirq, _event_irqchip.mask);
>  
> - opal_poll_events(_outstanding_events);
> - if (last_outstanding_events & opal_event_irqchip.mask)
> - /* Need to retrigger the interrupt */
> - irq_work_queue(_event_irq_work);
> + opal_poll_events();
> + opal_handle_events(be64_to_cpu(events));
>  }
>  
>  static int opal_event_set_type(struct irq_data *d, unsigned int flow_type)
> @@ -96,29 +119,6 @@ static int opal_event_map(struct irq_domain *d, unsigned 
> int irq,
>   return 0;
>  }
>  
> -void opal_handle_events(uint64_t events)
> -{
> - int virq, hwirq = 0;
> - u64 mask = opal_event_irqchip.mask;
> -
> - if (!in_irq() && (events & mask)) {
> - last_outstanding_events = events;
> - irq_work_queue(_event_irq_work);
> - return;
> - }
> -
> - while (events & mask) {
> - hwirq = fls64(events) - 1;
> - if (BIT_ULL(hwirq) & mask) {
> - virq = irq_find_mapping(opal_event_irqchip.domain,
> - hwirq);
> - if (virq)
> - generic_handle_irq(virq);
> - }
> - events &= ~BIT_ULL(hwirq);
> - }
> -}
> -
>  static irqreturn_t opal_interrupt(int irq, void *data)
>  {
>   __be64 events;
> @@ -131,7 +131,7 @@ static irqreturn_t opal_interrupt(int irq, void *data)
>  
>  static void opal_handle_irq_work(struct irq_work *work)
>  {
> - opal_handle_events(be64_to_cpu(last_outstanding_events));
> + opal_handle_events(last_outstanding_events);
>  }
>  
>  static int opal_event_match(struct irq_domain *h, struct device_node *node,


cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] cxl: Enable PCI device ID for future IBM CXL adapter

[Ian Munsie]

Acked-by: Ian Munsie 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] cxl: Enable PCI device ID for future IBM CXL adapter

[Uma Krishnan]

Add support for future IBM Coherent Accelerator (CXL) device
with ID of 0x0601.

Signed-off-by: Uma Krishnan 
---
 drivers/misc/cxl/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 13a97f8..3171e96 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -138,6 +138,7 @@ static DEFINE_PCI_DEVICE_TABLE(cxl_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x0477), },
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x044b), },
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x04cf), },
+   { PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x0601), },
{ PCI_DEVICE_CLASS(0x12, ~0), },
 
{ }
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powernv/opal-irqchip: Fix double endian conversion

[Alistair Popple]

On Tue, 8 Dec 2015 09:10:19 Michael Ellerman wrote:
> Subject should start "powerpc/", so probably "powerpc/opal-irqchip:", I can 
> fix
> it up here.

Ok, thanks.

> On Mon, 2015-07-12 at 00:28:28 UTC, Alistair Popple wrote:
> > The OPAL event calls return a mask of events that are active in big
> > endian format. This is checked when unmasking the events in the
> > irqchip by comparison with a cached value. The cached value was stored
> > in big endian format but should've been converted to CPU endian
> > first. This bug leads to OPAL event delivery being delayed or dropped
> > on some systems.
> > 
> > The bug is fixed by calling opal_handle_events(...) instead of
> > duplicating code in opal_event_unmask(...).
> > 
> > Signed-off-by: Alistair Popple 
> > Reported-by: Douglas L Lehr 
> > Cc: sta...@vger.kernel.org
> 
> Which commit does it fix? Looks like:
> 
> Fixes: 9f0fd0499d30 ("powerpc/powernv: Add a virtual irqchip for opal events")

Yep.

> > diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c 
> > b/arch/powerpc/platforms/powernv/opal-irqchip.c
> > index 2c91ee7..a387d18 100644
> > --- a/arch/powerpc/platforms/powernv/opal-irqchip.c
> > +++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
> > @@ -43,11 +43,34 @@ static unsigned int opal_irq_count;
> >  static unsigned int *opal_irqs;
> >  
> >  static void opal_handle_irq_work(struct irq_work *work);
> > -static __be64 last_outstanding_events;
> > +static u64 last_outstanding_events;
> >  static struct irq_work opal_event_irq_work = {
> > .func = opal_handle_irq_work,
> >  };
> >  
> > +void opal_handle_events(uint64_t events)
> > +{
> > +   int virq, hwirq = 0;
> > +   u64 mask = opal_event_irqchip.mask;
> > +
> > +   if (!in_irq() && (events & mask)) {
> > +   last_outstanding_events = events;
> > +   irq_work_queue(_event_irq_work);
> > +   return;
> > +   }
> > +
> > +   while (events & mask) {
> > +   hwirq = fls64(events) - 1;
> > +   if (BIT_ULL(hwirq) & mask) {
> > +   virq = irq_find_mapping(opal_event_irqchip.domain,
> > +   hwirq);
> > +   if (virq)
> > +   generic_handle_irq(virq);
> > +   }
> > +   events &= ~BIT_ULL(hwirq);
> > +   }
> > +}
> 
> So this is 100% just a move of the code from down below right?

That is correct - it should be identical.

Thanks.

- Alistair

> > @@ -55,12 +78,12 @@ static void opal_event_mask(struct irq_data *d)
> >  
> >  static void opal_event_unmask(struct irq_data *d)
> >  {
> > +   __be64 events;
> > +
> > set_bit(d->hwirq, _event_irqchip.mask);
> >  
> > -   opal_poll_events(_outstanding_events);
> > -   if (last_outstanding_events & opal_event_irqchip.mask)
> > -   /* Need to retrigger the interrupt */
> > -   irq_work_queue(_event_irq_work);
> > +   opal_poll_events();
> > +   opal_handle_events(be64_to_cpu(events));
> >  }
> >  
> >  static int opal_event_set_type(struct irq_data *d, unsigned int flow_type)
> > @@ -96,29 +119,6 @@ static int opal_event_map(struct irq_domain *d, 
> > unsigned int irq,
> > return 0;
> >  }
> >  
> > -void opal_handle_events(uint64_t events)
> > -{
> > -   int virq, hwirq = 0;
> > -   u64 mask = opal_event_irqchip.mask;
> > -
> > -   if (!in_irq() && (events & mask)) {
> > -   last_outstanding_events = events;
> > -   irq_work_queue(_event_irq_work);
> > -   return;
> > -   }
> > -
> > -   while (events & mask) {
> > -   hwirq = fls64(events) - 1;
> > -   if (BIT_ULL(hwirq) & mask) {
> > -   virq = irq_find_mapping(opal_event_irqchip.domain,
> > -   hwirq);
> > -   if (virq)
> > -   generic_handle_irq(virq);
> > -   }
> > -   events &= ~BIT_ULL(hwirq);
> > -   }
> > -}
> > -
> >  static irqreturn_t opal_interrupt(int irq, void *data)
> >  {
> > __be64 events;
> > @@ -131,7 +131,7 @@ static irqreturn_t opal_interrupt(int irq, void *data)
> >  
> >  static void opal_handle_irq_work(struct irq_work *work)
> >  {
> > -   opal_handle_events(be64_to_cpu(last_outstanding_events));
> > +   opal_handle_events(last_outstanding_events);
> >  }
> >  
> >  static int opal_event_match(struct irq_domain *h, struct device_node *node,
> 
> 
> cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] cxl: Enable PCI device ID for future IBM CXL adapter

[Matthew R. Ochs]

Reviewed-by: Matthew R. Ochs 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH net-next] Driver for IBM System i/p VNIC protocol

[Thomas Falcon]

On 12/05/2015 09:25 PM, David Miller wrote:
> From: Thomas Falcon 
> Date: Fri,  4 Dec 2015 11:49:46 -0600
>
>> +static int ibmvnic_buffs_per_pool = IBMVNIC_BUFFS_PER_POOL;
>> +module_param(ibmvnic_buffs_per_pool, int, S_IRUGO);
>> +MODULE_PARM_DESC(ibmvnic_buffs_per_pool,
>> + "IBMVNIC number of buffers per rx pool");
> Please do not use module parameters for settings that effect
> the basic operation of the driver.

Hi. Thanks for you feedback.  Could you clarify on what constitutes basic 
operation?  I just want to be sure if we should remove the other module 
parameters or just this one in particular?

>
> Instead use facilities that are generic and provide the same
> user interface for all networking drivers, such as ethtool.

Is it possible to change driver settings like this with ethtool? Would adding 
an interface in sysfs to change this setting be acceptable?

>
> Otherwise users would need to learn a different way to configure the
> same thing on different devices, which is not acceptable.
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] cxl: Set endianess of kernel contexts

[Michael Neuling]

On Mon, 2015-12-07 at 14:34 +0100, Frederic Barrat wrote:
> A process element (defined in CAIA) keeps track of the endianess of
> contexts through the Little Endian (LE) bit of the State Register. It
> is currently set for user contexts, but was somehow forgotten for
> kernel contexts, so this patch fixes it.
> It could lead to erratic behavior from an AFU when the context is
> attached through the kernel API.
> 
> Signed-off-by: Frederic Barrat 
> Suggested-by: Michael Neuling 
> Cc:  # 4.3+
> ---
> cxl kernel API is supported starting with 4.3 (for cxlflash)

The cxlflash's AFU doesn't use this bit, so the stable@ marker here is
probably not strictly needed.

Mikey


>  drivers/misc/cxl/native.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
> index d2e75c8..f409097 100644
> --- a/drivers/misc/cxl/native.c
> +++ b/drivers/misc/cxl/native.c
> @@ -497,6 +497,7 @@ static u64 calculate_sr(struct cxl_context *ctx)
>  {
>   u64 sr = 0;
>  
> + set_endian(sr);
>   if (ctx->master)
>   sr |= CXL_PSL_SR_An_MP;
>   if (mfspr(SPRN_LPCR) & LPCR_TC)
> @@ -506,7 +507,6 @@ static u64 calculate_sr(struct cxl_context *ctx)
>   sr |= CXL_PSL_SR_An_HV;
>   } else {
>   sr |= CXL_PSL_SR_An_PR | CXL_PSL_SR_An_R;
> - set_endian(sr);
>   sr &= ~(CXL_PSL_SR_An_HV);
>   if (!test_tsk_thread_flag(current, TIF_32BIT))
>   sr |= CXL_PSL_SR_An_SF;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: warn on spurious irq events (but ratelimited)

[Paul Gortmaker]

It might be worth warning on spurious IRQ events; they might
point someone at a bogus DTS value or similar.

But ratelimit them to ensure we aren't too spammy about it.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker 
---
 arch/powerpc/kernel/irq.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 290559df1e8b..5c777e3a4c04 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -497,10 +497,12 @@ void __do_irq(struct pt_regs *regs)
may_hard_irq_enable();
 
/* And finally process it */
-   if (unlikely(irq == NO_IRQ))
+   if (unlikely(irq == NO_IRQ)) {
+   printk_ratelimited(KERN_WARNING "spurious irq on %d\n", irq);
__this_cpu_inc(irq_stat.spurious_irqs);
-   else
+   } else {
generic_handle_irq(irq);
+   }
 
trace_irq_exit(regs);
 
-- 
2.6.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

[Michael Ellerman]

On Mon, 2015-12-07 at 14:42 -0600, Scott Wood wrote:
> On Tue, 2015-10-06 at 17:55 -0500, Scott Wood wrote:
> > It needs to know this because the SMP release mechanism for Freescale
> > book3e is different from when booting with normal hardware.  In theory
> > we could simulate the normal spin table mechanism, but not (easily) at
> > the addresses U-Boot put in the device tree -- so there'd need to be
> > even more communication between the kernel and kexec to set that up.
> > 
> > Signed-off-by: Scott Wood 
> > ---
> > v2: Use a device tree property rather than setting a flag in the kernel
> > image, as requested by Michael Ellerman.
> 
> ping?
> 
> Michael, can you review this?  Simon is waiting for another PPC person to
> review it.

Oh sorry I thought it'd been merged already, but I see now only 1 & 2 went in.

Horms this looks fine to me:

Acked-by: Michael Ellerman 

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH part3 v12 00/10] Cleanup platform pci_domain_nr()

[wangyijing]

> 
> Doesn't apply to v4.4-rc2.  Please refresh and repost if this is still
> relevant.

Hi Bjorn, this is still relevant, I will refresh it and post the new version 
soon.

Thanks!
Yijing.


> 
> .
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev