On Mon, Aug 20, 2012 at 09:36:22AM +0100, Srinivas KANDAGATLA wrote:
> On 17/08/12 16:36, Timur Tabi wrote:
> > Srinivas KANDAGATLA wrote:
> >> If you know in advance that device on that SOC is broken, then I guess
> >> "Fail"/"Failed" can be used in status property.
> >>
> >> One user of this flag in kernel device trees is
> >> ./arch/powerpc/boot/dts/mpc8313erdb.dts
> > /* Remove this (or change to "okay") if you have
> > * a REVA3 or later board, if you apply one of the
> > * workarounds listed in section 8.5 of the board
> > * manual, or if you are adapting this device tree
> > * to a different board.
> > */
> > status = "fail";
> >
> > I'm not sure this is the right way to do it.
> I agree, the way fail status is used is pretty much redundant to what
> "disabled" is used for.
> I think the device trees files should have status as "okay" or "ok" or
> "disabled" or skip status property totally.
>
> > Normally, the boot loader
> > should be able to detect the board revision, and it should dynamically set
> > the 'status'. We have other devices that fail if a work-around is not
> > applied, and we don't use this approach.
> >
> > But assuming that this really is the best approach, then it would make
> > sense for --strip-disabled to leave this node in the dtb, because
> > otherwise there would be no way to re-enable it.
> --strip-disabled should still get rid for nodes marked as failed
> as-well, because fail means something serious and un-recoverable.
>
> I think bootloader should not even consider nodes with status as
> fail, as the device is unlikely to become operational without
> repair.
I do worry about the usability implications of that - if a device that
was previously working stops working and is marked as "failed" it's
fairly easy for the user/admin to see what's going on. If the device
simply vanishes completely that would be rather more mysterious.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
