On Sun, Aug 31, 2008 at 02:01:44PM -0700, David Brownell wrote: > On Saturday 30 August 2008, Felipe Balbi wrote: > > +config LEDS_OMAP_DEBUG > > + boolean "LED Support for OMAP debug board LEDs" > > + depends on LEDS_CLASS=y && ARCH_OMAP > > + help > > + Enables support for the LEDs on the debug board used with OMAP > > + reference boards like H2/H3/H4 and Perseus2. Up to six of these > > + may be claimed by the original ARM debug LED API. > > This stuff is ancient and should not be pushed upstream. > Anything not using arch/arm/plat-omap/debug-leds.c should > be converted immediately. Ditto anything using the legacy > ARM led framework. > > > > +config LEDS_OMAP > > + tristate "LED Support for OMAP GPIO LEDs" > > + depends on LEDS_CLASS && ARCH_OMAP > > + help > > + This option enables support for the LEDs on OMAP processors. > > Similarly obsolete. Use drivers/leds/leds-gpio.c ... > Best to just remove this driver and convert its clients. > > > > +config LEDS_OMAP_PWM > > + tristate "LED Support for OMAP PWM-controlled LEDs" > > + depends on LEDS_CLASS && ARCH_OMAP && OMAP_DM_TIMER > > + help > > + This options enables support for LEDs connected to GPIO lines > > + controlled by a PWM timer on OMAP CPUs. > > This is more plausible. But looking -- briefly! -- at the code, I > don't see why it needs a work_struct at all, or why it's not using > the blink_set() method to control the hardware blink rate. One more to drop from the series. Someone will have to take care of these drivers. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
