Netdev Archive on lore.kernel.org
 help / color / Atom feed
* Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings
@ 2020-03-27 19:18 Ioana Ciornei
  2020-03-27 19:49 ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 6+ messages in thread
From: Ioana Ciornei @ 2020-03-27 19:18 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Florinel Iordache
  Cc: Andrew Lunn, davem, netdev, f.fainelli, hkallweit1, devicetree,
	linux-doc, robh+dt, mark.rutland, kuba, corbet, shawnguo, Leo Li,
	Madalin Bucur (OSS),
	linux-kernel


> Subject: Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt
> bindings
> 
> On Fri, Mar 27, 2020 at 03:00:22PM +0000, Florinel Iordache wrote:
> > > On Thu, Mar 26, 2020 at 03:51:15PM +0200, Florinel Iordache wrote:
> > > > Add ethernet backplane device tree bindings
> > >
> > > > +  - |
> > > > +    /* Backplane configurations for specific setup */
> > > > +    &mdio9 {
> > > > +        bpphy6: ethernet-phy@0 {
> > > > +            compatible = "ethernet-phy-ieee802.3-c45";
> > > > +            reg = <0x0>;
> > > > +            lane-handle = <&lane_d>; /* use lane D */
> > > > +            eq-algorithm = "bee";
> > > > +            /* 10G Short cables setup: up to 30 cm cable */
> > > > +            eq-init = <0x2 0x5 0x29>;
> > > > +            eq-params = <0>;
> > > > +        };
> > > > +    };
> > >
> > > So you are modelling this as just another PHY? Does the driver get
> > > loaded based on the PHY ID in registers 2 and 3? Does the standard
> > > define these IDs or are they vendor specific?
> > >
> > > Thanks
> > >         Andrew
> >
> > Hi Andrew,
> > Thank you all for the feedback.
> > I am currently working to address the entire feedback received so far
> > for this new Backplane driver.
> >
> > Yes, we are modelling backplane driver as a phy driver.
> 
> I think we need to think very carefully about that, and consider whether that
> really is a good idea.  phylib is currently built primarily around copper PHYs,
> although there are some which also support fiber as well in weird "non-
> standard" forms.
> 
> What worries me is the situation which I've been working on, where we want
> access to the PCS PHYs, and we can't have the PCS PHYs represented as a phylib
> PHY because we may have a copper PHY behind the PCS PHY, and we want to be
> talking to the copper PHY in the first instance (the PCS PHY effectively becomes
> a slave to the copper PHY.)
> 

We should think about the case when the PCS is the only transceiver on the local
board, as is happening in the backplane case, and the Ethernet driver does not
support phylink but rather phylib. By suggesting to not register the PCS with
phylib, you're effectively implying that the interface should operate as a fixed-link.
This PCS is shared for DPAA1 and DPAA2, and only one of those drivers uses phylink.

> My worry is that we're ending up with conflicting implementations for the same
> hardware which may only end up causing problems down the line.
> 
> Please can you look at my DPAA2 PCS series which has been previously posted to
> netdev -

I had a go today with your DPAA2 PCS patches and tried to see how one could
extend your approach in order to use it in combination with quad PCSs.

As I mentioned yesterday, in case of QSGMII all the 4 PCSs sit on the first MAC's
internal MDIO. This leads to an error in probing the second MAC from the group
of 4 since the mdio_device_register() will fail when trying with the same internal
MDIO bus the second time.

I cannot see how this limitation can be overcome going forward if we still pass the
entire internal MDIO bus as a handle, as you are doing, and not just the specific
PCS node as the current patch set is proposing.

> it's rather difficult to work out who in NXP should be copied, because
> that information is not visible to those of us in the community - we only find that
> out after someone inside NXP posts patches, and even then the MAINTAINERS
> file doesn't seem to get updated.
> 
> It's also worth mentioning that on other SoCs, such as Marvell SoCs, the serdes
> and "PCS" are entirely separate hardware blocks, and the implementation in the
> kernel, which works very well, is to use the drivers/phy for the serdes/comphy as
> they call it, and the ethernet driver binds to the comphy to control the serdes
> settings, whereas the ethernet driver looks after the PCS.  I haven't been able to
> look at your code enough yet to work out if that would be possible.
> 
> I also wonder whether we want a separate class of MDIO device for PCS PHYs,
> just as we have things like DSA switches implemented entirely separately from
> phylib - they're basically different sub- classes of a mdio device.
> 
> I think we have around 20 or so weeks to hash this out, since it's clear that the
> 10gbase-kr (10GKR) phy interface mode can't be used until we've eliminated it
> from existing dts files.
> 
> > The driver is loaded based on PHY ID in registers 2 and 3 which are
> > specified by the standard but it is a vendor specific value:
> > 32-Bit identifier composed of the 3rd through 24th bits of the
> > Organizationally Unique Identifier (OUI) assigned to the device
> > manufacturer by the IEEE, plus a six-bit model number, plus a four-bit
> > revision number.
> > This is done in the device specific code and not in backplane generic
> > driver.
> > You can check support for QorIQ devices where qoriq_backplane_driver
> > is registered as a phy_driver:
> >
> > @file: qoriq_backplane.c
> > +static struct phy_driver qoriq_backplane_driver[] = {
> > +	{
> > +	.phy_id		= PCS_PHY_DEVICE_ID,
> > +	.name		= QORIQ_BACKPLANE_DRIVER_NAME,
> > +	.phy_id_mask	= PCS_PHY_DEVICE_ID_MASK,
> > +	.features       = BACKPLANE_FEATURES,
> > +	.probe          = qoriq_backplane_probe,
> > +	.remove         = backplane_remove,
> > +	.config_init    = qoriq_backplane_config_init,
> > +	.aneg_done      = backplane_aneg_done,
> >
> > Here we register the particular phy device ID/mask and driver name
> > specific for qoriq devices.
> > Also we can use generic routines provided by generic backplane driver
> > if they are suitable for particular qoriq device or otherwise we can
> > use more specialized specific routines like:
> > qoriq_backplane_config_init
> >
> 
> --


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings
  2020-03-27 19:18 [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings Ioana Ciornei
@ 2020-03-27 19:49 ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 6+ messages in thread
From: Russell King - ARM Linux admin @ 2020-03-27 19:49 UTC (permalink / raw)
  To: Ioana Ciornei
  Cc: Florinel Iordache, Andrew Lunn, davem, netdev, f.fainelli,
	hkallweit1, devicetree, linux-doc, robh+dt, mark.rutland, kuba,
	corbet, shawnguo, Leo Li, Madalin Bucur (OSS),
	linux-kernel

On Fri, Mar 27, 2020 at 07:18:56PM +0000, Ioana Ciornei wrote:
> 
> > Subject: Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt
> > bindings
> > 
> > On Fri, Mar 27, 2020 at 03:00:22PM +0000, Florinel Iordache wrote:
> > > > On Thu, Mar 26, 2020 at 03:51:15PM +0200, Florinel Iordache wrote:
> > > > > Add ethernet backplane device tree bindings
> > > >
> > > > > +  - |
> > > > > +    /* Backplane configurations for specific setup */
> > > > > +    &mdio9 {
> > > > > +        bpphy6: ethernet-phy@0 {
> > > > > +            compatible = "ethernet-phy-ieee802.3-c45";
> > > > > +            reg = <0x0>;
> > > > > +            lane-handle = <&lane_d>; /* use lane D */
> > > > > +            eq-algorithm = "bee";
> > > > > +            /* 10G Short cables setup: up to 30 cm cable */
> > > > > +            eq-init = <0x2 0x5 0x29>;
> > > > > +            eq-params = <0>;
> > > > > +        };
> > > > > +    };
> > > >
> > > > So you are modelling this as just another PHY? Does the driver get
> > > > loaded based on the PHY ID in registers 2 and 3? Does the standard
> > > > define these IDs or are they vendor specific?
> > > >
> > > > Thanks
> > > >         Andrew
> > >
> > > Hi Andrew,
> > > Thank you all for the feedback.
> > > I am currently working to address the entire feedback received so far
> > > for this new Backplane driver.
> > >
> > > Yes, we are modelling backplane driver as a phy driver.
> > 
> > I think we need to think very carefully about that, and consider whether that
> > really is a good idea.  phylib is currently built primarily around copper PHYs,
> > although there are some which also support fiber as well in weird "non-
> > standard" forms.
> > 
> > What worries me is the situation which I've been working on, where we want
> > access to the PCS PHYs, and we can't have the PCS PHYs represented as a phylib
> > PHY because we may have a copper PHY behind the PCS PHY, and we want to be
> > talking to the copper PHY in the first instance (the PCS PHY effectively becomes
> > a slave to the copper PHY.)
> > 
> 
> We should think about the case when the PCS is the only transceiver on the local
> board, as is happening in the backplane case, and the Ethernet driver does not
> support phylink but rather phylib. By suggesting to not register the PCS with
> phylib,

Please don't, that's completely unnecessary.  phylink wraps itself
around phylib and offers essentially the same functionality that phylib
used to - with the added bonus that fixed links can be supported at
speeds greater than 1G, which is not possible with the phylib-based
fixed link implementation.

There is no reason for a network driver to choose between interfacing
to phylink and phylib.

> you're effectively implying that the interface should operate as a fixed-link.
> This PCS is shared for DPAA1 and DPAA2, and only one of those drivers uses phylink.

That in itself creates a problem.  Is there any reason DPAA1 can't be
transitioned over to phylink, given that phylink offers everything
that phylib does?

> > My worry is that we're ending up with conflicting implementations for the same
> > hardware which may only end up causing problems down the line.
> > 
> > Please can you look at my DPAA2 PCS series which has been previously posted to
> > netdev -
> 
> I had a go today with your DPAA2 PCS patches and tried to see how one could
> extend your approach in order to use it in combination with quad PCSs.
> 
> As I mentioned yesterday, in case of QSGMII all the 4 PCSs sit on the first MAC's
> internal MDIO. This leads to an error in probing the second MAC from the group
> of 4 since the mdio_device_register() will fail when trying with the same internal
> MDIO bus the second time.
> 
> I cannot see how this limitation can be overcome going forward if we still pass the
> entire internal MDIO bus as a handle, as you are doing, and not just the specific
> PCS node as the current patch set is proposing.

I think you're a little confused.  I'm not passing the MDIO bus around,
I create a MDIO device instead.  All that can be decided upon inside
dpaa2_pcs_create().

At the moment, that takes a simplistic approach, because I've only
considered basically SGMII/1000base-X and 10GBASE-R, and nothing else.
I've even short-cut that, because, although they use different PHY
blocks (one via clause 22 accesses, the other via clause 45 accesses)
they are both at address 0.

I've been thinking, however, that mac->pcs wants to not be a single
mdio device, but several - one for each PCS in the system, which
would include the appropriate PCS block for QSGMII, no matter which
MDIO bus it's on.

So, what I'm saying is that _that_ can be changed in order to support
QSGMII, and I suspect also needs to be changed to support 40G mode
as well.

> > it's rather difficult to work out who in NXP should be copied, because
> > that information is not visible to those of us in the community - we only find that
> > out after someone inside NXP posts patches, and even then the MAINTAINERS
> > file doesn't seem to get updated.
> > 
> > It's also worth mentioning that on other SoCs, such as Marvell SoCs, the serdes
> > and "PCS" are entirely separate hardware blocks, and the implementation in the
> > kernel, which works very well, is to use the drivers/phy for the serdes/comphy as
> > they call it, and the ethernet driver binds to the comphy to control the serdes
> > settings, whereas the ethernet driver looks after the PCS.  I haven't been able to
> > look at your code enough yet to work out if that would be possible.
> > 
> > I also wonder whether we want a separate class of MDIO device for PCS PHYs,
> > just as we have things like DSA switches implemented entirely separately from
> > phylib - they're basically different sub- classes of a mdio device.
> > 
> > I think we have around 20 or so weeks to hash this out, since it's clear that the
> > 10gbase-kr (10GKR) phy interface mode can't be used until we've eliminated it
> > from existing dts files.
> > 
> > > The driver is loaded based on PHY ID in registers 2 and 3 which are
> > > specified by the standard but it is a vendor specific value:
> > > 32-Bit identifier composed of the 3rd through 24th bits of the
> > > Organizationally Unique Identifier (OUI) assigned to the device
> > > manufacturer by the IEEE, plus a six-bit model number, plus a four-bit
> > > revision number.
> > > This is done in the device specific code and not in backplane generic
> > > driver.
> > > You can check support for QorIQ devices where qoriq_backplane_driver
> > > is registered as a phy_driver:
> > >
> > > @file: qoriq_backplane.c
> > > +static struct phy_driver qoriq_backplane_driver[] = {
> > > +	{
> > > +	.phy_id		= PCS_PHY_DEVICE_ID,
> > > +	.name		= QORIQ_BACKPLANE_DRIVER_NAME,
> > > +	.phy_id_mask	= PCS_PHY_DEVICE_ID_MASK,
> > > +	.features       = BACKPLANE_FEATURES,
> > > +	.probe          = qoriq_backplane_probe,
> > > +	.remove         = backplane_remove,
> > > +	.config_init    = qoriq_backplane_config_init,
> > > +	.aneg_done      = backplane_aneg_done,
> > >
> > > Here we register the particular phy device ID/mask and driver name
> > > specific for qoriq devices.
> > > Also we can use generic routines provided by generic backplane driver
> > > if they are suitable for particular qoriq device or otherwise we can
> > > use more specialized specific routines like:
> > > qoriq_backplane_config_init
> > >
> > 
> > --
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings
  2020-03-26 13:51 ` [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings Florinel Iordache
  2020-03-27  1:04   ` Andrew Lunn
@ 2020-03-30 15:39   ` Rob Herring
  1 sibling, 0 replies; 6+ messages in thread
From: Rob Herring @ 2020-03-30 15:39 UTC (permalink / raw)
  To: Florinel Iordache
  Cc: davem, netdev, andrew, f.fainelli, hkallweit1, linux, devicetree,
	linux-doc, robh+dt, mark.rutland, kuba, corbet, shawnguo,
	leoyang.li, madalin.bucur, ioana.ciornei, linux-kernel,
	Florinel Iordache

On Thu, 26 Mar 2020 15:51:15 +0200, Florinel Iordache wrote:
> Add ethernet backplane device tree bindings
> 
> Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
> ---
>  .../bindings/net/ethernet-controller.yaml          |  3 +-
>  .../devicetree/bindings/net/ethernet-phy.yaml      | 53 +++++++++++++
>  Documentation/devicetree/bindings/net/serdes.yaml  | 90 ++++++++++++++++++++++
>  3 files changed, 145 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/net/serdes.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/net/serdes.yaml:  mapping values are not allowed in this context
  in "<unicode string>", line 30, column 62
Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/net/serdes.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/net/serdes.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
Documentation/devicetree/bindings/net/ethernet-phy.yaml:  mapping values are not allowed in this context
  in "<unicode string>", line 179, column 20
Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/net/ethernet-phy.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/net/ethernet-phy.example.dts] Error 1
warning: no schema found in file: Documentation/devicetree/bindings/net/serdes.yaml
warning: no schema found in file: Documentation/devicetree/bindings/net/ethernet-phy.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/serdes.yaml: ignoring, error parsing file
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ethernet-phy.yaml: ignoring, error parsing file
Makefile:1262: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1261991

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade

Please check and re-submit.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings
  2020-03-27  1:04   ` Andrew Lunn
@ 2020-03-27 12:06     ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 6+ messages in thread
From: Russell King - ARM Linux admin @ 2020-03-27 12:06 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Florinel Iordache, davem, netdev, f.fainelli, hkallweit1,
	devicetree, linux-doc, robh+dt, mark.rutland, kuba, corbet,
	shawnguo, leoyang.li, madalin.bucur, ioana.ciornei, linux-kernel

On Fri, Mar 27, 2020 at 02:04:11AM +0100, Andrew Lunn wrote:
> On Thu, Mar 26, 2020 at 03:51:15PM +0200, Florinel Iordache wrote:
> > Add ethernet backplane device tree bindings
> 
> > +  - |
> > +    /* Backplane configurations for specific setup */
> > +    &mdio9 {
> > +        bpphy6: ethernet-phy@0 {
> > +            compatible = "ethernet-phy-ieee802.3-c45";
> > +            reg = <0x0>;
> > +            lane-handle = <&lane_d>; /* use lane D */
> > +            eq-algorithm = "bee";
> > +            /* 10G Short cables setup: up to 30 cm cable */
> > +            eq-init = <0x2 0x5 0x29>;
> > +            eq-params = <0>;
> > +        };
> > +    };
> 
> So you are modelling this as just another PHY? Does the driver get
> loaded based on the PHY ID in registers 2 and 3? Does the standard
> define these IDs or are they vendor specific?

We likely need some mutual coordination here between the patches I've
already posted for PCS support and these patches.

As I've said, we can't deal with multiple ethernet PHYs connected to
one MAC, the patches I've posted cope with that, but likely will need
changes for this.  Conversely, these patches will need changes for my
work.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings
  2020-03-26 13:51 ` [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings Florinel Iordache
@ 2020-03-27  1:04   ` Andrew Lunn
  2020-03-27 12:06     ` Russell King - ARM Linux admin
  2020-03-30 15:39   ` Rob Herring
  1 sibling, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2020-03-27  1:04 UTC (permalink / raw)
  To: Florinel Iordache
  Cc: davem, netdev, f.fainelli, hkallweit1, linux, devicetree,
	linux-doc, robh+dt, mark.rutland, kuba, corbet, shawnguo,
	leoyang.li, madalin.bucur, ioana.ciornei, linux-kernel

On Thu, Mar 26, 2020 at 03:51:15PM +0200, Florinel Iordache wrote:
> Add ethernet backplane device tree bindings

> +  - |
> +    /* Backplane configurations for specific setup */
> +    &mdio9 {
> +        bpphy6: ethernet-phy@0 {
> +            compatible = "ethernet-phy-ieee802.3-c45";
> +            reg = <0x0>;
> +            lane-handle = <&lane_d>; /* use lane D */
> +            eq-algorithm = "bee";
> +            /* 10G Short cables setup: up to 30 cm cable */
> +            eq-init = <0x2 0x5 0x29>;
> +            eq-params = <0>;
> +        };
> +    };

So you are modelling this as just another PHY? Does the driver get
loaded based on the PHY ID in registers 2 and 3? Does the standard
define these IDs or are they vendor specific?

Thanks
	Andrew

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings
  2020-03-26 13:51 [PATCH net-next 0/9] net: ethernet backplane support Florinel Iordache
@ 2020-03-26 13:51 ` Florinel Iordache
  2020-03-27  1:04   ` Andrew Lunn
  2020-03-30 15:39   ` Rob Herring
  0 siblings, 2 replies; 6+ messages in thread
From: Florinel Iordache @ 2020-03-26 13:51 UTC (permalink / raw)
  To: davem, netdev, andrew, f.fainelli, hkallweit1, linux
  Cc: devicetree, linux-doc, robh+dt, mark.rutland, kuba, corbet,
	shawnguo, leoyang.li, madalin.bucur, ioana.ciornei, linux-kernel,
	Florinel Iordache

Add ethernet backplane device tree bindings

Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
---
 .../bindings/net/ethernet-controller.yaml          |  3 +-
 .../devicetree/bindings/net/ethernet-phy.yaml      | 53 +++++++++++++
 Documentation/devicetree/bindings/net/serdes.yaml  | 90 ++++++++++++++++++++++
 3 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/net/serdes.yaml

diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index ac471b6..541cee5 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -93,8 +93,9 @@ properties:
       - rxaui
       - xaui
 
-      # 10GBASE-KR, XFI, SFI
+      # 10GBASE-KR, 40GBASE-KR4, XFI, SFI
       - 10gbase-kr
+      - 40gbase-kr4
       - usxgmii
 
   phy-mode:
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 8927941..2fb377e 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -158,6 +158,42 @@ properties:
     description:
       Specifies a reference to a node representing a SFP cage.
 
+  eq-algorithm:
+    oneOf:
+      - const: fixed
+        description:
+          Backplane KR using fixed coefficients meaning no
+          equalization algorithm
+      - const: bee
+        description:
+          Backplane KR using 3-Taps Bit Edge Equalization (BEE)
+          algorithm
+        description:
+          Specifies the desired equalization algorithm to be used
+          by the KR link training
+
+  eq-init:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 3
+    maxItems: 3
+        description:
+          Triplet of KR coefficients. Specifies the initialization
+	  values for standard KR equalization coefficients used by
+	  the link training: pre-cursor, post-cursor, main-cursor
+
+  eq-params:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+        description:
+          Variable size array of KR parameters. Specifies the HW
+	  specific parameters used by the link training
+
+  lane-handle:
+    $ref: /schemas/types.yaml#definitions/phandle
+    description:
+      Specifies a reference (or array of references) to a node
+      representing the desired SERDES lane (or lanes) used in
+      backplane mode
+
 required:
   - reg
 
@@ -180,3 +216,20 @@ examples:
             reset-deassert-us = <2000>;
         };
     };
+  - |
+    /* Backplane configurations for specific setup */
+    &mdio9 {
+        bpphy6: ethernet-phy@0 {
+            compatible = "ethernet-phy-ieee802.3-c45";
+            reg = <0x0>;
+            lane-handle = <&lane_d>; /* use lane D */
+            eq-algorithm = "bee";
+            /* 10G Short cables setup: up to 30 cm cable */
+            eq-init = <0x2 0x5 0x29>;
+            eq-params = <0>;
+        };
+    };
+    &mac9 {
+        phy-connection-type = "10gbase-kr";
+        phy-handle = <&bpphy6>;
+    };
diff --git a/Documentation/devicetree/bindings/net/serdes.yaml b/Documentation/devicetree/bindings/net/serdes.yaml
new file mode 100644
index 0000000..965152f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/serdes.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/serdes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Serdes Module Binding
+
+maintainers:
+  - Florinel Iordache <florinel.iordache@nxp.com>
+
+properties:
+  $nodename:
+    pattern: "^serdes(@[a-f0-9]+)?$"
+
+  compatible:
+    oneOf:
+      - const: serdes-10g
+        description: SerDes module type of 10G
+      - const: serdes-28g
+        description: SerDes module type of 28G
+
+  reg:
+    description:
+      Registers memory map offset and size for this serdes module
+
+  reg-names:
+    description:
+      Names of the register map given in "reg" node.
+      Should be one of the following according to serdes type:
+      "serdes", "serdes-10g", "serdes-28g"
+
+  little-endian:
+    description:
+      Specifies the endianness of serdes module
+      For complete definition see:
+      Documentation/devicetree/bindings/common-properties.txt
+
+  #address-cells:
+    description: Must be <1>
+
+  #size-cells:
+    description: Must be <1>
+
+  ranges:
+    description:
+      Address range of serdes module.
+
+properties:
+  $nodename:
+    pattern: "^lane(@[a-f0-9]+)?$"
+
+  compatible:
+    oneOf:
+      - const: lane-10g
+        description: Lane part of a 10G SerDes module
+      - const: lane-28g
+        description: Lane part of a 28G SerDes module
+
+  reg:
+    description:
+      Registers memory map offset and size for this lane
+
+  reg-names:
+    description:
+      Names of the register map given in "reg" node.
+      Should be one of the following: "lane", "serdes-lane"
+
+examples:
+  - |
+    serdes1: serdes@1ea0000 {
+        compatible = "serdes-10g";
+        reg = <0x0 0x1ea0000 0 0x00002000>;
+        reg-names = "serdes", "serdes-10g";
+        little-endian;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges = <0x0 0x00 0x1ea0000 0x00002000>;
+        lane_a: lane@800 {
+            compatible = "lane-10g";
+            reg = <0x800 0x40>;
+            reg-names = "lane", "serdes-lane";
+        };
+        lane_b: lane@840 {
+            compatible = "lane-10g";
+            reg = <0x840 0x40>;
+            reg-names = "lane", "serdes-lane";
+        };
+    };
-- 
1.9.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-27 19:18 [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings Ioana Ciornei
2020-03-27 19:49 ` Russell King - ARM Linux admin
  -- strict thread matches above, loose matches on Subject: below --
2020-03-26 13:51 [PATCH net-next 0/9] net: ethernet backplane support Florinel Iordache
2020-03-26 13:51 ` [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings Florinel Iordache
2020-03-27  1:04   ` Andrew Lunn
2020-03-27 12:06     ` Russell King - ARM Linux admin
2020-03-30 15:39   ` Rob Herring

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org
	public-inbox-index netdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git