From patchwork Fri Sep 8 11:20:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Russell King (Oracle)" X-Patchwork-Id: 13377369 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7CEF1863 for ; Fri, 8 Sep 2023 11:21:00 +0000 (UTC) Received: from pandora.armlinux.org.uk (unknown [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECB461FF2 for ; Fri, 8 Sep 2023 04:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ticEEEbSo8nOvPYC8Qkd9ImNP/7mT+DtGJtUFOASLiM=; b=V5bzmEr1CN+o8EX91SxaCKUpjd scgj067GYCDnpR5i+bCMIC0Q6lHLQEyGiatWeGNuALKPRrkVkRnuCgoicR3rrhLdg5jIWYdYVTS50 dXl6vShxrkUrFfavhFoIQHt11Ggb1PfeQRTCcZiuUCvRk6XvaR0W7YyxJYf1FtZPMpQn6dO+vrUJX 3dzSJFdSC+VIxPaaAQFk8W3SPe2ivNHEskjd7Knw+rUmpdiJoLA0osByzCYgNdd8lj/aP1EHrXhWY fT6ppXdKF4zhs8NmJLmexpThY3uEkfBTKHwovhsarO+L+hxFCQYQaucuNy4EQhy+sV30cPB/Te4vL DHaMojqg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:40328) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qeZXE-0004s7-1t; Fri, 08 Sep 2023 12:20:24 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qeZXC-0006qI-58; Fri, 08 Sep 2023 12:20:22 +0100 Date: Fri, 8 Sep 2023 12:20:22 +0100 From: "Russell King (Oracle)" To: Andrew Lunn , Heiner Kallweit Cc: chenhao418@huawei.com, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Jijie Shao , lanhao@huawei.com, liuyonglong@huawei.com, netdev@vger.kernel.org, Paolo Abeni , shenjian15@huawei.com, wangjie125@huawei.com, wangpeiyang1@huawei.com Subject: [PATCH RFC net-next 0/7] net: phy: avoid race when erroring stopping PHY Message-ID: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Sender: Russell King (Oracle) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,RDNS_NONE, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: kuba@kernel.org X-Patchwork-State: RFC This series addresses a problem reported by Jijie Shao where the PHY state machine can race with phy_stop() leading to an incorrect state. The issue centres around phy_state_machine() dropping the phydev->lock mutex briefly, which allows phy_stop() to get in half-way through the state machine, and when the state machine resumes, it overwrites phydev->state with a value incompatible with a stopped PHY. This causes a subsequent phy_start() to issue a warning. We address this firstly by using versions of functions that do not take tne lock, moving them into the locked region. The only function that this can't be done with is phy_suspend() which needs to call into the driver without taking the lock. For phy_suspend(), we split the state machine into two parts - the initial part which runs under the phydev->lock, and the second part which runs without the lock. We finish off by using the split state machine in phy_stop() which removes another unnecessary unlock-lock sequence from phylib. drivers/net/phy/phy.c | 204 +++++++++++++++++++++++++++----------------------- 1 file changed, 110 insertions(+), 94 deletions(-) Tested-by: Jijie Shao