* Greg KH <greg@xxxxxxxxx> [100907 17:17]: > On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote: > > This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch > > is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am > > hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know > > if there are any issues or concerns with this patch. > > Thanks, > > David > > > > Signed-off-by: David Cross <david.cross@xxxxxxxxxxx> > > > > diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c > > --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.000000000 -0700 > > +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.000000000 -0700 > > @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, > > reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx; > > __raw_writel(val, reg_addr); > > } > > +EXPORT_SYMBOL(gpmc_cs_write_reg); > > EXPORT_SYMBOL_GPL() perhaps? > > What about platforms that don't have this symbol, how will the driver > build properly then? Shouldn't something like this be in a arch-neutral > place in the kernel tree? I don't think exporting these functions is a good idea, so NAK from me for that. All the drivers should be generic, and whatever needs to be done that's omap specific should be done in the platform init code. If the driver needs to reconfigure something, such as memory timings, it can be done by passing a retime function pointer to the driver in the platform_data. Then the driver can call that function if it exists. Regards, Tony -- 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
