All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, lenz@cs.wisc.edu,
	rpurdie@openedhand.com
Subject: Re: private field in led_classdev?
Date: Wed, 17 Mar 2010 12:48:37 +0000	[thread overview]
Message-ID: <1268830117.3662.15.camel@rex> (raw)
In-Reply-To: <20100310110153.GA6838@const.bordeaux.inria.fr>

On Wed, 2010-03-10 at 12:01 +0100, Samuel Thibault wrote:
> Samuel Thibault, le Wed 10 Mar 2010 10:44:52 +0100, a écrit :
> > Greg KH, le Tue 09 Mar 2010 18:54:11 -0800, a écrit :
> > > What's wrong with using the private pointer in the struct device
> > > instead?
> > 
> > Ah, right. In my case there is a struct device corresponding to the
> > actual input device. I hadn't realized that since registering a led
> > creates a new device, I have another private pointer which I can use.
> 
> One issue, however, is that led_classdev_register() calls
> led_trigger_set_default(), which eventually calls the brightness_set
> hook, but the private field (platform_data) still hasn't been
> initialized, so the brightness_set hook has to abort setting the initial
> state. In my case, after led_classdev_register and setting
> platform_data, I can call the low level function by hand, it's just not
> very pretty...

That is a bit ugly :/.

It would probably make sense to pass that parameter to
led_classdev_register() but changing references to that function
everywhere will be a pain.

I'm tempted to make led_classdev_register() a wrapper around a
led_classdev_register_drvdata() function which takes an extra parameter.

I agree using the private pointer makes sense though.

Cheers,

Richard


      reply	other threads:[~2010-03-17 12:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-07 14:31 private field in led_classdev? Samuel Thibault
2010-03-10  2:54 ` Greg KH
2010-03-10  9:44   ` Samuel Thibault
2010-03-10 11:01     ` Samuel Thibault
2010-03-17 12:48       ` Richard Purdie [this message]

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=1268830117.3662.15.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=greg@kroah.com \
    --cc=lenz@cs.wisc.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@openedhand.com \
    --cc=samuel.thibault@ens-lyon.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.