Re: [RFC:PATCH dtc-1.3.0] dtc: Add --strip-disabled option to dtc.

On Mon, Aug 20, 2012 at 09:36:22AM +0100, Srinivas KANDAGATLA wrote:

On 17/08/12 16:36, Timur Tabi wrote:

quoted

Srinivas KANDAGATLA wrote:

quoted

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.

quoted

 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