Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2503191rwb; Fri, 2 Dec 2022 10:38:00 -0800 (PST) X-Google-Smtp-Source: AA0mqf7olgxj4yfX89PGMeRZGC9U3dHh6X/YlKNr7wewqzAda0uAj0qNyMvqbozlzfgUdfPeratW X-Received: by 2002:a17:903:1341:b0:189:9a36:accf with SMTP id jl1-20020a170903134100b001899a36accfmr20767139plb.19.1670006280122; Fri, 02 Dec 2022 10:38:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670006280; cv=none; d=google.com; s=arc-20160816; b=TqvoY7VzcOfAAxPTbXR1kVsfHVhDKic31BpHRDoiQDQ28FE3NTxQToyRc/zBx7MLp1 Jl77yLuDOIuBH1vjhE1gUD6V0AXdzThHXPd+vqDeGMqHRWbughoepj2SthEy9sorgdIc LArxnqQmdJQy2EHyaj0+PBG7o3d2939peoh9Kr7Grd5JDO2nbm9NgKRTS4rLZ0QGFALu F48NMsTveSyTKw7hbdcBmWR8HsYPUGgVrS47+xYsj8rDEfg73NjQaNaBz+ykfv5vR8lc VHmXPRSodoLnaI7JBZLNX5Cd5BD09Dgk2T2L407BRy9Jth1N98AfOpjkzsyd3Jdes7QX e0LA== 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=R0fGDqmvQrSQkxfa81/zaMzQhWSTRfKrZBbNxZjHPdY=; b=ncp+yWEQIKY9yNLfcmcsczjRctL2UqjjmMDM+J5SJ566wOVun9UHFtbEpSfJ92nkw+ ob0SN34vXFra+6zwK7RFLyxrqK/4bm7lITcNS+kF4DEsgJ1hu+uZQfNFJWEid6ME9TIc /ythH9Apm5ycObyAL2HPyI1gaSF4q7eelZic58MDQx2aJE0JSLIqPNyMhVQyDdM0fzlP 3J2yQYFNdewZnJ0ZWi2r/P8PWhi/CY1LF6DdkIuHGRM2mx16Gw12pXPl7bcqbkoWp5dg 7wt0U52cqNTd0F66BEEGIloFg03w7Y/Giuh4Lbu5asBAM/vyNYBqRBDuUWbGQfJM4WBB 9KlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=vpxC4Nup; 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 gf18-20020a17090ac7d200b002193f84afc5si9907747pjb.121.2022.12.02.10.37.49; Fri, 02 Dec 2022 10:38:00 -0800 (PST) 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=vpxC4Nup; 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 S234056AbiLBSXh (ORCPT + 83 others); Fri, 2 Dec 2022 13:23:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233783AbiLBSXg (ORCPT ); Fri, 2 Dec 2022 13:23:36 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3930BD94; Fri, 2 Dec 2022 10:23:35 -0800 (PST) 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=R0fGDqmvQrSQkxfa81/zaMzQhWSTRfKrZBbNxZjHPdY=; b=vpxC4NupKJoV9CYI2lEnN260KV cZ9bN7e+5IrBfxlAG8Qx9W+b3mfCLlVOtT1fpMztUKTZ2lJP4o3qb5YCDifKM43sOGcbWbHKdG61l UbO6hI6QOAY+84XOUdV2vatxZgXjPWewt92Pnb29D233Oh6sPzZ8pDJVQu22bkxOJ9ug=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1p1Agi-004Clh-Si; Fri, 02 Dec 2022 19:23:04 +0100 Date: Fri, 2 Dec 2022 19:23:04 +0100 From: Andrew Lunn To: Michael Walle Cc: Xu Liang , Heiner Kallweit , Russell King , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH net-next v1 1/4] net: phy: mxl-gpy: add MDINT workaround Message-ID: References: <20221202151204.3318592-1-michael@walle.cc> <20221202151204.3318592-2-michael@walle.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221202151204.3318592-2-michael@walle.cc> 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 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 Fri, Dec 02, 2022 at 04:12:01PM +0100, Michael Walle wrote: > At least the GPY215B and GPY215C has a bug where it is still driving the > interrupt line (MDINT) even after the interrupt status register is read > and its bits are cleared. This will cause an interrupt storm. > > Although the MDINT is multiplexed with a GPIO pin and theoretically we > could switch the pinmux to GPIO input mode, this isn't possible because > the access to this register will stall exactly as long as the interrupt > line is asserted. We exploit this very fact and just read a random > internal register in our interrupt handler. This way, it will be delayed > until the external interrupt line is released and an interrupt storm is > avoided. > > The internal register access via the mailbox was deduced by looking at > the downstream PHY API because the datasheet doesn't mention any of > this. > > Signed-off-by: Michael Walle > --- > drivers/net/phy/mxl-gpy.c | 83 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 83 insertions(+) > > diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c > index 0ff7ef076072..20e610dda891 100644 > --- a/drivers/net/phy/mxl-gpy.c > +++ b/drivers/net/phy/mxl-gpy.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -81,6 +82,14 @@ > #define VSPEC1_TEMP_STA 0x0E > #define VSPEC1_TEMP_STA_DATA GENMASK(9, 0) > > +/* Mailbox */ > +#define VSPEC1_MBOX_DATA 0x5 > +#define VSPEC1_MBOX_ADDRLO 0x6 > +#define VSPEC1_MBOX_CMD 0x7 > +#define VSPEC1_MBOX_CMD_ADDRHI GENMASK(7, 0) > +#define VSPEC1_MBOX_CMD_RD (0 << 8) > +#define VSPEC1_MBOX_CMD_READY BIT(15) > + > /* WoL */ > #define VPSPEC2_WOL_CTL 0x0E06 > #define VPSPEC2_WOL_AD01 0x0E08 > @@ -88,7 +97,15 @@ > #define VPSPEC2_WOL_AD45 0x0E0A > #define WOL_EN BIT(0) > > +/* Internal registers, access via mbox */ > +#define REG_GPIO0_OUT 0xd3ce00 > + > struct gpy_priv { > + struct phy_device *phydev; > + > + /* serialize mailbox acesses */ > + struct mutex mbox_lock; > + > static int gpy_probe(struct phy_device *phydev) > { > struct device *dev = &phydev->mdio.dev; > @@ -228,7 +286,9 @@ static int gpy_probe(struct phy_device *phydev) > priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); > if (!priv) > return -ENOMEM; > + priv->phydev = phydev; I don't think you use this anywhere. Maybe in one of the following patches? Andrew