Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp553802imw; Wed, 13 Jul 2022 03:48:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sr43PS9EaEIl7Zws6DWWbiI0agadVqrqoPTSkLmUPdD3DYWKYFUUv8DXpabVp1IOj34D0e X-Received: by 2002:a17:902:7106:b0:16c:6c95:6153 with SMTP id a6-20020a170902710600b0016c6c956153mr2561811pll.166.1657709294247; Wed, 13 Jul 2022 03:48:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657709294; cv=none; d=google.com; s=arc-20160816; b=rTYhnv039S/q/c1dAlhzRh3T5y4BXTdxPgmP160K3gi0livSUBSlvEwZNn1e13nZmK C9xTs0WsVlHGIE4Vx2mOm0v30UKNn+XBkeGMGsqtTg7LWUDWNiu/MdGHTw0qv0tX+/KP /H4AF7HfopCTpgQtqcACP5cF3rh6LOTZ4ZQzPg/GInJz+2HyJQMdSyKdovnLc2LnMV6Z FPWph/dk8Oucb49QR/8SQE3PiWeYc9fZEZwv4qUaK47RDfQt5halJrbr2ctJSbA+H3HK 7NouIXeklxv5T8S4ItV8ENG4cF/YabiMPl4PQeOZvf/MEf7rSFJi3Y6U93S5rjsWmcbk yY1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :dkim-signature; bh=YwnhdLLIH/ztIf1B0luePvRjqCfvKsdMVxFwIwlVIUQ=; b=L+FJV8W+SkYst+jSRGwOTjQZIBUQ7u1Bx7p9NHEWYupVKQzO4NVYdBXMgDRzYdrwR1 pYLw9CC12Q0RJbNVswk2THZrnr7dXSBsCQjY3muHOwWKhVjEC53oPgVGesgRjBNlRKlb ouxJOyk54kSOPXlffzgvNPAKqlm/z5tsTA3BuWwi26OJmjkiy3Rn4yF591M7fUHhmRIq HkZJu/bSddodWnlGLl1j2dCqSzNC0JWJbj/ZwETgJnjW/BEjHR3tG3Ao0XMCi0GaC9gj HEbDkCpAFx8G0pgAdsT0d0TzLo695Jc1wTBcukpifV76sWXMVl5ZmAUC+i0blTPzj/fv SfrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=StaWDPjX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i10-20020a170902cf0a00b0016bda9d975esi17247022plg.555.2022.07.13.03.48.02; Wed, 13 Jul 2022 03:48:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=StaWDPjX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231251AbiGMJwH (ORCPT + 99 others); Wed, 13 Jul 2022 05:52:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235614AbiGMJwD (ORCPT ); Wed, 13 Jul 2022 05:52:03 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 529B6F897D for ; Wed, 13 Jul 2022 02:52:02 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 7667D2222E; Wed, 13 Jul 2022 11:52:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1657705920; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YwnhdLLIH/ztIf1B0luePvRjqCfvKsdMVxFwIwlVIUQ=; b=StaWDPjXVzfBqSyBYE1HKYApzxrbhlNbcDTJ7750A2SUTCjOS4RlxPF0E+QkmoMOftYK5q rPOyXRD7ROB9VjR7IuNbJP4//ILzppLN2Il7yhB9Z+hzBvvT6JlDr2P2yK8RTRn9Od8WzA x2qI1N/H9X326CjGYXEAf86HrS+tGeU= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 13 Jul 2022 11:52:00 +0200 From: Michael Walle To: Steen Hegelund Cc: Philipp Zabel , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lars Povlsen , =?UTF-8?Q?Cl=C3=A9ment_L=C3=A9ger?= , Claudiu Beznea , Kavyasree Kotagiri , Horatiu Vultur Subject: Re: [PATCH] Revert "reset: microchip-sparx5: allow building as a module" In-Reply-To: References: <20220713084010.168720-1-p.zabel@pengutronix.de> <73dc6fcedebcae098751bd093fe2d028@walle.cc> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <595347d292ee31a9f0de031d6349f44e@walle.cc> X-Sender: michael@walle.cc X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+ Horatiu, I missed you earlier, sorry] Hi Steen, Am 2022-07-13 11:40, schrieb Steen Hegelund: > I am afraid that the exact list of affected modules is not available, > so using the > RESET_PROT_STAT.SYS_RST_PROT_VCORE bit is the best known way of > resetting as much as possible, and > still continue execution. Mh, you are designing that chip (at least the LAN966x) no? Shouldn't that information be available anywhere at Microchip? ;) Anyway, it looks like almost the whole chip is reset except some minor things. So the driver has actually a wrong name. Until recently only the switch driver was the sole user of it (at least on the lan966x). So, my question remains, is this correct? I mean the switch driver says, "reset the switch core", but what actually happens is that the the entire SoC except the CPU and maybe the io mux is reset. What about the watchdog for example? Will that be reset, too? -michael > This is what the Sparx5 datasheet has to say about the > SYS_RST_PROT_VCORE protect bit: > > The device can be soft-reset by writing SOFT_RST.SOFT_CHIP_RST. The > VCore system and CPU can be > protected from a device soft-reset by writing > RESET_PROT_STAT.SYS_RST_PROT_VCORE = 1 before > initiating soft-reset.  > > In this case, a chip-level soft reset is applied to all other blocks > except the VCore system and the > VCore CPU. When protecting the VCore system and CPU from a soft reset, > the frame DMA must be > disabled prior to a chip-level soft reset. The SERDES and PLL blocks > can be protected from reset by > writing to SOFT_RST.SOFT_SWC_RST instead of SOFT_CHIP_RST. > > The VCore general purpose registers (CPU::GPR) and GPIO alternate > modes (DEVCPU_GCB::GPIO_ALT) are > not affected by a soft-reset. These registers are only reset when an > external reset is asserted. > > BR > Steen > > On Wed, 2022-07-13 at 11:03 +0200, Michael Walle wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know >> the content is safe >> >> [+ Claudiu, Kavyasree ] >> Am 2022-07-13 10:40, schrieb Philipp Zabel: >> > This reverts commit b6b9585876da018bdde2d5f15d206a689c0d70f3. >> > >> > This breaks MDIO on kswitch-d10, presumably because the global switch >> > reset is not released early enough anymore. >> > >> > Reported-by: Michael Walle >> > Cc: Clément Léger >> > Signed-off-by: Philipp Zabel >> >> Thanks! >> >> Tested-by: Michael Walle >> >> And maybe Microchip can chime in here and tell us what >> subsystems in the SoC will actually be reset by this. >> I fear this reset will affect almost every part of the >> SoC. So it would have to be bound to every single >> device? Or maybe adding that reset to the switch driver >> was a mistake in the first place? >> >> I mean, if it wouldn't be for the guard bit, it would >> also reset the CPU core.. >> >> -michael