From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
Christian Marangi <ansuelsmth@gmail.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
David Epping <david.epping@missinglinkelectronics.com>,
Vladimir Oltean <olteanv@gmail.com>,
Harini Katakam <harini.katakam@amd.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
workflows@vger.kernel.org
Subject: Re: [net-next PATCH v3 3/3] net: phy: add support for PHY package MMD read/write
Date: Tue, 5 Dec 2023 16:11:26 +0000 [thread overview]
Message-ID: <ZW9LroqqugXzqAY9@shell.armlinux.org.uk> (raw)
In-Reply-To: <20231205072912.2d79a1d5@kernel.org>
On Tue, Dec 05, 2023 at 07:29:12AM -0800, Jakub Kicinski wrote:
> On Tue, 5 Dec 2023 15:10:50 +0000 Russell King (Oracle) wrote:
> > I've raised this before in other subsystems, and it's suggested that
> > it's better to have it in the .c file. I guess the reason is that it's
> > more obvious that the function is documented when modifying it, so
> > there's a higher probability that the kdoc will get updated when the
> > function is altered.
>
> Plus I think people using IDEs (i.e. not me) may use the "jump to
> definition" functionality, to find the doc?
>
> TBH I thought putting kdoc in the C source was documented in the coding
> style, but I can't find any mention of it now.
Well, in Documentation/doc-guide/kernel-doc.rst:
The function and type kernel-doc comments should be placed just before
the function or type being described in order to maximise the chance
that somebody changing the code will also change the documentation.
That implies (but not explicitly) that it should be at the function
definition site, since "changing the code" is used as an argument as
I did in my previous email.
Secondly, this document goes on to give an example of running
scripts/kernel-doc on a .c file.
Thirdly, there are seven references in this document of kernel-doc
in .c files, and only one for kernel-doc in a .h file. So this suggests
that "it will be in a .c file" isn't a rule (it can't be because of
documenting structures!)
So let's not get hung up on whether it should be in .c or .h because I
think that isn't relevant. Instead, I think it's about "it should be at
the definition site" - that being a structure definition or a function
definition, and not at a function prototype.
The only exception I can think of is the style I've used in
linux/phylink.h for the _method_ definitions which look like function
prototypes - that's just a work-around because one can't kernel-doc
the structure-of-function-pointers and document the function parameters
without jumping through that hoop, and it would be silly to document
the methods in some random driver!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-12-05 16:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231128133630.7829-1-ansuelsmth@gmail.com>
[not found] ` <20231128133630.7829-3-ansuelsmth@gmail.com>
[not found] ` <20231204181752.2be3fd68@kernel.org>
[not found] ` <51aae9d0-5100-41af-ade0-ecebeccbc418@lunn.ch>
[not found] ` <656f37a6.5d0a0220.96144.356f@mx.google.com>
[not found] ` <adbe5299-de4a-4ac1-90d0-f7ae537287d0@lunn.ch>
[not found] ` <ZW89errbJWUt33vz@shell.armlinux.org.uk>
2023-12-05 15:29 ` Jakub Kicinski
2023-12-05 16:11 ` Russell King (Oracle) [this message]
2023-12-05 17:44 ` Jeff Johnson
2023-12-05 18:14 ` Russell King (Oracle)
2023-12-05 19:58 ` Jeff Johnson
2023-12-05 20:11 ` Andrew Lunn
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=ZW9LroqqugXzqAY9@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=david.epping@missinglinkelectronics.com \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=harini.katakam@amd.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=workflows@vger.kernel.org \
/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