All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Documentation List <linux-doc@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Subject: Re: anonymous enums in kernel doc
Date: Tue, 16 Feb 2021 10:05:39 -0700	[thread overview]
Message-ID: <87mtw4x7rw.fsf@meer.lwn.net> (raw)
In-Reply-To: <CAHp75Vc0SwC=WxUOiokUik1G4uPE6bHfX_F_ckgp-eEJaVuWhA@mail.gmail.com>

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Tue, Feb 16, 2021 at 6:51 PM Jonathan Corbet <corbet@lwn.net> wrote:
>>
>> > Mauro, can you do some test cases in your workflow against anonymous
>> > enum in ernel doc, please?
>> >
>> > They are broken again, please fix the script!
>> >
>> > drivers/pinctrl/intel/pinctrl-intel.c:204: warning: wrong kernel-doc
>> > identifier on line:
>> > * enum - Locking variants of the pad configuration
>> >
>> > Above is simply a wrong statement.
>>
>> The real problem, perhaps, is that there seems to be little point in
>> adding kerneldoc comments for anonymous enums; where are you going to
>> use that documentation?
>
> I had been explicitly told during review (IIRC by maintainers) to make
> it such, while the initial version was exactly like you are thinking
> of. So, I'm not the right person to be asked :-)
>
>>  The error message could perhaps be changed to
>> say that; meanwhile, perhaps this one could be fixed with an action like
>> s%/**%/*% ?
>
> See above. I think regression comes from the kernel doc script,
> earlier it was okay. That said, the author of kernel doc changes has
> to submit a patch to amend the driver and maintainers will review it.

kerneldoc now warns about various incorrect things that it used to just
silently pass over.  There is no regression here, just a new diagnostic
to point out something that was never going to work right.  Unless you
have a good idea for what kerneldoc should do with a block like that?

(An alternative fix, of course, would be to give the enum a name so it
can actually be used for type checking.)

Thanks,

jon

  reply	other threads:[~2021-02-16 17:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 14:34 anonymous enums in kernel doc Andy Shevchenko
2021-02-16 16:51 ` Jonathan Corbet
2021-02-16 16:59   ` Andy Shevchenko
2021-02-16 17:05     ` Jonathan Corbet [this message]
2021-02-16 17:12       ` Andy Shevchenko
2021-03-03  8:42         ` [PATCH] scripts/kernel-doc: ignore identifier on anonymous enums Mauro Carvalho Chehab
2021-03-09  0:10           ` Jonathan Corbet
2021-03-03  8:44         ` anonymous enums in kernel doc Mauro Carvalho Chehab
2021-03-03  9:27           ` Andy Shevchenko

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=87mtw4x7rw.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@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.