[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1181258872.30600.12.camel@localhost.localdomain>
Date: Fri, 08 Jun 2007 00:27:52 +0100
From: Richard Purdie <rpurdie@...ys.net>
To: Robin Farine <robin.farine@...minus.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] LEDS: generic driver
On Wed, 2007-06-06 at 19:02 +0200, Robin Farine wrote:
> From: Robin Farine <robin.farine@...minus.org>
>
> This generic LED driver implements the platform independent part of a
> LED driver letting platform specific code focus on the hardware
> details. The driver binds to platform devices named "Generic-LED"
> which provide the platform specific data and code needed to act on an
> LED.
>
> This is useful for platforms with exotic ways of controlling LEDs
> which preclude the use of a common LED driver such as GPIO based
> drivers.
>
> Signed-off-by: Robin Farine <robin.farine@...minus.org>
I'm not sure about this to be honest. I can see a case for perhaps
having a couple of standard suspend/resume functions for platform device
based LED drivers as those functions are often identical. I'm not sure
whether there is going to be much need for more than that.
Having looked through a few of the LED drivers, even the suspend/resume
functions are often different...
>>From a style point of view, why not s/pdev_to_led/platform_get_drvdata/?
What are your thoughts on multiple LEDs on a single device?
Given the LED class is going to get a conversion to struct device soon,
I'd prefer to put this on hold until after I've made that conversion at
which point I'll reconsider this.
Regards,
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists