All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davide Ciminaghi <ciminaghi@gnudd.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] regmap : make lock/unlock functions customizable.
Date: Fri, 12 Oct 2012 10:24:12 +0200	[thread overview]
Message-ID: <20121012082412.GA9779@mail.gnudd.com> (raw)
In-Reply-To: <20121012062607.GN11726@opensource.wolfsonmicro.com>

On Fri, Oct 12, 2012 at 03:26:09PM +0900, Mark Brown wrote:
> On Mon, Oct 01, 2012 at 11:31:04PM +0200, ciminaghi@gnudd.com wrote:
> > From: Davide Ciminaghi <ciminaghi@gnudd.com>
> > 
> > It is sometimes convenient for a regmap user to override the standard
> > regmap lock/unlock functions with custom functions.
> 
> This looks good overall but...
> 
> > -static void regmap_lock_mutex(struct regmap *map)
> > +static void regmap_lock_mutex(void *__map)
> >  {
> > +	struct regmap *map = (struct regmap *)__map;
> >  	mutex_lock(&map->mutex);
> 
> ...you should never need to cast away from or to void, if you do there's
> a bug somewhere.

regmap lock/unlock original functions just received a struct regmap * .
I needed a void * for the customized version of such functions, so just
replaced struct regmap * with void *

typedef void (*regmap_lock)(void *);
typedef void (*regmap_unlock)(void *);

The cast isn't actually needed (code compiles with no warnings without it).
I could also do something like this, if you think it's better:

typedef void (*regmap_lock)(struct regmap *, void *);
typedef void (*regmap_unlock)(struct regmap *, void *);

and then ignore the second argument in the default version of the functions.

Thanks and regards
Davide


  reply	other threads:[~2012-10-12  8:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-01 21:31 [PATCH] regmap : make lock/unlock functions customizable ciminaghi
2012-10-12  6:26 ` Mark Brown
2012-10-12  8:24   ` Davide Ciminaghi [this message]
2012-10-15  0:58     ` Mark Brown

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=20121012082412.GA9779@mail.gnudd.com \
    --to=ciminaghi@gnudd.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.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.