From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76507C433E2 for ; Mon, 13 Jul 2020 15:38:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3387A20771 for ; Mon, 13 Jul 2020 15:38:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bnn3vBgS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3387A20771 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oW7s3Alb3GUH5mgB2SESQtmDjsUs7Mu69bI5wMloOWA=; b=bnn3vBgS0sgn5sG6ftILoIc2z JBTNgZmWy93X/cki/v3TwQPhQ1Mj2o8emjgLm97dAkq7RAhHRzmtR9t/XK/iXEm5SqQPs0g3OZ3Qq m3bqAZcY8bH2NR/aq4PM58txlz0ZofaauWx491Z4w9W9vyr4yLugunlqNeUCwcW4dOTd4kQcR0chg MKNsMsG+NvHOCApcDWppj7NqFAurVSESABXHw/B7ubJhMHzgk+Ez6lazbQaiaDrRnX1qY7r+4zn6x 4hziPcVR4HULFxEMI8t/cnxl9UzOCckYdUeluAqHtop1OcoUZ9mnerQwzFwyckvHyVZ1D5fhbaNGm 8oOgS4wYQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jv0Vr-0004kp-6H; Mon, 13 Jul 2020 15:37:03 +0000 Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jv0Vn-0004j4-Bc for linux-arm-kernel@lists.infradead.org; Mon, 13 Jul 2020 15:37:01 +0000 X-Originating-IP: 91.175.115.186 Received: from localhost (91-175-115-186.subs.proxad.net [91.175.115.186]) (Authenticated sender: gregory.clement@bootlin.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 7B534C0002; Mon, 13 Jul 2020 15:36:54 +0000 (UTC) From: Gregory CLEMENT To: Vinod Koul , Russell King - ARM Linux admin Subject: Re: [PATCH 2/2] phy: armada-38x: fix NETA lockup when repeatedly switching speeds In-Reply-To: <20200713061846.GE34333@vkoul-mobl> References: <20200630160452.GD1551@shell.armlinux.org.uk> <20200701065727.GY2599@vkoul-mobl> <20200710151921.GJ1551@shell.armlinux.org.uk> <20200713061846.GE34333@vkoul-mobl> Date: Mon, 13 Jul 2020 17:36:54 +0200 Message-ID: <87365v5svd.fsf@FE-laptop> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200713_113659_616782_FCF5253E X-CRM114-Status: GOOD ( 30.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Jason Cooper , devicetree@vger.kernel.org, Kishon Vijay Abraham I , Rob Herring , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello, > On 10-07-20, 16:19, Russell King - ARM Linux admin wrote: >> On Wed, Jul 01, 2020 at 12:27:27PM +0530, Vinod Koul wrote: >> > On 30-06-20, 17:05, Russell King wrote: >> > > The mvneta hardware appears to lock up in various random ways when >> > > repeatedly switching speeds between 1G and 2.5G, which involves >> > > reprogramming the COMPHY. It is not entirely clear why this happens, >> > > but best guess is that reprogramming the COMPHY glitches mvneta clocks >> > > causing the hardware to fail. It seems that rebooting resolves the >> > > failure, but not down/up cycling the interface alone. >> > > >> > > Various other approaches have been tried, such as trying to cleanly >> > > power down the COMPHY and then take it back through the power up >> > > initialisation, but this does not seem to help. >> > > >> > > It was finally noticed that u-boot's last step when configuring a >> > > COMPHY for "SGMII" mode was to poke at a register described as >> > > "GBE_CONFIGURATION_REG", which is undocumented in any external >> > > documentation. All that we have is the fact that u-boot sets a bit >> > > corresponding to the "SGMII" lane at the end of COMPHY initialisation. >> > > >> > > Experimentation shows that if we clear this bit prior to changing the >> > > speed, and then set it afterwards, mvneta does not suffer this problem >> > > on the SolidRun Clearfog when switching speeds between 1G and 2.5G. >> > > >> > > This problem was found while script-testing phylink. >> > > >> > > Signed-off-by: Russell King >> > > --- >> > > arch/arm/boot/dts/armada-38x.dtsi | 3 +- >> > >> > lgtm, i need ack for dts parts before I can apply this >> >> I'm not sure what the situation is for Bootlin, but they don't seem to >> be very responsive right now (covid related?) >> >> What I know from what I've been party to on netdev is that Bootlin >> sent a patch for the MVPP2 driver, and the very next day someone >> reported that the patch caused a bug. Unfortunately, the patch got >> picked up anyway, but there was no response from Bootlin. After a >> month or so, -final was released containing this patch, so now it >> had become a regression - and still no response from Bootlin. >> >> Eventually the bug got fixed - not because Bootlin fixed it, but >> because I ended up spending the time researching how that part of >> the network driver worked, diagnosing what was going on, and >> eventually fixing it in the most obvious way - but it's not clear >> that the fix was the right approach. Bootlin never commented. See >> 3138a07ce219 ("net: mvpp2: fix RX hashing for non-10G ports"). >> >> So, I think we have to assume that Bootlin are struggling right now, >> and as it's been over a week, it's unlikely that they are going to >> respond soon. What do you think we should do? >> >> I also note that Rob has not responded to the DT binding change >> either, despite me gently prodding, and Rob processing a whole raft >> of DT binding stuff yesterday. >> >> I can split the DTS change from the rest of the patch, but I don't >> think that really helps without at least the binding change being >> agreed. > > I would prefer splitting, you may sent the DTS to arm arch folks if no > response from subarch folks Yes please could you split the patch to put the dts apart ? And if the binding is accepted we will apply it. Thanks, Gregory > > -- > ~Vinod -- Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82235C433E7 for ; Mon, 13 Jul 2020 15:37:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6EC4C20773 for ; Mon, 13 Jul 2020 15:37:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729811AbgGMPhC (ORCPT ); Mon, 13 Jul 2020 11:37:02 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:35673 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729806AbgGMPg6 (ORCPT ); Mon, 13 Jul 2020 11:36:58 -0400 X-Originating-IP: 91.175.115.186 Received: from localhost (91-175-115-186.subs.proxad.net [91.175.115.186]) (Authenticated sender: gregory.clement@bootlin.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 7B534C0002; Mon, 13 Jul 2020 15:36:54 +0000 (UTC) From: Gregory CLEMENT To: Vinod Koul , Russell King - ARM Linux admin Cc: Andrew Lunn , Jason Cooper , Kishon Vijay Abraham I , Rob Herring , Sebastian Hesselbarth , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/2] phy: armada-38x: fix NETA lockup when repeatedly switching speeds In-Reply-To: <20200713061846.GE34333@vkoul-mobl> References: <20200630160452.GD1551@shell.armlinux.org.uk> <20200701065727.GY2599@vkoul-mobl> <20200710151921.GJ1551@shell.armlinux.org.uk> <20200713061846.GE34333@vkoul-mobl> Date: Mon, 13 Jul 2020 17:36:54 +0200 Message-ID: <87365v5svd.fsf@FE-laptop> MIME-Version: 1.0 Content-Type: text/plain Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hello, > On 10-07-20, 16:19, Russell King - ARM Linux admin wrote: >> On Wed, Jul 01, 2020 at 12:27:27PM +0530, Vinod Koul wrote: >> > On 30-06-20, 17:05, Russell King wrote: >> > > The mvneta hardware appears to lock up in various random ways when >> > > repeatedly switching speeds between 1G and 2.5G, which involves >> > > reprogramming the COMPHY. It is not entirely clear why this happens, >> > > but best guess is that reprogramming the COMPHY glitches mvneta clocks >> > > causing the hardware to fail. It seems that rebooting resolves the >> > > failure, but not down/up cycling the interface alone. >> > > >> > > Various other approaches have been tried, such as trying to cleanly >> > > power down the COMPHY and then take it back through the power up >> > > initialisation, but this does not seem to help. >> > > >> > > It was finally noticed that u-boot's last step when configuring a >> > > COMPHY for "SGMII" mode was to poke at a register described as >> > > "GBE_CONFIGURATION_REG", which is undocumented in any external >> > > documentation. All that we have is the fact that u-boot sets a bit >> > > corresponding to the "SGMII" lane at the end of COMPHY initialisation. >> > > >> > > Experimentation shows that if we clear this bit prior to changing the >> > > speed, and then set it afterwards, mvneta does not suffer this problem >> > > on the SolidRun Clearfog when switching speeds between 1G and 2.5G. >> > > >> > > This problem was found while script-testing phylink. >> > > >> > > Signed-off-by: Russell King >> > > --- >> > > arch/arm/boot/dts/armada-38x.dtsi | 3 +- >> > >> > lgtm, i need ack for dts parts before I can apply this >> >> I'm not sure what the situation is for Bootlin, but they don't seem to >> be very responsive right now (covid related?) >> >> What I know from what I've been party to on netdev is that Bootlin >> sent a patch for the MVPP2 driver, and the very next day someone >> reported that the patch caused a bug. Unfortunately, the patch got >> picked up anyway, but there was no response from Bootlin. After a >> month or so, -final was released containing this patch, so now it >> had become a regression - and still no response from Bootlin. >> >> Eventually the bug got fixed - not because Bootlin fixed it, but >> because I ended up spending the time researching how that part of >> the network driver worked, diagnosing what was going on, and >> eventually fixing it in the most obvious way - but it's not clear >> that the fix was the right approach. Bootlin never commented. See >> 3138a07ce219 ("net: mvpp2: fix RX hashing for non-10G ports"). >> >> So, I think we have to assume that Bootlin are struggling right now, >> and as it's been over a week, it's unlikely that they are going to >> respond soon. What do you think we should do? >> >> I also note that Rob has not responded to the DT binding change >> either, despite me gently prodding, and Rob processing a whole raft >> of DT binding stuff yesterday. >> >> I can split the DTS change from the rest of the patch, but I don't >> think that really helps without at least the binding change being >> agreed. > > I would prefer splitting, you may sent the DTS to arm arch folks if no > response from subarch folks Yes please could you split the patch to put the dts apart ? And if the binding is accepted we will apply it. Thanks, Gregory > > -- > ~Vinod -- Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com