Re: [PATCH 4.1 11/56] mvneta: add forgotten initialization of autonegotiation bits

[Greg Kroah-Hartman]

On Wed, Jul 08, 2015 at 09:36:46PM +0300, Stas Sergeev wrote:
> 08.07.2015 20:36, Greg Kroah-Hartman ÐÐÑÐÑ:
> >On Wed, Jul 08, 2015 at 08:10:46PM +0300, Stas Sergeev wrote:
> >>08.07.2015 10:35, Greg Kroah-Hartman ÐÐÑÐÑ:
> >>>4.1-stable review patch.  If anyone has any objections, please let me know.
> >>>
> >>>------------------
> >>>
> >>>From: Stas Sergeev <stsp@xxxxxxx>
> >>>
> >>>[ Upstream commit 538761b794c1542f1c6e31eadd9d7aae118889f7 ]
> >>>
> >>>The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state
> >>>signaling")
> >>>changed mvneta_adjust_link() so that it does not clear the auto-negotiation
> >>>bits in MVNETA_GMAC_AUTONEG_CONFIG register. This was necessary for
> >>>auto-negotiation mode to work.
> >>>Unfortunately I haven't checked if these bits are ever initialized.
> >>>It appears they are not.
> >>>This patch adds the missing initialization of the auto-negotiation bits
> >>>in the MVNETA_GMAC_AUTONEG_CONFIG register.
> >>>It fixes the following regression:
> >>>https://www.mail-archive.com/netdev@xxxxxxxxxxxxxxx/msg67928.html
> >>>
> >>>Since the patch was tested to fix a regression, it should be applied to
> >>>stable tree.
> >>>
> >>>Tested-by: Arnaud Ebalard <arno@xxxxxxxxxxxx>
> >>>
> >>>CC: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
> >>>CC: Florian Fainelli <f.fainelli@xxxxxxxxx>
> >>>CC: netdev@xxxxxxxxxxxxxxx
> >>>CC: linux-kernel@xxxxxxxxxxxxxxx
> >>>CC: stable@xxxxxxxxxxxxxxx
> >>>
> >>>Signed-off-by: Stas Sergeev <stsp@xxxxxxxxxxxxxxxxxxxxx>
> >>>Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> >>>Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> >>>---
> >>>  drivers/net/ethernet/marvell/mvneta.c |    6 ++++++
> >>>  1 file changed, 6 insertions(+)
> >>>
> >>>--- a/drivers/net/ethernet/marvell/mvneta.c
> >>>+++ b/drivers/net/ethernet/marvell/mvneta.c
> >>>@@ -1013,6 +1013,12 @@ static void mvneta_defaults_set(struct m
> >>>  		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);
> >>Hi Greg.
> >>
> >>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.

That's fine, we will be in sync with Linus's tree, so all is fine, and
it might spur people to get the thing fixed properly faster :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/