Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

[Pantelis Antoniou]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/