The PHY driver entry for BCM50160 and BCM50610M calls
bcm54xx_config_init() but does not call bcm54xx_config_clock_delay() in
order to configuration appropriate clock delays on the PHY, fix that.
Fixes: 76262b28 ("net: phy: Allow BCM5481x PHYs to setup internal TX/RX
clock delay")
Hi folks!
vger seems to be randomly inserting many-hour delays on forwarding
emails which also renders patchwork pretty hard to use.
Sorry if there are delays or mistakes in applying patches, the issue
has been known (and repeatedly reported) for the last two weeks, and
it's ge
Newer SoCs starting with the Amlogic Meson G12A have more a precise
RGMII RX delay configuration register. This means more complexity in the
code. Extract the existing RGMII delay configuration code into a
separate function to make it easier to read/understand even when adding
more logic in the fut
Newer SoCs starting with the Amlogic Meson G12A have more a precise
RGMII RX delay configuration register. This means more complexity in the
code. Extract the existing RGMII delay configuration code into a
separate function to make it easier to read/understand even when adding
more logic in the fut
On 11/15/20 10:52 AM, Martin Blumenstingl wrote:
> Newer SoCs starting with the Amlogic Meson G12A have more a precise
> RGMII RX delay configuration register. This means more complexity in the
> code. Extract the existing RGMII delay configuration code into a
> separate function to make it easier
On Sun, Nov 15, 2020 at 07:52:09PM +0100, Martin Blumenstingl wrote:
> Newer SoCs starting with the Amlogic Meson G12A have more a precise
> RGMII RX delay configuration register. This means more complexity in the
> code. Extract the existing RGMII delay configuration code into a
> separate functio
Newer SoCs starting with the Amlogic Meson G12A have more a precise
RGMII RX delay configuration register. This means more complexity in the
code. Extract the existing RGMII delay configuration code into a
separate function to make it easier to read/understand even when adding
more logic in the fut
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
David
Thanks for the review
On 6/22/20 5:40 PM, David Miller wrote:
From: Dan Murphy
Date: Fri, 19 Jun 2020 11:18:09 -0500
@@ -162,6 +162,19 @@ properties:
description:
Specifies a reference to a node representing a SFP cage.
+
+ rx-internal-delay-ps:
Do you really want t
From: Dan Murphy
Date: Fri, 19 Jun 2020 11:18:09 -0500
> @@ -162,6 +162,19 @@ properties:
> description:
>Specifies a reference to a node representing a SFP cage.
>
> +
> + rx-internal-delay-ps:
Do you really want two empty lines between these two sections?
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
des is specified, because the delays are
a function of "the other side" of the link.
So, the proposal that macb should limit itself to only accepting
"rgmii" in it's _local_ phy-mode property because the _local_ MAC
does not support delays is wrong.
--
RMK's Patch syst
ave a RGMII conformant link is to
>>>>> have the PCB traces induce the necessary delay. That errs towards
>>>>> PHY_INTERFACE_MODE_RGMII for this case.
>>>>
>>>> Yes.
>>>>
>>>>> However, considering the MAC-to-PHY RGM
_INTERFACE_MODE_RGMII for this case.
> >>
> >> Yes.
> >>
> >>> However, considering the MAC-to-PHY RGMII fixed link case, where the
> >>> PHY may not be accessible, and may be configured with the necessary
> >>> delay, should that case a
MAC end) or
>>> specified in the PHY node (to be applied only at the PHY end.)
>>> In the normal case, this would be the standard delay value, but
>>> in exceptional cases where supported, the delays can be arbitary.
>>> We know there are PHYs out there which a
On 6/17/2020 4:57 AM, Russell King - ARM Linux admin wrote:
> On Wed, Jun 17, 2020 at 02:38:25PM +0300, Vladimir Oltean wrote:
>> On Wed, 17 Jun 2020 at 14:34, Russell King - ARM Linux admin
>> wrote:
>>>
>>
>>>
>>> Why are you so abrasive?
>>>
>>> Not responding to this until you start behavin
, and may be configured with the necessary
>>> delay, should that case also use PHY_INTERFACE_MODE_RGMII - clearly
>>> that would be as wrong as using PHY_INTERFACE_MODE_RGMII_ID would
>>> be for the MAC-to-MAC RGMII with PCB-delays case.
>>
>> If you tak
Andrew
On 6/17/20 9:01 PM, Andrew Lunn wrote:
On Wed, Jun 17, 2020 at 01:20:14PM -0500, Dan Murphy wrote:
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or
> In the normal case, this would be the standard delay value, but
> > in exceptional cases where supported, the delays can be arbitary.
> > We know there are PHYs out there which allow other delays.
> >
> > This means each end is responsible for parsing these properties in
>
= ;
> rgmii-rx-delay-ps = ;
>
> specified in the MAC node (to be applied only at the MAC end) or
> specified in the PHY node (to be applied only at the PHY end.)
> In the normal case, this would be the standard delay value, but
> in exceptional cases where supported, the delays can be a
se.
>
> Yes.
>
> > However, considering the MAC-to-PHY RGMII fixed link case, where the
> > PHY may not be accessible, and may be configured with the necessary
> > delay, should that case also use PHY_INTERFACE_MODE_RGMII - clearly
> > that would be as wrong as using PHY_
ixed link case, where the
> PHY may not be accessible, and may be configured with the necessary
> delay, should that case also use PHY_INTERFACE_MODE_RGMII - clearly
> that would be as wrong as using PHY_INTERFACE_MODE_RGMII_ID would
> be for the MAC-to-MAC RGMII with PCB-delays case.
If
On Wed, Jun 17, 2020 at 01:20:14PM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes
On Wed, Jun 17, 2020 at 01:20:14PM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
On 16/06/2020 at 09:49, Helmut Grohne wrote:
The macb driver does not support configuring rgmii delays. At least for
the Zynq GEM, delays are not supported by the hardware at all. However,
the driver happily accepts and ignores any such delays.
When operating in a mac to phy connection, the
, the only way to have a RGMII conformant link is to
have the PCB traces induce the necessary delay. That errs towards
PHY_INTERFACE_MODE_RGMII for this case.
However, considering the MAC-to-PHY RGMII fixed link case, where the
PHY may not be accessible, and may be configured with the necessary
de
On Wed, Jun 17, 2020 at 02:38:25PM +0300, Vladimir Oltean wrote:
> On Wed, 17 Jun 2020 at 14:34, Russell King - ARM Linux admin
> wrote:
> >
>
> >
> > Why are you so abrasive?
> >
> > Not responding to this until you start behaving more reasonably.
> >
> > --
> > RMK's Patch system: https://www.a
On Wed, Jun 17, 2020 at 01:40:25PM +0200, Russell King - ARM Linux admin wrote:
> > For a fixed-link, the validation function is never called. Therefore, it
> > cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice.
>
> Hmm, I'm not so sure, but then I don't know exactly what code you're
>
On Wed, Jun 17, 2020 at 01:21:53PM +0200, Helmut Grohne wrote:
> On Wed, Jun 17, 2020 at 12:55:18PM +0200, Russell King - ARM Linux admin
> wrote:
> > The individual RGMII delay modes are more about what the PHY itself is
> > asked to do with respect to inserting delays, so
On Wed, 17 Jun 2020 at 14:34, Russell King - ARM Linux admin
wrote:
>
>
> Why are you so abrasive?
>
> Not responding to this until you start behaving more reasonably.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connect
On Wed, Jun 17, 2020 at 02:32:09PM +0300, Vladimir Oltean wrote:
> On Wed, 17 Jun 2020 at 13:56, Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Jun 16, 2020 at 09:49:56AM +0200, Helmut Grohne wrote:
> > > The macb driver does not support configuring rgmii del
On Wed, 17 Jun 2020 at 13:56, Russell King - ARM Linux admin
wrote:
>
> On Tue, Jun 16, 2020 at 09:49:56AM +0200, Helmut Grohne wrote:
> > The macb driver does not support configuring rgmii delays. At least for
> > the Zynq GEM, delays are not supported by the hardware at all
On Wed, Jun 17, 2020 at 12:55:18PM +0200, Russell King - ARM Linux admin wrote:
> The individual RGMII delay modes are more about what the PHY itself is
> asked to do with respect to inserting delays, so I don't think your
> patch makes sense.
This seems to be the same aspect that V
21-olte...@gmail.com/,
this is less and less clear to me.
I think we can agree that the current definition of phy-mode is
confusing when it comes to rgmii delays. The documentation doesn't even
mention the possibility of using serpentines.
Your interpretation seems to be that this valu
On Tue, Jun 16, 2020 at 09:49:56AM +0200, Helmut Grohne wrote:
> The macb driver does not support configuring rgmii delays. At least for
> the Zynq GEM, delays are not supported by the hardware at all. However,
> the driver happily accepts and ignores any such delays.
>
> When ope
Hi Helmut,
On Tue, 16 Jun 2020 at 11:00, Helmut Grohne wrote:
>
> The macb driver does not support configuring rgmii delays. At least for
> the Zynq GEM, delays are not supported by the hardware at all. However,
> the driver happily accepts and ignores any such delays.
>
> W
The macb driver does not support configuring rgmii delays. At least for
the Zynq GEM, delays are not supported by the hardware at all. However,
the driver happily accepts and ignores any such delays.
When operating in a mac to phy connection, the delay setting applies to
the phy. Since the MAC
On Thu, Jun 04, 2020 at 06:14:07AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
The lack of PHY mode support was compensated by the
EtherAVB MAC driver, which configures TX and/or RX internal delay
itself, based on the PHY mode.
However, now the KSZ9031 driver has gained PHY mode support, delays may
be configured twice, causing regressions. E.g. on the Renesas
Salvator-X board w
skew-ps"
> DT properties. The lack of PHY mode support was compensated by the
> EtherAVB MAC driver, which configures TX and/or RX internal delay
> itself, based on the PHY mode.
>
> However, now the KSZ9031 driver has gained PHY mode support, delays may
> be configured t
On Fri, May 29, 2020 at 1:24 PM Dan Murphy wrote:
>
> Rob
>
> On 5/29/20 1:25 PM, Rob Herring wrote:
> > On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
> >> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> >> capable dev
Rob
On 5/29/20 1:25 PM, Rob Herring wrote:
On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or
On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes
DT properties. The lack of PHY mode support was compensated by the
> EtherAVB MAC driver, which configures TX and/or RX internal delay
> itself, based on the PHY mode.
>
> However, now the KSZ9031 driver has gained PHY mode support, delays may
> be configured twice, causing regre
skew-ps"
> DT properties. The lack of PHY mode support was compensated by the
> EtherAVB MAC driver, which configures TX and/or RX internal delay
> itself, based on the PHY mode.
>
> However, now the KSZ9031 driver has gained PHY mode support, delays may
> be configured t
EtherAVB MAC driver, which configures TX and/or RX internal delay
itself, based on the PHY mode.
However, now the KSZ9031 driver has gained PHY mode support, delays may
be configured twice, causing regressions. E.g. on the Renesas
Salvator-X board with R-Car M3-W ES1.0, TX performance dropped from
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
On 5/26/2020 9:22 AM, Antoine Tenart wrote:
> The MSCC MIIM MDIO driver uses delays to read poll a status register. I
> made multiple tests on a Ocelot PCS120 platform which led me to reduce
> those delays. The delay in between which the polling function is allowed
> to sleep is
On 26/05/2020 18:22:53+0200, Antoine Ténart wrote:
> The MSCC MIIM MDIO driver uses delays to read poll a status register. I
> made multiple tests on a Ocelot PCS120 platform which led me to reduce
> those delays. The delay in between which the polling function is allowed
> to slee
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
The MSCC MIIM MDIO driver uses delays to read poll a status register. I
made multiple tests on a Ocelot PCS120 platform which led me to reduce
those delays. The delay in between which the polling function is allowed
to sleep is reduced from 100us to 50us which in almost all cases is a
good value
On Fri, May 22, 2020 at 07:25:31AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
On 5/21/2020 10:48 AM, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to t
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection
From: Rahul Lakkireddy
[ Upstream commit bd019427bf3623ee3c7d2845cf921bbf4c14846c ]
Fetching PTP sync information from mailbox is slow and can take
up to 10 milliseconds. Reduce this unnecessary delay by directly
reading the information from the corresponding registers.
Fixes: 9c33e4208bce ("cx
From: Florian Westphal
test with less predictable setups:
tc qdisc delay is now random, same for reordering and loss.
Main motivation is to cover more scenarious without a large
increase in test-time.
Signed-off-by: Florian Westphal
---
.../selftests/net/mptcp/mptcp_connect.sh | 28 ++
On 8/12/2019 4:23 AM, Alexandru Ardelean wrote:
> The internal delays for the RGMII are configurable for both RX & TX. This
> change adds support for configuring them via device-tree (or ACPI).
>
> Reviewed-by: Andrew Lunn
> Signed-off-by: Alexandru Ardelean
Reviewed-b
se the rgmii-id, rgmii-txid or rgmii-rxid phy-modes.
>
> Tested on a board where RGMII delays were already set up, by adding
> MAC-side delays on the RGMII interface towards a BCM5464R PHY and
> noticing that the MAC now reports SFD, preamble, FCS etc. errors.
>
> Conflict
RGMII delays were already set up, by adding
MAC-side delays on the RGMII interface towards a BCM5464R PHY and
noticing that the MAC now reports SFD, preamble, FCS etc. errors.
Conflicts trivially in drivers/net/dsa/sja1105/sja1105_spi.c with
https://patchwork.ozlabs.org/project/netdev/list/?series
gt; > > On 5/11/2019 10:37 PM, Andrew Lunn wrote:
> > > >> On Sat, May 11, 2019 at 07:17:08PM -0400, Peter Geis wrote:
> > > >>> Good Evening,
> > > >>>
> > > >>> Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net:
t 07:17:08PM -0400, Peter Geis wrote:
> > >>> Good Evening,
> > >>>
> > >>> Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
> > >>> rtl8211e rx/tx delays config" breaks networking completely on th
> Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
> >>> rtl8211e rx/tx delays config" breaks networking completely on the
> >>> rk3328-roc-cc.
> >>> Reverting the offending commit solves the problem.
> >>
> >> Hi
Hello Guenter,
On Sun, May 12, 2019 at 10:41:32PM -0700, Guenter Roeck wrote:
> Hi,
>
> On Sat, Apr 27, 2019 at 12:21:11AM +0300, Serge Semin wrote:
> > There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> > delays to TXC and RXC for TXD/RXD latching.
Hi,
On Sat, Apr 27, 2019 at 12:21:11AM +0300, Serge Semin wrote:
> There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> delays to TXC and RXC for TXD/RXD latching. Alas this is the only
> documented info regarding the RGMII timing control configurations the PHY
&
On 12.05.2019 04:50, Peter Geis wrote:
> On 5/11/2019 10:37 PM, Andrew Lunn wrote:
>> On Sat, May 11, 2019 at 07:17:08PM -0400, Peter Geis wrote:
>>> Good Evening,
>>>
>>> Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
>>&g
On 5/11/2019 10:37 PM, Andrew Lunn wrote:
On Sat, May 11, 2019 at 07:17:08PM -0400, Peter Geis wrote:
Good Evening,
Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
rtl8211e rx/tx delays config" breaks networking completely on the
rk3328-roc-cc.
Reverting the
On Sat, May 11, 2019 at 07:17:08PM -0400, Peter Geis wrote:
> Good Evening,
>
> Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
> rtl8211e rx/tx delays config" breaks networking completely on the
> rk3328-roc-cc.
> Reverting the offending co
Good Evening,
Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
rtl8211e rx/tx delays config" breaks networking completely on the
rk3328-roc-cc.
Reverting the offending commit solves the problem.
The following error occurs:
[ 49.442425] Unable to han
From: Vinod Koul
Date: Thu, 21 Feb 2019 15:53:13 +0530
> Peter[1] reported that patch cd28d1d6e52e: ("net: phy: at803x: Disable
> phy delay for RGMII mode") caused regression on am335x-evmsk board.
> This board expects the Phy delay to be enabled but specified RGMII mode
>
Peter[1] reported that patch cd28d1d6e52e: ("net: phy: at803x: Disable
phy delay for RGMII mode") caused regression on am335x-evmsk board.
This board expects the Phy delay to be enabled but specified RGMII mode
which refers to delays being disabled. So fix this by disabling delay only
Hi Vinod,
On 19/02/2019 8.17, Vinod Koul wrote:
> Peter[1] reported that patch cd28d1d6e52e: ("net: phy: at803x: Disable
> phy delay for RGMII mode") caused regression on am335x-evmsk board.
> This board expects the Phy delay to be enabled but specified RGMII mode
> which
Peter[1] reported that patch cd28d1d6e52e: ("net: phy: at803x: Disable
phy delay for RGMII mode") caused regression on am335x-evmsk board.
This board expects the Phy delay to be enabled but specified RGMII mode
which refers to delays being disabled. So fix this by disabling delay only
tional properties:
>> - snps,mb: mixed-burst
>> - snps,rb: rebuild INCRx Burst
>> - mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
>> +- rx-delay-disable: bool, when present disable the rx delay
>> +- tx-delay-disable: bool
HI Rob,
On 11-01-19, 09:01, Rob Herring wrote:
> On Wed, Jan 02, 2019 at 02:47:25PM +0530, Vinod Koul wrote:
> > Some controllers require that phy delay should be disabled. So add
>
> If the MAC requires it, then the compatible string should imply this. If
> it depends on the PHY, then okay.
Th
On Wed, Jan 02, 2019 at 02:47:25PM +0530, Vinod Koul wrote:
> Some controllers require that phy delay should be disabled. So add
If the MAC requires it, then the compatible string should imply this. If
it depends on the PHY, then okay.
> optional properties rx-disable-delay and tx-disable-delay
Hi Andrew,
Thanks for the comments,
On 02-01-19, 14:40, Andrew Lunn wrote:
> On Wed, Jan 02, 2019 at 02:47:28PM +0530, Vinod Koul wrote:
> > Some controllers require the tx and rx delays to be disabled. So check
> > the property and if present do not enable the delay and disabl
On Wed, Jan 02, 2019 at 02:47:28PM +0530, Vinod Koul wrote:
> Some controllers require the tx and rx delays to be disabled. So check
> the property and if present do not enable the delay and disable the
> delay explicitly.
>
> Signed-off-by: Vinod Koul
> ---
> drivers/
Some controllers require the tx and rx delays to be disabled. So check
the property and if present do not enable the delay and disable the
delay explicitly.
Signed-off-by: Vinod Koul
---
drivers/net/phy/at803x.c | 36
1 file changed, 36 insertions(+)
diff
Some controllers require that phy delay should be disabled. So add
optional properties rx-disable-delay and tx-disable-delay for it.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/net/stmmac.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindi
Hi,
I'm seeing occasional massive delays between packets being received in the
r8169 driver and them turning up in the rxrpc_data_ready() function called by
the UDP or UDP6 ->data_ready() handler. By massive, I mean I've seen anything
up to about 4s. I *think* that the effect gets
From: Andrew Lunn
Date: Tue, 31 Oct 2017 20:31:28 +0100
> The fix 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo")
> uncovered another bug in the Marvell PHY driver, which broke the
> Marvell OpenRD platform. It relies on the bootloader configuring the
> RGM
On 10/31/2017 12:31 PM, Andrew Lunn wrote:
> The fix 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo")
> uncovered another bug in the Marvell PHY driver, which broke the
> Marvell OpenRD platform. It relies on the bootloader configuring the
> RGMII delays and
Hi,
On Tue, Oct 31, 2017 at 08:31:28PM +0100, Andrew Lunn wrote:
> The fix 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo")
> uncovered another bug in the Marvell PHY driver, which broke the
> Marvell OpenRD platform. It relies on the bootloader configuring the
The fix 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo")
uncovered another bug in the Marvell PHY driver, which broke the
Marvell OpenRD platform. It relies on the bootloader configuring the
RGMII delays and does not specify a phy-mode in its device tree. The
PHY driver s
On Fri, Jul 28, 2017 at 3:27 PM, Marc Gonzalez
wrote:
> RX and TX clock delays are required. Request them explicitly.
>
> Fixes: cad008b8a77e6 ("ARM: dts: tango4: Initial device trees")
> Signed-off-by: Marc Gonzalez
> ---
> Arnd, Kevin, Olof, can one of you tak
RX and TX clock delays are required. Request them explicitly.
Fixes: cad008b8a77e6 ("ARM: dts: tango4: Initial device trees")
Signed-off-by: Marc Gonzalez
---
Arnd, Kevin, Olof, can one of you take this patch through arm-soc?
Greg will apply it to all stable branches, right?
---
arc
On 21/07/2017 14:47, Marc Gonzalez wrote:
> fping caps at 1000 packets per second, which limits
> its usefulness as a benchmarking tool.
"Normal" ping is slightly faster (5000 packets per second).
time ping -f -c 6 -s 1450 -q 172.27.64.1
--- 172.27.64.1 ping statistics ---
6 packets tra
On 21/07/2017 13:22, Marc Gonzalez wrote:
> Changes from v1
> - Drop support for disabling RX and TX clock delays
> (it breaks some boards). Document the issues instead.
> - Split the MAC patch in two unrelated parts
> - Fix the vantage 1172 DTS
>
> Marc Gonzalez (4):
Changes from v1
- Drop support for disabling RX and TX clock delays
(it breaks some boards). Document the issues instead.
- Split the MAC patch in two unrelated parts
- Fix the vantage 1172 DTS
Marc Gonzalez (4):
net: phy: at803x: Document RGMII RX and TX clock delay issues
net: ethernet
RX and TX clock delays are required.
Signed-off-by: Marc Gonzalez
---
arch/arm/boot/dts/tango4-vantage-1172.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tango4-vantage-1172.dts
b/arch/arm/boot/dts/tango4-vantage-1172.dts
index 86d8df98802f
On 07/19/2017 02:29 PM, Mason wrote:
> On 19/07/2017 21:30, Florian Fainelli wrote:
>> On 07/19/2017 12:24 PM, Grygorii Strashko wrote:
>>> Hi
>>>
>>> On 07/19/2017 10:31 AM, Marc Gonzalez wrote:
>>>> The current code supports enabling RGMII RX and
On 19/07/2017 21:30, Florian Fainelli wrote:
> On 07/19/2017 12:24 PM, Grygorii Strashko wrote:
>> Hi
>>
>> On 07/19/2017 10:31 AM, Marc Gonzalez wrote:
>>> The current code supports enabling RGMII RX and TX clock delays.
>>> The unstated assumption
On 07/19/2017 02:30 PM, Florian Fainelli wrote:
On 07/19/2017 12:24 PM, Grygorii Strashko wrote:
Hi
On 07/19/2017 10:31 AM, Marc Gonzalez wrote:
The current code supports enabling RGMII RX and TX clock delays.
The unstated assumption is that these settings are disabled by
default at reset
On 07/19/2017 12:24 PM, Grygorii Strashko wrote:
> Hi
>
> On 07/19/2017 10:31 AM, Marc Gonzalez wrote:
>> The current code supports enabling RGMII RX and TX clock delays.
>> The unstated assumption is that these settings are disabled by
>> default at reset, which is n
1 - 100 of 168 matches
Mail list logo
