[PATCH QUESTION] arm64: configs: Add Snapdragon 845 config fragment

[David Heidelberg]

On 26/11/2025 19:10, Catalin Marinas wrote:
> On Wed, Nov 26, 2025 at 05:19:20PM +0100, David Heidelberg via B4 Relay wrote:
>> From: Casey Connolly <casey.connolly at linaro.org>
>>
>> This fragment provides reasonable default for the mobile devices
>> based on Snapdragon 845 architecture. While default config could be
>> used, the reality is it brings many issues to the development workflows,
>> which are much harder to address than on generic boards or devices with
>> available UART console.
>>
>> This config fragment produces the .config used by distributions.
>> It is designed to be fairly minimal and specific to the
>> supported SDM845 devices whilst offering all the features you would
>> expect.
>>
>> It disables other arm64 architectures to speed up build times and
>> decrease the size of the kernel image.
>>
>> To generate a .config use "make defconfig sdm845.config"
>>
>> [David]
>>   - Dropped distribution specific options.
>>   - Added entry into the MAINTAINERS file.
> [...]
>>   MAINTAINERS                      |    5 +
>>   arch/arm64/configs/sdm845.config | 1048 ++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 1053 insertions(+)
> 
> I really don't think the kernel should carry configs other than the
> generic ones used by developers. We had this on arm32 but mostly because
> we didn't have a single kernel image for a long time (and when we got
> it, it was mostly for v7 cores). I don't want to get back to hosting a
> multitude of configs in mainline.
> 

On the arm32 it was custom defconfigs.
Here we use default defconfig with the sdm845 fragment to accommodate 
mobile devices (e.g. `make defconfig sdm845.config`).

So far, I would say phones based on sdm845 are one of the most popular 
for daily-driving, thus I think giving it extra care until the drivers 
gets rock solid to work with default defconfig would make sense.

We could have sdm845 config in a separate git tree and developers would 
contribute to it, but why not have it inside the mainline itself?
We have the SoC, drivers, most of stuff  needed to get the phones 
running, why keep the latest piece of puzzle out of kernel?

One of the best outcomes in long-term would be get rid of it, but we're 
not there yet.

Example: In -next tree for sdm845, I recently had to enable 
`REGULATOR_QCOM_REFGEN=y`, but that means I need to communicate with 
everyone else trying to use sdm845.config that they need to enable it 
with 6.19 or their -next tree experiments.
If it was in mainline, people carrying custom changes on top of sdm845 
fragment or combining it with distribution fragment would get it 
together with 6.19 prior without effort with clear commit why this 
option was enabled instead of fixing/squashing commits.

Do you think the fragment could cause some issues for people working on 
things outside sdm845 phones area? Or the concert was more about 
possible precedent?

David