Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp4304863rwd; Tue, 23 May 2023 06:10:00 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ76PIrpSDDJAzMiAxu6s8lldyZ6tXtZdlWZpH0jWf8+Ysk7aYIwgijiUPalAGk5CLQJbK8+ X-Received: by 2002:a05:6a20:1441:b0:10c:4a13:a5cf with SMTP id a1-20020a056a20144100b0010c4a13a5cfmr3174728pzi.6.1684847399924; Tue, 23 May 2023 06:09:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684847399; cv=none; d=google.com; s=arc-20160816; b=D7VcZ0itzpG+6hhfNfmERckOBmK72gbI4ZEWLh4/Py5gKpoqwWkqqjctl11RbF31v+ WdRJp+BjSpT4cRW1pIaQzrJLGviQ/dN0zrCVpRKp15gZQ6hmJqTgiVSgWfYmGnI/gp3q 9lUmx99xrvJPVknU0zh4JqB4v/QykHvuZTk62jxqPPhM3ZyEG9HuYJK/UPc0S3k/3Xt2 yR4h2usQX5zoLXgrQhfizeWmC06verGmGkpf9WumLpK0jXH+/GdnJdRCQm6cPX9juFsC TpwLL3vgYDhk1YfKkaLdZeDBMljlW+CNqimGGM9YsZI8FaSTF+2x6/wsG41kiOFxVir6 a3Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Z6eOEPsyrN+N7rxxjRZ8obpKLPnx37W4en5fClkPwhs=; b=dlU1Xvq8vr7njUW/kuCtO6w7e9i6q6pW08Ewr/1pwGO/HWALygeMMH7smqt2j4vxHe vC55TLGgm7xzBQaIyUdCMCURVQr+QgUagla/Ick3JtzmFPja/LqiNp3ohzFRiG2FGo07 HoMkOKiYYDHHxHfck/DCSzV4khy1zxqFgCALFJiHNI3n0RZElKWnk9fVQmAxV82F/2op w99klCwmZok14abbhuaD4sPACSQqdch1YDVEMlrcoiyBi0WISMXQEpCmOFCeamNxlYTx GboMQigxgZ/b12nhxJAqq9sv+vYHh+XXgPcGqvrW/d92Kf8+rscDGcbu3s9sT/elrWeT 5Obg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=QF5fCvNg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g19-20020a625213000000b0063b669ec9a0si6735824pfb.103.2023.05.23.06.09.46; Tue, 23 May 2023 06:09:59 -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=@lunn.ch header.s=20171124 header.b=QF5fCvNg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236124AbjEWMr4 (ORCPT + 99 others); Tue, 23 May 2023 08:47:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236631AbjEWMrw (ORCPT ); Tue, 23 May 2023 08:47:52 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 392ABFF; Tue, 23 May 2023 05:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=Z6eOEPsyrN+N7rxxjRZ8obpKLPnx37W4en5fClkPwhs=; b=QF5fCvNg3Rr9X+pP2QSVuCCfxr tRKORr+icqPX3ynC8b13QzqnUzmvGDMeaoKWSKU5AS06sH0CjHQo02WPuIVG0Gq4i76PkYBkOUZRe vx6dYseNOBWFBd9yu6Z+i2TDSWwvBXVatZxVUy7pMLN30zEjmZcQYjbZvuM+Av3cwmrw=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1q1R3W-00DgTf-Ti; Tue, 23 May 2023 14:23:58 +0200 Date: Tue, 23 May 2023 14:23:58 +0200 From: Andrew Lunn To: Parthiban.Veerasooran@microchip.com Cc: hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ramon.nordin.rodriguez@ferroamp.se, Horatiu.Vultur@microchip.com, Woojung.Huh@microchip.com, Nicolas.Ferre@microchip.com, Thorsten.Kummermehr@microchip.com Subject: Re: [PATCH net-next v2 4/6] net: phy: microchip_t1s: fix reset complete status handling Message-ID: References: <20230522113331.36872-1-Parthiban.Veerasooran@microchip.com> <20230522113331.36872-5-Parthiban.Veerasooran@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 On Tue, May 23, 2023 at 05:30:06AM +0000, Parthiban.Veerasooran@microchip.com wrote: > Hi Andrew, > > On 22/05/23 6:13 pm, Andrew Lunn wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > On Mon, May 22, 2023 at 05:03:29PM +0530, Parthiban Veerasooran wrote: > >> As per the datasheet DS-LAN8670-1-2-60001573C.pdf, the Reset Complete > >> status bit in the STS2 register to be checked before proceeding for the > >> initial configuration. > > > > Is this the unmaskable interrupt status bit which needs clearing? > Yes, it is non-maskable interrupt. > > There is no mention of interrupts here. > The device will assert the Reset Complete (RESETC) bit in the Status 2 > (STS2) register to indicate that it has completed its internal > initialization and is ready for configuration. As the Reset Complete > status is non-maskable, the IRQ_N pin will always be asserted and driven > low following a device reset. Upon reading of the Status 2 register, the > pending Reset Complete status bit will be automatically cleared causing > the IRQ_N pin to be released and pulled high again. > > Do you think it makes sense to add these explanation regarding the reset > and interrupt behavior with the above comment for a better understanding? Comments should explain 'Why?'. At the moment, it is not clear why you are reading the status. The discussion so far has been about clearing the interrupt, not about checking it has actually finished its internal reset. So i think you should be mentioning interrupts somewhere. Especially since this is a rather odd behaviour. Andrew