From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: Potential issue with f5e64032a799 "net: phy: fix resume handling" Date: Tue, 6 Feb 2018 13:55:07 +0100 Message-ID: <20180206125507.GA25595@lunn.ch> References: <4886212b-0274-ffa0-f98e-da2e43a3b042@gmail.com> <20180203201748.GN16818@lunn.ch> <1fa6517b-2a73-7c0c-48aa-afb17ff89440@gmail.com> <4b67f2ac-3fe0-9567-404b-1e58b0fc5eaf@gmail.com> <928cdba7-bc44-92af-9763-3a14da036289@gmail.com> <20180206110012.GJ9418@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Heiner Kallweit , Florian Fainelli , "netdev@vger.kernel.org" To: Russell King - ARM Linux Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:46828 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752815AbeBFMzN (ORCPT ); Tue, 6 Feb 2018 07:55:13 -0500 Content-Disposition: inline In-Reply-To: <20180206110012.GJ9418@n2100.armlinux.org.uk> Sender: netdev-owner@vger.kernel.org List-ID: > Maybe a better solution now would be to restore phy_resume()'s lock- > taking behaviour, and provide a lockless __phy_resume() which can be > used internally within phylib. This means drivers using phy_resume() > would see no change. Maybe something like (untested): Hi Russell I was thinking the same, and have a pretty much identical untested patch. This gets things 'fixed' and we can then later come back and look at the overall architecture. Andrew