Re: [v6,2/2] QE: remove PPCisms for QE

2016-09-24 Thread Scott Wood 
On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote:
> On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote:
> > QE was supported on PowerPC, and dependent on PPC,
> > Now it is supported on other platforms. so remove PPCisms.
> > 
> > Signed-off-by: Zhao Qiang 
> > ---
> > Changes for v2:
> > - na
> > Changes for v3:
> > - add NO_IRQ
> > Changes for v4:
> > - modify spin_event_timeout to opencoded timeout loop
> > - remove NO_IRQ
> > - modify virq_to_hw to opencoed code
> > Changes for v5:
> > - modify commit msg
> > - modify depends of QUICC_ENGINE
> > - add kerneldoc header for qe_issue_cmd
> > Changes for v6:
> > - add dependency on FSL_SOC and PPC32 for drivers
> >   depending on QUICC_ENGING but not available on ARM
> > 
> >  drivers/irqchip/qe_ic.c| 28 +++-
> >  drivers/net/ethernet/freescale/Kconfig | 10 ++---
> >  drivers/soc/fsl/qe/Kconfig |  2 +-
> >  drivers/soc/fsl/qe/qe.c| 80 
> > --
> >  drivers/soc/fsl/qe/qe_io.c | 42 --
> >  drivers/soc/fsl/qe/qe_tdm.c|  8 ++--
> >  drivers/soc/fsl/qe/ucc.c   | 10 ++---
> >  drivers/soc/fsl/qe/ucc_fast.c  | 68 ++---
> >  drivers/tty/serial/Kconfig |  2 +-
> >  drivers/usb/gadget/udc/Kconfig |  2 +-
> >  drivers/usb/host/Kconfig   |  2 +-
> >  include/soc/fsl/qe/qe.h|  1 -
> >  include/soc/fsl/qe/qe_ic.h | 12 ++---
> >  13 files changed, 141 insertions(+), 126 deletions(-)
> 
> I assume this means you'll be updating
> http://patchwork.ozlabs.org/patch/654473/
> to be based on top of this...

Apparently that assumption was wrong, since I now see that you're
patching drivers/irqchip/qe_ic.c rather than drivers/soc/fsl/qe/qe_ic.c. 
Please keep the drivers/irqchip stuff separate and send to the
appropriate maintainers.

-Scott

Re: [v6,2/2] QE: remove PPCisms for QE

2016-09-24 Thread Scott Wood 
On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote:
> QE was supported on PowerPC, and dependent on PPC,
> Now it is supported on other platforms. so remove PPCisms.
> 
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v2:
>   - na
> Changes for v3:
>   - add NO_IRQ
> Changes for v4:
>   - modify spin_event_timeout to opencoded timeout loop
>   - remove NO_IRQ
>   - modify virq_to_hw to opencoed code
> Changes for v5:
>   - modify commit msg
>   - modify depends of QUICC_ENGINE
>   - add kerneldoc header for qe_issue_cmd
> Changes for v6:
>   - add dependency on FSL_SOC and PPC32 for drivers
> depending on QUICC_ENGING but not available on ARM
> 
>  drivers/irqchip/qe_ic.c| 28 +++-
>  drivers/net/ethernet/freescale/Kconfig | 10 ++---
>  drivers/soc/fsl/qe/Kconfig |  2 +-
>  drivers/soc/fsl/qe/qe.c| 80 
> --
>  drivers/soc/fsl/qe/qe_io.c | 42 --
>  drivers/soc/fsl/qe/qe_tdm.c|  8 ++--
>  drivers/soc/fsl/qe/ucc.c   | 10 ++---
>  drivers/soc/fsl/qe/ucc_fast.c  | 68 ++---
>  drivers/tty/serial/Kconfig |  2 +-
>  drivers/usb/gadget/udc/Kconfig |  2 +-
>  drivers/usb/host/Kconfig   |  2 +-
>  include/soc/fsl/qe/qe.h|  1 -
>  include/soc/fsl/qe/qe_ic.h | 12 ++---
>  13 files changed, 141 insertions(+), 126 deletions(-)

I assume this means you'll be updating
http://patchwork.ozlabs.org/patch/654473/
to be based on top of this...

-Scott

Re: powernv/pci: Fix m64 checks for SR-IOV and window alignment

2016-09-24 Thread Michael Ellerman 
On Wed, 2016-14-09 at 06:37:17 UTC, Russell Currey wrote:
> Commit 5958d19a143e checks for prefetchable m64 BARs by comparing the
> addresses instead of using resource flags.  This broke SR-IOV as the m64
> check in pnv_pci_ioda_fixup_iov_resources() fails.
> 
> The condition in pnv_pci_window_alignment() also changed to checking
> only IORESOURCE_MEM_64 instead of both IORESOURCE_MEM_64 and
> IORESOURCE_PREFETCH.
> 
> Revert these cases to the previous behaviour, adding a new helper function
> to do so.  This is named pnv_pci_is_m64_flags() to make it clear this
> function is only looking at resource flags and should not be relied on for
> non-SRIOV resources.
> 
> Fixes: 5958d19a143e ("Fix incorrect PE reservation attempt on some 64-bit 
> BARs")
> Reported-by: Alexey Kardashevskiy 
> Signed-off-by: Russell Currey 
> Tested-by: Alexey Kardashevskiy 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/b79331a5eb9f96e4dfd2169745

cheers

[GIT PULL] Please pull powerpc/linux.git powerpc-4.8-7 tag

2016-09-24 Thread Michael Ellerman 
Hi Linus,

Please pull one more powerpc fix for 4.8:

The following changes since commit ed7d9a1d7da6fe7b1c7477dc70e95051583fd60c:

  powerpc/powernv/pci: Fix missed TCE invalidations that should fallback to 
OPAL (2016-09-15 17:05:11 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.8-7

for you to fetch changes up to b79331a5eb9f96e4dfd216974581168ec4c8a4d4:

  powerpc/powernv/pci: Fix m64 checks for SR-IOV and window alignment 
(2016-09-21 14:04:13 +1000)


powerpc fixes for 4.8 #7

 - powernv/pci: Fix m64 checks for SR-IOV and window alignment from Russell 
Currey


Russell Currey (1):
  powerpc/powernv/pci: Fix m64 checks for SR-IOV and window alignment

 arch/powerpc/platforms/powernv/pci-ioda.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)


signature.asc
Description: PGP signature

Re: powerpc/32: Remove CLR_TOP32

2016-09-24 Thread Michael Ellerman 
On Fri, 2016-05-08 at 11:27:59 UTC, Christophe Leroy wrote:
> CLR_TOP32() is defined as blank. Last useful instance of CLR_TOP32()
> was removed by commit 40ef8cbc6d360 ("powerpc: Get 64-bit configs to
> compile with ARCH=powerpc")
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/148151a66a74bf43c6acc932a3

cheers

Re: powerpc: Remove all usages of NO_IRQ

2016-09-24 Thread Michael Ellerman 
On Tue, 2016-06-09 at 11:53:24 UTC, Michael Ellerman wrote:
> NO_IRQ has been == 0 on powerpc for just over ten years (since commit
> 0ebfff1491ef ("[POWERPC] Add new interrupt mapping core and change
> platforms to use it")). It's also 0 on most other arches.
> 
> Although it's fairly harmless, every now and then it causes confusion
> when a driver is built on powerpc and another arch which doesn't define
> NO_IRQ. There's at least 6 definitions of NO_IRQ in drivers/, at least
> some of which are to work around that problem.
> 
> So we'd like to remove it. This is fairly trivial in the arch code, we
> just convert:
> 
> if (irq == NO_IRQ)to  if (!irq)
> if (irq != NO_IRQ)to  if (irq)
> irq = NO_IRQ; to  irq = 0;
> return NO_IRQ;to  return 0;
> 
> And a few other odd cases as well.
> 
> At least for now we need to continue to #define NO_IRQ, because there is
> driver code that builds on powerpc and may build on arm (and possibly
> other arches), where NO_IRQ is *not* == 0. Hopefully they can be fixed
> in the medium term and we can drop the definition entirely.
> 
> Note we also change some occurrences in PPC sound drivers, drivers/ps3,
> and drivers/macintosh.
> 
> Signed-off-by: Michael Ellerman 

Applied to powerpc next.

https://git.kernel.org/powerpc/c/ef24ba7091517d2bbf9ba2cb42

cheers

Re: [v2] powerpc: fix usage of _PAGE_RO in hugepage

2016-09-24 Thread Michael Ellerman 
On Mon, 2016-19-09 at 10:58:54 UTC, Christophe Leroy wrote:
> On some CPUs like the 8xx, _PAGE_RW hence _PAGE_WRITE is defined
> as 0 and _PAGE_RO has to be set when a page is not writable
> 
> _PAGE_RO is defined by default in pte-common.h, however BOOK3S/64
> doesn't include that file so _PAGE_RO has to be defined explicitly
> in book3s/64/pgtable.h
> 
> fixes: a7b9f671f2d14 ("powerpc32: adds handling of _PAGE_RO")
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Aneesh Kumar K.V 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/6b8cb66a6a7cc182b47da6a0a1

cheers

Re: [v2] powerpc: Clean up tm_abort duplication in hash_utils_64.c

2016-09-24 Thread Michael Ellerman 
On Fri, 2016-02-09 at 06:17:26 UTC, Rui Teng wrote:
> The same logic appears twice and should probably be pulled out into a 
> function.
> 
> Suggested-by: Michael Ellerman 
> Signed-off-by: Rui Teng 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/f1a55ce0544251746d9b52fb85

cheers

Re: [v3] powernv/pci: Add PHB register dump debugfs handle

2016-09-24 Thread Michael Ellerman 
On Thu, 2016-28-07 at 05:05:03 UTC, Russell Currey wrote:
> On EEH events the kernel will print a dump of relevant registers.
> If EEH is unavailable (i.e. CONFIG_EEH is disabled, a new platform
> doesn't have EEH support, etc) this information isn't readily available.
> 
> Add a new debugfs handler to trigger a PHB register dump, so that this
> information can be made available on demand.
> 
> Signed-off-by: Russell Currey 
> Reviewed-by: Gavin Shan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/98b665da5751b10f3f5f3ce3ba

cheers

Re: [V3] powerpc/mm: Add radix flush all with IS=3

2016-09-24 Thread Michael Ellerman 
On Tue, 2016-23-08 at 10:57:48 UTC, "Aneesh Kumar K.V" wrote:
> Signed-off-by: Aneesh Kumar K.V 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/be34d300597a7a4fb38c6e3f99

cheers

Re: [2/8] powerpc/pseries: syscall remove trampoline

2016-09-24 Thread Michael Ellerman 
On Tue, 2016-13-09 at 03:08:40 UTC, Nicholas Piggin wrote:
> The syscall trampoline is not required, remove it.
>
> Signed-off-by: Nicholas Piggin 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a24553dd02dc6c7d2912af0b4b

I rewrote the change log to be:

powerpc/pseries: Remove unnecessary syscall trampoline

When we originally added the ability to split the exception vectors from
the kernel (commit 1f6a93e4c35e ("powerpc: Make it possible to move the
interrupt handlers away from the kernel" 2008-09-15)), the LOAD_HANDLER() 
macro
used an addi instruction to compute the offset of the common handler
from the kernel base address.

Using addi meant the handler had to be within 32K of the kernel base
address, due to the addi instruction taking a signed immediate value.
That necessitated creating a trampoline for the system call handler,
because system_call_common (in entry64.S) is not linked within 32K of
the kernel base address.

Later in commit 61e2390ede3c ("powerpc: Make load_hander handle upto 64k
offset" 2012-11-15) we changed LOAD_HANDLER to take a 64K offset, by
changing it to use ori.

Although system_call_common is not in head_64.S or exceptions-64s.S, it
is included in head-y, which causes it to be linked early in the kernel
text, so in practice it ends up below 64K. Additionally if it can't be
placed below 64K the linker will fail to build with a "relocation
truncated to fit" error.

So remove the trampoline.

Newer toolchains are able to work out that the ori in LOAD_HANDLER only
takes a 16 bit offset, and so they generate a 16 bit relocation. Older
toolchains (binutils 2.22 at least) are not so smart, so we have to add
the @l annotation to tell the assembler to generate a 16 bit relocation.

cheers

Re: [1/8] powerpc/pseries: hypervisor facility unavailable use correct handler

2016-09-24 Thread Michael Ellerman 
On Tue, 2016-13-09 at 03:08:39 UTC, Nicholas Piggin wrote:
> The 0xf80 hv_facility_unavailable trampoline branches to the 0xf60
> handler. This works because they both do the same thing, but it should
> be fixed.
> 
> Signed-off-by: Nicholas Piggin 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/40e1b1cfb529891307b21f6e33

cheers

Re: [V2, 1/5] powerpc/64/kexec: NULL check "clear_all" in kexec_sequence

2016-09-24 Thread Michael Ellerman 
On Fri, 2016-19-08 at 08:52:35 UTC, "Aneesh Kumar K.V" wrote:
> From: Benjamin Herrenschmidt 
> 
> With Radix, it can be NULL even on !BOOKE these days so replace
> the ifdef with a NULL check which is cleaner anyway.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> Signed-off-by: Aneesh Kumar K.V 
> Acked-by: Balbir Singh 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/fc48bad53142c991a5280940fd

cheers

Re: [1/3] powerpc/eeh: Null check uses of eeh_pe_bus_get

2016-09-24 Thread Michael Ellerman 
On Mon, 2016-12-09 at 04:17:22 UTC, Russell Currey wrote:
> eeh_pe_bus_get() can return NULL if a PCI bus isn't found for a given PE.
> Some callers don't check this, and can cause a null pointer dereference
> under certain circumstances.
> 
> Fix this by checking NULL everywhere eeh_pe_bus_get() is called.
> 
> Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
> Cc: sta...@vger.kernel.org # v3.11+
> Signed-off-by: Russell Currey 
> Reviewed-by: Andrew Donnellan 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/04fec21c06e35b169a83e75a84

cheers

Re: [RFC,1/3] powerpc/powernv: fix comment style and spelling

2016-09-24 Thread Michael Ellerman 
On Fri, 2016-16-09 at 10:39:44 UTC, Andrew Donnellan wrote:
> Signed-off-by: Andrew Donnellan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/6060e9ea8d2b69fff8fc70ed6a

cheers

Re: [RFC] fs: add userspace critical mounts event support

2016-09-24 Thread Dmitry Torokhov 
On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc  wrote:
> On 03/09/2016 11:10, Dmitry Torokhov wrote:
>> I was thinking if we kernel could post
>> "conditions" (maybe simple stings) that it waits for, and userspace
>> could unlock these "conditions". One of them might be "firmware
>> available".
>
> On idea offered by Josh Triplett that seems to overlap with this one
> is to have something similar to the (deprecated) userhelper with
> *per-blob* requests and notifications except for one major difference:
> userspace would not anymore be in charge of *providing* the blob but
> would instead only *signal* when a given blob becomes available and is
> either found or found missing. Then the kernel loads the blob _by
> itself_; unlike the userhelper. No new “critical filesystem” concept
> and a *per-blob basis*, allowing any variation of blob locations
> across any number of initramfs and filesystems.
>

Really, I do not quite understand why people have issues with usermode
helper/uevents. It used to work reasonably well (if you were using
request_firmware_nowait()), as the kernel would post the request and
then, when userspace was ready[^Hier], uevents would be processed and
firmware would be loaded. We had a timeout of 60(?) seconds by
default, but that would be adjusted as systems needed.

Unfortunately it all broke when udev started insisting [1] on
servicing some uevents in strict sequence, which resulted in boot
stalls. Maybe the ultimate answer is to write a firmware loading
daemon that would also listen to netlink events and do properly what
udev refused to be doing? The distribution would know when it is ready
to service firmware requests (and thus when to start this daemon), and
we would have the freedom of having drivers both built-in and as
modules and bulding firmware into kernel, intiramfs or keep on a
"real" fs available at later time.

Thanks.

-- 
Dmitry

[1] https://lwn.net/Articles/518942/

Re: [PATCH 2/3] bpf powerpc: implement support for tail calls

2016-09-24 Thread Alexei Starovoitov 
On Sat, Sep 24, 2016 at 12:33:54AM +0200, Daniel Borkmann wrote:
> On 09/23/2016 10:35 PM, Naveen N. Rao wrote:
> >Tail calls allow JIT'ed eBPF programs to call into other JIT'ed eBPF
> >programs. This can be achieved either by:
> >(1) retaining the stack setup by the first eBPF program and having all
> >subsequent eBPF programs re-using it, or,
> >(2) by unwinding/tearing down the stack and having each eBPF program
> >deal with its own stack as it sees fit.
> >
> >To ensure that this does not create loops, there is a limit to how many
> >tail calls can be done (currently 32). This requires the JIT'ed code to
> >maintain a count of the number of tail calls done so far.
> >
> >Approach (1) is simple, but requires every eBPF program to have (almost)
> >the same prologue/epilogue, regardless of whether they need it. This is
> >inefficient for small eBPF programs which may not sometimes need a
> >prologue at all. As such, to minimize impact of tail call
> >implementation, we use approach (2) here which needs each eBPF program
> >in the chain to use its own prologue/epilogue. This is not ideal when
> >many tail calls are involved and when all the eBPF programs in the chain
> >have similar prologue/epilogue. However, the impact is restricted to
> >programs that do tail calls. Individual eBPF programs are not affected.
> >
> >We maintain the tail call count in a fixed location on the stack and
> >updated tail call count values are passed in through this. The very
> >first eBPF program in a chain sets this up to 0 (the first 2
> >instructions). Subsequent tail calls skip the first two eBPF JIT
> >instructions to maintain the count. For programs that don't do tail
> >calls themselves, the first two instructions are NOPs.
> >
> >Signed-off-by: Naveen N. Rao 
> 
> Thanks for adding support, Naveen, that's really great! I think 2) seems
> fine as well in this context as prologue size can vary quite a bit here,
> and depending on program types likelihood of tail call usage as well (but
> I wouldn't expect deep nesting). Thanks a lot!

Great stuff. In this circumstances approach 2 makes sense to me as well.

Re: [PATCH 2/2] bpf samples: update tracex5 sample to use __seccomp_filter

2016-09-24 Thread Alexei Starovoitov 
On Sat, Sep 24, 2016 at 02:10:05AM +0530, Naveen N. Rao wrote:
> seccomp_phase1() does not exist anymore. Instead, update sample to use
> __seccomp_filter(). While at it, set max locked memory to unlimited.
> 
> Signed-off-by: Naveen N. Rao 

Acked-by: Alexei Starovoitov

Re: [PATCH 1/2] bpf samples: fix compiler errors with sockex2 and sockex3

2016-09-24 Thread Alexei Starovoitov 
On Sat, Sep 24, 2016 at 02:10:04AM +0530, Naveen N. Rao wrote:
> These samples fail to compile as 'struct flow_keys' conflicts with
> definition in net/flow_dissector.h. Fix the same by renaming the
> structure used in the sample.
> 
> Signed-off-by: Naveen N. Rao 

Thanks for the fix.
Acked-by: Alexei Starovoitov

[PATCH] fsl/qe: Use resource_size

2016-09-24 Thread Vaishali Thakkar 
Use the function resource_size instead of explicit computation.

Problem found using Coccinelle.

Signed-off-by: Vaishali Thakkar 
---
 drivers/soc/fsl/qe/qe_tdm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/fsl/qe/qe_tdm.c b/drivers/soc/fsl/qe/qe_tdm.c
index 5e48b14..124e222 100644
--- a/drivers/soc/fsl/qe/qe_tdm.c
+++ b/drivers/soc/fsl/qe/qe_tdm.c
@@ -167,7 +167,7 @@ int ucc_of_parse_tdm(struct device_node *np, struct ucc_tdm 
*utdm,
}
 
if (siram_init_flag == 0) {
-   memset_io(utdm->siram, 0,  res->end - res->start + 1);
+   memset_io(utdm->siram, 0,  resource_size(res));
siram_init_flag = 1;
}
 
-- 
2.1.4