[PATCH] powerpc: fsl: update fman dt binding for PCS PHY

[shh.xie]

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: Shaohui Xie 
---
based on: http://patchwork.ozlabs.org/patch/560936/

 Documentation/devicetree/bindings/powerpc/fsl/fman.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
index 55c2c03..b38e727 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
@@ -432,6 +432,16 @@ example of how to define a PHY (Internal PHY has no 
interrupt line).
 - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
 - For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY,
   PCS PHY addr must be '0'.
+  PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs to
+  change the corresponding serdes lane settings.
+
+  PCS PHY node properties required for backplane:
+
+  - compatible: must be "ethernet-phy-ieee802.3-c45".
+  - phy-mode: string, operation mode of the PHY interface; must be 
"1000base-kx"
+for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.
+  - lane-handle: phandle, specifies a reference to a node representing a 
Serdes.
+  - lane-range: offset and length of the register set for the serdes lane.
 
 EXAMPLE
 
@@ -464,7 +474,11 @@ mdio@f1000 {
fsl,fman-internal-mdio;
 
pcsphy6: ethernet-phy@0 {
+   compatible = "ethernet-phy-ieee802.3-c45";
+   phy-mode = "10gbase-kr";
reg = <0x0>;
+   lane-handle = <>;
+   lane-range = <0x18c0 0x40>;
};
 };
 
-- 
2.1.0.27.g96db324

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

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

[Boqun Feng]

On Sun, Dec 27, 2015 at 06:53:39PM +1100, Michael Ellerman wrote:
> On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote:
> > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote:
> > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote:
> > > > Hi all,
> > > > 
> > > > This is v6 of the series.
> > > > 
> > > > Link for v1: https://lkml.org/lkml/2015/8/27/798
> > > > Link for v2: https://lkml.org/lkml/2015/9/16/527
> > > > Link for v3: https://lkml.org/lkml/2015/10/12/368
> > > > Link for v4: https://lkml.org/lkml/2015/10/14/670
> > > > Link for v5: https://lkml.org/lkml/2015/10/26/141
> > > > 
> > > > 
> > > > Changes since v5:
> > > > 
> > > > *   rebase on the next branch of powerpc.
> > > > 
> > > > *   pull two fix and one testcase patches out, which are already
> > > > sent separately
> > > > 
> > > > *   some clean up or code format fixing.
> > > > 
> > > > 
> > > > Paul, Peter and Will, thank you for your comments and suggestions in 
> > > > the review
> > > > of previous versions. From this version on, This series is against the 
> > > > next
> > > > branch of powerpc tree, because most of the code touch arch/powerpc/*.
> > > 
> > > 
> > > Sorry if we already discussed this, but did we decide how we were going to
> > > merge this? There's the one patch to generic code and then three powerpc
> > > patches.
> > > 
> > > It'd make most sense for it to go via powerpc I think. Given that the 
> > > change to
> > > generic code is relatively trivial I'll plan to merge this unless someone
> > > objects.
> > > 
> > > Also it is pretty late in the -next cycle for something like this. But 
> > > AFAICS
> > > there are no users of these "atomic*relaxed" variants yet other than 
> > > arm64 code
> > > and qspinlocks, neither of which are used on powerpc. So adding them 
> > > should be
> > > pretty harmless.
> > > 
> > 
> > There is one thing we should be aware of, that is the bug:
> > 
> > http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com
> > 
> > which though has been fixed by:
> > 
> > http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net
> > 
> > but the fix is not in powerpc/next right now. As this patchset makes
> > atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if
> > this series gets merged in the next branch of powerpc tree, though
> > that's not the problem of this patchset.
> > 
> > Not sure whether this is a problem for your maintence, but just think
> > it's better to make you aware of this ;-)
> 
> Yes that's pretty important thank you :)
> 
> It's not so much that bug that's important, but the fact that I completely
> forget about the acquire/release implementations. Those are used already in
> mainline and so we don't want to add implementations this late in the cycle
> without wider testing.
> 

Understood.

> So I'll have to push this series until 4.6 so it can get some time in -next.
> Sorry!
> 

That's fine, thank you!

Regards,
Boqun


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

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

[David Miller]

From: Thomas Falcon 
Date: Mon, 21 Dec 2015 11:26:06 -0600

> This is a new device driver for a high performance SR-IOV assisted virtual
> network for IBM System p and IBM System i systems.  The SR-IOV VF will be
> attached to the VIOS partition and mapped to the Linux client via the
> hypervisor's VNIC protocol that this driver implements.
> 
> This driver is able to perform basic tx and rx, new features
> and improvements will be added as they are being developed and tested.
> 
> Signed-off-by: Thomas Falcon 
> Signed-off-by: John Allen 

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

Re: [v10, 0/6] Freescale DPAA FMan

[David Miller]

From: 
Date: Mon, 21 Dec 2015 02:21:24 +0200

> The Freescale Data Path Acceleration Architecture (DPAA) is a set
> of hardware components on specific QorIQ multicore processors.
> This architecture provides the infrastructure to support
> simplified sharing of networking interfaces and accelerators
> by multiple CPU cores and the accelerators.
> 
> One of the DPAA accelerators is the Frame Manager (FMan)
> which contains a series of hardware blocks: ports, Ethernet MACs,
> a multi user RAM (MURAM) and Storage Profile (SP).
> 
> This patch set introduce the FMan drivers.
> Each driver configures and initializes the corresponding
> FMan hardware module (described above).
> The MAC driver offers support for three different
> types of MACs (eTSEC, TGEC, MEMAC).

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