Hi Rob, On 27.04.18 18:40, Rob Herring wrote: > On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf <ag...@suse.de> wrote: >> >> >> On 27.04.18 08:24, Udit Kumar wrote: >>> Hi >>> There is bit of discussion on linux-efi too , to handle DT update >>> >>> I guess some members of this forum are active there too. >>> >>> https://www.spinics.net/lists/linux-efi/msg13700.html >>> >>> To summaries >>> 1/ Ownership of DTB >>> IMO should be firmware and we should retain this >>> ownership in EBBR as well, Any objections/thoughts ? >> >> I fully agree. On top of that we need to make clear that backward and >> forward compatibility are not optional. >> >> For that I think we may need to actually give people workable solutions >> to create device trees that are compatible with multiple levels of >> kernel support. The main areas I'm aware of that keep breaking are: >> >> * fine grained interrupt controller support > > Do you have an example of that? The only thing I can think of is > people switching interrupts from the GIC to an always-on, low-power > mode custom interrupt controller.
The last time I've seen that breakage was: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/bcm270x.dtsi#L158 which indeed does switch interrupts from the GIC to an interrupt muxer behind the GIC. The problem is that once support for that lands upstream, you will have very little option but to break backwards compatibility today. > >> * clock support > > Are there cases other than going from fixed, fake clocks to a real > clock controller node. I'm inclined to stop allowing people to do > that. A better way this could be done is just provide a clock > controller driver with a bunch of fixed clocks. Then the switch from > the dumb driver to the real driver is just a kernel change. Going from fixed to in-kernel clock driver is one case I'm aware of, yes. The other one I can think of right now is going from one clock interface to another. For example if you configure clocks using a firmware interface and that firmware interface moves to a newer, more shiny interface (say proprietary to SCMI). That switch may also regress users of the device tree. I think Andre had other examples of where DT compatibility broke, so I'll let him chime in as well. > >> * power domain support > > Example? https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm64/boot/dts/xilinx/zynqmp.dtsi#L110 Booting with the power-domains properties included in the device tree fails for me, because the driver framework considers them critical to load a device and just errors out with -EDEFER. > >> * pinctrl support > > This would be the firmware initially does all the pin setup, then you > move it to DT and drop the setup from the firmware? Otherwise I don't > understand the problem in this case. We'd start with no pinctrl and > then add it to the DT. Why wouldn't the kernel just ignore it? Because it doesn't. The linux driver framework as it works today looks at the pinctrl parent for a specific device and if it can't find it loaded, throws -EDEFER for the driver getting loaded. I suppose the rationale behind that is that pinctrl drivers could be modules that get loaded after the driver you want to load. > >> Every time a device tree changes in any of the above, that usually ends >> up in backwards incompatibility. > > TBC, you're talking about new dtb with old kernels. We've mainly cared Yes. Both really. > about old dtbs and new kernels. So first we should agree the former is > important too. I do, because simply you wouldn't want a BIOS update to > make your PC stop booting your already installed OS. Yes. > I'd like to solve this with policy and good practice before we try to > apply technical solutions on top of a mess. I'm not holding my hopes up, but we can try ;). Another full dimension of messiness are downstream, unapproved bindings that some times can't live in the same device tree as their upstream counterparts once upstream chose a different route. For pinctrl and power domain, I suppose we could have a compatible whitelist in the kernel and instead of -EDEFER just consider the targets immutable if we hit none of the whitelisted strings. > >> My idea to solve that would be to basically create a device tree that >> has self-contained overlays that only trigger when certain feature >> strings are available. That way the base device tree could for example >> contain fixed clocks, but an overlay can get applied when the clock >> driver is enabled in the kernel configuration. That overlay would then >> enable the kernel to drive clocks. > > The number of combinations that would create makes me run away. Then > we're going to combine that with all the other ways people want to use > overlays. I'm happy to see better alternatives, but the current state is just plain painful. >> Further down, we could even extend dtc with annotations that indicate >> "this property should only be exposed when feature string X is >> available" to not force people to write overlays inside the device tree. > > How would that work with clocks where you are changing: > > clocks = <&fake_fixed_clk>; > > to: > > clocks = <&soc_clock_ctrlr 123>; I haven't made up my mind if we need to come up with a legacy dtc compatible syntax for this. But assume we don't, then it would be something as easy as: clocks$can_handle_soc_clock_ctrlr = <&soc_clock_ctrlr 123>; clocks$!can_handle_soc_clock_ctrlr = <&fake_fixed_clk>; which would result in 2 overlays, one that matches when the kernel understands the compatible for soc_clock_ctrlr (feature string "can_handle_sock_clock_ctrlr"), one that only matches when it doesn't. Alex _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
