Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

> > For it to be unsafe, i think that would mean phylib would need to call > > back into the MAC driver? The only way that could happen is via the > > adjust_link call. And that will deadlock, since it takes the same > > lock. > > > > Or am i/we missing something? > >It doesn't take any

Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

On Thu, May 24, 2018 at 07:18:28PM +0300, Sergei Shtylyov wrote: > Hello! > > On 05/24/2018 05:11 PM, Vladimir Zapolskiy wrote: > > >>> The change fixes a sleep in atomic context issue, which can be > >>> always triggered by running 'ethtool -r' command, because > >>> phy_start_aneg() protects

Re: [PATCH 5/6] sh_eth: remove custom .get_link_ksettings from ethtool ops

ccess to phydev fields. > > Signed-off-by: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH 4/6] sh_eth: remove custom .nway_reset from ethtool ops

ange implicitly replaces phy_start_aneg() > with a newer phy_restart_aneg(). > > Signed-off-by: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH 3/6] ravb: remove custom .set_link_ksettings from ethtool ops

On Thu, May 24, 2018 at 02:11:55PM +0300, Vladimir Zapolskiy wrote: > The change replaces a custom implementation of .set_link_ksettings > callback with a shared phy_ethtool_set_link_ksettings(), this fixes > sleep in atomic context bug, which is encountered every time when link > settings are

Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

It would be good to add some sort of fixes: tag. Maybe for the commit that added the generic nway_reset? That would at least cover some stable kernels. Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH v2 1/1] sh_eth: add RGMII support

Ah, your don't see that form used very often. I just checked, clang/llvm should also support it. Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH 1/3] sh_eth: add RGMII support

> > Hi Sergei > > > > What about > > PHY_INTERFACE_MODE_RGMII_ID, > > PHY_INTERFACE_MODE_RGMII_RXID, > > PHY_INTERFACE_MODE_RGMII_TXID, > >Oops, totally forgot about those... :-/ Everybody does. I keep intending to write a email template for this, and

Re: [PATCH 1/3] sh_eth: add RGMII support

On Wed, May 16, 2018 at 10:56:45PM +0300, Sergei Shtylyov wrote: > The R-Car V3H (AKA R8A77980) GEther controller adds support for the RGMII > PHY interface mode as a new value for the RMII_MII register. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by:

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

On Wed, May 16, 2018 at 10:54:12AM +0200, Geert Uytterhoeven wrote: > Hi Florian, > > Thanks for your series! > I like the effect on simplifying drivers. > > On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli > wrote: > > This patch series updates of_mdiobus_register()

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

> Sorry, the phy_restore_page() semantics are driving me crazy. > Let's revert. I will try to take a look today. Andrew

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

> > I took a quick look at the uses of phy_modify(). I don't see any uses > > of the return code other than as an error indicator. So having it > > return 0 on success seems like a better fix. > > I'd like to avoid that, because I don't want to have yet another > accessor that needs to be used

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote: > In case of success, the return values of (__)phy_write() and > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while > (__)phy_modify() returns the old PHY register value. > > Apparently this change was catered

Re: [PATCH v2] net: sh_eth: do not advertise Gigabit capabilities when not available

7786 platform, with a Gigabit PHY. > > Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH] net: sh_eth: do not advertise Gigabit capabilities when not available

> >diff --git a/drivers/net/ethernet/renesas/sh_eth.c > >b/drivers/net/ethernet/renesas/sh_eth.c > >index db72d13cebb9..0074c5998481 100644 > >--- a/drivers/net/ethernet/renesas/sh_eth.c > >+++ b/drivers/net/ethernet/renesas/sh_eth.c > >@@ -1892,6 +1892,11 @@ static int sh_eth_phy_init(struct

Re: [PATCH] net: sh_eth: do not advertise Gigabit capabilities when not available

Gigabit PHY. > > Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH 2/2] net: smsc911x: Quiten netif during suspend

On Tue, Aug 22, 2017 at 08:37:26PM +0200, Geert Uytterhoeven wrote: Hi Geert quieten. Has an E in the middle. Otherwise this patch looks reasonable. Andrew

Re: [PATCH v2] ravb: add wake-on-lan support via magic packet

On Sun, Jul 30, 2017 at 09:51:54PM +0200, Niklas Söderlund wrote: > Hi Andrew, > > On 2017-07-30 19:07:38 +0200, Andrew Lunn wrote: > > Hi Niklas > > > > > @@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev) > > > > > >

Re: [PATCH v2] ravb: add wake-on-lan support via magic packet

Hi Niklas > @@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev) > > priv->chip_id = chip_id; > > + /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */ > + priv->clk = devm_clk_get(>dev, NULL); > + if (IS_ERR(priv->clk)) > +

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

> It sure does fix a real issue, but I am really concerned about the > inability to test this patch in a configuration where we have multiple > PHY(s) or MDIO device(s) hanging off the same MDIO bus and one of those > requesting an EPROBE_DEFER. > > I currently don't have a setup where I could

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

> > This most certainly works fine in the simple case where you have one PHY > > hanging off the MDIO bus, now what happens if you have several? > > > > Presumably, the first PHY that returns EPROBE_DEFER will make the entire > > bus registration return EPROB_DEFER as well, and so on, and so

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

> >> phy = get_phy_device(mdio, addr, is_c45); > >> if (IS_ERR(phy)) > >> - return; > >> + return PTR_ERR(phy); > >> > >> - rc = irq_of_parse_and_map(child, 0); > >> + rc = of_irq_get(child, 0); > >> + if (rc == -EPROBE_DEFER) { > >> +

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

On Thu, May 18, 2017 at 02:59:05PM +0200, Geert Uytterhoeven wrote: > If an Ethernet PHY is initialized before the interrupt controller it is > connected to, a message like the following is printed: > > irq: no irq domain found for /interrupt-controller@e61c ! > > However, the actual

Re: [PATCH v2 2/3] net: phy: leds: Break dependency of phy.h on phy_led_triggers.h

On Wed, Jan 25, 2017 at 11:39:49AM +0100, Geert Uytterhoeven wrote: > includes , which is not really > needed. Drop the include from , and add it to all users > that didn't include it explicitly. > > Suggested-by: Andrew Lunn <and...@lunn.ch> > Signed-off-by: Geert

Re: [PATCH v2 3/3] net: phy: leds: Fix truncated LED trigger names

ixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy > link state change") > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: [PATCH 2/2] net: phy: leds: Fix truncated LED trigger names

> diff --git a/include/linux/phy.h b/include/linux/phy.h > index 5c9d2529685fe215..f6ab919528ab3627 100644 > --- a/include/linux/phy.h > +++ b/include/linux/phy.h > @@ -25,7 +25,6 @@ > #include > #include > #include > -#include > > #include > > @@ -339,6 +338,8 @@ struct