From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: corbet@lwn.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs: driver-model: Update the documentation for device class
Date: Sat, 3 Apr 2021 19:10:32 +0530 [thread overview]
Message-ID: <20210403134032.GA3817@thinkpad> (raw)
In-Reply-To: <YGhn6u3GrWZyrXuI@kroah.com>
On Sat, Apr 03, 2021 at 03:04:42PM +0200, Greg KH wrote:
> On Sat, Apr 03, 2021 at 05:30:50PM +0530, Manivannan Sadhasivam wrote:
> > The current documentation about the device class is out of date such
> > that it refers to non-existent APIs and structures. This commit updates
> > them to the current device class APIs and structures, removes wordings
> > that no longer valid while trying to keep the original content intact.
>
> Thanks for working on this!
>
> One thing that instantly jumped out at me:
>
> > -Class drivers can export attributes using the DEVCLASS_ATTR macro that works
> > -similarly to the DEVICE_ATTR macro for devices. For example, a definition
> > +Class drivers can export attributes using the CLASS_ATTR_* macros that works
> > +similarly to the DEVICE_ATTR_* macros for devices. For example, a definition
> > like this::
> >
> > - static DEVCLASS_ATTR(debug,0644,show_debug,store_debug);
> > + static CLASS_ATTR_RW(debug, 0644, show_debug, store_debug);
>
> CLASS_ATTR_RW(debug);
> is the correct way to write the above, what you added there will not
> build.
>
Oops... I just did a blind replace there, thanks for spotting.
> But a meta-comment, should stuff like this go directly into the .c files
> itself so that the documentation is created automatically? the fact
> that this lives so "far away" from the source ensures that it will
> always be out of date. I know other subsystems (graphics, v4l2) have
> tied the documentation into their code files much better so I think the
> build and markup infrastructure is there today to do this.
>
Well you're right that this documentation is far from its implementation but
that applies to most of the stuffs inside kernel, right? Also, I think if we
move these into .c file, then it will flood the whole file IMO.
We already have the kernel doc for most of the APIs/structures and that should
be enough for the .c/.h code in my perspective. If a developer wants to obtain
more information other than the API/struct definitions, then they should land
in documentation.
It should be responsibility of the maintainer to keep the doc up-to date :)
Thanks,
Mani
> thanks,
>
> greg k-h
prev parent reply other threads:[~2021-04-03 13:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-03 12:00 [PATCH] docs: driver-model: Update the documentation for device class Manivannan Sadhasivam
2021-04-03 13:04 ` Greg KH
2021-04-03 13:40 ` Manivannan Sadhasivam [this message]
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=20210403134032.GA3817@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@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 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.