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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,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 39162C433E0 for ; Tue, 21 Jul 2020 17:29:32 +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 051BD2065D for ; Tue, 21 Jul 2020 17:29:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="c5/AofYq"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="GYzhbEZx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 051BD2065D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rX2Fd7tWUnwqFNhITX41bP80idHFG+HHHP5PQumAPlU=; b=c5/AofYq4LW2RIIql53FUcsyv Yi+uElzgI4XS2Mt7wHgn9n8H8nQx0GPF4zV0gnSB0khqmIk1urDqrwtp4rBw45LjteFQaT6p7LyuT z6luHROXey1+yfRluxMqiH7aJTECiAIX0sLGqw56eZXkSeVX5WuTzxzmED66e8GyqEJO/JslJJKqV WvLeX4n+VQxLQKzd3EPFUTrEJGZSznVwsbqUzzvPCj15hN6zNtb52Y/EvQxMtLPIW8vxeH9ON723E ZjppJJW8cLJAW3aswA6NIFUb5msVEc+gEfRL1rRsfqO+I1z9svs0aGJV8VYsg4EemxXDtkNIEQP+e uyBH4/j2Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jxw3q-0003gK-KC; Tue, 21 Jul 2020 17:28:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jxw3o-0003fc-9F for linux-arm-kernel@lists.infradead.org; Tue, 21 Jul 2020 17:28:12 +0000 Received: from localhost (unknown [122.171.202.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 41B302065D; Tue, 21 Jul 2020 17:28:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595352491; bh=YF4nPnFDznHPW2MW5uypg9cVqrtkKdwCBtlzagc+f2k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GYzhbEZxz26TtxCK9ZuVFVZP9GQaJioiufy3WmmEu3Wq7FdtzC2HA2UB7LZmMD9HK BBKGQo5EIk1Uii16I00PXLCEPtaMfwQMha6bDowXr2fz3aqj+pwboq9OZ4Uo+3o2Ae o8zbx0kERanOxW/F+Z09QdwfofyRz2REfdlkCoHY= Date: Tue, 21 Jul 2020 22:58:07 +0530 From: Vinod Koul To: Russell King - ARM Linux admin Subject: Re: [PATCH v2 0/3] Fix Armada 38x mvneta lockups when switching speeds Message-ID: <20200721172807.GN12965@vkoul-mobl> References: <20200721143756.GT1605@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200721143756.GT1605@shell.armlinux.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200721_132812_406159_C939D74B X-CRM114-Status: GOOD ( 21.93 ) 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, Gregory Clement , 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 On 21-07-20, 15:37, Russell King - ARM Linux admin wrote: > Hi, > > While testing phylink over the weekend, I found it was possible to > cause the mvneta hardware to lockup in various weird and wonderful > ways by switching the interface speed between 1G and 2.5G repeatedly. > It didn't require a rapid switching, but one switch every few seconds. > > Symptoms included one or more of: > - Timeout while trying to stop transmit (seen once) > - 2500BASE-X link negotiation failure (fails to exchange link word.) > - Detects lack of sync, but fails to flag 10ms of sync failure. > - SyncOk bit randomly toggles. > > Once the hardware gets into a "bad" state, trying to recover it by > using the mvneta GMAC port reset fails to resolve the issue. > Disabling the port also fails to recover it. The only way to > recover seemed to be via a reboot. > > Many solutions to solve this were tried in various combinations - > while changing the COMPHY configuration: > - putting the GMAC into reset > - disabling the GMAC port > - augmenting the COMPHY configuration to try to "cleanly" disable > the COMPHY via phy_power_down() and reconfigure it via > phy_power_up(), including resetting parts of the COMPHY and > re-running the RX initialisation. > > None of that worked. It was then discovered from the u-boot sources > that there is an undocumented register that has a lane-specific bit > set at the end of COMPHY initialisation, once the loosely documented > COMPHY setup has completed. > > Experimentation with that showed that if the lane specific bit is > cleared before changing the COMPHY "GEN" configuration, and set > afterwards, mvneta no longer locks up. > > Unfortunately, this undocumented register is not part of the COMPHY > register set that we map - it is located in a region of "System > Registers" which are shared between multiple different devices. > > Who should be responsible for mapping this register (mvneta or > COMPHY) was considered; the register is only present on Armada 38x > systems, and seemingly not on Armada 37x or Armada 37xx systems. > It seems that it is a system-level register. The COMPHYs seem to > be system specific, so let's make it part of the COMPHY. > > With no real information on this register, all we can do is guess > about it's function and how to fit it into the system. Applied 1 & 3, thanks -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel