public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-kernel@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH] reset: generate reset_control_get variants with macro expansion
Date: Thu, 21 Jul 2016 10:41:01 +0200	[thread overview]
Message-ID: <1469090461.3435.15.camel@pengutronix.de> (raw)
In-Reply-To: <1469077523-23163-1-git-send-email-yamada.masahiro@socionext.com>

Hi Masahiro,

Am Donnerstag, den 21.07.2016, 14:05 +0900 schrieb Masahiro Yamada:
> The recent update in the reset subsystem requires all reset consumers
> to be explicit about the requested reset lines; _explicit or _shared.
> This effectively doubled the number of reset_control_get variants.
> Also, we already had _optional variants.
> 
> We see some pattern in the reset_control_get APIs.
> 
> There are 6 base functions in terms of function prototype:
>   reset_control_get
>   reset_control_get_by_index
>   of_reset_control_get
>   of_reset_control_get_by_index
>   devm_reset_control_get
>   devm_reset_control_get_by_index
> 
> Each of them has 4 variants with the following suffixes:
>   _exclusive
>   _shared
>   _optional_exclusive
>   _optional_shared
> 
> The exhaustive set of functions (6 * 4) can be generated with macro
> expansion.  It will mitigate the pain of maintaining proliferating
> APIs.
> 
> I merged similar comment blocks into two, for functions in core.c
> because copy-paste work for similar comment blocks is error-prone.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Thank you for the patch, but while I'm all for reducing unnecessary
duplication, I do not like this change for two reasons:
First, the macro generated API functions can not be found by name using
tools like ctags or grep anymore.
And secondly, we would now have detailed kerneldoc comments for two
functions that are never called directly, but the public facing API
itself is completely without documentation. I wouldn't mind removing
duplicated documentation paragraphs though, for example by referencing
reset_control_get_* from the of_reset_control_get_* kerneldoc comments.

I think when Lee suggested the API change, I initially leaned towards a
single entry point with flags, similar to the irq request API:
  reset_control_get(..., RSTF_EXCLUSIVE)
  reset_control_get(..., RSTF_SHARED)
  reset_control_get(..., RSTF_OPTIONAL | RSTF_EXCLUSIVE)
  reset_control_get(..., RSTF_OPTIONAL | RSTF_SHARED)
On the other hand, with that API users could forget the flags or use
incompatible combinations, which is impossible with the current API.

regards
Philipp

  reply	other threads:[~2016-07-21  8:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21  5:05 [PATCH] reset: generate reset_control_get variants with macro expansion Masahiro Yamada
2016-07-21  8:41 ` Philipp Zabel [this message]
2016-07-21  9:53   ` Masahiro Yamada
2016-07-21 12:06     ` Lee Jones
2016-07-22 12:58     ` Philipp Zabel

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=1469090461.3435.15.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=hdegoede@redhat.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox