Tony Lindgren had written, on 07/08/2010 07:21 AM, the following:
* Menon, Nishanth <nm@xxxxxx> [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
--
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
