tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl@xxxxxxxxx: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
