Re: [PATCH 3/9 v3] omap: generic: introduce a single check_revision

[Nishanth Menon <nm@ti.com>]

Tony Lindgren had written, on 07/08/2010 07:21 AM, the following:
> * Menon, Nishanth <nm@ti.com> [100708 14:49]:
>> ----- Original message -----
>>> Hi,
>>>
>>> On Wed, Jul 07, 2010 at 07:24:16PM +0200, ext Nishanth Menon wrote:
>>>> I am not sure.. if you would like drivers to be modprobabe, there may
>>> be
>>>> quirks that you'd want to enable based on cpu_is_omapxxx checks. so it
>>>> probably does not make sense to __initdata the revision/feature
>>> variables.
>>>
>>> can't you pass the quirks via pdata, then ?
>> If pdata is passed based on board: Imagine 3630 and uart quirk. Why share errata xyz over pdata for every board using 3630? Quirks are cpu specific and not really domain of board..  
> 
> We should be able to handle the quirks by passing some
> flag or function pointer from platform data.
> 
> The drivers should be arch independent, using cpu_is_omapxxxx
> tests anywhere under drivers/* is wrong and should be
> fixed.

there are two forms of quirks:
a) quirks which can be detected based on IP rev
b) quirks which are silicon integration related - only cpu_is_xxxx can 
be used to detect them.
for a) - I disagree that pdata should be used (this was my original 
contention)
for b) the question IMHO is: How is pdata provided to the driver - that 
is important. IMHO, pdata taken into drivers could have quirks, but if 
the quirk addition is done from board files, I disagree, then should be 
done in arch/arm/mach-omap[12]/somefile.c where somefile.c is common for 
all boards (e.g. device.c) and that allows the driver to be cpu 
independent and allows board files not to have redundant information.

BUT, features *should* be kept distinct from quirks for readability 
purposes.

-- 
Regards,
Nishanth Menon