Re: [PATCH v2] net: fec: fix MDIO probing for some FEC hardware blocks

* - writing MSCR: > + * - mmfr[31:0]_not_zero & mscr[7:0]_is_zero & > + *mscr_reg_data_in[7:0] != 0 > + * - writing MMFR: > + * - mscr[7:0]_not_zero > + */ > + writel(0, fep->hwp + FEC_MII_DATA); > + } > > writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED); > > -- > 2.25.1 > This fixes the problem on i.MX6Q! Tested-by: Clemens Gruber Best regards, Clemens

Re: [PATCH net-next v5] net: ethernet: fec: Replace interrupt driven MDIO with polled IO

Hi Andrew, On Sat, Aug 15, 2020 at 07:53:49PM +0200, Andrew Lunn wrote: > On Sat, Aug 15, 2020 at 06:55:56PM +0200, Clemens Gruber wrote: > > Hi, > > > > this patch / commit f166f890c8 ("net: ethernet: fec: Replace interrupt > > driven MDIO with polled IO") b

Re: [PATCH net-next v5] net: ethernet: fec: Replace interrupt driven MDIO with polled IO

Hi, this patch / commit f166f890c8 ("net: ethernet: fec: Replace interrupt driven MDIO with polled IO") broke networking on i.MX6Q boards with Marvell 88E1510 PHYs (Copper / 1000Base-T). Reverting said commit fixes the problem. We also reverted 7cdaa4cc4b ("net: ethernet: fec: prevent tx starvat

[RFT] net: fec: Fix MDIO polled IO

Hi, this patch fixes the problem on our i.MX6Q boards with Marvell 88E1510 PHYs (1000Base-T). Tested-by: Clemens Gruber Thanks, Clemens

Re: [PATCH RFT net-next 0/2] net: phy: Eliminate unnecessary soft

t reset > > drivers/net/phy/marvell.c| 63 > drivers/net/phy/phy_device.c | 2 -- > 2 files changed, 21 insertions(+), 44 deletions(-) > > -- > 2.17.1 > I tested your patches on our board with a Marvell 88E1510. Looks good! Tested-by: Clemens Gruber Clemens

[PATCH] phy: marvell: fix LED configuration via marvell,reg-init

LED configuration through marvell,reg-init in the device tree, which should override said default if it exists. Signed-off-by: Clemens Gruber --- drivers/net/phy/marvell.c | 38 ++ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/drivers/net/phy

Re: [PATCH] phy: marvell: remove LED config override

Hi Andrew, On Fri, Jun 10, 2016 at 08:38:57PM +0200, Andrew Lunn wrote: > On Fri, Jun 10, 2016 at 07:42:52PM +0200, Clemens Gruber wrote: > > Configuring the PHY LED registers for the Marvell 88E1510 and others is > > not possible, because regardless of the values in marvell,reg-

[PATCH] phy: marvell: remove LED config override

figuration from the device tree. This patch removes this override and allows the user to again set the PHY LED configuration through marvell,reg-init or if that does not exist, keep the original defaults as documented in the datasheet. Signed-off-by: Clemens Gruber --- drivers/net/phy/marv

[PATCH 1/1] phy: marvell: Fix 88E1510 initialization

and moves the specific init function for the 88E1510 below the marvell_config_init function to avoid adding a function predeclaration. Signed-off-by: Clemens Gruber --- drivers/net/phy/marvell.c | 70 +++ 1 file changed, 35 insertions(+), 35 deletion

[PATCH 0/1] net and net-next merge conflict bug

is merged back into davem/net. (?) davem/net is fine, the problem exists only in davem/net-next. Thanks, Clemens Clemens Gruber (1): phy: marvell: Fix 88E1510 initialization drivers/net/phy/marvell.c | 70 +++ 1 file changed, 35 insertions(+), 35 deletions(-) -- 2.7.1

[PATCH v3] phy: marvell: Fix and unify reg-init behavior

uched. The generic marvell_config_init function is called for all the others, to get consistent behavior across all Marvell PHYs. Signed-off-by: Clemens Gruber --- Changes from v2: - Simplified marvell_config_init (No preemptive error handling) --- drivers/net/phy/marvell.c | 15 +

Re: [PATCH v2] phy: marvell: Fix and unify reg-init behavior

Hi Fabio, On Mon, Feb 15, 2016 at 06:54:29PM -0200, Fabio Estevam wrote: > On Mon, Feb 15, 2016 at 6:01 PM, Clemens Gruber > wrote: > > > +static int marvell_config_init(struct phy_device *phydev) > > +{ > > + int err; > > + > > + /* Set regi

Re: [PATCH] phy: marvell: Fix and unify reg-init behavior

Hi Florian, On Mon, Feb 15, 2016 at 10:22:14AM -0800, Florian Fainelli wrote: > > > On 15/02/2016 10:19, Florian Fainelli wrote: > > On 15/02/2016 09:52, Clemens Gruber wrote: > >> For the Marvell 88E1510, marvell_of_reg_init was called too late (in > >> m88e151

[PATCH v2] phy: marvell: Fix and unify reg-init behavior

uched. The generic marvell_config_init function is called for all the others, to get consistent behavior across all Marvell PHYs. Signed-off-by: Clemens Gruber --- Changes since v1: - No longer touch the PHYs that already call marvell_of_reg_init - No more reset in marvell_config_init. - Moved th

[PATCH] phy: marvell: Fix and unify reg-init behavior

, marvell_of_reg_init was not called at all. Add a generic marvell_config_init function, which in turn calls marvell_of_reg_init and resets the PHY, to get more consistent behavior across all Marvell PHYs. Signed-off-by: Clemens Gruber --- drivers/net/phy/marvell.c | 65

Re: [PATCH] phy: marvell: Fix reg-init bug on 88E1510

On Sun, Feb 14, 2016 at 09:48:22PM +0100, Andrew Lunn wrote: > On Sun, Feb 14, 2016 at 09:31:25PM +0100, Clemens Gruber wrote: > > The function marvell_of_reg_init was called too late, in > > m88e1510_config_aneg. This function was not reached, due to the phy > > state m

[PATCH] phy: marvell: Fix reg-init bug on 88E1510

commit moves the call of marvell_of_reg_init to config_init. Now, a marvell,reg-init option to enable PHY interrupts on pin LED[2] is set early on and the phy state machine does not get stuck anymore. Tested on i.MX6Q boards with Marvell 88E1510 PHYs. Signed-off-by: Clemens Gruber --- drivers/net/phy

Re: [PATCH] Revert "net: phy: turn carrier off on phy attach"

On Fri, Feb 12, 2016 at 10:56:04AM -0800, Florian Fainelli wrote: > On 12/02/16 10:01, Clemens Gruber wrote: > > Commit 113c74d83eef ("net: phy: turn carrier off on phy attach") breaks > > the eth0 link coming up on all my i.MX6Q boards with a Marvell 88E1510. > > If

Re: [PATCH] Revert "net: phy: turn carrier off on phy attach"

Hi Florian, On Fri, Feb 12, 2016 at 10:56:04AM -0800, Florian Fainelli wrote: > On 12/02/16 10:01, Clemens Gruber wrote: > > Commit 113c74d83eef ("net: phy: turn carrier off on phy attach") breaks > > the eth0 link coming up on all my i.MX6Q boards with a Marvell 88

[PATCH] Revert "net: phy: turn carrier off on phy attach"

orker load in that state. This reverts commit 113c74d83eef870e43a0d9279044e9d5435f0d07. Signed-off-by: Clemens Gruber --- drivers/net/phy/phy_device.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index bad3f00..903737a 10

Re: RX packet loss on i.MX6Q running 4.2-rc7

On Fri, Aug 21, 2015 at 06:49:20AM +0200, Jon Nettleton wrote: > On Fri, Aug 21, 2015 at 12:30 AM, Clemens Gruber > wrote: > > Hi, > > > > I am experiencing massive RX packet loss on my i.MX6Q (Chip rev 1.3) on > > Linux > > 4.2-rc7 with a Marvell 88E1510

RX packet loss on i.MX6Q running 4.2-rc7

Hi, I am experiencing massive RX packet loss on my i.MX6Q (Chip rev 1.3) on Linux 4.2-rc7 with a Marvell 88E1510 Gigabit Ethernet PHY connected over RGMII. I noticed it when doing an UDP benchmark with iperf3. When sending UDP packets from a Debian PC to the i.MX6 with a rate of 100 Mbit/s, 99% of

[no subject]

unsubscribe -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Revert "net: fec: Ensure clocks are enabled while using mdio bus"

On Wed, Jul 15, 2015 at 05:32:13PM -0700, David Miller wrote: > From: Clemens Gruber > Date: Thu, 16 Jul 2015 02:04:04 +0200 > > > This reverts commit 6c3e921b18edca290099adfddde8a50236bf2d80. > > > > The change did break ethernet support on the i.MX6Q and possibly

[PATCH] Revert "net: fec: Ensure clocks are enabled while using mdio bus"

This reverts commit 6c3e921b18edca290099adfddde8a50236bf2d80. The change did break ethernet support on the i.MX6Q and possibly also on other platforms: The PHY was not detected anymore and eth0 was not found. Signed-off-by: Clemens Gruber Cc: Andrew Lunn Cc: Fugang Duan Cc: David S. Miller