lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150708213116.GA31433@kroah.com>
Date:	Wed, 8 Jul 2015 14:31:16 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Arnaud Ebalard <arno@...isbad.org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev@...r.kernel.org, Stas Sergeev <stsp@...rs.sourceforge.net>,
	"David S. Miller" <davem@...emloft.net>,
	Sebastien Rannou <mxs@...k.org>
Subject: Re: [PATCH 4.1 11/56] mvneta: add forgotten initialization of
 autonegotiation bits

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@...t.ru>
> >>>
> >>>[ 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@vger.kernel.org/msg67928.html
> >>>
> >>>Since the patch was tested to fix a regression, it should be applied to
> >>>stable tree.
> >>>
> >>>Tested-by: Arnaud Ebalard <arno@...isbad.org>
> >>>
> >>>CC: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
> >>>CC: Florian Fainelli <f.fainelli@...il.com>
> >>>CC: netdev@...r.kernel.org
> >>>CC: linux-kernel@...r.kernel.org
> >>>CC: stable@...r.kernel.org
> >>>
> >>>Signed-off-by: Stas Sergeev <stsp@...rs.sourceforge.net>
> >>>Signed-off-by: David S. Miller <davem@...emloft.net>
> >>>Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >>>---
> >>>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ