All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>, Lukas Wunner <lukas@wunner.de>
Cc: Andrew Lunn <andrew@lunn.ch>, Oliver Neukum <oneukum@suse.com>,
	Oleksij Rempel <linux@rempel-privat.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: ordering of call to unbind() in usbnet_disconnect
Date: Thu, 31 Mar 2022 11:20:50 +0200	[thread overview]
Message-ID: <37ff78db-8de5-56c0-3da2-9effc17b4e41@suse.com> (raw)
In-Reply-To: <20220327083702.GC27264@pengutronix.de>



On 27.03.22 10:37, Oleksij Rempel wrote:
> On Sat, Mar 26, 2022 at 02:04:30PM +0100, Lukas Wunner wrote:
>> On Sat, Mar 26, 2022 at 01:49:28PM +0100, Andrew Lunn wrote:
>>> On Sat, Mar 26, 2022 at 01:39:29PM +0100, Lukas Wunner wrote:
>>>
>>>> On probe, they first attach the PHY, then register the netdev.
>>>> On remove, they detach the PHY, then unregister the netdev.
>>>>
>>>> Is it legal to detach the PHY from a registered (potentially running)
>>>> netdev? It looks wrong to me.
>>> I think the network stack guarantee that the close() method is called
>>> before unregister completes. It is a common pattern to attach the PHY
>>> in open() and detach it in close(). The stack itself should not be
>>> using the PHY when it is down, the exception being IOCTL handlers
>>> which people often get wrong.
>> But the PHY is detached from a *running* netdev *before* that netdev
>> is unregistered (and closed).  Is that really legal?
> IMO, it reflects, more or less, the reality of devices with SFP modules.
> The PHY can be physically removed from running netdev. At same time,
> netdev should be registered and visible for the user, even if PHY is not
> physically attached.
>
>
Hi,

this makes sense, but the relevance to the question of how to do an
unplug of the whole device is indirect, isn't it? I am afraid, putting my
maintainer's hat on, I have to point on that we have a stable tree for
which we will need some solution.

Nor can usbnet exclusively cater to device that expose their PHY
over MDIO. (or at all really). Intuitively I must say that exactly reversing
the order of probe() in disconnect() is kind of the default.
If there is a need to deviate from that, of course we will acomodate that,
but making this the exclusive order is another matter.

I really get that you want to discuss this matter exhaustively, but we
need to
come to some kind of conclusion.

    Regards
        Oliver


  reply	other threads:[~2022-03-31  9:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 11:25 ordering of call to unbind() in usbnet_disconnect Oliver Neukum
2022-03-10 11:38 ` Oleksij Rempel
2022-03-14 18:42   ` Lukas Wunner
2022-03-14 19:14     ` Andrew Lunn
2022-03-15  5:44       ` Oleksij Rempel
2022-03-15  8:32         ` Lukas Wunner
2022-03-15 11:38           ` Oleksij Rempel
2022-03-15 13:28             ` Andrew Lunn
2022-03-17 15:53               ` Oliver Neukum
2022-03-17 21:03                 ` Lukas Wunner
2022-03-21 10:17                 ` Lukas Wunner
2022-03-21 10:43                   ` Oleksij Rempel
2022-03-31  9:35                   ` Oliver Neukum
2022-03-21 10:02               ` Lukas Wunner
2022-03-21 13:10                 ` Andrew Lunn
2022-03-26 12:39                   ` Lukas Wunner
2022-03-26 12:49                     ` Andrew Lunn
2022-03-26 13:04                       ` Lukas Wunner
2022-03-27  8:37                         ` Oleksij Rempel
2022-03-31  9:20                           ` Oliver Neukum [this message]
2022-03-31  9:30                             ` Lukas Wunner
2022-03-31  9:59                               ` Oliver Neukum
2022-03-31 11:22                                 ` Lukas Wunner
2022-03-26 12:25             ` Lukas Wunner
2022-03-26 12:44               ` Andrew Lunn
2022-03-26 13:01                 ` Lukas Wunner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37ff78db-8de5-56c0-3da2-9effc17b4e41@suse.com \
    --to=oneukum@suse.com \
    --cc=andrew@lunn.ch \
    --cc=hkallweit1@gmail.com \
    --cc=linux@rempel-privat.de \
    --cc=lukas@wunner.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.