On Mon, Jan 7, 2013 at 5:03 PM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Dec 24, 2012 at 08:10:24AM -0600, Omar Ramirez Luna wrote: >> 3.8-rc1 introduced changes in the clock management header files, >> this resulted in compilation breakages for this driver. >> >> Define this locally while APIs are made available, given that driver >> code shouldn't include mach header files. >> >> This fixes: >> drivers/staging/tidspbridge/core/tiomap3430.c:550:13: error: >> 'OMAP3430_CM_AUTOIDLE_PLL' undeclared (first use in this function) >> drivers/staging/tidspbridge/core/tiomap_io.c:416:13: error: >> 'OMAP3430_CM_CLKEN_PLL' undeclared (first use in this function) >> >> Reported-by: Chen Gang <gang.chen@xxxxxxxxxxx> >> Signed-off-by: Omar Ramirez Luna <omar.ramirez@xxxxxxxxxx> > > Enric sent me a patch that just includes the proper .h file, which > should be better than doing this: It looks better because the driver is already including related headers in a similar fashion, but in reality those headers are under arch/arm/mach-omap2 and the driver shouldn't have any business in including headers from there. >> --- a/drivers/staging/tidspbridge/core/_tiomap.h >> +++ b/drivers/staging/tidspbridge/core/_tiomap.h >> @@ -40,6 +40,14 @@ >> #include <dspbridge/sync.h> >> #include <dspbridge/clk.h> >> >> +/* >> + * XXX These mach-omap2/ defines are wrong and should be removed. No >> + * driver should read or write to PRM/CM registers directly; they >> + * should rely on OMAP core code to do this. >> + */ >> +#define OMAP3430_CM_AUTOIDLE_PLL 0x0034 >> +#define OMAP3430_CM_CLKEN_PLL 0x0004 > > Don't define things that are already defined elsewhere... > > I'll not apply this. Ok, not a problem, I'll be working on the real fix which is to get APIs from the core code for the driver to use. Cheers, Omar _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
