Re: [PATCH v4 2/3] omap4: opp: add OPP table data

[Kevin Hilman <khilman@deeprootsystems.com>]

Nishanth Menon <nm@ti.com> writes:

> Kevin Hilman had written, on 11/22/2010 06:09 PM, the following:
>> Nishanth Menon <nm@ti.com> writes:
>>
>>> Kevin Hilman wrote, on 11/22/2010 05:19 PM:
>>>> Nishanth Menon<nm@ti.com>  writes:
>>>>
>>>>> This patch adds OPP tables for OMAP4. New file has been added to keep
>>>>> the OMAP4 opp tables and the registration of these tables with the
>>>>> generic opp framework by OMAP SoC OPP interface.
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
>>>>> index 66e12be..48a553f 100644
>>>>> --- a/arch/arm/mach-omap2/opp.c
>>>>> +++ b/arch/arm/mach-omap2/opp.c
>>>>> @@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def *opp_def,
>>>>>
>>>>>   /* omap3 opps */
>>>>>   #include "opp3xxx_data.c"
>>>>> -
>>>>> +/* omap4 opps */
>>>>> +#include "opp4xxx_data.c"
>>>> I'm not sure I like the including of C files.  Any reason you prefer
>>>> this to just adding them to the Makefile?  e.g. opp24xx_dta.c are
>>>> compiled in via Makefile and these two are included.
>>> I dont buy it. I am seeing us go around in circles for this:
>>> http://marc.info/?l=linux-omap&m=128986880406272&w=2
>>> a) we dont want others to use specifics implemented in opp.c in other
>>> files (e.g. board files)
>>
>> not sure how this is prevented.
> The approach is as follows:
> the #defines and struct definitions are in opp.c
> opp{3,4}xxx_data.c use the same - by itself wont build because they
> need the defines in opp.c
> that way, there is no possibility of clean hacks possible except to
> follow the current mechanism for a future omap silicon
>
> The main objective was to restrict the potential of board developers
> from hacking the default OPP table - which would be possible by
> exposing the headers for board files - which as Thomas rightly pointed
> out in the thread I pointed out,  opens up a possibility for board
> files to include them as well and re-instantiate the table again..

OK, then this falls into the "trick to make ugly hacks *really* ugly"
category.   I can live with that. :)

Kevin

>>
>>> b) we have many similar usage in linux kernel - so this usage is not
>>> first time.
>>> c) opp2xx usage is very different from opp3/4 usage
>>
>> I'm not going to insist on one way or the other, just stating my
>> preference for not including C files from C files without good
>> justification.  You've stated your reasons, I guess Tony can decide.
> okay by me - will post a v5 after seeing the final decision on that front :)