public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: drop misleading usb_set_intfdata() kernel doc
Date: Mon, 12 Dec 2022 17:08:17 +0100	[thread overview]
Message-ID: <Y5dR8X2mnytSCWrp@hovoldconsulting.com> (raw)
In-Reply-To: <Y5dH5RqY2yOK1bVj@rowland.harvard.edu>

On Mon, Dec 12, 2022 at 10:25:25AM -0500, Alan Stern wrote:

> > Since you insist, I'll just rewrite the whole thing.
> 
> You're both missing the main point, which is that the USB core clears 
> intfdata after a driver is unbound.

I assure you that that hasn't been missed. :)

> As a consequence, drivers don't 
> need to worry about clearing intfdata themselves -- a fact which is 
> _not_ easily apparent from the implementation.  This would be a useful 
> thing to mention in the kerneldoc, as it may help prevent lots of 
> drivers from making unnecessary function calls (like the ones that 
> Vincent recently removed).

My point is that the fact the USB core (and driver core) clears the
pointer after the driver is unbound is mostly irrelevant. The driver
would typically have freed the driver data at that point anyway, and the
interface must no longer be used by the driver (e.g. as it could be
bound to a new driver).

This is a fundamental property of the driver model and not something
that necessarily needs to be repeated for every function that operates
on a struct device (or a subsystem container like struct usb_interface).

> Of course, this doesn't mean that drivers can't clear intfdata if they 
> want to, for example, if they use it as an internal flag.  But 
> developers shouldn't feel that they _need_ to clear it as a sort of 
> hygienic measure.

Right.

> IMO it's worthwhile keeping the kerneldoc (but correcting it) so that it 
> can get this point across.

As you saw I fixed up the kernel doc in v2, and tried to get the point
about not having to clear the pointer across without getting into too
much detail.

The fact that USB core and driver core clears the pointer is an
implementation detail which in principle could change. The important
part is that drivers generally should not touch the struct device or
containing structure after unbind (and must do so with care otherwise).

Johan

  reply	other threads:[~2022-12-12 16:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-11 12:06 [PATCH] USB: drop misleading usb_set_intfdata() kernel doc Johan Hovold
2022-12-12 10:19 ` Oliver Neukum
2022-12-12 10:31   ` Johan Hovold
2022-12-12 11:13     ` Oliver Neukum
2022-12-12 13:14       ` Johan Hovold
2022-12-12 13:27         ` Oliver Neukum
2022-12-12 13:40           ` Johan Hovold
2022-12-12 14:04             ` Oliver Neukum
2022-12-12 14:14               ` Johan Hovold
2022-12-12 15:25                 ` Alan Stern
2022-12-12 16:08                   ` Johan Hovold [this message]
2022-12-12 16:39                     ` Alan Stern

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=Y5dR8X2mnytSCWrp@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=oneukum@suse.com \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox