Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758894AbbGHUQL (ORCPT ); Wed, 8 Jul 2015 16:16:11 -0400 Received: from smtp34.i.mail.ru ([94.100.177.94]:48192 "EHLO smtp34.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757946AbbGHUQI (ORCPT ); Wed, 8 Jul 2015 16:16:08 -0400 X-Greylist: delayed 12024 seconds by postgrey-1.27 at vger.kernel.org; Wed, 08 Jul 2015 16:16:07 EDT Subject: Re: [PATCH 4.1 11/56] mvneta: add forgotten initialization of autonegotiation bits To: Arnaud Ebalard References: <20150708073237.780280770@linuxfoundation.org> <20150708073238.389781888@linuxfoundation.org> <559D5996.5080506@list.ru> <20150708173655.GA16101@kroah.com> <559D6DBE.4040900@list.ru> <87k2uasapl.fsf@natisbad.org> Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Thomas Petazzoni , Florian Fainelli , netdev@vger.kernel.org, Stas Sergeev , "David S. Miller" , Sebastien Rannou From: Stas Sergeev Message-ID: <559D84FA.5030203@list.ru> Date: Wed, 8 Jul 2015 23:15:54 +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: <87k2uasapl.fsf@natisbad.org> 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 Content-Length: 2687 Lines: 60 08.07.2015 22:36, Arnaud Ebalard пишет: > Hi, > > Stas Sergeev 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 That one is fixed, so doesn't count. > and a new one on the table now > that 4.1 is out. For that we don't know the impact yet. I asked Sebastien Rannou about what HW he has connected via sgmii link and why does he use a fixed-link. If it is just some strange HW that does not generate the inband status where it should, perhaps it is not such a big deal to rush reverting it from Linus tree. > 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. I am not reluctant for a revert, I in fact _propose_ the revert for -stable. As for mainline - yes, I'd really rather just do a proper fix there, as there is probably not a big deal to wait just for a little longer till the proper fix is discussed. But since Greg have spoken against the divergence, I am currently in an undecided state. I guess I'll code the fix first, then will see. Hope the news will be tomorrow. > Anyway, if you come w/ a fix, I can commit to test it on the boards I > have. Thanks, I'll keep you CCed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/