* Re: [PATCH] net: ethernet: et131x: Use GFP_KERNEL instead of GFP_ATOMIC when allocating tx_ring->tcb_ring
From: Matthew Wilcox @ 2019-08-08 11:24 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Christophe JAILLET, mark.einon, davem, f.fainelli, andrew, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <20190807222346.00002ba7@intel.com>
On Wed, Aug 07, 2019 at 10:23:46PM -0700, Jesse Brandeburg wrote:
> On Wed, 31 Jul 2019 09:38:42 +0200
> Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
>
> > There is no good reason to use GFP_ATOMIC here. Other memory allocations
> > are performed with GFP_KERNEL (see other 'dma_alloc_coherent()' below and
> > 'kzalloc()' in 'et131x_rx_dma_memory_alloc()')
> >
> > Use GFP_KERNEL which should be enough.
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>
> Sure, but generally I'd say GFP_ATOMIC is ok if you're in an init path
> and you can afford to have the allocation thread sleep while memory is
> being found by the kernel.
That's not what GFP_ATOMIC means. GFP_ATOMIC _will not_ sleep. GFP_KERNEL
will.
^ permalink raw reply
* Re: [PATCH net 1/2] sock: make cookie generation global instead of per netns
From: Eric Dumazet @ 2019-08-08 11:37 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, netdev, bpf, m, Alexei Starovoitov,
Willem de Bruijn
In-Reply-To: <d87d35a1-0ebc-4e48-1950-e94fde62a6c4@iogearbox.net>
On Thu, Aug 8, 2019 at 1:09 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 8/8/19 12:45 PM, Eric Dumazet wrote:
> > On Thu, Aug 8, 2019 at 11:50 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> >> Socket cookie consumers must assume the value as opqaue in any case.
> >> The cookie does not guarantee an always unique identifier since it
> >> could wrap in fabricated corner cases where two sockets could end up
> >> holding the same cookie,
> >
> > What do you mean by this ?
> >
> > Cookie is guaranteed to be unique, it is from a 64bit counter...
> >
> > There should be no collision.
>
> I meant the [theoretical] corner case where socket_1 has cookie X and
> we'd create, trigger sock_gen_cookie() to increment, close socket in a
> loop until we wrap and get another cookie X for socket_2; agree it's
> impractical and for little gain anyway. So in practice there should be
> no collision which is what I tried to say.
If a 64bit counter, updated by one unit at a time could overflow
during the lifetime of a host,
I would agree with you, but this can not happen, even if we succeed to
make 1 billion
locked increments per second (this would still need 584 years)
I would prefer not mentioning something that can not possibly happen
in your changelog ;)
^ permalink raw reply
* Re: [PATCH net 1/2] sock: make cookie generation global instead of per netns
From: Daniel Borkmann @ 2019-08-08 11:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, bpf, m, Alexei Starovoitov,
Willem de Bruijn
In-Reply-To: <CANn89iLqhYF=JYtNtB25O=0a_tn50dRko3fqvvC-sWTZXuK+0g@mail.gmail.com>
On 8/8/19 1:37 PM, Eric Dumazet wrote:
> On Thu, Aug 8, 2019 at 1:09 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 8/8/19 12:45 PM, Eric Dumazet wrote:
>>> On Thu, Aug 8, 2019 at 11:50 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>
>>>> Socket cookie consumers must assume the value as opqaue in any case.
>>>> The cookie does not guarantee an always unique identifier since it
>>>> could wrap in fabricated corner cases where two sockets could end up
>>>> holding the same cookie,
>>>
>>> What do you mean by this ?
>>>
>>> Cookie is guaranteed to be unique, it is from a 64bit counter...
>>>
>>> There should be no collision.
>>
>> I meant the [theoretical] corner case where socket_1 has cookie X and
>> we'd create, trigger sock_gen_cookie() to increment, close socket in a
>> loop until we wrap and get another cookie X for socket_2; agree it's
>> impractical and for little gain anyway. So in practice there should be
>> no collision which is what I tried to say.
>
> If a 64bit counter, updated by one unit at a time could overflow
> during the lifetime of a host,
> I would agree with you, but this can not happen, even if we succeed to
> make 1 billion
> locked increments per second (this would still need 584 years)
>
> I would prefer not mentioning something that can not possibly happen
> in your changelog ;)
Yep fair enough, makes sense. I'll fix it :)
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-08 11:41 UTC (permalink / raw)
To: robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel, Rob Herring
In-Reply-To: <20190808114101.29982-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4377f511a51d..c78be15704b9 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: net: snps,dwmac: update reg minItems maxItems
From: Neil Armstrong @ 2019-08-08 11:41 UTC (permalink / raw)
To: robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel, Rob Herring,
Maxime Ripard
In-Reply-To: <20190808114101.29982-1-narmstrong@baylibre.com>
The Amlogic Meson DWMAC glue bindings needs a second reg cells for the
glue registers, thus update the reg minItems/maxItems to allow more
than a single reg cell.
Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify
maxItems to 1.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml | 3 +++
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 06b1cc8bea14..ef446ae166f3 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
const: allwinner,sun7i-a20-gmac
+ reg:
+ maxItems: 1
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..4377f511a51d 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -61,7 +61,8 @@ properties:
- snps,dwxgmac-2.10
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
interrupts:
minItems: 1
--
2.22.0
^ permalink raw reply related
* [PATCH v3 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-08 11:40 UTC (permalink / raw)
To: robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel
This patchsets converts the Amlogic Meson DWMAC glue bindings over to
YAML schemas using the already converted dwmac bindings.
The first patch is needed because the Amlogic glue needs a supplementary
reg cell to access the DWMAC glue registers.
Changes since v2:
- Added review tags
- Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
Neil Armstrong (2):
dt-bindings: net: snps,dwmac: update reg minItems maxItems
dt-bindings: net: meson-dwmac: convert to yaml
.../net/allwinner,sun7i-a20-gmac.yaml | 3 +
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 8 +-
4 files changed, 123 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
--
2.22.0
^ permalink raw reply
* RE: Clause 73 and USXGMII
From: Jose Abreu @ 2019-08-08 11:45 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
Heiner Kallweit
In-Reply-To: <20190808092313.GC5193@shell.armlinux.org.uk>
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Aug/08/2019, 10:23:13 (UTC+00:00)
> On Thu, Aug 08, 2019 at 09:02:57AM +0000, Jose Abreu wrote:
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Date: Aug/08/2019, 09:26:26 (UTC+00:00)
> >
> > > Hi,
> > >
> > > Have you tried enabling debug mode in phylink (add #define DEBUG at the
> > > top of the file) ?
> >
> > Yes:
> >
> > [ With > 2.5G modes removed ]
> > # dmesg | grep -i phy
> > libphy: stmmac: probed
> > stmmaceth 0000:04:00.0 enp4s0: PHY [stmmac-1:00] driver [Synopsys 10G]
> > stmmaceth 0000:04:00.0 enp4s0: phy: setting supported
> > 00,00000000,0002e040 advertising 00,00000000,0002e040
> > stmmaceth 0000:04:00.0 enp4s0: configuring for phy/usxgmii link mode
> > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config:
> > mode=phy/usxgmii/Unknown/Unknown adv=00,00000000,0002e040 pause=10
> > link=0 an=1
> > stmmaceth 0000:04:00.0 enp4s0: phy link down usxgmii/Unknown/Unknown
>
> This shows that the PHY isn't reporting that the link came up. Did
> the PHY negotiate link? If so, why isn't it reporting that the link
> came up? Maybe something is mis-programming the capability bits in
> the PHY? Maybe disabling the 10G speeds disables everything faster
> than 1G?
Autoneg was started but never finishes and disabling 10G modes is
causing autoneg to fail.
>
> > [ Without any limit ]
> > # dmesg | grep -i phy
> > libphy: stmmac: probed
> > stmmaceth 0000:04:00.0 enp4s0: PHY [stmmac-1:00] driver [Synopsys 10G]
> > stmmaceth 0000:04:00.0 enp4s0: phy: setting supported
> > 00,00000000,000ee040 advertising 00,00000000,000ee040
> > stmmaceth 0000:04:00.0 enp4s0: configuring for phy/usxgmii link mode
> > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config:
> > mode=phy/usxgmii/Unknown/Unknown adv=00,00000000,000ee040 pause=10
> > link=0 an=1
> > stmmaceth 0000:04:00.0 enp4s0: phy link down usxgmii/Unknown/Unknown
> > stmmaceth 0000:04:00.0 enp4s0: phy link up usxgmii/2.5Gbps/Full
> > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config:
> > mode=phy/usxgmii/2.5Gbps/Full adv=00,00000000,00000000 pause=0f link=1
> > an=0
> >
> > I'm thinking on whether this can be related with USXGMII. As link is
> > operating in 10G but I configure USXGMII for 2.5G maybe autoneg outcome
> > should always be 10G ?
>
> As I understand USXGMII (which isn't very well, because the spec isn't
> available) I believe that it operates in a similar way to SGMII where
> data is replicated the appropriate number of times to achieve the link
> speed. So, the USXGMII link always operates at a bit rate equivalent
> to 10G, but data is replicated twice for 5G, four times for 2.5G, ten
> times for 1G, etc.
>
> I notice that you don't say that you support any copper speeds, which
> brings up the question about what the PHY's media is...
I just added the speeds that XPCS supports within Clause 73
specification:
Technology Ability field. Indicates the supported technologies:
A0: When this bit is set to 1, the 1000BASE-KX technology is supported
A1: When this bit is set to 1, the 10GBASE-KX4 technology is supported
A2: When this bit is set to 1, the 10GBASE-KR technology is supported
A11: When this bit is set to 1, the 2.5GBASE-KX technology is supported
A12: When this bit is set to 1, the 5GBASE-KR technology is supported
And, within USXGMII, XPCS supports the following:
Single Port: 10G-SXGMII, 5G-SXGMII, 2.5G-SXGMII
Dual Port: 10G-DXGMII, 5G-DXGMII
Quad Port: 10G-XGMII
My HW is currently fixed for USXGMII at 2.5G.
>
> > > On Thu, Aug 08, 2019 at 08:17:29AM +0000, Jose Abreu wrote:
> > > > ++ PHY Experts
> > > >
> > > > From: Jose Abreu <joabreu@synopsys.com>
> > > > Date: Aug/07/2019, 16:46:23 (UTC+00:00)
> > > >
> > > > > Hello,
> > > > >
> > > > > I've some sample code for Clause 73 support using Synopsys based XPCS
> > > > > but I would like to clarify some things that I noticed.
> > > > >
> > > > > I'm using USXGMII as interface and a single SERDES that operates at 10G
> > > > > rate but MAC side is working at 2.5G. Maximum available bandwidth is
> > > > > therefore 2.5Gbps.
> > > > >
> > > > > So, I configure USXGMII for 2.5G mode and it works but if I try to limit
> > > > > the autoneg abilities to 2.5G max then it never finishes:
> > > > > # ethtool enp4s0
> > > > > Settings for enp4s0:
> > > > > Supported ports: [ ]
> > > > > Supported link modes: 1000baseKX/Full
> > > > > 2500baseX/Full
> > > > > Supported pause frame use: Symmetric Receive-only
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 1000baseKX/Full
> > > > > 2500baseX/Full
> > > > > Advertised pause frame use: Symmetric Receive-only
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Speed: Unknown!
> > > > > Duplex: Unknown! (255)
> > > > > Port: MII
> > > > > PHYAD: 0
> > > > > Transceiver: internal
> > > > > Auto-negotiation: on
> > > > > Supports Wake-on: ug
> > > > > Wake-on: d
> > > > > Current message level: 0x0000003f (63)
> > > > > drv probe link timer ifdown ifup
> > > > > Link detected: no
> > > > >
> > > > > When I do not limit autoneg and I say that maximum limit is 10G then I
> > > > > get Link Up and autoneg finishes with this outcome:
> > > > > # ethtool enp4s0
> > > > > Settings for enp4s0:
> > > > > Supported ports: [ ]
> > > > > Supported link modes: 1000baseKX/Full
> > > > > 2500baseX/Full
> > > > > 10000baseKX4/Full
> > > > > 10000baseKR/Full
> > > > > Supported pause frame use: Symmetric Receive-only
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 1000baseKX/Full
> > > > > 2500baseX/Full
> > > > > 10000baseKX4/Full
> > > > > 10000baseKR/Full
> > > > > Advertised pause frame use: Symmetric Receive-only
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Link partner advertised link modes: 1000baseKX/Full
> > > > > 2500baseX/Full
> > > > > 10000baseKX4/Full
> > > > > 10000baseKR/Full
> > > > > Link partner advertised pause frame use: Symmetric Receive-only
> > > > > Link partner advertised auto-negotiation: Yes
> > > > > Link partner advertised FEC modes: Not reported
> > > > > Speed: 2500Mb/s
> > > > > Duplex: Full
> > > > > Port: MII <- Never mind this, it's a SW issue
> > > > > PHYAD: 0
> > > > > Transceiver: internal
> > > > > Auto-negotiation: on
> > > > > Supports Wake-on: ug
> > > > > Wake-on: d
> > > > > Current message level: 0x0000003f (63)
> > > > > drv probe link timer ifdown ifup
> > > > > Link detected: yes
> > > > >
> > > > > I was expecting that, as MAC side is limited to 2.5G, I should set in
> > > > > phylink the correct capabilities and then outcome of autoneg would only
> > > > > have up to 2.5G modes. Am I wrong ?
> > > > >
> > > > > ---
> > > > > Thanks,
> > > > > Jose Miguel Abreu
> > > >
> > > >
> > > > ---
> > > > Thanks,
> > > > Jose Miguel Abreu
> > > >
> > >
> > > --
> > > RMK's Patch system: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.armlinux.org.uk_developer_patches_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=1MdSlPrmzsMMCJbbLcDYTNuPq1njfusBRjcRz3UD4Dg&s=_30hwSYkGf9DfyCG48mnh7lXP8iiULXpfAP_6agUJno&e=
> > > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > > According to speedtest.net: 11.9Mbps down 500kbps up
> >
> >
> > ---
> > Thanks,
> > Jose Miguel Abreu
> >
>
> --
> RMK's Patch system: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.armlinux.org.uk_developer_patches_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=d_Og5QaTJOl1WoLi43ZAlCMajHnZp4mGg8Npwlaa2pk&s=bs6ws6HmZNKiutYWGFPy1ztnEQBuhtWyjiE0Hr1_URo&e=
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next 5/5] r8152: change rx_frag_head_sz and rx_max_agg_num dynamically
From: Maciej Fijalkowski @ 2019-08-08 11:49 UTC (permalink / raw)
To: Hayes Wang
Cc: Jakub Kicinski, netdev@vger.kernel.org, nic_swsd,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2F18D0D8E@RTITMBSVM03.realtek.com.tw>
On Thu, 8 Aug 2019 08:52:51 +0000
Hayes Wang <hayeswang@realtek.com> wrote:
> Jakub Kicinski [mailto:jakub.kicinski@netronome.com]
> > Sent: Wednesday, August 07, 2019 6:10 AM
> [...]
> > On Tue, 6 Aug 2019 19:18:04 +0800, Hayes Wang wrote:
> > > Let rx_frag_head_sz and rx_max_agg_num could be modified dynamically
> > > through the sysfs.
> > >
> > > Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> >
> > Please don't expose those via sysfs. Ethtool's copybreak and descriptor
> > count should be applicable here, I think.
>
> Excuse me again.
> I find the kernel supports the copybreak of Ethtool.
> However, I couldn't find a command of Ethtool to use it.
Ummm there's set_tunable ops. Amazon's ena driver is making use of it from what
I see. Look at ena_set_tunable() in
drivers/net/ethernet/amazon/ena/ena_ethtool.c.
Maciej
> Do I miss something?
>
> Best Regards,
> Hayes
>
^ permalink raw reply
* [PATCH net v2 0/2] Fix collisions in socket cookie generation
From: Daniel Borkmann @ 2019-08-08 11:57 UTC (permalink / raw)
To: davem; +Cc: netdev, bpf, m, edumazet, ast, willemb, Daniel Borkmann
This change makes the socket cookie generator as a global counter
instead of per netns in order to fix cookie collisions for BPF use
cases we ran into. See main patch #1 for more details.
Given the change is small/trivial and fixes an issue we're seeing
my preference would be net tree (though it cleanly applies to
net-next as well). Went for net tree instead of bpf tree here given
the main change is in net/core/sock_diag.c, but either way would be
fine with me.
Thanks a lot!
v1 -> v2:
- Fix up commit description in patch #1, thanks Eric!
Daniel Borkmann (2):
sock: make cookie generation global instead of per netns
bpf: sync bpf.h to tools infrastructure
include/net/net_namespace.h | 1 -
include/uapi/linux/bpf.h | 4 ++--
net/core/sock_diag.c | 3 ++-
tools/include/uapi/linux/bpf.h | 11 +++++++----
4 files changed, 11 insertions(+), 8 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net v2 1/2] sock: make cookie generation global instead of per netns
From: Daniel Borkmann @ 2019-08-08 11:57 UTC (permalink / raw)
To: davem; +Cc: netdev, bpf, m, edumazet, ast, willemb, Daniel Borkmann
In-Reply-To: <20190808115726.31703-1-daniel@iogearbox.net>
Generating and retrieving socket cookies are a useful feature that is
exposed to BPF for various program types through bpf_get_socket_cookie()
helper.
The fact that the cookie counter is per netns is quite a limitation
for BPF in practice in particular for programs in host namespace that
use socket cookies as part of a map lookup key since they will be
causing socket cookie collisions e.g. when attached to BPF cgroup hooks
or cls_bpf on tc egress in host namespace handling container traffic
from veth or ipvlan devices with peer in different netns. Change the
counter to be global instead.
Socket cookie consumers must assume the value as opqaue in any case.
Not every socket must have a cookie generated and knowledge of the
counter value itself does not provide much value either way hence
conversion to global is fine.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Martynas Pumputis <m@lambda.lt>
---
include/net/net_namespace.h | 1 -
include/uapi/linux/bpf.h | 4 ++--
net/core/sock_diag.c | 3 ++-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 4a9da951a794..cb668bc2692d 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -61,7 +61,6 @@ struct net {
spinlock_t rules_mod_lock;
u32 hash_mix;
- atomic64_t cookie_gen;
struct list_head list; /* list of network namespaces */
struct list_head exit_list; /* To linked to call pernet exit
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index fa1c753dcdbc..a5aa7d3ac6a1 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1466,8 +1466,8 @@ union bpf_attr {
* If no cookie has been set yet, generate a new cookie. Once
* generated, the socket cookie remains stable for the life of the
* socket. This helper can be useful for monitoring per socket
- * networking traffic statistics as it provides a unique socket
- * identifier per namespace.
+ * networking traffic statistics as it provides a global socket
+ * identifier that can be assumed unique.
* Return
* A 8-byte long non-decreasing number on success, or 0 if the
* socket field is missing inside *skb*.
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 3312a5849a97..c13ffbd33d8d 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -19,6 +19,7 @@ static const struct sock_diag_handler *sock_diag_handlers[AF_MAX];
static int (*inet_rcv_compat)(struct sk_buff *skb, struct nlmsghdr *nlh);
static DEFINE_MUTEX(sock_diag_table_mutex);
static struct workqueue_struct *broadcast_wq;
+static atomic64_t cookie_gen;
u64 sock_gen_cookie(struct sock *sk)
{
@@ -27,7 +28,7 @@ u64 sock_gen_cookie(struct sock *sk)
if (res)
return res;
- res = atomic64_inc_return(&sock_net(sk)->cookie_gen);
+ res = atomic64_inc_return(&cookie_gen);
atomic64_cmpxchg(&sk->sk_cookie, 0, res);
}
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] tcp: Update TCP_BASE_MSS comment
From: Neal Cardwell @ 2019-08-08 11:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Josh Hunt, Netdev, David Miller, Eric Dumazet
In-Reply-To: <c1c2febd-742d-4e13-af9f-a7d7ec936ed9@gmail.com>
On Thu, Aug 8, 2019 at 2:13 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 8/8/19 1:52 AM, Josh Hunt wrote:
> > TCP_BASE_MSS is used as the default initial MSS value when MTU probing is
> > enabled. Update the comment to reflect this.
> >
> > Suggested-by: Neal Cardwell <ncardwell@google.com>
> > Signed-off-by: Josh Hunt <johunt@akamai.com>
> > ---
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Josh!
neal
^ permalink raw reply
* Re: [PATCH v2 1/2] tcp: add new tcp_mtu_probe_floor sysctl
From: Neal Cardwell @ 2019-08-08 12:02 UTC (permalink / raw)
To: Josh Hunt; +Cc: Netdev, David Miller, Eric Dumazet
In-Reply-To: <1565221950-1376-1-git-send-email-johunt@akamai.com>
On Wed, Aug 7, 2019 at 7:55 PM Josh Hunt <johunt@akamai.com> wrote:
>
> The current implementation of TCP MTU probing can considerably
> underestimate the MTU on lossy connections allowing the MSS to get down to
> 48. We have found that in almost all of these cases on our networks these
> paths can handle much larger MTUs meaning the connections are being
> artificially limited. Even though TCP MTU probing can raise the MSS back up
> we have seen this not to be the case causing connections to be "stuck" with
> an MSS of 48 when heavy loss is present.
>
> Prior to pushing out this change we could not keep TCP MTU probing enabled
> b/c of the above reasons. Now with a reasonble floor set we've had it
> enabled for the past 6 months.
>
> The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives
> administrators the ability to control the floor of MSS probing.
>
> Signed-off-by: Josh Hunt <johunt@akamai.com>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Josh. I agree with Eric that it would be great if you are able
to share the value that you have found to work well.
neal
^ permalink raw reply
* Re: Clause 73 and USXGMII
From: Russell King - ARM Linux admin @ 2019-08-08 12:09 UTC (permalink / raw)
To: Jose Abreu
Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
Heiner Kallweit
In-Reply-To: <BN8PR12MB3266DF4F017FCB03E6ED8097D3D70@BN8PR12MB3266.namprd12.prod.outlook.com>
On Thu, Aug 08, 2019 at 11:45:29AM +0000, Jose Abreu wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Date: Aug/08/2019, 10:23:13 (UTC+00:00)
>
> > On Thu, Aug 08, 2019 at 09:02:57AM +0000, Jose Abreu wrote:
> > > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > > Date: Aug/08/2019, 09:26:26 (UTC+00:00)
> > >
> > > > Hi,
> > > >
> > > > Have you tried enabling debug mode in phylink (add #define DEBUG at the
> > > > top of the file) ?
> > >
> > > Yes:
> > >
> > > [ With > 2.5G modes removed ]
> > > # dmesg | grep -i phy
> > > libphy: stmmac: probed
> > > stmmaceth 0000:04:00.0 enp4s0: PHY [stmmac-1:00] driver [Synopsys 10G]
> > > stmmaceth 0000:04:00.0 enp4s0: phy: setting supported
> > > 00,00000000,0002e040 advertising 00,00000000,0002e040
> > > stmmaceth 0000:04:00.0 enp4s0: configuring for phy/usxgmii link mode
> > > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config:
> > > mode=phy/usxgmii/Unknown/Unknown adv=00,00000000,0002e040 pause=10
> > > link=0 an=1
> > > stmmaceth 0000:04:00.0 enp4s0: phy link down usxgmii/Unknown/Unknown
> >
> > This shows that the PHY isn't reporting that the link came up. Did
> > the PHY negotiate link? If so, why isn't it reporting that the link
> > came up? Maybe something is mis-programming the capability bits in
> > the PHY? Maybe disabling the 10G speeds disables everything faster
> > than 1G?
>
> Autoneg was started but never finishes and disabling 10G modes is
> causing autoneg to fail.
>
> >
> > > [ Without any limit ]
> > > # dmesg | grep -i phy
> > > libphy: stmmac: probed
> > > stmmaceth 0000:04:00.0 enp4s0: PHY [stmmac-1:00] driver [Synopsys 10G]
> > > stmmaceth 0000:04:00.0 enp4s0: phy: setting supported
> > > 00,00000000,000ee040 advertising 00,00000000,000ee040
> > > stmmaceth 0000:04:00.0 enp4s0: configuring for phy/usxgmii link mode
> > > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config:
> > > mode=phy/usxgmii/Unknown/Unknown adv=00,00000000,000ee040 pause=10
> > > link=0 an=1
> > > stmmaceth 0000:04:00.0 enp4s0: phy link down usxgmii/Unknown/Unknown
> > > stmmaceth 0000:04:00.0 enp4s0: phy link up usxgmii/2.5Gbps/Full
> > > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config:
> > > mode=phy/usxgmii/2.5Gbps/Full adv=00,00000000,00000000 pause=0f link=1
> > > an=0
> > >
> > > I'm thinking on whether this can be related with USXGMII. As link is
> > > operating in 10G but I configure USXGMII for 2.5G maybe autoneg outcome
> > > should always be 10G ?
> >
> > As I understand USXGMII (which isn't very well, because the spec isn't
> > available) I believe that it operates in a similar way to SGMII where
> > data is replicated the appropriate number of times to achieve the link
> > speed. So, the USXGMII link always operates at a bit rate equivalent
> > to 10G, but data is replicated twice for 5G, four times for 2.5G, ten
> > times for 1G, etc.
> >
> > I notice that you don't say that you support any copper speeds, which
> > brings up the question about what the PHY's media is...
>
> I just added the speeds that XPCS supports within Clause 73
> specification:
> Technology Ability field. Indicates the supported technologies:
> A0: When this bit is set to 1, the 1000BASE-KX technology is supported
> A1: When this bit is set to 1, the 10GBASE-KX4 technology is supported
> A2: When this bit is set to 1, the 10GBASE-KR technology is supported
> A11: When this bit is set to 1, the 2.5GBASE-KX technology is supported
> A12: When this bit is set to 1, the 5GBASE-KR technology is supported
>
> And, within USXGMII, XPCS supports the following:
> Single Port: 10G-SXGMII, 5G-SXGMII, 2.5G-SXGMII
> Dual Port: 10G-DXGMII, 5G-DXGMII
> Quad Port: 10G-XGMII
>
> My HW is currently fixed for USXGMII at 2.5G.
So what do you actually have?
+-----+ +----------+
| STM | USXGMII | Synopsis | ????????
| MAC | <----------> | PHY | <----------> ????
| | link | |
+-----+ +----------+ (media side)
Does the above refer to what the STM MAC and Synopsis PHY support for
the USXGMII link? What about the media side?
If you just tell phylink what the USXGMII part is capable of, there's
no way for the media side to do anything unless it also supports the
capabilities that the USXGMII link supports.
phylink doesn't do any kind of translation of capabilities of the
MAC-PHY link to media capabilities; this is why the documentation for
the validate callback has this note:
* Note that the PHY may be able to transform from one connection
* technology to another, so, eg, don't clear 1000BaseX just
* because the MAC is unable to BaseX mode. This is more about
* clearing unsupported speeds and duplex settings.
To put it another way - if the link between the MAC and PHY supports
10G speed, the MAC should indicate that _all_ 10G ethtool link modes
that support 10G speed are set in the supported mask. If the link
supports 1G speeds, then all 1G ethtool link modes that can be
supported irrespective of technology should be set. This is because
the capabilities of the overall setup is the logical union of the
capabilities of each device in the setup.
So, if, say, the USXGMII link can support 2.5Gbps, and the PHY
supports copper media at 2.5Gbps via the NBASE-T specifications,
then the system as a whole can support
ETHTOOL_LINK_MODE_2500baseT_Full_BIT. If the MAC decides to clear
that bit, then the system can't support 2.5Gbps even if the PHY
does.
Maybe what we need to do with phylink is move away from exposing
ethtool link modes to the MAC validate callback, and instead
devise a way for the MAC to indicate merely the speeds and duplexes
it supports without any of the technology stuff getting in the way.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH net v2 2/2] bpf: sync bpf.h to tools infrastructure
From: Daniel Borkmann @ 2019-08-08 11:57 UTC (permalink / raw)
To: davem; +Cc: netdev, bpf, m, edumazet, ast, willemb, Daniel Borkmann
In-Reply-To: <20190808115726.31703-1-daniel@iogearbox.net>
Pull in updates in BPF helper function description.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
tools/include/uapi/linux/bpf.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 4e455018da65..a5aa7d3ac6a1 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1466,8 +1466,8 @@ union bpf_attr {
* If no cookie has been set yet, generate a new cookie. Once
* generated, the socket cookie remains stable for the life of the
* socket. This helper can be useful for monitoring per socket
- * networking traffic statistics as it provides a unique socket
- * identifier per namespace.
+ * networking traffic statistics as it provides a global socket
+ * identifier that can be assumed unique.
* Return
* A 8-byte long non-decreasing number on success, or 0 if the
* socket field is missing inside *skb*.
@@ -1571,8 +1571,11 @@ union bpf_attr {
* but this is only implemented for native XDP (with driver
* support) as of this writing).
*
- * All values for *flags* are reserved for future usage, and must
- * be left at zero.
+ * The lower two bits of *flags* are used as the return code if
+ * the map lookup fails. This is so that the return value can be
+ * one of the XDP program return codes up to XDP_TX, as chosen by
+ * the caller. Any higher bits in the *flags* argument must be
+ * unset.
*
* When used to redirect packets to net devices, this helper
* provides a high performance increase over **bpf_redirect**\ ().
--
2.17.1
^ permalink raw reply related
* RE: [PATCH net-next 5/5] r8152: change rx_frag_head_sz and rx_max_agg_num dynamically
From: Hayes Wang @ 2019-08-08 12:16 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Jakub Kicinski, netdev@vger.kernel.org, nic_swsd,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <20190808134959.00006a58@gmail.com>
Maciej Fijalkowski [mailto:maciejromanfijalkowski@gmail.com]
> Sent: Thursday, August 08, 2019 7:50 PM
[...]
> > Excuse me again.
> > I find the kernel supports the copybreak of Ethtool.
> > However, I couldn't find a command of Ethtool to use it.
>
> Ummm there's set_tunable ops. Amazon's ena driver is making use of it from
> what
> I see. Look at ena_set_tunable() in
> drivers/net/ethernet/amazon/ena/ena_ethtool.c.
The kernel could support it. And I has finished it.
However, when I want to test it by ethtool, I couldn't find suitable command.
I couldn't find relative feature in the source code of ethtool, either.
Best Regards,
Hayes
^ permalink raw reply
* [PATCH v2 04/15] net: phy: adin: add support for interrupts
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
This change adds support for enabling PHY interrupts that can be used by
the PHY framework to get signal for link/speed/auto-negotiation changes.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 45490fbe273b..69000fb16704 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -14,11 +14,45 @@
#define PHY_ID_ADIN1200 0x0283bc20
#define PHY_ID_ADIN1300 0x0283bc30
+#define ADIN1300_INT_MASK_REG 0x0018
+#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
+#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
+#define ADIN1300_INT_ANEG_PAGE_RX_EN BIT(6)
+#define ADIN1300_INT_IDLE_ERR_CNT_EN BIT(5)
+#define ADIN1300_INT_MAC_FIFO_OU_EN BIT(4)
+#define ADIN1300_INT_RX_STAT_CHNG_EN BIT(3)
+#define ADIN1300_INT_LINK_STAT_CHNG_EN BIT(2)
+#define ADIN1300_INT_SPEED_CHNG_EN BIT(1)
+#define ADIN1300_INT_HW_IRQ_EN BIT(0)
+#define ADIN1300_INT_MASK_EN \
+ (ADIN1300_INT_ANEG_STAT_CHNG_EN | ADIN1300_INT_ANEG_PAGE_RX_EN | \
+ ADIN1300_INT_LINK_STAT_CHNG_EN | ADIN1300_INT_SPEED_CHNG_EN | \
+ ADIN1300_INT_HW_IRQ_EN)
+#define ADIN1300_INT_STATUS_REG 0x0019
+
static int adin_config_init(struct phy_device *phydev)
{
return genphy_config_init(phydev);
}
+static int adin_phy_ack_intr(struct phy_device *phydev)
+{
+ /* Clear pending interrupts */
+ int rc = phy_read(phydev, ADIN1300_INT_STATUS_REG);
+
+ return rc < 0 ? rc : 0;
+}
+
+static int adin_phy_config_intr(struct phy_device *phydev)
+{
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ return phy_set_bits(phydev, ADIN1300_INT_MASK_REG,
+ ADIN1300_INT_MASK_EN);
+
+ return phy_clear_bits(phydev, ADIN1300_INT_MASK_REG,
+ ADIN1300_INT_MASK_EN);
+}
+
static struct phy_driver adin_driver[] = {
{
PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
@@ -27,6 +61,8 @@ static struct phy_driver adin_driver[] = {
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.get_features = genphy_read_abilities,
+ .ack_interrupt = adin_phy_ack_intr,
+ .config_intr = adin_phy_config_intr,
.resume = genphy_resume,
.suspend = genphy_suspend,
},
@@ -37,6 +73,8 @@ static struct phy_driver adin_driver[] = {
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.get_features = genphy_read_abilities,
+ .ack_interrupt = adin_phy_ack_intr,
+ .config_intr = adin_phy_config_intr,
.resume = genphy_resume,
.suspend = genphy_suspend,
},
--
2.20.1
^ permalink raw reply related
* [PATCH v2 07/15] net: phy: adin: make RGMII internal delays configurable
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
The internal delays for the RGMII are configurable for both RX & TX. This
change adds support for configuring them via device-tree (or ACPI).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 82 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 9169d6c08383..62c1268e55f7 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -5,11 +5,13 @@
* Copyright 2019 Analog Devices Inc.
*/
#include <linux/kernel.h>
+#include <linux/bitfield.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/mii.h>
#include <linux/phy.h>
+#include <linux/property.h>
#define PHY_ID_ADIN1200 0x0283bc20
#define PHY_ID_ADIN1300 0x0283bc30
@@ -34,15 +36,83 @@
#define ADIN1300_INT_STATUS_REG 0x0019
#define ADIN1300_GE_RGMII_CFG_REG 0xff23
+#define ADIN1300_GE_RGMII_RX_MSK GENMASK(8, 6)
+#define ADIN1300_GE_RGMII_RX_SEL(x) \
+ FIELD_PREP(ADIN1300_GE_RGMII_RX_MSK, x)
+#define ADIN1300_GE_RGMII_GTX_MSK GENMASK(5, 3)
+#define ADIN1300_GE_RGMII_GTX_SEL(x) \
+ FIELD_PREP(ADIN1300_GE_RGMII_GTX_MSK, x)
#define ADIN1300_GE_RGMII_RXID_EN BIT(2)
#define ADIN1300_GE_RGMII_TXID_EN BIT(1)
#define ADIN1300_GE_RGMII_EN BIT(0)
+/* RGMII internal delay settings for rx and tx for ADIN1300 */
+#define ADIN1300_RGMII_1_60_NS 0x0001
+#define ADIN1300_RGMII_1_80_NS 0x0002
+#define ADIN1300_RGMII_2_00_NS 0x0000
+#define ADIN1300_RGMII_2_20_NS 0x0006
+#define ADIN1300_RGMII_2_40_NS 0x0007
+
#define ADIN1300_GE_RMII_CFG_REG 0xff24
#define ADIN1300_GE_RMII_EN BIT(0)
+/**
+ * struct adin_cfg_reg_map - map a config value to aregister value
+ * @cfg value in device configuration
+ * @reg value in the register
+ */
+struct adin_cfg_reg_map {
+ int cfg;
+ int reg;
+};
+
+static const struct adin_cfg_reg_map adin_rgmii_delays[] = {
+ { 1600, ADIN1300_RGMII_1_60_NS },
+ { 1800, ADIN1300_RGMII_1_80_NS },
+ { 2000, ADIN1300_RGMII_2_00_NS },
+ { 2200, ADIN1300_RGMII_2_20_NS },
+ { 2400, ADIN1300_RGMII_2_40_NS },
+ { },
+};
+
+static int adin_lookup_reg_value(const struct adin_cfg_reg_map *tbl, int cfg)
+{
+ size_t i;
+
+ for (i = 0; tbl[i].cfg; i++) {
+ if (tbl[i].cfg == cfg)
+ return tbl[i].reg;
+ }
+
+ return -EINVAL;
+}
+
+static u32 adin_get_reg_value(struct phy_device *phydev,
+ const char *prop_name,
+ const struct adin_cfg_reg_map *tbl,
+ u32 dflt)
+{
+ struct device *dev = &phydev->mdio.dev;
+ u32 val;
+ int rc;
+
+ if (device_property_read_u32(dev, prop_name, &val))
+ return dflt;
+
+ rc = adin_lookup_reg_value(tbl, val);
+ if (rc < 0) {
+ phydev_warn(phydev,
+ "Unsupported value %u for %s using default (%u)\n",
+ val, prop_name, dflt);
+ return dflt;
+ }
+
+ return rc;
+}
+
static int adin_config_rgmii_mode(struct phy_device *phydev)
{
+ u32 val;
int reg;
if (!phy_interface_is_rgmii(phydev))
@@ -59,6 +129,12 @@ static int adin_config_rgmii_mode(struct phy_device *phydev)
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
reg |= ADIN1300_GE_RGMII_RXID_EN;
+
+ val = adin_get_reg_value(phydev, "adi,rx-internal-delay-ps",
+ adin_rgmii_delays,
+ ADIN1300_RGMII_2_00_NS);
+ reg &= ~ADIN1300_GE_RGMII_RX_MSK;
+ reg |= ADIN1300_GE_RGMII_RX_SEL(val);
} else {
reg &= ~ADIN1300_GE_RGMII_RXID_EN;
}
@@ -66,6 +142,12 @@ static int adin_config_rgmii_mode(struct phy_device *phydev)
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
reg |= ADIN1300_GE_RGMII_TXID_EN;
+
+ val = adin_get_reg_value(phydev, "adi,tx-internal-delay-ps",
+ adin_rgmii_delays,
+ ADIN1300_RGMII_2_00_NS);
+ reg &= ~ADIN1300_GE_RGMII_GTX_MSK;
+ reg |= ADIN1300_GE_RGMII_GTX_SEL(val);
} else {
reg &= ~ADIN1300_GE_RGMII_TXID_EN;
}
--
2.20.1
^ permalink raw reply related
* [PATCH v2 06/15] net: phy: adin: configure RGMII/RMII/MII modes on config
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
The ADIN1300 chip supports RGMII, RMII & MII modes. Default (if
unconfigured) is RGMII.
This change adds support for configuring these modes via the device
registers.
For RGMII with internal delays (modes RGMII_ID,RGMII_TXID, RGMII_RXID),
the default delay is 2 ns. This can be configurable and will be done in
a subsequent change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 79 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 78 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index a833e329be6f..9169d6c08383 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -33,9 +33,86 @@
ADIN1300_INT_HW_IRQ_EN)
#define ADIN1300_INT_STATUS_REG 0x0019
+#define ADIN1300_GE_RGMII_CFG_REG 0xff23
+#define ADIN1300_GE_RGMII_RXID_EN BIT(2)
+#define ADIN1300_GE_RGMII_TXID_EN BIT(1)
+#define ADIN1300_GE_RGMII_EN BIT(0)
+
+#define ADIN1300_GE_RMII_CFG_REG 0xff24
+#define ADIN1300_GE_RMII_EN BIT(0)
+
+static int adin_config_rgmii_mode(struct phy_device *phydev)
+{
+ int reg;
+
+ if (!phy_interface_is_rgmii(phydev))
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_GE_RGMII_CFG_REG,
+ ADIN1300_GE_RGMII_EN);
+
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, ADIN1300_GE_RGMII_CFG_REG);
+ if (reg < 0)
+ return reg;
+
+ reg |= ADIN1300_GE_RGMII_EN;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+ reg |= ADIN1300_GE_RGMII_RXID_EN;
+ } else {
+ reg &= ~ADIN1300_GE_RGMII_RXID_EN;
+ }
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ reg |= ADIN1300_GE_RGMII_TXID_EN;
+ } else {
+ reg &= ~ADIN1300_GE_RGMII_TXID_EN;
+ }
+
+ return phy_write_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_GE_RGMII_CFG_REG, reg);
+}
+
+static int adin_config_rmii_mode(struct phy_device *phydev)
+{
+ int reg;
+
+ if (phydev->interface != PHY_INTERFACE_MODE_RMII)
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_GE_RMII_CFG_REG,
+ ADIN1300_GE_RMII_EN);
+
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, ADIN1300_GE_RMII_CFG_REG);
+ if (reg < 0)
+ return reg;
+
+ reg |= ADIN1300_GE_RMII_EN;
+
+ return phy_write_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_GE_RMII_CFG_REG, reg);
+}
+
static int adin_config_init(struct phy_device *phydev)
{
- return genphy_config_init(phydev);
+ int rc;
+
+ rc = genphy_config_init(phydev);
+ if (rc < 0)
+ return rc;
+
+ rc = adin_config_rgmii_mode(phydev);
+ if (rc < 0)
+ return rc;
+
+ rc = adin_config_rmii_mode(phydev);
+ if (rc < 0)
+ return rc;
+
+ phydev_dbg(phydev, "PHY is using mode '%s'\n",
+ phy_modes(phydev->interface));
+
+ return 0;
}
static int adin_phy_ack_intr(struct phy_device *phydev)
--
2.20.1
^ permalink raw reply related
* [PATCH v2 10/15] net: phy: adin: add EEE translation layer from Clause 45 to Clause 22
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
The ADIN1200 & ADIN1300 PHYs support EEE by using standard Clause 45 access
to access MMD registers for EEE.
The EEE register addresses (when using Clause 22) are available at
different addresses (than Clause 45), and since accessing these regs (via
Clause 22) needs a special mechanism, a translation table is required to
convert these addresses.
For Clause 45, this is not needed; the addresses are available as specified
by IEEE.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 69 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 69ef53bbecc3..c1cea1b6bd75 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -42,6 +42,17 @@
#define ADIN1300_PHY_STATUS1 0x001a
#define ADIN1300_PAIR_01_SWAP BIT(11)
+/* EEE register addresses, accessible via Clause 22 access using
+ * ADIN1300_MII_EXT_REG_PTR & ADIN1300_MII_EXT_REG_DATA.
+ * The bit-fields are the same as specified by IEEE, and can be
+ * accessed via standard Clause 45 access.
+ */
+#define ADIN1300_EEE_CAP_REG 0x8000
+#define ADIN1300_EEE_ADV_REG 0x8001
+#define ADIN1300_EEE_LPABLE_REG 0x8002
+#define ADIN1300_CLOCK_STOP_REG 0x9400
+#define ADIN1300_LPI_WAKE_ERR_CNT_REG 0xa000
+
#define ADIN1300_GE_RGMII_CFG_REG 0xff23
#define ADIN1300_GE_RGMII_RX_MSK GENMASK(8, 6)
#define ADIN1300_GE_RGMII_RX_SEL(x) \
@@ -103,6 +114,26 @@ static const struct adin_cfg_reg_map adin_rmii_fifo_depths[] = {
{ },
};
+/**
+ * struct adin_clause45_mmd_map - map to convert Clause 45 regs to Clause 22
+ * @devad device address used in Clause 45 access
+ * @cl45_regnum register address defined by Clause 45
+ * @adin_regnum equivalent register address accessible via Clause 22
+ */
+struct adin_clause45_mmd_map {
+ int devad;
+ u16 cl45_regnum;
+ u16 adin_regnum;
+};
+
+static struct adin_clause45_mmd_map adin_clause45_mmd_map[] = {
+ { MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE, ADIN1300_EEE_CAP_REG },
+ { MDIO_MMD_AN, MDIO_AN_EEE_LPABLE, ADIN1300_EEE_LPABLE_REG },
+ { MDIO_MMD_AN, MDIO_AN_EEE_ADV, ADIN1300_EEE_ADV_REG },
+ { MDIO_MMD_PCS, MDIO_CTRL1, ADIN1300_CLOCK_STOP_REG },
+ { MDIO_MMD_PCS, MDIO_PCS_EEE_WK_ERR, ADIN1300_LPI_WAKE_ERR_CNT_REG },
+};
+
static int adin_lookup_reg_value(const struct adin_cfg_reg_map *tbl, int cfg)
{
size_t i;
@@ -253,10 +284,33 @@ static int adin_phy_config_intr(struct phy_device *phydev)
ADIN1300_INT_MASK_EN);
}
+static int adin_cl45_to_adin_reg(struct phy_device *phydev, int devad,
+ u16 cl45_regnum)
+{
+ struct adin_clause45_mmd_map *m;
+ int i;
+
+ if (devad == MDIO_MMD_VEND1)
+ return cl45_regnum;
+
+ for (i = 0; i < ARRAY_SIZE(adin_clause45_mmd_map); i++) {
+ m = &adin_clause45_mmd_map[i];
+ if (m->devad == devad && m->cl45_regnum == cl45_regnum)
+ return m->adin_regnum;
+ }
+
+ phydev_err(phydev,
+ "No translation available for devad: %d reg: %04x\n",
+ devad, cl45_regnum);
+
+ return -EINVAL;
+}
+
static int adin_read_mmd(struct phy_device *phydev, int devad, u16 regnum)
{
struct mii_bus *bus = phydev->mdio.bus;
int phy_addr = phydev->mdio.addr;
+ int adin_regnum;
int err;
if (phydev->is_c45) {
@@ -265,7 +319,12 @@ static int adin_read_mmd(struct phy_device *phydev, int devad, u16 regnum)
return __mdiobus_read(bus, phy_addr, addr);
}
- err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR, regnum);
+ adin_regnum = adin_cl45_to_adin_reg(phydev, devad, regnum);
+ if (adin_regnum < 0)
+ return adin_regnum;
+
+ err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR,
+ adin_regnum);
if (err)
return err;
@@ -277,6 +336,7 @@ static int adin_write_mmd(struct phy_device *phydev, int devad, u16 regnum,
{
struct mii_bus *bus = phydev->mdio.bus;
int phy_addr = phydev->mdio.addr;
+ int adin_regnum;
int err;
if (phydev->is_c45) {
@@ -285,7 +345,12 @@ static int adin_write_mmd(struct phy_device *phydev, int devad, u16 regnum,
return __mdiobus_write(bus, phy_addr, addr, val);
}
- err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR, regnum);
+ adin_regnum = adin_cl45_to_adin_reg(phydev, devad, regnum);
+ if (adin_regnum < 0)
+ return adin_regnum;
+
+ err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR,
+ adin_regnum);
if (err)
return err;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 13/15] net: phy: adin: configure downshift on config_init
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
Down-speed auto-negotiation may not always be enabled, in which case the
PHY won't down-shift to 100 or 10 during auto-negotiation.
This change enables downshift and configures the number of retries to
default 8 (maximum supported value).
The change has been adapted from the Marvell PHY driver.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index bc4393195de7..d6d1f5037eb7 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -29,6 +29,18 @@
#define ADIN1300_NRG_PD_TX_EN BIT(2)
#define ADIN1300_NRG_PD_STATUS BIT(1)
+#define ADIN1300_PHY_CTRL2 0x0016
+#define ADIN1300_DOWNSPEED_AN_100_EN BIT(11)
+#define ADIN1300_DOWNSPEED_AN_10_EN BIT(10)
+#define ADIN1300_GROUP_MDIO_EN BIT(6)
+#define ADIN1300_DOWNSPEEDS_EN \
+ (ADIN1300_DOWNSPEED_AN_100_EN | ADIN1300_DOWNSPEED_AN_10_EN)
+
+#define ADIN1300_PHY_CTRL3 0x0017
+#define ADIN1300_LINKING_EN BIT(13)
+#define ADIN1300_DOWNSPEED_RETRIES_MSK GENMASK(12, 10)
+#define ADIN1300_DOWNSPEED_RETRIES_OFF 10
+
#define ADIN1300_INT_MASK_REG 0x0018
#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
@@ -259,6 +271,29 @@ static int adin_config_rmii_mode(struct phy_device *phydev)
ADIN1300_GE_RMII_CFG_REG, reg);
}
+static int adin_config_down_shift(struct phy_device *phydev, bool enable,
+ u8 retries)
+{
+ u16 mask, set;
+ int rc;
+
+ if (!enable)
+ return phy_clear_bits(phydev, ADIN1300_PHY_CTRL2,
+ ADIN1300_DOWNSPEEDS_EN);
+
+ mask = ADIN1300_LINKING_EN | ADIN1300_DOWNSPEED_RETRIES_MSK;
+ set = (retries << ADIN1300_DOWNSPEED_RETRIES_OFF);
+ set &= ADIN1300_DOWNSPEED_RETRIES_MSK;
+ set |= ADIN1300_LINKING_EN;
+
+ rc = phy_modify_changed(phydev, ADIN1300_PHY_CTRL3, mask, set);
+ if (rc < 0)
+ return rc;
+
+ return phy_set_bits(phydev, ADIN1300_PHY_CTRL2,
+ ADIN1300_DOWNSPEEDS_EN);
+}
+
static int adin_config_init_edpd(struct phy_device *phydev)
{
struct adin_priv *priv = phydev->priv;
@@ -289,6 +324,10 @@ static int adin_config_init(struct phy_device *phydev)
if (rc < 0)
return rc;
+ rc = adin_config_down_shift(phydev, true, 8);
+ if (rc < 0)
+ return rc;
+
rc = adin_config_init_edpd(phydev);
if (rc < 0)
return rc;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 15/15] dt-bindings: net: add bindings for ADIN PHY driver
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
This change adds bindings for the Analog Devices ADIN PHY driver, detailing
all the properties implemented by the driver.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
.../devicetree/bindings/net/adi,adin.yaml | 76 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/adi,adin.yaml
diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml b/Documentation/devicetree/bindings/net/adi,adin.yaml
new file mode 100644
index 000000000000..86177c8fe23a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/adi,adin.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: GPL-2.0+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/adi,adin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADIN1200/ADIN1300 PHY
+
+maintainers:
+ - Alexandru Ardelean <alexandru.ardelean@analog.com>
+
+description: |
+ Bindings for Analog Devices Industrial Ethernet PHYs
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ adi,rx-internal-delay-ps:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ RGMII RX Clock Delay used only when PHY operates in RGMII mode with
+ internal delay (phy-mode is 'rgmii-id' or 'rgmii-rxid') in pico-seconds.
+ enum: [ 1600, 1800, 2000, 2200, 2400 ]
+ default: 2000
+
+ adi,tx-internal-delay-ps:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ RGMII TX Clock Delay used only when PHY operates in RGMII mode with
+ internal delay (phy-mode is 'rgmii-id' or 'rgmii-txid') in pico-seconds.
+ enum: [ 1600, 1800, 2000, 2200, 2400 ]
+ default: 2000
+
+ adi,fifo-depth-bits:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ When operating in RMII mode, this option configures the FIFO depth.
+ enum: [ 4, 8, 12, 16, 20, 24 ]
+ default: 8
+
+ adi,disable-energy-detect:
+ description: |
+ Disables Energy Detect Powerdown Mode (default disabled, i.e energy detect
+ is enabled if this property is unspecified)
+ type: boolean
+
+examples:
+ - |
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-mode = "rgmii-id";
+
+ ethernet-phy@0 {
+ reg = <0>;
+
+ adi,rx-internal-delay-ps = <1800>;
+ adi,tx-internal-delay-ps = <2200>;
+ };
+ };
+ - |
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-mode = "rmii";
+
+ ethernet-phy@1 {
+ reg = <1>;
+
+ adi,fifo-depth-bits = <16>;
+ adi,disable-energy-detect;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index e8aa8a667864..fd9ab61c2670 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -944,6 +944,7 @@ L: netdev@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/net/phy/adin.c
+F: Documentation/devicetree/bindings/net/adi,adin.yaml
ANALOG DEVICES INC ADIS DRIVER LIBRARY
M: Alexandru Ardelean <alexandru.ardelean@analog.com>
--
2.20.1
^ permalink raw reply related
* [PATCH v2 14/15] net: phy: adin: add ethtool get_stats support
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
This change implements retrieving all the error counters from the PHY.
The PHY supports several error counters/stats. The `Mean Square Errors`
status values are only valie when a link is established, and shouldn't be
accumulated. These values characterize the quality of a signal.
The rest of the error counters are self-clearing on read.
Most of them are reports from the Frame Checker engine that the PHY has.
Not retrieving the `LPI Wake Error Count Register` here, since that is used
by the PHY framework to check for any EEE errors. And that register is
self-clearing when read (as per IEEE spec).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 109 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 109 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index d6d1f5037eb7..d170d1e837b5 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -155,12 +155,40 @@ static struct adin_clause45_mmd_map adin_clause45_mmd_map[] = {
{ MDIO_MMD_PCS, MDIO_PCS_EEE_WK_ERR, ADIN1300_LPI_WAKE_ERR_CNT_REG },
};
+struct adin_hw_stat {
+ const char *string;
+ u16 reg1;
+ u16 reg2;
+ bool do_not_accumulate;
+};
+
+/* Named just like in the datasheet */
+static struct adin_hw_stat adin_hw_stats[] = {
+ { "RxErrCnt", 0x0014, },
+ { "MseA", 0x8402, 0, true },
+ { "MseB", 0x8403, 0, true },
+ { "MseC", 0x8404, 0, true },
+ { "MseD", 0x8405, 0, true },
+ { "FcFrmCnt", 0x940A, 0x940B }, /* FcFrmCntH + FcFrmCntL */
+ { "FcLenErrCnt", 0x940C },
+ { "FcAlgnErrCnt", 0x940D },
+ { "FcSymbErrCnt", 0x940E },
+ { "FcOszCnt", 0x940F },
+ { "FcUszCnt", 0x9410 },
+ { "FcOddCnt", 0x9411 },
+ { "FcOddPreCnt", 0x9412 },
+ { "FcDribbleBitsCnt", 0x9413 },
+ { "FcFalseCarrierCnt", 0x9414 },
+};
+
/**
* struct adin_priv - ADIN PHY driver private data
* edpd_enabled true if Energy Detect Powerdown mode is enabled
+ * stats statistic counters for the PHY
*/
struct adin_priv {
bool edpd_enabled;
+ u64 stats[ARRAY_SIZE(adin_hw_stats)];
};
static int adin_lookup_reg_value(const struct adin_cfg_reg_map *tbl, int cfg)
@@ -561,6 +589,81 @@ static int adin_reset(struct phy_device *phydev)
return adin_subsytem_soft_reset(phydev);
}
+static int adin_get_sset_count(struct phy_device *phydev)
+{
+ return ARRAY_SIZE(adin_hw_stats);
+}
+
+static void adin_get_strings(struct phy_device *phydev, u8 *data)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(adin_hw_stats); i++) {
+ strlcpy(&data[i * ETH_GSTRING_LEN],
+ adin_hw_stats[i].string, ETH_GSTRING_LEN);
+ }
+}
+
+static int adin_read_mmd_stat_regs(struct phy_device *phydev,
+ struct adin_hw_stat *stat,
+ u32 *val)
+{
+ int ret;
+
+ ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg1);
+ if (ret < 0)
+ return ret;
+
+ *val = (ret & 0xffff);
+
+ if (stat->reg2 == 0)
+ return 0;
+
+ ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg2);
+ if (ret < 0)
+ return ret;
+
+ *val <<= 16;
+ *val |= (ret & 0xffff);
+
+ return 0;
+}
+
+static u64 adin_get_stat(struct phy_device *phydev, int i)
+{
+ struct adin_hw_stat *stat = &adin_hw_stats[i];
+ struct adin_priv *priv = phydev->priv;
+ u32 val;
+ int ret;
+
+ if (stat->reg1 > 0x1f) {
+ ret = adin_read_mmd_stat_regs(phydev, stat, &val);
+ if (ret < 0)
+ return (u64)(~0);
+ } else {
+ ret = phy_read(phydev, stat->reg1);
+ if (ret < 0)
+ return (u64)(~0);
+ val = (ret & 0xffff);
+ }
+
+ if (stat->do_not_accumulate)
+ priv->stats[i] = val;
+ else
+ priv->stats[i] += val;
+
+ return priv->stats[i];
+}
+
+static void adin_get_stats(struct phy_device *phydev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(adin_hw_stats); i++)
+ data[i] = adin_get_stat(phydev, i);
+}
+
static int adin_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
@@ -588,6 +691,9 @@ static struct phy_driver adin_driver[] = {
.get_features = genphy_read_abilities,
.ack_interrupt = adin_phy_ack_intr,
.config_intr = adin_phy_config_intr,
+ .get_sset_count = adin_get_sset_count,
+ .get_strings = adin_get_strings,
+ .get_stats = adin_get_stats,
.resume = genphy_resume,
.suspend = genphy_suspend,
.read_mmd = adin_read_mmd,
@@ -603,6 +709,9 @@ static struct phy_driver adin_driver[] = {
.get_features = genphy_read_abilities,
.ack_interrupt = adin_phy_ack_intr,
.config_intr = adin_phy_config_intr,
+ .get_sset_count = adin_get_sset_count,
+ .get_strings = adin_get_strings,
+ .get_stats = adin_get_stats,
.resume = genphy_resume,
.suspend = genphy_suspend,
.read_mmd = adin_read_mmd,
--
2.20.1
^ permalink raw reply related
* [PATCH v2 12/15] net: phy: adin: implement Energy Detect Powerdown mode
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
The ADIN PHYs support Energy Detect Powerdown mode, which puts the PHY into
a low power mode when there is no signal on the wire (typically cable
unplugged).
This behavior is enabled by default, but can be disabled via device
property.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index f276d692bdee..bc4393195de7 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -24,6 +24,11 @@
#define ADIN1300_AUTO_MDI_EN BIT(10)
#define ADIN1300_MAN_MDIX_EN BIT(9)
+#define ADIN1300_PHY_CTRL_STATUS2 0x0015
+#define ADIN1300_NRG_PD_EN BIT(3)
+#define ADIN1300_NRG_PD_TX_EN BIT(2)
+#define ADIN1300_NRG_PD_STATUS BIT(1)
+
#define ADIN1300_INT_MASK_REG 0x0018
#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
@@ -138,6 +143,14 @@ static struct adin_clause45_mmd_map adin_clause45_mmd_map[] = {
{ MDIO_MMD_PCS, MDIO_PCS_EEE_WK_ERR, ADIN1300_LPI_WAKE_ERR_CNT_REG },
};
+/**
+ * struct adin_priv - ADIN PHY driver private data
+ * edpd_enabled true if Energy Detect Powerdown mode is enabled
+ */
+struct adin_priv {
+ bool edpd_enabled;
+};
+
static int adin_lookup_reg_value(const struct adin_cfg_reg_map *tbl, int cfg)
{
size_t i;
@@ -246,6 +259,18 @@ static int adin_config_rmii_mode(struct phy_device *phydev)
ADIN1300_GE_RMII_CFG_REG, reg);
}
+static int adin_config_init_edpd(struct phy_device *phydev)
+{
+ struct adin_priv *priv = phydev->priv;
+
+ if (priv->edpd_enabled)
+ return phy_set_bits(phydev, ADIN1300_PHY_CTRL_STATUS2,
+ (ADIN1300_NRG_PD_EN | ADIN1300_NRG_PD_TX_EN));
+
+ return phy_clear_bits(phydev, ADIN1300_PHY_CTRL_STATUS2,
+ (ADIN1300_NRG_PD_EN | ADIN1300_NRG_PD_TX_EN));
+}
+
static int adin_config_init(struct phy_device *phydev)
{
int rc;
@@ -264,6 +289,10 @@ static int adin_config_init(struct phy_device *phydev)
if (rc < 0)
return rc;
+ rc = adin_config_init_edpd(phydev);
+ if (rc < 0)
+ return rc;
+
phydev_dbg(phydev, "PHY is using mode '%s'\n",
phy_modes(phydev->interface));
@@ -495,6 +524,17 @@ static int adin_reset(struct phy_device *phydev)
static int adin_probe(struct phy_device *phydev)
{
+ struct device *dev = &phydev->mdio.dev;
+ struct adin_priv *priv;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->edpd_enabled =
+ device_property_read_bool(dev, "adi,disable-energy-detect");
+ phydev->priv = priv;
+
return adin_reset(phydev);
}
--
2.20.1
^ permalink raw reply related
* [PATCH v2 11/15] net: phy: adin: implement PHY subsystem software reset
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
The ADIN PHYs supports 4 types of reset:
1. The standard PHY reset via BMCR_RESET bit in MII_BMCR reg
2. Reset via GPIO
3. Reset via reg GeSftRst (0xff0c) & reload previous pin configs
4. Reset via reg GeSftRst (0xff0c) & request new pin configs
Resets 2 & 4 are almost identical, with the exception that the crystal
oscillator is available during reset for 2.
As it turns out, phylib already supports GPIO reset.
In case this is configured, the PHY driver won't do anything. In case it
isn't specified the subsystem software reset will kick in.
Resetting via GeSftRst or via GPIO is useful when doing a warm reboot,
because this will reset the subsystem registers to default values.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 43 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index c1cea1b6bd75..f276d692bdee 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -6,6 +6,7 @@
*/
#include <linux/kernel.h>
#include <linux/bitfield.h>
+#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/module.h>
@@ -53,6 +54,9 @@
#define ADIN1300_CLOCK_STOP_REG 0x9400
#define ADIN1300_LPI_WAKE_ERR_CNT_REG 0xa000
+#define ADIN1300_GE_SOFT_RESET_REG 0xff0c
+#define ADIN1300_GE_SOFT_RESET BIT(0)
+
#define ADIN1300_GE_RGMII_CFG_REG 0xff23
#define ADIN1300_GE_RGMII_RX_MSK GENMASK(8, 6)
#define ADIN1300_GE_RGMII_RX_SEL(x) \
@@ -457,11 +461,49 @@ static int adin_read_status(struct phy_device *phydev)
return genphy_read_status(phydev);
}
+static int adin_subsytem_soft_reset(struct phy_device *phydev)
+{
+ int reg, rc, i;
+
+ rc = phy_set_bits_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_GE_SOFT_RESET_REG,
+ ADIN1300_GE_SOFT_RESET);
+ if (rc < 0)
+ return rc;
+
+ for (i = 0; i < 20; i++) {
+ usleep_range(500, 1000);
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_GE_SOFT_RESET_REG);
+ if (reg < 0 || (reg & ADIN1300_GE_SOFT_RESET))
+ continue;
+ return 0;
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int adin_reset(struct phy_device *phydev)
+{
+ /* If there is a reset GPIO just exit */
+ if (!IS_ERR_OR_NULL(phydev->mdio.reset_gpio))
+ return 0;
+
+ /* Reset PHY core regs & subsystem regs */
+ return adin_subsytem_soft_reset(phydev);
+}
+
+static int adin_probe(struct phy_device *phydev)
+{
+ return adin_reset(phydev);
+}
+
static struct phy_driver adin_driver[] = {
{
PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
.name = "ADIN1200",
.config_init = adin_config_init,
+ .probe = adin_probe,
.config_aneg = adin_config_aneg,
.read_status = adin_read_status,
.get_features = genphy_read_abilities,
@@ -476,6 +518,7 @@ static struct phy_driver adin_driver[] = {
PHY_ID_MATCH_MODEL(PHY_ID_ADIN1300),
.name = "ADIN1300",
.config_init = adin_config_init,
+ .probe = adin_probe,
.config_aneg = adin_config_aneg,
.read_status = adin_read_status,
.get_features = genphy_read_abilities,
--
2.20.1
^ permalink raw reply related
* [PATCH v2 09/15] net: phy: adin: add support MDI/MDIX/Auto-MDI selection
From: Alexandru Ardelean @ 2019-08-08 12:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
The ADIN PHYs support automatic MDI/MDIX negotiation. By default this is
disabled, so this is enabled at `config_init`.
This is controlled via the PHY Control 1 register.
The supported modes are:
1. Manual MDI
2. Manual MDIX
3. Auto MDIX - prefer MDIX
4. Auto MDIX - prefer MDI
The phydev mdix & mdix_ctrl fields include modes 3 & 4 into a single
auto-mode. So, the default mode this driver enables is 4 when Auto-MDI mode
is used.
When detecting MDI/MDIX mode, a combination of the PHY Control 1 register
and PHY Status 1 register is used to determine the correct MDI/MDIX mode.
If Auto-MDI mode is not set, then the manual MDI/MDIX mode is returned.
If Auto-MDI mode is set, then MDIX mode is returned differs from the
preferred MDI/MDIX mode.
This covers all cases where:
1. MDI preferred & Pair01Swapped == MDIX
2. MDIX preferred & Pair01Swapped == MDI
3. MDI preferred & ! Pair01Swapped == MDIX
4. MDIX preferred & ! Pair01Swapped == MDI
The preferred MDI/MDIX mode is not configured via SW, but can be configured
via HW pins. Note that the `Pair01Swapped` is the Green-Yellow physical
pairs.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 117 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 113 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 26b2f2b21596..69ef53bbecc3 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -19,6 +19,10 @@
#define ADIN1300_MII_EXT_REG_PTR 0x0010
#define ADIN1300_MII_EXT_REG_DATA 0x0011
+#define ADIN1300_PHY_CTRL1 0x0012
+#define ADIN1300_AUTO_MDI_EN BIT(10)
+#define ADIN1300_MAN_MDIX_EN BIT(9)
+
#define ADIN1300_INT_MASK_REG 0x0018
#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
@@ -35,6 +39,9 @@
ADIN1300_INT_HW_IRQ_EN)
#define ADIN1300_INT_STATUS_REG 0x0019
+#define ADIN1300_PHY_STATUS1 0x001a
+#define ADIN1300_PAIR_01_SWAP BIT(11)
+
#define ADIN1300_GE_RGMII_CFG_REG 0xff23
#define ADIN1300_GE_RGMII_RX_MSK GENMASK(8, 6)
#define ADIN1300_GE_RGMII_RX_SEL(x) \
@@ -208,6 +215,8 @@ static int adin_config_init(struct phy_device *phydev)
{
int rc;
+ phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
+
rc = genphy_config_init(phydev);
if (rc < 0)
return rc;
@@ -283,13 +292,113 @@ static int adin_write_mmd(struct phy_device *phydev, int devad, u16 regnum,
return __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_DATA, val);
}
+static int adin_config_mdix(struct phy_device *phydev)
+{
+ bool auto_en, mdix_en;
+ int reg;
+
+ mdix_en = false;
+ auto_en = false;
+ switch (phydev->mdix_ctrl) {
+ case ETH_TP_MDI:
+ break;
+ case ETH_TP_MDI_X:
+ mdix_en = true;
+ break;
+ case ETH_TP_MDI_AUTO:
+ auto_en = true;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ reg = phy_read(phydev, ADIN1300_PHY_CTRL1);
+ if (reg < 0)
+ return reg;
+
+ if (mdix_en)
+ reg |= ADIN1300_MAN_MDIX_EN;
+ else
+ reg &= ~ADIN1300_MAN_MDIX_EN;
+
+ if (auto_en)
+ reg |= ADIN1300_AUTO_MDI_EN;
+ else
+ reg &= ~ADIN1300_AUTO_MDI_EN;
+
+ return phy_write(phydev, ADIN1300_PHY_CTRL1, reg);
+}
+
+static int adin_config_aneg(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = adin_config_mdix(phydev);
+ if (ret)
+ return ret;
+
+ return genphy_config_aneg(phydev);
+}
+
+static int adin_mdix_update(struct phy_device *phydev)
+{
+ bool auto_en, mdix_en;
+ bool swapped;
+ int reg;
+
+ reg = phy_read(phydev, ADIN1300_PHY_CTRL1);
+ if (reg < 0)
+ return reg;
+
+ auto_en = !!(reg & ADIN1300_AUTO_MDI_EN);
+ mdix_en = !!(reg & ADIN1300_MAN_MDIX_EN);
+
+ /* If MDI/MDIX is forced, just read it from the control reg */
+ if (!auto_en) {
+ if (mdix_en)
+ phydev->mdix = ETH_TP_MDI_X;
+ else
+ phydev->mdix = ETH_TP_MDI;
+ return 0;
+ }
+
+ /**
+ * Otherwise, we need to deduce it from the PHY status2 reg.
+ * When Auto-MDI is enabled, the ADIN1300_MAN_MDIX_EN bit implies
+ * a preference for MDIX when it is set.
+ */
+ reg = phy_read(phydev, ADIN1300_PHY_STATUS1);
+ if (reg < 0)
+ return reg;
+
+ swapped = !!(reg & ADIN1300_PAIR_01_SWAP);
+
+ if (mdix_en != swapped)
+ phydev->mdix = ETH_TP_MDI_X;
+ else
+ phydev->mdix = ETH_TP_MDI;
+
+ return 0;
+}
+
+static int adin_read_status(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = adin_mdix_update(phydev);
+ if (ret < 0)
+ return ret;
+
+ return genphy_read_status(phydev);
+}
+
static struct phy_driver adin_driver[] = {
{
PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
.name = "ADIN1200",
.config_init = adin_config_init,
- .config_aneg = genphy_config_aneg,
- .read_status = genphy_read_status,
+ .config_aneg = adin_config_aneg,
+ .read_status = adin_read_status,
.get_features = genphy_read_abilities,
.ack_interrupt = adin_phy_ack_intr,
.config_intr = adin_phy_config_intr,
@@ -302,8 +411,8 @@ static struct phy_driver adin_driver[] = {
PHY_ID_MATCH_MODEL(PHY_ID_ADIN1300),
.name = "ADIN1300",
.config_init = adin_config_init,
- .config_aneg = genphy_config_aneg,
- .read_status = genphy_read_status,
+ .config_aneg = adin_config_aneg,
+ .read_status = adin_read_status,
.get_features = genphy_read_abilities,
.ack_interrupt = adin_phy_ack_intr,
.config_intr = adin_phy_config_intr,
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox