From: Rodolfo Giometti <giometti@enneenne.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>, linux-kernel@vger.kernel.org
Subject: Re: regulator_register() API
Date: Tue, 9 Jun 2009 17:52:35 +0200 [thread overview]
Message-ID: <20090609155235.GK18591@gundam.enneenne.com> (raw)
In-Reply-To: <20090609151834.GA30774@rakim.wolfsonmicro.main>
On Tue, Jun 09, 2009 at 04:18:34PM +0100, Mark Brown wrote:
> On Tue, Jun 09, 2009 at 03:59:47PM +0200, Rodolfo Giometti wrote:
>
> > Current regulator_register() implementation forces the caller to
> > allocate a proper device for each regulators and also the line:
>
> > struct regulator_init_data *init_data = dev->platform_data;
>
> > forces the user to define the pointer platform_data as a "struct
> > regulator_init_data" only.
>
> That's not the case in current mainline - the init data is passed in as
> an argument to regulator_register(). There should be no requirement
> that the struct device be unique, you should be able to use the same
> struct device for all the regulators on the device. It's mostly just
> used for printk.
>
> > However if the regulator_register() worked in a similar way to
> > led_classdev_register(), I simply can do something like this:
>
> > for (i = 0; i < regulators_num; i++) {
> > /* init regulators structs */
> > ...
> >
> > ret = regulator_register(&client->dev, ®[i].dev);
> > if (ret < 0)
> > dev_warn(&client->dev, "unable to register\n");
> > }
>
> You can do exactly this in current mainline. You do need to supply init
> data for each regulator to make them useful. The change came in commit
> 0527100fd11d9710c7e153d791da78824b7b46fa which was merged during the
> 2.6.30 merge window.
Great! However this resolve one issue, the caller still needs to
allocate a device struct by itsown. On the other hand, doing like
led_classdev_register() does will resolve it also!
See first lines of the function:
int led_classdev_register(struct device *parent, struct led_classdev
*led_cdev)
{
int rc;
led_cdev->dev = device_create(leds_class, parent, 0, led_cdev,
"%s", led_cdev->name);
if (IS_ERR(led_cdev->dev))
return PTR_ERR(led_cdev->dev);
/* register the attributes */
rc = device_create_file(led_cdev->dev, &dev_attr_brightness);
if (rc)
goto err_out;
...
As you can see in this case I simply can do:
/* Register the led devices */
for (i = 0; i < 6; i++)
if (pdata->led[i].name) {
data->led[i].dev.name = pdata->led[i].name;
data->led[i].dev.brightness = pdata->led[i].brightness;
data->led[i].dev.brightness_set = max8821_led_set;
#ifdef CONFIG_LEDS_TRIGGERS
data->led[i].dev.default_trigger =
pdata->led[i].trigger;
#endif
INIT_WORK(&data->led[i].work, max8821_led_set_work);
ret = led_classdev_register(&client->dev,
&data->led[i].dev);
if (ret < 0)
dev_warn(&client->dev, "unable to register "
"led%d into the system\n",
i + 1);
}
No device allocation at all, I simply supply the parent device and the
register function does the rest, also all info regarding the led
device are into "struct led_classdev".
> > This will keep backward compatibility with old drivers and may offer a
> > more versatile way to define a regulator expecially for
> > multifunctional devices.
>
> Most of the regulators currently supported are part of multi-function
> devices so they're not an unusual case here.
But I never said that it is an unusual case, I said it's more complex
to manage. :)
By doing a "struct regulator_classdev" and defining a
regulator_classdev_register() the device driver writer will be easier!
Maybe we can just adding the regulator_classdev_register() as a
wrapper function...
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
next prev parent reply other threads:[~2009-06-09 15:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 13:59 Rodolfo Giometti
2009-06-09 15:18 ` Mark Brown
2009-06-09 15:52 ` Rodolfo Giometti [this message]
2009-06-09 22:06 ` 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=20090609155235.GK18591@gundam.enneenne.com \
--to=giometti@enneenne.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
/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
all inboxes | Powered by JetHome®