Hi Michael, On May 14, 2014, at 5:11 AM, Michael Stickel wrote: > Hi Grant, > > Am 14.05.2014 12:08, schrieb Grant Likely: >> More generally I am concerned about whether or not overlays >> will introduce corner cases that can never be handled correctly, >> particularly in how multiple overlays will get handled. I want to see >> very clear rules on what happens when multiple overlays are applied, and >> then removed again. Is it possible to remove overlays out of order? If >> so, what are the conditions that would not be allowed? > > Yes, it is possible that an overlay depends on another. > > The problem is not, that an overlay is removed other overlays depend on, > but that nodes of an overlay may depend on the to-be-removed overlay and > the resulting devicetree can become inconsistent. > > > I have an SPI Bus with two slaves. The second slave is used only on one > of our boards. That is why we split the overlays the following way: > > xxxx_spi1.dts: > Pinmux for SPI-Bus and activation of spi-controller. > Pinmux for CS0 and definition of first slave. > > xxxx_spi1_cs1: > Pinmux for CS1 and definition of second slave. > > When the overlay for the bus is removed, the overlays for the second > slave does not make any sense anymore. > > It is even worse in a scenario we have with a test board. > One of the slaves is an spi-io-controller with a few bitbanging i2c > masters. In an extreme case, each component is defined in a separate > overlay and only the overlay with the master is removed. I know, that > this is completely sick. The devices are removed cleanly because of the > device dependency. > Well, shouldn't you be reverting the overlays in reverse sequence? As I see it, when proper subtree tracking is implemented this use case (of removing #0 before #1) will not be allowed. What is your ideal scenario for this use case? > Michael > Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
