On Fri, 23 Sep 2011, J, KEERTHY wrote: > On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > > On Thu, 22 Sep 2011, Keerthy wrote: > > > >> diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c b/arch/arm/mach-omap2/temp_sensor4460_data.c > >> new file mode 100644 > >> index 0000000..2804615 > >> --- /dev/null > >> +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c > > > > Is there some reason why this shouldn't go into drivers/ in some form? > > This is used by mach-omap2. Why does something in mach-omap2 need this data? > >> diff --git a/arch/arm/plat-omap/include/plat/scm.h b/arch/arm/plat-omap/include/plat/scm.h > >> new file mode 100644 > >> index 0000000..47aa38f > >> --- /dev/null > >> +++ b/arch/arm/plat-omap/include/plat/scm.h > > > > If this is being used by a driver, then this header file should go into > > the appropriate drivers/ subdirectory. If it is being used by code in > > arch/arm/mach-omap2, then please use the existing > > arch/arm/mach-omap2/control.h instead. > > The header file has structures used both by drivers/ and mach-omap. > So kept it in plat-omap. The point is, if there are structure definitions and macros that are only needed by code in drivers/, then those should be split off into a separate file and placed in drivers/. Similarly, if there are elements of this file that are only used in mach-omap2/, then those should go into mach-omap2/control.h. About the only part off the top of my head that should go into a plat-omap header file should be the dev_attr structure. And it's debatable whether this driver even needs a dev_attr, or whether all this data should just go into an omap4460_scm.c MFD driver that uses a bunch of common code for the parts that are shared with 4430, etc. Do you have any views on this issue? - Paul