On Mon, Oct 19, 2020 at 8:02 PM Andy Duan wrote:
>
> From: Andrew Lunn Sent: Tuesday, October 20, 2020 10:40 AM
> > On Tue, Oct 20, 2020 at 12:14:04PM +1000, Greg Ungerer wrote:
> > > Hi Andrew,
> > >
> > > Commit f166f890c8f0 ("[PATCH] net: ethernet: fec: Replace interrupt
> > > driven MDIO with
With this patch applied, I no longer experience the kernel warning messages.
Tested-by: Chris Healy
On Sun, Aug 16, 2020 at 12:27 PM Andrew Lunn wrote:
>
> It is possible to trigger this WARN_ON from user space by triggering a
> devlink snapshot with an ID which already exists. We d
88E6352.
Full series is:
Tested-by: Chris Healy
On Sun, Aug 16, 2020 at 12:44 PM Andrew Lunn wrote:
>
> Make use of devlink regions to allow read access to some of the
> internal of the switches. The switch itself will never trigger a
> region snapshot, it is assumed it is performed fro
On Mon, Jul 27, 2020 at 8:24 AM Laurent Pinchart
wrote:
>
> Hi Andrew,
>
> On Mon, Jul 27, 2020 at 02:05:45PM +0200, Andrew Lunn wrote:
> > On Sun, Jul 26, 2020 at 08:01:25PM -0700, Chris Healy wrote:
> > > It appears quite a few boards were affected by this micr
> > I just updated the phy-mode with my board from rgmii to rgmii-id and
> > everything started working fine with net-next again:
>
> Hi Chris
>
> Is this a mainline supported board? Do you plan to submit a patch?
>
Yes, my board is in mainline so I plan on submitting a patch.
> Laurent, does the
dropped:0 overruns:0 frame:0
TX packets:76178 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2762845502 (2.5 GiB) TX bytes:5026376 (4.7 MiB)
On Sun, Jul 26, 2020 at 7:40 PM Chris Healy wrote:
>
> Actually, I was a little quick to
n Sun, Jul 26, 2020 at 7:35 PM Chris Healy wrote:
>
> Hi Laurent,
>
> I have the exact same copper PHY. I just reverted a patch specific to
> this PHY and went from broken to working. Give this a try:
>
> git revert bcf3440c6dd78bfe5836ec0990fe36d7b4bb7d20
>
> Regar
Hi Laurent,
I have the exact same copper PHY. I just reverted a patch specific to
this PHY and went from broken to working. Give this a try:
git revert bcf3440c6dd78bfe5836ec0990fe36d7b4bb7d20
Regards,
Chris
On Sun, Jul 26, 2020 at 7:33 PM Laurent Pinchart
wrote:
>
> Hi Andrew,
>
> On Mon,
On Sun, Jul 26, 2020 at 7:06 PM Laurent Pinchart
wrote:
>
> On Mon, Jul 27, 2020 at 04:24:02AM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 27, 2020 at 10:08:04PM +0800, Fugang Duan wrote:
> > > This reverts commit 29ae6bd1b0d8a57d7c00ab12cbb949fc41986eef.
> > >
> > > The commit breaks ethernet
From: Andrew Lunn
In addition to the port registers, the device can provide the
SERDES/PCS registers. Dump these, and for a few of the important
SGMII/1000Base-X registers decode the bits.
Signed-off-by: Andrew Lunn
Signed-off-by: Chris Healy
---
v2:
- Add SERDES_OFFSET define
- Improve
On Sun, Jul 19, 2020 at 2:16 PM Michal Kubecek wrote:
>
> On Thu, Jul 16, 2020 at 10:55:26AM -0700, Chris Healy wrote:
> > From: Andrew Lunn
> >
> > In addition to the port registers, the device can provide the
> > SERDES/PCS registers. Dump these, and for a
On Sat, Jul 18, 2020 at 8:22 AM Marek Behun wrote:
>
> On Sat, 18 Jul 2020 17:05:14 +0200
> Andrew Lunn wrote:
>
> > > If the traces were broken between the fiber module and the SERDES, I
> > > should not see these counters incrementing.
> >
> > Plus it is reproducible on multiple boards, of diff
unit:
serdes_rx_pkts: 6
serdes_rx_bytes: 384
serdes_rx_pkts_error: 0
If the traces were broken between the fiber module and the SERDES, I
should not see these counters incrementing.
>
> Marek
>
> On Sat, 18 Jul 2020 07:27:33 -0700
> Chris Healy wrote:
>
> > I've been t
I've been trying to get the fiber interface of the vf610-zii-dev-rev-c
board working with net-next to no avail. This platform utilizes a
Cotsworks SFF attached to port 9 of a Marvell 88E6390X.
I have fiber link up on port 9 and am able to send packets from the
management CPU of the switch through
From: Andrew Lunn
In addition to the port registers, the device can provide the
SERDES/PCS registers. Dump these, and for a few of the important
SGMII/1000Base-X registers decode the bits.
Signed-off-by: Andrew Lunn
Signed-off-by: Chris Healy
---
dsa.c | 196
correct.
Signed-off-by: Chris Healy
---
drivers/net/phy/sfp.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..2737d9b6b0ae 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
Add deb_dbg print statements in both serdes_read and serdes_write
functions.
Signed-off-by: Chris Healy
---
drivers/net/dsa/mv88e6xxx/serdes.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c
b/drivers/net/dsa
Add error checking with sfp_irq_name before use.
Signed-off-by: Chris Healy
---
drivers/net/phy/sfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 7bdfcde98266..eef458ab0e5b 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy
On Mon, Jul 6, 2020 at 11:52 PM Andy Shevchenko
wrote:
>
>
>
> On Tuesday, July 7, 2020, Chris Healy wrote:
>>
>> From: Chris Healy
>>
>> Dynamically generate a unique GPIO interrupt name, based on the
>> device name and the GPIO name. For example
From: Chris Healy
Dynamically generate a unique GPIO interrupt name, based on the
device name and the GPIO name. For example:
103: 0 sx1503q 12 Edge sff2-los
104: 0 sx1503q 13 Edge sff2-tx-fault
The sffX indicates the SFP the los and tx-fault are associated
: Chris Healy
v2:
- added net-next to PATCH part of subject line
- switched to devm_kasprintf()
---
drivers/net/phy/sfp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..193a124c26c4 100644
--- a/drivers
On Mon, Jul 6, 2020 at 1:42 PM Russell King - ARM Linux admin
wrote:
>
> On Mon, Jul 06, 2020 at 12:38:37PM -0700, Chris Healy wrote:
> > Dynamically generate a unique GPIO interrupt name, based on the
> > device name and the GPIO name. For example:
> >
> > 103:
On Mon, Jul 6, 2020 at 1:07 PM Andrew Lunn wrote:
>
> On Mon, Jul 06, 2020 at 12:38:37PM -0700, Chris Healy wrote:
> > Dynamically generate a unique GPIO interrupt name, based on the
> > device name and the GPIO name. For example:
> >
> > 103: 0 sx1503q
: Chris Healy
---
drivers/net/phy/sfp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..9b03c7229320 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -220,6 +220,7 @@ struct sfp {
struct
With NXP i.MX51 and Marvell 88E6352 and the referenced ethtool, I
tested this functionality successfully.
Tested-by: Chris Healy
On Sun, May 24, 2020 at 8:28 AM Andrew Lunn wrote:
>
> Some ethernet PHYs allow access to raw TDR data in addition to summary
> diagnostics information. Ad
On Sun, May 17, 2020 at 1:51 PM Andrew Lunn wrote:
>
> > > +static int marvell_vct5_amplitude_distance(struct phy_device *phydev,
> > > + int meters)
> > > +{
> > > + int mV_pair0, mV_pair1, mV_pair2, mV_pair3;
> > > + int distance;
> > > +
On Sun, May 17, 2020 at 12:59 PM Andrew Lunn wrote:
>
> The Marvell PHYs can measure the amplitude of the returned signal for
> a given distance. Implement this option of the cable test
> infrastructure.
>
> Signed-off-by: Andrew Lunn
> ---
> drivers/net/phy/marvell.c | 227 +
> Some of the older Marvell switches use the 1540 for its internal
> PHYs. Same OUI as the external PHY. I don't remember which
> switches. Maybe the mv88e6161 in the RDU1?
>
I'm using a Marvell 88E6161 with 5.0.1 and I get the following output
which I think indicates that the 6161 does not use th
> This patch series eliminates unnecessary software resets of the PHY.
> This should hopefully not break anybody's hardware; but I would
> appreciate testing to make sure this is is the case.
Tested-by: Chris Healy
Tested with Marvell 88E6161 and Marvell 88E6352 switches (which u
Tested-by: Chris Healy
Successfully tested on a machine with a Broadcom BCM5395 switch.
On Thu, Dec 14, 2017 at 5:48 PM, Florian Fainelli wrote:
> Add an entry for the builtin PHYs present in the Broadcom BCM5395 switch. This
> allows us to retrieve the PHY statistics among other
Hi Florian,
In saying the below, I may just be showing my naivety but here goes:
If I understand this correctly, what you are using is similar to the
TCAM hardware present in the newer Marvell switches. I think Pablo is
doing some work with nftables and HW offload using TCAM HW. Is there
overla
31 matches
Mail list logo
