On 17.01.2019 07:19, Heiner Kallweit wrote: > On 16.01.2019 22:48, Andrew Lunn wrote: >> On Wed, Jan 16, 2019 at 09:25:15PM +0100, Heiner Kallweit wrote: >>> Every driver should have called phy_stop() before calling >>> phy_disconnect(). Let's check for this and ensure PHY is stopped >>> when starting with the actual work in phy_disconnect(). >> >> Hi Heiner >> >> Looking at the patch, i think why must the MAC driver call phy_stop() >> before phy_disconnect()? It keeps is symmetrical, you need >> phy_connect() and then phy_start(). But if the core can detect that >> phy_stop() has not been called, and can call phy_stop() when needed, >> we can probably simplify the MAC drivers by removing many of the >> phy_stop() calls. >> >> I think it might come down to where the phy_connect()/phy_disconnect() >> is performed. Sometimes it is in probe()/remove(), sometimes it is in >> open()/close(). If phy_disconnect() is in remove(), phy_stop() is >> needed in close(). But if phy_disconnect() is called in close() the >> phy_stop() could be skipped? >> > Right, there may be cases where this is possible. However typically I > see the following in network drivers in close(): > - first different things are stopped / cleaned up, where order is > critical (stopping PHY, tx queues, ..) > - then resources are released (free interrupt, ..) > Therefore I assume that in most cases the split to phy_stop() and > phy_disconnect() is needed. > After thinking about it again I think I'll go with the proposed approach to leave it to the driver whether he wants to call phy_stop() separately or not. So I will just remove the warning.
>> Before we start adding warning, we probably should first document the >> expectations. Documentation/networking/phy.txt seems like a good >> place. >> > Indeed, that's something we should do. > >> Andrew >> > Heiner >
