On 03/05/2018 21:14, Frank Rowand wrote:
On 05/03/18 04:31, Phil Elwell wrote:
David,
On 03/05/2018 03:22, David Gibson wrote:
On Wed, May 02, 2018 at 05:06:06PM +0100, Phil Elwell wrote:
Rob,
On 02/05/2018 16:49, Rob Herring wrote:
On Wed, May 2, 2018 at 4:19 AM, Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote:
David et al.,
I've mentioned before the problem posed for overlays by boolean properties, i.e.
that a boolean property that is "true" in a base DTB cannot be made "false" by an
overlay because doing so requires that the property be deleted. A solution for this
problem would be to define a new FDT tag - FDT_DEL_PROP, say - that is used to encode
any /delete-property/ found in a node during overlay compilation. When the overlay is
applied, the named property would be deleted if present.
A heuristic would be needed to decide whether this property should be encoded or just
acted on immediately - the use of the '-@' command line parameter would seem to fit the
bill.
Although one might consider extending this mechanism to cover node deletion, in practice
I think this would be too problematic in terms of broken phandle references etc., and in
most cases 'status = "disabled"' achieves the same objective, so I'm not proposing this
be added.
Is such a change something you would consider supporting, or do you have an alternative
preferred solution?
Can you give some examples of cases where you need this feature.
The case I've encountered is the "non-removable" flag on an SD interface, specifically
the SD interface used for an SDIO link to a WiFi chip on the Raspberry Pi 3B, which is
marked "non-removable" for operational reasons. Some users prefer to repurpose the SD
interface to drive a second SD card on a different set of pins, which they could do using
an overlay except for the "non-removable". The ugly workaround is to disable the original
interface node and create a near-clone in the overlay without the unwanted property.
I'm concerned about how an OS is supposed to deal with properties
disappearing. Do we need to start refcounting properties too? That's
not really a reason to not support this in dtc, but rather perhaps a
policy decision in the OS to not delete properties once a node is in
use/active. Would such a policy break your use case?
I agree that deletion of a property at run-time could prove awkward - if only booleans
were implemented another way - but a non-run-time restriction wouldn't bother me since
we can require users to only apply the overlay via the firmware.
Since writing the original email I've thought some more about the implementation, and
perhaps a new tag is too disruptive a change. An alternative implementation would be to
create a new node, in the same vein as "__symbols__", listing properties to delete in
some suitable encoding.
That has the advantage(?) of not actively breaking things that don't
understand the new tag. The reason I question whether that's an
advantage is that things that didn't understand the new encoding still
obviously wouldn't be able to process the deletion. So the question
is whether silently ignoring the delete is better or worse than
blowing up entirely when given an fdt with the new deletion encoding.
Since the overlay doesn't know the state of the base DTB it is being applied to, there
I beg to differ. An overlay and the base DTB it is applied to are not independent
objects. An overlay has to apply to a "known base". This might not be quite as strict
as it sounds. For example, two different base DTBs might include a .dtsi that defines
node "A". It may be reasonable for an overlay to create a sub-node (path .../A/B)
such that the overlay can cleanly be applied on top of either base DTB.
The overlay and base DTB clearly have to match, but I think this is more at the level
of type information rather than specific instances. For example, early Raspberry Pis
kept I2C1 for system use leaving I2C0 for user applications; later models swapped
these roles. Assigning the labels i2c_arm and i2c_vc to I2C nodes in model-specific
pairings allows a single overlay to target the bus with a specific role rather than
a specific instance of the controller.
You may prefer to cater for multiple platforms by creating multiple tailored instances of
each overlay, but that would lead to an increase in the already large number of overlays
and make it harder to support our goal of allowing a single card image to run in
all Pis.
Phil
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
