Re: [PATCH v4] kernel.h: add comments for system_states

James Bottomley
2025-09-06T12:13:06Z

On Fri, 2025-09-05 at 16:06 +0300, Jani Nikula wrote:
> On Fri, 05 Sep 2025, Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> > Em Fri, 05 Sep 2025 12:02:37 +0300
> > Jani Nikula <jani.nikula@linux.intel.com> escreveu:
> >
> > > On Wed, 03 Sep 2025, Randy Dunlap <rdunlap@infradead.org> wrote:
[...]
> > > > +++ linux-next-20250819/Documentation/driver-api/pm/devices.rst
> > > > @@ -241,6 +241,14 @@ before reactivating its class I/O queues
> > > >  More power-aware drivers might prepare the devices for
> > > > triggering system wakeup
> > > >  events.
> > > >
> > > > +System states available for drivers
> > > > +-----------------------------------
> > > > +
> > > > +These system states are available for drivers to help them
> > > > determine how to
> > > > +handle state transitions.
> > > > +
> > > > +.. kernel-doc:: include/linux/kernel.h
> > > > +   :doc: General system_states available for drivers
> > > >
> > > >  Call Sequence Guarantees
> > > >  ------------------------
> > > >
> > >
> >
> > If the problem is with "extern" before enum, fixing kdoc be
> > fairly trivial.
>
> The non-trivial part is deciding whether you're documenting the enum
> type or the variable. Both are equally valid options.

If you're building a system that's easy to maintain, it shouldn't be at
all non trivial: you add the documentation where someone adding a new
state would find it. i.e. on the enum. If you document the variable,
no-one adding a new state would likely look at it. I get that in this
case they're one after the other, but think about the precedent for
when they're not.

Regards,

James