On Mon, Jan 27, 2014 at 12:58:39PM +0000, Russell King - ARM Linux wrote:

On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote:

quoted

I do have a worry that because the kernel won't normally use this
information, by default it will get pasted between .dts files, won't get
tested and will be wrong rather often.  It also violates the DT principle
that probeable information should not be present in the DT -- ePAPR
obviously envisages systems where cache geometry information is not
probeable, but that's not the case for architected caches on ARM, except
in rare cases where the CLIDR is wrong.

That statement is wrong.  There are caches on ARM CPUs where there is no
CLIDR register.  I suggest reading the earlier DDI0100 revisions.

You're right; I should have qualified that statement with the proviso
that there _is_ a CLIDR (or some other reliably way to discover the
cache geometry directly from the hardware).  In particular, this applies
to all v7-[AR] CPUs, but not to <=v5.  Not sure about v6 -- it may be
a mixture.

My worry was about duplication of information; so if there is no discovery
mechanism then there is no duplication and no problem -- on those older
CPUs, the corresponding information could be placed in the DT, or where
it doesn't cause a problem it can remain hard-coded into the kernel, as
at present.  If we _allow_ inclusion of that information in the DT for
pre-v7, that still raises questions about what information gets used if
there is hard-coded geometry in the kernel too.

I can't see a sufficient reason to advocate churn for pre-v7 platforms,
but other people's views may differ.

Cheers
---Dave