Re: [PATCH net v5 0/4] net: enable inband link state negotiation only when explicitly requested
Hi guys, Florian Fainelli f.faine...@gmail.com writes: Changes in v5: - removed an invalid use of the link_update callback in the SF2 driver was appeared after merging net: phy: fixed_phy: handle link-down case - reworded the commit message for patch 2 to make it clear what it fixes and why this is required Initial cover letter from Stas: Hello. Currently the link status auto-negotiation is enabled for any SGMII link with fixed-link DT binding. The regression was reported: https://lkml.org/lkml/2015/7/8/865 Apparently not all HW that implements SGMII protocol, generates the inband status for the auto-negotiation to work. More details here: https://lkml.org/lkml/2015/7/10/206 The following patches reverts to the old behavior by default, which is to not enable the auto-negotiation for fixed-link. The new DT property is added that allows to explicitly request the auto-negotiation. FWIW, I tested this v5 series on mirabox (2 mvneta interfaces using RGMII); both interfaces still work as expected, i.e. no regression on my side. a+ -- 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 4.1 11/56] mvneta: add forgotten initialization of autonegotiation bits
Hi, Stas Sergeev s...@list.ru writes: Another problem was reported: https://lkml.org/lkml/2015/7/8/865 So, while the above patch is correct and fixes what it should, the original patch has more problems to deal with. Maybe for stable it would be better to just revert the whole thing? No, you will have to fix this in Linus's tree, right? So I'll take the patch that you get into there when that happens, I don't want to diverge from what is in that tree. For Linus tree I am planning a new DT property to explicitly enable the inband status. I don't see any quick fix suitable for -stable, and new DT property will likely not be quickly accepted. If you don't want a revert, then the stable will likely have that regression for quite long, that's the warning. I do not think the problem is to have a revert in -stable, it's more having in in Linus tree *first* ;-) OTOH, the revert will remove the support for my board, so I won't be able to even test it, which is also not perfect. ATM, the priority is more on fixing the regressions the initial patch caused *for existing boards*. There were at least three boards which got hit by first regression during 4.1-rc and a new one on the table now that 4.1 is out. I understand your reluctance to revert the patch that made mvneta work for your custom board but it's unfair for others that are hit by the regressions it causes and have to spend time bisecting/fixing it. Anyway, if you come w/ a fix, I can commit to test it on the boards I have. Cheers, a+ -- 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
[BUG,BISECTED] mvneta: second interface no more usable on mirabox
Hi, On Mirabox, the second ethernet interface is no more usable on 4.1-rc* series (no packets coming out of the interface, when using dhclient for instance). It works as expected on 4.0. Bisecting the issue, I ended up on 898b2970e2c9 (mvneta: implement SGMII-based in-band link state signaling). Reverting that commit gives me back the second interface. Then, I also tested on a NETGEAR ReadyNAS 104, which is also powered by the same SoC (Armada 370) and also has two (mvneta-supported) ethernet interfaces. With an unmodified 4.1-rc8, only one of the two interfaces is available. Reverting 898b2970e2c9 makes both usable again. FWIW, mirabox and RN104 ethernet interfaces use RGMII. Cheers, a+ -- 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: [BUG,BISECTED] mvneta: second interface no more usable on mirabox
Hi,
Stas Sergeev s...@list.ru writes:
17.06.2015 00:44, Arnaud Ebalard пишет:
Hi,
On Mirabox, the second ethernet interface is no more usable on 4.1-rc*
series (no packets coming out of the interface, when using dhclient for
instance). It works as expected on 4.0.
Bisecting the issue, I ended up on 898b2970e2c9 (mvneta: implement
SGMII-based in-band link state signaling). Reverting that commit gives
me back the second interface.
Then, I also tested on a NETGEAR ReadyNAS 104, which is also powered by
the same SoC (Armada 370) and also has two (mvneta-supported) ethernet
interfaces. With an unmodified 4.1-rc8, only one of the two interfaces
is available. Reverting 898b2970e2c9 makes both usable again.
FWIW, mirabox and RN104 ethernet interfaces use RGMII.
Hi, hope someone who can reproduce the problem,
can provide a better help.
I looked into a patch, and it seems most things are done
under if (pp-use_inband_status), which is not your case.
Looking at the patch, yes. Both platforms I have which encounter the
problem use RGMII and if (pp-use_inband_status) changes are for
SGMII.
But it seems the patch can still change a couple of flags
for you, and maybe that makes a problem?
AFAICT, autoneg config register (MVNETA_GMAC_AUTONEG_CONFIG) is
modified. And the logic when link status changes is also modified:
- MVNETA_GMAC_FORCE_LINK_DOWN flag cleared when there is carrier. It was
previously set when that event occured.
- The link down event logic is also modified.
Please try the attached (absolutely untested) patch.
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index ce5f7f9..74176ec 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1013,6 +1013,12 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER);
val |= MVNETA_GMAC_1MS_CLOCK_ENABLE;
mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val);
+ } else {
+ val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
+ val = ~(MVNETA_GMAC_INBAND_AN_ENABLE |
+MVNETA_GMAC_AN_SPEED_EN |
+MVNETA_GMAC_AN_DUPLEX_EN);
+ mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);
}
mvneta_set_ucast_table(pp, -1);
*Second interface is back w/ that patch applied*. Cannot tell if it is a
proper fix, though or a valid workaround.
Thanks for your feedback.
a+
--
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
[Patch] Make ULA flagged unicast global
Hi, Find attached a patch to get IPv6 Unique Local Addresses (FC00::/7) flagged unicast global in __ipv6_addr_type(), as expected by RFC 4193. One easy way to see the current difference of handling with a more common unicast global address is by trying to insert a default route using a unique local address for the gateway: $ sudo ip -6 addr add fd00::1/64 dev eth0 $ sudo ip -6 route add default via fd00::2 dev eth0 RTNETLINK answers: Invalid argument where sth like 2001:db8::1 (in fact, where first 3 bits are different of 000 or 111) does work. The patch is against Linus git tree but the code in the modified file is pretty stable so it should apply without problems. One remark: as ULA get flagged as unicast global by that change, there might be a difference in address selection mechanism. Anyway, the longest prefix match rule should do his job if something better is available, i.e. a unique local address will not be selected as src or dst for something in 2000::/3, for instance. Regards, a+ ps : i'm aware LL addresses should be used for expressing gw, not global ones. diff --git a/net/ipv6/addrconf_core.c b/net/ipv6/addrconf_core.c index faaefb6..93b17d5 100644 --- a/net/ipv6/addrconf_core.c +++ b/net/ipv6/addrconf_core.c @@ -29,11 +29,13 @@ int __ipv6_addr_type(const struct in6_addr *addr) st = addr-s6_addr32[0]; - /* Consider all addresses with the first three bits different of - 000 and 111 as unicasts. + /* - Consider all addresses with the first three bits different of +000 and 111 as unicasts. + - Unique Local Addresses (FC00::/7, RFC 4193) are unicast global. */ - if ((st htonl(0xE000)) != htonl(0x) - (st htonl(0xE000)) != htonl(0xE000)) + if (((st htonl(0xE000)) != htonl(0x) +(st htonl(0xE000)) != htonl(0xE000)) || + ((st htonl(0xFE00)) == htonl(0xFC00))) return (IPV6_ADDR_UNICAST | IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_GLOBAL)); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
