Re: [PATCH] arm64: dts: qcom: sa8775p: Add new memory map updates to SA8775P

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/22/2024 12:02 PM, Bjorn Andersson wrote:
> 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?

I agree with what Bjorn is mentioning here. Why we are freezing the kernel version
here/commit of it here. Memory map can change during the active development
and this target is under active development. 

New board file approach doesn't work - since how do you select the new 
board file? Both old and new board file will still point to the same
platform type and version.

We also saw recently that IOT SOCs which are similar to in some
sense Mobile SOCs are having the different map. The same almost
same SOCs used in the different product segments like Chrome
and Mobile and IOT can have different memory map as well. The good
part there was that they had different soc-id and it will be easier
to differentiate them. 

As Brian M mentioned earlier, we want soc vendors to submit the support
for their SOCs and platforms on top it as early as possible and it means
such memory map changes will continue. Even memory map changes
continue even few months after the commercial s/w release in certain cases
due to critical bugs were found in some usecases which warrants the changes. 


-- 
---Trilok Soni





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux