public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH v5 02/11] pinctrl: Reformat documentation in dm/pinctrl.h
Date: Wed, 2 Sep 2020 17:17:03 +0200	[thread overview]
Message-ID: <b05abaea-e886-beff-ac49-7d127bf0ff07@gmx.de> (raw)
In-Reply-To: <0154adc6-32f4-e2b2-6503-988d6be60681@gmail.com>

On 02.09.20 16:56, Sean Anderson wrote:
>
> On 9/2/20 8:26 AM, Heinrich Schuchardt wrote:
>> On 15.08.20 17:52, Sean Anderson wrote:
>>> This normalizes the documentatation to conform to kernel-doc style [1]. It
>>
>> Nits:
>> %s/documentatation/documentation/
>>
>>> also moves the documentation for pinctrl_ops inline, and adds argument and
>>> return-value documentation. I have kept the usual function style for these
>>> comments. I could not find any existing examples of function documentation
>>> inside structs.
>>>
>>> [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
>>>
>>> Signed-off-by: Sean Anderson <seanga2@gmail.com>
>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>
>>
>> Before and after this patch the documentation format is incorrect. See
>> output below for the situation after the patch.
>>
>> Please include include/dm/pinctrl.h into doc/api/index.rst via a new
>> file doc/api/pnctrl.rst.
>>
>> A documentation style accepted by 'make htmldocs' is:
>>
>> struct pinctrl_ops {
>>     /**
>>      * @get_pins_count:           Get the number of selectable pins
>>      *
>>      * @get_pins_count.dev:       Pinctrl device to use
>>      *
>>      * This function is necessary to parse the "pins" property
>>      * in DTS.
>>      *
>>      * @get_pins_count.Return:    number of selectable named pins
>>      *                            available in this driver
>>      */
>>     int (*get_pins_count)(struct udevice *dev);
>>
>> See the nested structures in
>>
>> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#in-line-member-documentation-comments
>> and
>> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#nested-structs-unions
>
> Thanks for suggesting those changes. This works better. As far as I can
> tell, fully-qualified members are only necessary when documenting nested
> structs at the top-level. When using in-line documentation, members are
> automatically nested. With that in mind, I am using the following format
>
> 	/**
> 	 * @pinmux_property_set: Enable a pinmux group
> 	 *
> 	 * @dev: Pinctrl device to use
> 	 *
> 	 * @pinmux_group: A u32 representing the pin identifier and mux
> 	 *                settings. The exact format of a pinmux group is left
> 	 *                up to the driver.
> 	 *
> 	 * Mux a single pin to a single function based on a driver-specific
> 	 * pinmux group. This function is necessary for parsing the "pinmux"
> 	 * property in DTS, and for pin-muxing against a pinmux group.
> 	 *
> 	 * @Return:
> 	 *	Pin selector for the muxed pin if OK, or negative error code on
> 	 *	failure
> 	 */
> 	int (*pinmux_property_set)(struct udevice *dev, u32 pinmux_group);
>
> However, I am having some problems with multi-line descriptions. In the
> example above, the desciption for @pinmux_group has the first line
> bolded and the rest of the description is typeset as normal, but is
> indented. The generated html is

Use fully qualified names and you are fine.

Best regards

Heinrich

>
> <dl class="docutils">
> <dt><strong>pinmux_group</strong>: A u32 representing the pin identifier
> and mux</dt>
> <dd>settings. The exact format of a pinmux group is left up to the
> driver.</dd>
> </dl>
>
> However, it should be something like
>
> <p><strong>pinmux_group</strong>: A u32 representing the pin identifier
> and mux settings. The exact format of a pinmux group is left up to the
> driver.</p>
>
> I have also tried an alternate style, as shown for @Return. However,
> this too generated the wrong html:
>
> <dl class="last docutils">
> <dt><strong>Return</strong>:</dt>
> <dd>Pin selector for the muxed pin if OK, or negative error code on
> failure</dd>
> </dl>
>
> where it should generate something like
>
> <p class="last"><strong>Return</strong>: Pin selector for the muxed pin
> if OK, or negative error code on failure</p>
>
> Do you have any suggestions for generating the latter forms? My current
> work is at [1].
>
> --Sean
>
> [1] https://github.com/Forty-Bot/u-boot/commit/e835cf9552dc96438699806731a208b40daead7b
>

  reply	other threads:[~2020-09-02 15:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-15 15:52 [PATCH v5 00/11] riscv: Add FPIOA and GPIO support for Kendryte K210 Sean Anderson
2020-08-15 15:52 ` [PATCH v5 01/11] pinctrl: Add pinmux property support to pinctrl-generic Sean Anderson
2020-08-15 15:52 ` [PATCH v5 02/11] pinctrl: Reformat documentation in dm/pinctrl.h Sean Anderson
2020-09-02 12:26   ` Heinrich Schuchardt
2020-09-02 14:56     ` Sean Anderson
2020-09-02 15:17       ` Heinrich Schuchardt [this message]
2020-09-02 15:38         ` Sean Anderson
2020-08-15 15:52 ` [PATCH v5 03/11] test: pinmux: Add test for pin muxing Sean Anderson
2020-08-15 15:52 ` [PATCH v5 04/11] pinctrl: Add support for Kendryte K210 FPIOA Sean Anderson
2020-08-15 15:52 ` [PATCH v5 05/11] gpio: dw: Fix warnings about casting int to pointer Sean Anderson
2020-08-15 15:52 ` [PATCH v5 06/11] gpio: dw: Add a trailing underscore to generated name Sean Anderson
2020-08-15 15:52 ` [PATCH v5 07/11] gpio: dw: Return output value when direction is out Sean Anderson
2020-08-15 15:52 ` [PATCH v5 08/11] led: gpio: Default to using node name if label is absent Sean Anderson
2020-08-15 15:52 ` [PATCH v5 09/11] test: dm: Test for default led naming Sean Anderson
2020-08-15 15:52 ` [PATCH v5 10/11] riscv: Add pinmux and gpio bindings for Kendryte K210 Sean Anderson
2020-09-02 18:04   ` Heinrich Schuchardt
2020-09-02 20:43     ` Sean Anderson
2020-08-15 15:52 ` [PATCH v5 11/11] riscv: Add FPIOA and GPIO support " Sean Anderson
2020-08-19  3:48   ` Rick Chen
2020-08-19 11:12     ` Sean Anderson
2020-08-20  8:07       ` Rick Chen
2020-08-20  8:47         ` Rick Chen
2020-08-31 21:48           ` Sean Anderson
2020-09-01  1:19             ` Rick Chen
2020-09-02 12:26               ` Heinrich Schuchardt
2020-09-02 15:59                 ` Sean Anderson
2020-09-05 14:40                   ` Sean Anderson
     [not found]       ` <752D002CFF5D0F4FA35C0100F1D73F3FA473754A@ATCPCS16.andestech.com>
2020-08-21  9:08         ` Ruinland ChuanTzu Tsai
2020-08-21 10:06           ` Sean Anderson

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=b05abaea-e886-beff-ac49-7d127bf0ff07@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /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