On Fri, 23 Sep 2011, J, KEERTHY wrote:

> On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley <[email protected]> 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

Reply via email to