[PATCH v2 1/2] ARM: mxc: Introduce imx_add_gpio_leds

Russell King - ARM Linux linux at arm.linux.org.uk
Mon Apr 4 14:17:59 EDT 2011


On Mon, Apr 04, 2011 at 01:06:52PM -0500, H Hartley Sweeten wrote:
> On Monday, April 04, 2011 10:53 AM, Russell King wrote:
> > On Mon, Apr 04, 2011 at 07:42:44PM +0200, Uwe Kleine-König wrote:
> >> The mechanims could be made a bit more aggressive by something like
> >> that:
> >> 
> >> 	struct gpio_led_platform_data *_pdata = *pdata;
> >> 	_pdata->leds = kmemdup(pdata->leds, pdata->num_leds * sizeof(*pdata->leds), GFP_KERNEL)
> >> 	if (!_pdata->leds)
> >> 		return ...
> >> 
> >> 	ret = imx_add_platform_device("leds-gpio", -1, NULL, 0, _pdata, sizeof(_pdata));
> >> 	if (IS_ERR(ret))
> >> 		kfree(_pdata->leds);
> >> 
> >> 	return PTR_RET(ret);
> >> 
> >> This would allow to have the struct gpio_led array in init memory, too.
> >
> > If you go to the effort of making it _that_ generic, then it shouldn't
> > even be in plat-mxc, but somewhere *everyone* can benefit from it.  See
> > Linus' complaints in the OMAP pull request thread about the amount of
> > largely similar arch/arm code.
> 
> If it's made generic, mach-ep93xx/core.c could use it to register it's two
> platform leds.  Please keep me in the loop if this is done.

In which case we don't want "if it's made generic", we *require* it to be
generic.

As I say, we *must* get away from the idea that something in mach-xyz has
nothing to do with our own development in mach-abc, and start taking an
interest in consolidating some of this stuff.  Otherwise we may get to
the point where further arch/arm development is barred from the mainline
kernel.



More information about the linux-arm-kernel mailing list