Hello Scott,
Scott Wood wrote:
> On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
>> 1) add in the soc node an "errata" node and in this "errata" node
>> we can add all CPU specific errata as an example the qe_enet10
>> errata, which above code covers:
>
> What about errata discovered after the device tree is deployed?
Didn;t know that there are such errata. Ok, this is a problem.
>> soc8...@e0000000 {
>> [...]
>> errata {
>> device_type = "errata";
>
> device_type is deprecated except for a couple of legacy uses. Please do
> not add new ones.
Ok.
>> compatible = "fsl,mpc83xx_errata";
>
> To be bound to by an "errata driver"? :-P
Why not ;-) ?
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> qe_ene...@14a8 {
>> device_type = "errata";
>> compatible = "fsl,mpc83xx_errata_qe_enet10";
>> reg = <0x14a8 0x08>;
>
> But that register is part of the "QE parallel I/O port" block (even if it
> happens to be undocumented within that block), not part of the "QE ENET10
> erratum" block. The device tree describes the hardware, not what you
> want to do with it.
Hmm.. isn;t this an errata for a buggy hardware? Why not describing this
in the dts?
> The presence of the erratum itself is indicated by the presence of the
> buggy device, possibly in conjunction with SVR if the device tree is not
> specific enough.
Ah, Ok, that was just an idea ... so, where and how to solve the qe_enet10
errata without using get_immrbase() (and I vote not to solve it as it
actuall is in board specific code, maybe as i proposed in an earlier mail
in the ucc_geth.c driver?)?
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
