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 <[email protected]>
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 <[email protected]>
Co-developed-by: Joel Selvaraj <[email protected]>
Signed-off-by: Joel Selvaraj <[email protected]>
Co-developed-by: Alexander Martinz <[email protected]>
Signed-off-by: Alexander Martinz <[email protected]>
Co-developed-by: Dzmitry Sankouski <[email protected]>
Signed-off-by: Dzmitry Sankouski <[email protected]>
Co-developed-by: Pablo Correa Gómez <[email protected]>
Signed-off-by: Pablo Correa Gómez <[email protected]>
Co-developed-by: David Heidelberg <[email protected]>
Signed-off-by: David Heidelberg <[email protected]>
---
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
[...]
