On Mon, Jan 22, 2024 at 08:45:51AM -0500, Brian Masney wrote: > Hi Dmitry, > > On Fri, Jan 19, 2024 at 10:35:43PM +0200, Dmitry Baryshkov wrote: > > This kind of change sets a very bad precedent. This way old kernels > > become incompatible with the updated firmware. For me it looks like > > Linux kernel suddenly being unable to boot after the BIOS upgrade. > > Generally memory map updates should be disallowed after the board hits > > the production and the DT is published and merged. There can be other > > users of DT. BSD systems, U-Boot. We spend sensible efforts in making > > sure that DT is an ABI: newer kernel remain compatible with older DT > > files. We expect the same kind of efforts from device manufacturers. > > > > I think unless there is a good reason, the memory map update should be > > reverted on the Qualcomm side as a breaking change. > > If this kind of update is absolutely necessary, it might be better to > > define a new set of board files utilising the new memory map, marking > > existing DT files as legacy. > > This is on a development board that's not in production yet, so > personally I think this change is fine. It's in all of our best > interests to have SoC vendors push their code upstream early, even if > it means that later on we need to make memory map changes like this. > The problem I have with the patch is that I don't know which precedence it sets, because the commit message indicates that we have a new firmware version, while Eric's report lacks this information. As long as everyone with access to the hardware agrees that breaking backwards compatibility is the right thing to do, I'm not against it. But then again, if the support is under active development, why would anyone run a stable@ kernel on this thing? Or are you asking for it to be included in v6.8-rc, so that you guys have a "stable" tree to do further development (with this patch) on? > Once this is in production, then I agree with you that changes like > this should be avoided if possible. > Agreed Regards, Bjorn
