On Thu, May 3, 2018 at 11:11 AM, Rob Herring robh@kernel.org wrote:
On Thu, May 3, 2018 at 9:29 AM, Alexander Graf agraf@suse.de wrote:
On 04/30/2018 08:36 PM, Rob Herring wrote:
On Fri, Apr 27, 2018 at 4:39 PM, Alexander Graf agraf@suse.de wrote:
Hi Rob,
On 27.04.18 18:40, Rob Herring wrote:
On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf agraf@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/bcm27...
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.
This one is unfortunate. It could have been handled better. An interrupt-map property in the aux ctrlr could have mapped the interrupts to GIC without any aux driver. Then when the aux driver lands, it just needs to remove the interrupt-map (on boot).
To do that you would've needed to know that you need the change in the first place ;).
Actually, I think we can still solve this. Add the interrupt-map now. Then when the aux driver lands it has to fixup the interrupt-map.
Scrap that...
I think I actually hit the problem when testing my deferred probe patch. I saw a 30 sec delay in the console output when the pl011 driver probed and using the pl011 as the console (they really made a mess of the serial console on RPi 3).
Alternatively, I skimmed thru some discussions of the issue, but I'm not clear why the devices behind the aux controller can't all just treat their interrupts as shared. But that would be a simple change to the drivers' irq handlers, so I'm probably missing something. If that worked, then the DT would never need to change.
Fix posted[1]. :) In fact the IRQ handlers are shared already, there's just a bug in the handler.
Rob