linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier.adi@gmail.com>
To: Bill Gatliff <bgat@billgatliff.com>
Cc: linux-embedded@vger.kernel.org
Subject: Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to  vary the brightness of an LED according to system load
Date: Mon, 19 Oct 2009 23:58:39 -0400	[thread overview]
Message-ID: <8bd0f97a0910192058p2b3144cfl9ef7d3e5fe352e8c@mail.gmail.com> (raw)
In-Reply-To: <4ADD158C.2090708@billgatliff.com>

On Mon, Oct 19, 2009 at 21:42, Bill Gatliff wrote:
> Mike Frysinger wrote:
>> On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote:
>>>  #include <linux/pwm.h>
>>> +#include <linux/pwm-led.h>
>>
>> if there's going to be a bunch of new pwm related headers, perhaps a
>> subdir makes more sense: linux/pwm/xxx
>
> In general I don't have a problem with this.  However, in this specific case
> would it make more sense to just fold pwm-led.h into pwm.h?  There really
> isn't much to pwm-led.h.

since pwm-led.h is meant for platform data and for boards to include
it, keeping it separate makes sense to me.  and once we start getting
more pwm based drivers that want to do headers of their own, having
linux/pwm/ for them would be nice.

as for the core pwm header, either linux/pwm.h or linux/pwm/pwm.h
would work i think.

>>> +static void
>>> +led_pwm_brightness_set(struct led_classdev *c,
>>> +                      enum led_brightness b)
>>> +{
>>> +       struct led_pwm *led;
>>> +       int percent;
>>> +
>>> +       percent = (b * 100) / (LED_FULL - LED_OFF);
>>> +       led = container_of(c, struct led_pwm, led);
>>
>> instead of using container_of() everywhere, why not add a helper macro
>> that turns a led_classev into a led_pwm
>
> That's just a personal style thing.  As soon as I write a helper macro, I
> tend to forget how it works and then start mis-using it everywhere.  But I
> don't have a problem with doing a helper.
>
> For better type-safety, would a helper inline-function be a better choice
> than a helper macro?  Or would it make any difference?

an inline function might be better.  it would also allow you to pass
in void* pointers though ...

>>> +       if (!try_module_get(d->driver->owner))
>>> +               return -ENODEV;
>>
>> is this really needed ?
>
> Not sure.

after looking at the other patches, i dont think it is.  the core pwm
framework does the module_get for you when you register the driver.
-mike

  reply	other threads:[~2009-10-20  3:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 20:32 [[RFC] 0/5] Generic PWM API Proposal Bill Gatliff
2009-10-19 20:32 ` [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface Bill Gatliff
2009-10-19 20:32   ` [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin Bill Gatliff
2009-10-19 20:32     ` [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API Bill Gatliff
2009-10-19 20:32       ` [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load Bill Gatliff
2009-10-19 20:32         ` [[RFC] 5/5] Incorporate PWM API code into KBuild Bill Gatliff
2009-10-19 22:30           ` Mike Frysinger
2009-10-19 21:51         ` [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load Mike Frysinger
2009-10-20  1:42           ` Bill Gatliff
2009-10-20  3:58             ` Mike Frysinger [this message]
2009-10-30 14:03             ` Luotao Fu
2009-10-31  7:43               ` Trilok Soni
2009-10-31  7:45                 ` Trilok Soni
2009-10-19 22:34       ` [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API Mike Frysinger
2009-10-20  2:02         ` Bill Gatliff
2009-10-19 21:56     ` [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin Mike Frysinger
2009-10-20  1:47       ` Bill Gatliff
2009-11-17  8:29     ` David Brownell
2009-11-17 16:00       ` Bill Gatliff
2009-11-18 21:02         ` Aras Vaichas
2009-10-19 22:29   ` [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface Mike Frysinger
2009-10-20  1:59     ` Bill Gatliff

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=8bd0f97a0910192058p2b3144cfl9ef7d3e5fe352e8c@mail.gmail.com \
    --to=vapier.adi@gmail.com \
    --cc=bgat@billgatliff.com \
    --cc=linux-embedded@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).