Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

On Thu, Jan 14, 2016 at 04:23:59PM +0800, shh@gmail.com wrote: > From: Shaohui Xie > > This commit adds necessary definitions for the PHY layer to recognize > backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces, > "1000base-kx" for 1000BASE-KX,

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote: > On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: > > On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > > > > > >>I ask HW team about it but I have a

[PATCH 2/3] [v2] powerpc: fsl: update fman dt binding for PCS PHY

From: Shaohui Xie PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs to change corresponding serdes lane settings, so a reference is needed for serdes lane. This patch describes properties needed for PCS PHY to support backplane. Signed-off-by:

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > And all that is out-of-topic here in my mind. I just want to be sure that > this patchset still provides a use of a specific lightweight SYNCs on MIPS > vs bold and heavy generalized "SYNC 0" in any case. > > - Leonid. Of course

RE: cxl: Fix DSI misses when the context owning task exits

From: Vaibhav Jain > Sent: 14 January 2016 07:51 > David Laight writes: > > > I don't even claim to understand the linux model for handling process > > address maps, nor what the cxl driver is doing, but the above looks > > more than dodgy. > > > > David > > Thanks

[PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

From: Shaohui Xie This commit adds necessary definitions for the PHY layer to recognize backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces, "1000base-kx" for 1000BASE-KX, "10gbase-kr" for 10GBASE-KR. Signed-off-by: Shaohui Xie

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: > On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > > > >>I ask HW team about it but I have a question - has it any relationship with > >>replacing MIPS SYNC with

Re: [PATCH 2/2] powerpc/perf: Export Power8 generic and cache events to sysfs

On Tuesday 12 January 2016 04:25 AM, Sukadev Bhattiprolu wrote: > Power8 supports a large number of events in each susbystem so when a > user runs: > > perf stat -e branch-instructions sleep 1 > perf stat -e L1-dcache-loads sleep 1 > > it is not clear as to which PMU events were

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > On 01/13/2016 02:45 AM, Will Deacon wrote: > >> > >I don't think the address dependency is enough on its own. By that > >reasoning, the following variant (WRC+addr+addr) would work too: > > > > > >P0: > >Wx = 1 > > > >P1: > >Rx ==

Re: Pull request: scottwood/linux.git next

On Mon, 2016-01-04 at 15:38 -0600, Scott Wood wrote: > Highlights include moving QE code out of arch/powerpc (to be shared with > arm), device tree updates, and minor fixes. > > Sorry for sending this in so late and not getting to everything in my > queue -- in addition to the holidays I've been

RE: [PATCH 2/3] [v2] powerpc: fsl: update fman dt binding for PCS PHY

> > + - fsl-lane-handle: phandle, specifies a reference to a node representing > > a > Serdes. > > + - fsl-lane-reg: offset and length of the register set for the serdes > > lane. > > These should be fsl,... not fsl-... Will fix it. Thank you! Shaohui

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > >>> > >>>The WRC+addr+addr is OK because data dependencies are not required to be > >>>transitive, in other words, they are

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 02:24 PM, Paul E. McKenney wrote: Actually, the Linux kernel doesn't have an acquire barrier, just an smp_load_acquire(). Or did someone sneak one in while I wasn't looking? That was an exactly starting point for this discussion. This patch just pulls out from MIPS files

Re: [PATCH V2] powerpc/powernv: Remove support for p5ioc2

Russell Currey writes: > "p5ioc2 is used by approximately 2 machines in the world, and has never > ever been a supported configuration." > > The code for p5ioc2 is essentially unused and complicates what is already > a very complicated codebase. Its removal is essentially a

Re: [PATCH 2/3] [v2] powerpc: fsl: update fman dt binding for PCS PHY

On Thu, Jan 14, 2016 at 04:27:18PM +0800, shh@gmail.com wrote: > From: Shaohui Xie > > PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs > to change corresponding serdes lane settings, so a reference is needed > for serdes lane. This patch

RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Friday, January 15, 2016 12:44 AM > To: shh@gmail.com > Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; f.faine...@gmail.com; da...@davemloft.net; Shaohui Xie > Subject:

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:45:44PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 01:34 PM, Paul E. McKenney wrote: > >On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: > >>On 01/14/2016 12:15 PM, Peter Zijlstra wrote: > >>>On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 02:55 PM, Paul E. McKenney wrote: OK, so it looks like Will was asking not about WRC+addr+addr, but instead about WRC+sync+addr. (He actually asked twice about this and that too but skip this) I am guessing that the manual's "Older instructions which must be globally performed

Re: [RFC PATCH V1 03/33] powerpc/mm: Switch book3s 64 with 64K page size to 4 level page table

On 12/01/16 18:15, Aneesh Kumar K.V wrote: > This is needed so that we can support both hash and radix page table > using single kernel. Radix kernel uses a 4 level table. > > Signed-off-by: Aneesh Kumar K.V > --- > arch/powerpc/Kconfig

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

On Thu, 2016-01-14 at 17:59 -0200, Guilherme G. Piccoli wrote: > On 01/13/2016 07:25 PM, Michael Ellerman wrote: > > But for example what happens if the user boots with eeh=off on the command > > line, and then hotplugs a device. It looks like because you're not using > > eeh_enabled() you will

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 02:55 PM, Paul E. McKenney wrote: > >OK, so it looks like Will was asking not about WRC+addr+addr, but instead > >about WRC+sync+addr. > (He actually asked twice about this and that too but skip this) Fair enough!

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 08:16 AM, Paul E. McKenney wrote: On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote: On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: On 01/13/2016 12:48 PM, Peter Zijlstra wrote: On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: I ask

[PATCH V2 1/8] selftests/powerpc: Test the preservation of FPU and VMX regs across syscall

Test that the non volatile floating point and Altivec registers get correctly preserved across the fork() syscall. fork() works nicely for this purpose, the registers should be the same for both parent and child Signed-off-by: Cyril Bur ---

[PATCH V2 5/8] powerpc: Restore FPU/VEC/VSX if previously used

Currently the FPU, VEC and VSX facilities are lazily loaded. This is not a problem unless a process is using these facilities. Modern versions of GCC are very good at automatically vectorising code, new and modernised workloads make use of floating point and vector facilities, even the kernel

[PATCH V2 6/8] powerpc: Add the ability to save FPU without giving it up

This patch adds the ability to be able to save the FPU registers to the thread struct without giving up (disabling the facility) next time the process returns to userspace. This patch optimises the thread copy path (as a result of a fork() or clone()) so that the parent thread can return to

Re: [PATCH V2 8/8] powerpc: Add the ability to save VSX without giving it up

On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote: > This patch adds the ability to be able to save the VSX registers to > the > thread struct without giving up (disabling the facility) next time > the > process returns to userspace. > > This patch builds on a previous optimisation for the FPU

[PATCH V2 0/8] FP/VEC/VSX switching optimisations

Cover-letter for V1 of the series is at https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-November/136350.html Version one of this series used a cmpb instruction in handcrafted assembly which it turns out is not supported on older power machines. Michael suggested replacing it with crandc,

[PATCH V2 4/8] powerpc: Explicitly disable math features when copying thread

With threads leaving the math bits enabled in their saved MSR to indicate that the hardware is hot and a restore is not needed, children need to turn it off as when they do get scheduled, there's no way their registers could have been hot. Signed-off-by: Cyril Bur ---

[PATCH V2 8/8] powerpc: Add the ability to save VSX without giving it up

This patch adds the ability to be able to save the VSX registers to the thread struct without giving up (disabling the facility) next time the process returns to userspace. This patch builds on a previous optimisation for the FPU and VEC registers in the thread copy path to avoid a possibly

[PATCH V2 7/8] powerpc: Add the ability to save Altivec without giving it up

This patch adds the ability to be able to save the VEC registers to the thread struct without giving up (disabling the facility) next time the process returns to userspace. This patch builds on a previous optimisation for the FPU registers in the thread copy path to avoid a possibly pointless

Re: [PATCH V2 4/8] powerpc: Explicitly disable math features when copying thread

On Fri, 2016-01-15 at 16:54 +1100, Cyril Bur wrote: > On Fri, 15 Jan 2016 16:42:22 +1100 > Michael Neuling wrote: > > > On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote: > > > With threads leaving the math bits enabled in their saved MSR to > > > indicate > > > that the

[PATCH V2 3/8] selftests/powerpc: Test FPU and VMX regs in signal ucontext

Load up the non volatile FPU and VMX regs and ensure that they are the expected value in a signal handler Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/math/.gitignore | 2 + tools/testing/selftests/powerpc/math/Makefile | 4 +-

[PATCH V2 2/8] selftests/powerpc: Test preservation of FPU and VMX regs across preemption

Loop in assembly checking the registers with many threads. Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/math/.gitignore| 2 + tools/testing/selftests/powerpc/math/Makefile | 5 +- tools/testing/selftests/powerpc/math/fpu_asm.S | 34 +++

Re: [V3] powerpc/powernv: Add a kmsg_dumper that flushes console output on panic

Michael Ellerman writes: >> > > Applied to powerpc next, thanks. >> > > >> > > https://git.kernel.org/powerpc/c/affddff69c55eb68969448f35f >> > >> > The firmware interface changed slightly since this kernel patch[1], it >> > added a parameter to OPAL_CONSOLE_FLUSH which

Re: [PATCH V2 4/8] powerpc: Explicitly disable math features when copying thread

On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote: > With threads leaving the math bits enabled in their saved MSR to indicate > that the hardware is hot and a restore is not needed, children need to turn > it off as when they do get scheduled, there's no way their registers could > have been

Re: [PATCH V2 4/8] powerpc: Explicitly disable math features when copying thread

On Fri, 15 Jan 2016 16:42:22 +1100 Michael Neuling wrote: > On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote: > > With threads leaving the math bits enabled in their saved MSR to indicate > > that the hardware is hot and a restore is not needed, children need to turn > > it

Re: [PATCH V2 5/8] powerpc: Restore FPU/VEC/VSX if previously used

> Currently the FPU, VEC and VSX facilities are lazily loaded. This is not a > problem unless a process is using these facilities. > Modern versions of GCC are very good at automatically vectorising code, new > and modernised workloads make use of floating point and vector facilities, > even the

Re: [PATCH V2 6/8] powerpc: Add the ability to save FPU without giving it up

On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote: > This patch adds the ability to be able to save the FPU registers to > the > thread struct without giving up (disabling the facility) next time > the > process returns to userspace. > > This patch optimises the thread copy path (as a result of

[RFC PATCH v3 0/5] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table on PPC64 platform

Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because sub-page BARs' mmio page may be shared with other BARs and MSI-X table should not be accessed directly from the guest for security reasons. But these will easily cause some

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > Yes. > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > >smp_read_barrier_depends(), but

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 04:47 PM, Paul E. McKenney wrote: On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote: Don't be fooled here by words "ordered" and "completed" - it is HW design items and actually written poorly. Just assume that SYNC_MB is absolutely the same as SYNC for any CPU and

[RFC PATCH v3 1/5] PCI: Add support for enforcing all MMIO BARs to be page aligned

When vfio passthrough a PCI device of which MMIO BARs are smaller than PAGE_SIZE, guest will not handle the mmio accesses to the BARs which leads to mmio emulations in host. This is because vfio will not allow to passthrough one BAR's mmio page which may be shared with other BARs. To solve this

[RFC PATCH v3 3/5] PCI: Add host bridge attribute to indicate filtering of MSIs is supported

MSI-X tables are not allowed to be mmapped in vfio-pci driver in case that user get to touch this directly. This will cause some performance issues when when PCI adapters have critical registers in the same page as the MSI-X table. However, some kind of PCI host bridge such as IODA bridge on

[RFC PATCH v3 2/5] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page may be shared with other BARs. But we should allow to mmap these sub-page MMIO BARs if PCI resource allocator can make sure these BARs' mmio page will not be shared with other

[RFC PATCH v3 5/5] vfio-pci: Allow to mmap MSI-X table if host bridge supports filtering of MSIs

Current vfio-pci implementation disallows to mmap MSI-X table in case that user get to touch this directly. But we should allow to mmap these MSI-X tables if the PCI host bridge supports filtering of MSIs. Signed-off-by: Yongji Xie --- drivers/vfio/pci/vfio_pci.c |

[RFC PATCH v3 4/5] powerpc/powernv/pci-ioda: Enable msi_filtered bit for any IODA host bridge

This patch enables msi_filtered bit for any IODA host bridge. Signed-off-by: Yongji Xie --- arch/powerpc/platforms/powernv/pci-ioda.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c

Re: [PATCH V2 6/8] powerpc: Add the ability to save FPU without giving it up

On 1/15/16, Cyril Bur wrote: > This patch adds the ability to be able to save the FPU registers to the > thread struct without giving up (disabling the facility) next time the > process returns to userspace. > > This patch optimises the thread copy path (as a result of a

Re: [PATCH V2 6/8] powerpc: Add the ability to save FPU without giving it up

On 1/15/16, Denis Kirjanov wrote: > On 1/15/16, Cyril Bur wrote: >> This patch adds the ability to be able to save the FPU registers to the >> thread struct without giving up (disabling the facility) next time the >> process returns to userspace. >> >>

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 04:04 AM, Will Deacon wrote: Consequently, it's important that the architecture back-ends implement these portable primitives (e.g. smp_mb()) in a way that satisfies the kernel memory model so that core code doesn't need to worry about the underlying architecture for

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > An the only point - please use an appropriate SYNC_* barriers instead of > heavy bold hammer. That stuff was design explicitly to support the > requirements of Documentation/memory-barriers.txt That's madness. That document

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 12:48 PM, Paul E. McKenney wrote: So SYNC_RMB is intended to implement smp_rmb(), correct? Yes. You could use SYNC_ACQUIRE() to implement read_barrier_depends() and smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. If smp_read_barrier_depends() is used to

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote: > I need some time to understand your test examples. However, Understood. > On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > > > > >The WRC+addr+addr is OK because data dependencies are not required to be > >transitive, in other

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:15 PM, Peter Zijlstra wrote: > >On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > >>An the only point - please use an appropriate SYNC_* barriers instead of > >>heavy bold hammer. That stuff was

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 01:29 PM, Paul E. McKenney wrote: On 01/14/2016 12:34 PM, Paul E. McKenney wrote: The WRC+addr+addr is OK because data dependencies are not required to be transitive, in other words, they are not required to flow from one CPU to another without the help of an explicit memory

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > > An the only point - please use an appropriate SYNC_* barriers instead of > > heavy bold hammer. That stuff was design explicitly to support the > > requirements of

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 12:15 PM, Peter Zijlstra wrote: On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: An the only point - please use an appropriate SYNC_* barriers instead of heavy bold hammer. That stuff was design explicitly to support the requirements of

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 12:12:53PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 04:04 AM, Will Deacon wrote: > >Consequently, it's important that the architecture back-ends > >implement these portable primitives (e.g. smp_mb()) in a way that > >satisfies the kernel memory model so that core code

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

I need some time to understand your test examples. However, On 01/14/2016 12:34 PM, Paul E. McKenney wrote: The WRC+addr+addr is OK because data dependencies are not required to be transitive, in other words, they are not required to flow from one CPU to another without the help of an

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 04:14 AM, Will Deacon wrote: On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: Moreover, there are voices against guarantee that it will be in future and that voices point me to Documentation/memory-barriers.txt section "DATA DEPENDENCY BARRIERS" examples

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

On 01/13/2016 07:25 PM, Michael Ellerman wrote: But for example what happens if the user boots with eeh=off on the command line, and then hotplugs a device. It looks like because you're not using eeh_enabled() you will incorrectly initialise EEH anyway? Thanks very much for this catch Michael!

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 11:28:18AM -0800, Leonid Yegoshin wrote: > On 01/14/2016 04:14 AM, Will Deacon wrote: > >On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > > > >> Moreover, there are voices against guarantee that it will be in future > >>and that voices point me to

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > > An the only point - please use an appropriate SYNC_* barriers instead of > > heavy bold hammer. That stuff was design explicitly to support the > > requirements of

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/14/2016 01:34 PM, Paul E. McKenney wrote: On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: On 01/14/2016 12:15 PM, Peter Zijlstra wrote: On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: An the only point - please use an appropriate SYNC_* barriers instead