From: Johan Hovold <johan@kernel.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: 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 14:14:07 +0100 [thread overview]
Message-ID: <Y5cpH8aV7aox2Pbd@hovoldconsulting.com> (raw)
In-Reply-To: <4cf7bce3-dfbb-b064-9d91-27616bf11d6a@suse.com>
On Mon, Dec 12, 2022 at 12:13:54PM +0100, Oliver Neukum wrote:
>
>
> On 12.12.22 11:31, Johan Hovold wrote:
> > On Mon, Dec 12, 2022 at 11:19:00AM +0100, Oliver Neukum wrote:
> >> On 11.12.22 13:06, Johan Hovold wrote:
> >>
> >>> Due to a misunderstanding, a redundant and misleading kernel doc comment
> >>> for usb_set_intfdata() was recently added which claimed that the driver
> >>> data pointer must not be cleared during disconnect before "all actions
> >>> [are] completed", which is both imprecise and incorrect.
> >>
> >> OK, but is that a reason to remove all kerneldoc? Kerneldoc is generally
> >> a good thing. And if a pointer is NULLed by driver core, that will need
> >> to be in it. IMHO you'd better just remove the questionable part of the
> >> kerneldoc.
> >
> > Yeah, I started off with just rewriting the kernel doc and removing the
> > obviously incorrect bits, but then there is essentially nothing left of
> > the documentation.
>
> 1. that the function exists and its purpose
That should be apparent from the function name (and implementation).
> 2. its parameters
Apparent from the prototype.
But sure, it would not show up in generated documentation (like many
other functions).
> most kerneldoc isn't exactly a great revelation. Nevertheless it
> serves a purpose.
Yeah, we have a lot of
/**
* set_x_to_y() - set x to y
* @x: the x
* @y: the y
*/
it seems. Not sure how much value there is in that, though.
And in this case there was also no kernel doc for usb_get_intfdata()
which is equally self documenting. Why add redundant docs for only one
of these functions?
I'd rather drop this particular documentation which was added due to a
misunderstanding then go down the rabbit hole of adding mindless kernel
doc to every helper we have.
> > A driver does not need to care that the pointer is cleared by driver
> > core after the driver is unbound. The driver is gone.
>
> Is that true even with respect to sysfs?
Yes. The (device group) attributes are removed by driver core before
->remove() is called, otherwise you'd have an even bigger issue with the
driver data itself which is typically deallocated before the pointer is
cleared.
Johan
next prev parent reply other threads:[~2022-12-12 13:14 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 [this message]
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
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=Y5cpH8aV7aox2Pbd@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 \
/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.