From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933010AbbGHSg7 (ORCPT ); Wed, 8 Jul 2015 14:36:59 -0400 Received: from smtp13.mail.ru ([94.100.181.94]:35780 "EHLO smtp13.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755310AbbGHSg5 (ORCPT ); Wed, 8 Jul 2015 14:36:57 -0400 X-Greylist: delayed 5151 seconds by postgrey-1.27 at vger.kernel.org; Wed, 08 Jul 2015 14:36:56 EDT Subject: Re: [PATCH 4.1 11/56] mvneta: add forgotten initialization of autonegotiation bits To: Greg Kroah-Hartman References: <20150708073237.780280770@linuxfoundation.org> <20150708073238.389781888@linuxfoundation.org> <559D5996.5080506@list.ru> <20150708173655.GA16101@kroah.com> Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Arnaud Ebalard , Thomas Petazzoni , Florian Fainelli , netdev@vger.kernel.org, Stas Sergeev , "David S. Miller" , Sebastien Rannou From: Stas Sergeev Message-ID: <559D6DBE.4040900@list.ru> Date: Wed, 8 Jul 2015 21:36:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150708173655.GA16101@kroah.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>> >>> [ 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 >>> >>> CC: Thomas Petazzoni >>> CC: Florian Fainelli >>> CC: netdev@vger.kernel.org >>> CC: linux-kernel@vger.kernel.org >>> CC: stable@vger.kernel.org >>> >>> Signed-off-by: Stas Sergeev >>> Signed-off-by: David S. Miller >>> Signed-off-by: Greg Kroah-Hartman >>> --- >>> 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. 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.