Message-ID: <a243e024-c7df-4a3d-a855-4738a4970de2@ixit.cz>
Date: Wed, 26 Nov 2025 23:33:07 +0100
From: David Heidelberg <david@...t.cz>
To: Casey Connolly <casey.connolly@...aro.org>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Joel Selvaraj <foss@...lselvaraj.com>,
 Alexander Martinz <amartinz@...ftphones.com>,
 Dzmitry Sankouski <dsankouski@...il.com>,
 Pablo Correa Gómez <ablocorrea@...mail.com>
Cc: Guido Günther <agx@...xcpu.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 phone-devel@...r.kernel.org
Subject: Re: [PATCH QUESTION] arm64: configs: Add Snapdragon 845 config
 fragment

On 26/11/2025 20:03, Casey Connolly wrote:
> Hi David,
> 
> On 26/11/2025 17:19, David Heidelberg via B4 Relay wrote:
>> From: Casey Connolly <casey.connolly@...aro.org>
> 
> It's not the first time you're sending patches with my authorship and
> SoB upstream without even a heads up... fixes and minor feature
> additions I can understand (particularly if you're doing the work to
> polish them off and get them accepted), but frankly I think it's little
> unprofessional to post a very clearly "never-intended-for-upstream"
> patch verbatim to the list, particularly when it has someone elses name
> on it.

I wanted to use the patch as starting point for the discussion, not a 
patch to get things upstreamed right away.

I respect the original authorship. I wouldn't feel comfortable send code 
someone else wrote with my name.
Other remaining option here would be never send it, but I think people 
could benefit from the config fragment.

Here, I wanted to have a discussion (thus it's marked as [QUESTION]) 
what is the best way how to address this fragment, while not end up 
being separated from the mainline development.

I and many others see a value to keep this file upstream and care about 
the file there, as that would ease changes done to upstream defconfig to 
be reflected onto sdm845 fragment, when bigger changes are introduced to 
the Linux kernel.

> 
>>
>> 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.
> 
> I wrote this like 4+ years ago and it's even more wrong now than it was
> then (not least because I eventually found the UART XD).

Yeah, but since then people continue activelycontribute to it, so 
generally it's pretty up-to-date =)

>>
>> 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.
>>
>> Signed-off-by: Casey Connolly <casey@...nolly.tech>
>> Co-developed-by: Joel Selvaraj <foss@...lselvaraj.com>
>> Signed-off-by: Joel Selvaraj <foss@...lselvaraj.com>
>> Co-developed-by: Alexander Martinz <amartinz@...ftphones.com>
>> Signed-off-by: Alexander Martinz <amartinz@...ftphones.com>
>> Co-developed-by: Dzmitry Sankouski <dsankouski@...il.com>
>> Signed-off-by: Dzmitry Sankouski <dsankouski@...il.com>
>> Co-developed-by: Pablo Correa Gómez <ablocorrea@...mail.com>
>> Signed-off-by: Pablo Correa Gómez <ablocorrea@...mail.com>
>> Co-developed-by: David Heidelberg <david@...t.cz>
>> Signed-off-by: David Heidelberg <david@...t.cz>
>> ---
>> This patch is a question, if it would be viable to introduce this
>> configuration fragment as part of mainline kernel, so keeping it in sync
>> with recent kernel updates would be more straighforward.
>>
>> When this file is kept by distributions, it cannot be reused on latest
>> releases and for building latest kernels, as the options gets
>> desynchronized.>
>> I offer to maintain this file within the mainline kernel, and I believe
>> most likely some of the co-authors of the file will likely step up to
>> keep it up-to-date, so people who want to contribute can avoid fighting
> 
> The same co-authors who knew you were going to post this??

I assume people who made it may want this to become useful for others. 
If not, I said I offer maintaining it.

> 
>> with old configuration file downloaded from downstream project and can
>> focus on fixing actual bugs.
>>
>> In case this fragment gets unmaintained status in the future, there
>> shouldn't be any issues to just remove it from the kernel.
>>
>> What do you think?
> 
> I don't think it makes sense to put a platform+distro-specific (read:
> opinionated) config fragment into the kernel, any distro trying to use
> this would likely always find themselves carrying patches (sending a
> patch to enable a driver or whatever just doesn't scale very well),
> nevermind if multiple distros with different requirements tried to use it.

I tried to shave the distro specific bits to keep only the HW relevant 
changes. I think each distro can apply the specific bits themselves and 
keep here the sdm845 generics.

I would like to reduce the fragmentation and leverage good review 
process of the mainline kernel.

Distributions should really apply only their custom changes, not some 
version of sdm845.config fragment based on very different 
sdm845-mainline versions (multiple currently) or sdm845-next version.

How can we version the sdm845.config, while keeping configs from:
1. generic stable releases
2. generic development / -next versions
3. distributions optimized configs

IMHO would be nice to have one source of truth, at least for base option 
related to one upstream kernel version which makes the hardware works.

With upstreaming the fragment, we can use mainline and `Fixes / Cc: 
stable` tags to mark what should belong where without confusion.

David

[...]

Powered by blists - more mailing lists