All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi.hannula@gmail.com>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: dtor_core@ameritech.net, linux-joystick@atrey.karlin.mff.cuni.cz,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: input: fix comments and blank lines in new ff code
Date: Thu, 01 Jun 2006 23:03:09 +0300	[thread overview]
Message-ID: <447F47FD.2050705@gmail.com> (raw)
In-Reply-To: <20060601125256.de2897f4.rdunlap@xenotime.net>

Randy.Dunlap wrote:
> On Thu, 01 Jun 2006 22:07:16 +0300 Anssi Hannula wrote:
> 
> 
>>Fix comments so that they conform to kernel-doc and add/remove some
>>blank lines.
>>
>>Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
> 
> 
> (attachments make review/comments more trying, so this is an
> abbreviated reply)

Sorry, I'll try to use some other client when I send the fixed patch.

>  /**
> - * Lock the mutex and check the device has not been deleted
> + * input_ff_safe_lock - lock the mutex and check for the ff_device struct
> + *
> + * Returns 0 if device still present, 1 otherwise.
>   */
>  static inline int input_ff_safe_lock(struct input_dev *dev)
>  {
> 
> Functions that are commented with kernel-doc need all of the parameters
> documented also, like:
> 
>  * @dev: the input_dev (or better description)
> 
> There were a few places where you had these and deleted them.  :(
> ~~~~~~~~~~~~~~
> 
> (repeat for several functions...)
> 

Ah, so if the comment is kernel-doc all parameters have to be always
documented...

I guess I can just remove the double ** for static functions, as I'm not
sure it is necessary to document all the obvious parameters of those.

Or what do you think?

-- 
Anssi Hannula


  reply	other threads:[~2006-06-01 20:03 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-30 10:57 [patch 00/12] input: force feedback updates, third time Anssi Hannula
2006-05-30 10:57 ` [patch 01/12] input: move fixp-arith.h to drivers/input Anssi Hannula
2006-05-30 10:57 ` [patch 02/12] input: fix accuracy of fixp-arith.h Anssi Hannula
2006-05-30 10:57 ` [patch 03/12] input: new force feedback interface Anssi Hannula
2006-05-31  5:21   ` Randy.Dunlap
2006-05-31 10:13     ` Anssi Hannula
2006-06-01 19:02     ` input: return -ENOSYS for registering functions when ff is disabled Anssi Hannula
2006-06-01 19:07     ` input: fix comments and blank lines in new ff code Anssi Hannula
2006-06-01 19:52       ` Randy.Dunlap
2006-06-01 20:03         ` Anssi Hannula [this message]
2006-06-01 20:09           ` Randy.Dunlap
2006-06-01 20:47             ` Anssi Hannula
2006-06-01 21:33               ` Randy.Dunlap
2006-06-01 22:16                 ` Anssi Hannula
2006-06-01 22:31                   ` Randy.Dunlap
2006-06-02 17:44                 ` [patch] input: fix function name in a comment Anssi Hannula
2006-06-05 18:52   ` [patch 03/12] input: new force feedback interface Dmitry Torokhov
2006-06-05 21:11     ` Anssi Hannula
2006-06-06  2:02       ` Dmitry Torokhov
2006-06-06 11:23         ` Anssi Hannula
2006-06-06 12:45           ` Dmitry Torokhov
2006-06-06 13:11             ` Anssi Hannula
2006-06-19 20:09               ` Anssi Hannula
2006-05-30 10:57 ` [patch 04/12] input: adapt hid force feedback drivers for the new interface Anssi Hannula
2006-05-30 10:57 ` [patch 05/12] input: adapt uinput for the new force feedback interface Anssi Hannula
2006-05-30 10:57 ` [patch 06/12] input: adapt iforce driver " Anssi Hannula
2006-05-30 10:57 ` [patch 07/12] input: force feedback driver for PID devices Anssi Hannula
2006-05-30 10:57 ` [patch 08/12] input: force feedback driver for Zeroplus devices Anssi Hannula
2006-05-30 10:57 ` [patch 09/12] input: update documentation of force feedback Anssi Hannula
2006-05-30 10:57 ` [patch 10/12] input: drop the remains of the old ff interface Anssi Hannula
2006-05-30 10:57 ` [patch 11/12] input: drop the old PID driver Anssi Hannula
2006-05-30 10:57 ` [patch 12/12] input: use -ENOSPC instead of -ENOMEM in iforce when device full Anssi Hannula
2006-05-31  5:02   ` Randy.Dunlap
2006-05-31 10:04     ` Anssi Hannula
2006-05-31 15:15       ` Randy.Dunlap

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=447F47FD.2050705@gmail.com \
    --to=anssi.hannula@gmail.com \
    --cc=akpm@osdl.org \
    --cc=dtor_core@ameritech.net \
    --cc=linux-joystick@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    /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.