[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Henrik Nordström]

tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:

> So what are the rules going to be? Once the OS is up and starts
> changing things the state in the DT and the OS are going to diverge.
> How does this get handled for a kernel driver that can load/unload?
> Should the kernel remove those state nodes as soon as it alters the
> state?

hardware that is no longer there should also not be represented/active
in DT.

A simple fb that have been torn down is no more, no different from never
having been there. It can be argued that it never was in the first place
(i.e. that it is not actually hardware) but that it another can of worms
and both have their benefits and drawbacks. One thing is certain
however, as far as simplefb is concerned it is hardware, not really any
different from a persistent framebuffer with hardwired settings in
hardware.

Regarding kexec, it's the responsibility of the kernel doing kexec to
make sure DT and hardware matches for the next started kernel. With
hardware that can be reconfigured it is not safe to assume that the DT
can be passed as-is from before the kernel reconfigured hardware. If the
currently running kernel wants to set up a framebuffer for simplefb use
by the next kernel than it's free to do so, but in either case it needs
to provide the right information to next kernel.

If it was given a simplefb node, but then killed the simplefb then no
simplefb node should be provided to the next kernel. If it was not given
a simplefb node, but have configured the hardware suitable for simplefb
node then it may provide a simplefb node.

A UART that have changed rate no longer have that rate.

Same applies to numerous other items as well. If a kernel remaps IRQs,
bus addresses, or whatever in hardware aspects where such changes is
possible then DT needs to be updated as well. A bit less common than a
simplefb being destroyed by driver reconfiguring the framebuffer, but if
you look at it from a little distance then the problem is exactly the
same. Hardware is not 100% static, and therefore hardware description
also can not be 100% static. And hardware is getting more and more
dynamically reconfigurable.

A DT that contains false information is generally worse than no DT / not
having that information at all.

Regards
Henrik