All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 5/5] drm/doc: Use new substruct support
Date: Tue, 20 Feb 2018 13:23:36 +0200	[thread overview]
Message-ID: <87k1v73nwn.fsf@intel.com> (raw)
In-Reply-To: <20180220094952.GE23425@ulmo>

On Tue, 20 Feb 2018, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote:
>> Note: This is untested because the new stuff hasn't landed in upstream
>> yet. But it should work.
>> 
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> ---
>>  include/drm/drm_vblank.h | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>
> I couldn't find a reference to the new stuff, so maybe this was already
> discussed, but wouldn't it be possible for the parser to figure out the
> substruct by itself? That way the event. prefix could be avoided.

The short answer, supporting this format is a one-line change, while I'm
told anything else is harder.

Also, the format then is the same at all nesting levels, and you can do
any one of the three options below:

/**
 * struct foo - foo
 * @bar.baz: baz description, option 1 (support upstream)
 */
struct foo {
	/**
         * @bar.baz: baz description, option 2 (support in docs-next)
         */
	struct bar {
        	/**
	         * @bar.baz: baz description, option 3 (support in docs-next)
                 */
        	int baz;
        };
}

I don't deny it would be nice to be able to leave out the prefix when it
can be figured out from the context, but I'm not prepared to do the
work, and Mauro helpfully provided the patch for this approach, so it
seemed like the rational choice. See also [1] and [2].

BR,
Jani.


[1] http://mid.mail-archive.com/874lmjlfmg.fsf@intel.com
[2] http://mid.mail-archive.com/cover.1518788761.git.mchehab@s-opensource.com


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-02-20 11:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19 22:53 [PATCH 1/5] drm/docs: Discourage adding more to kms-properties.csv Daniel Vetter
2018-02-19 22:53 ` [PATCH 2/5] drm/docs: Align layout of optional plane blending properties Daniel Vetter
2018-02-20  9:42   ` Thierry Reding
2018-02-19 22:53 ` [PATCH 3/5] drm/docs: Document "scaling mode" property better Daniel Vetter
2018-02-20  9:45   ` Thierry Reding
2018-02-19 22:53 ` [PATCH 4/5] drm/doc: Polish for drm_mode_parse_command_line_for_connector Daniel Vetter
2018-02-20  9:46   ` Thierry Reding
2018-02-19 22:53 ` [PATCH 5/5] drm/doc: Use new substruct support Daniel Vetter
2018-02-20  9:49   ` Thierry Reding
2018-02-20 11:10     ` Daniel Vetter
2018-02-20 11:22       ` Thierry Reding
2018-02-20 13:25         ` Daniel Vetter
2018-02-20 11:23     ` Jani Nikula [this message]
2018-02-20  9:41 ` [PATCH 1/5] drm/docs: Discourage adding more to kms-properties.csv Thierry Reding
2018-02-21  0:23 ` Laurent Pinchart

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=87k1v73nwn.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=thierry.reding@gmail.com \
    /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.