Message-ID: <9221ccef-f1b9-4491-83e2-7116b7523857@ixit.cz>
Date: Thu, 11 Dec 2025 11:41:20 +0100
From: David Heidelberg <david@...t.cz>
To: Arnd Bergmann <arnd@...db.de>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Casey Connolly <casey.connolly@...aro.org>,
 Casey Connolly <casey@...nolly.tech>, 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 03/12/2025 22:35, Arnd Bergmann wrote:
> On Wed, Nov 26, 2025, at 17:19, David Heidelberg via B4 Relay wrote:
>>
>> 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.
> 
> I don't mind the idea of having additional fragments for specific
> purposes, but as others have said this one does not seem that useful.
> 
> I think it does too many things at once and is still too specific to
> a relatively uncommon usecase. Having an SDM845 specific fragment is
> clearly too narrow, but I can see us adding a fragment for phones
> overall, which would then turn on options for Qualcomm, Mediatek
> and Samsung based phones.

I agree there are too specific things. I sent this as a conversation 
starter more than "a fragment to ship".

Having something like a pure mobile fragment would be awesome.
Bringing up phones is challenging enough, so when people have one more 
pillar to rely on, it'll definitely accelerate work.

I believe it would help many close-to-mainline projects to have a more 
stable base in the kernel instead of every repository playing on own 
small playground.

> 
>> +# Samsung S9 SM-G9600(starqltechn)
>> +CONFIG_SND_SOC_MAX98512=y
>> +CONFIG_SND_SOC_MAXIM_DSM=y
>> +CONFIG_SND_SOC_MAXIM_DSM_CAL=y
>> +CONFIG_DRM_PANEL_SAMSUNG_S6E3HA8=y
>> +CONFIG_TOUCHSCREEN_S6SY761=m
>> +CONFIG_MFD_SEC_CORE=m
>> +CONFIG_REGULATOR_S2DOS05=m
>> +CONFIG_MFD_MAX77705=m
>> +CONFIG_LEDS_MAX77705=m
>> +CONFIG_CHARGER_MAX77705=m
>> +CONFIG_BATTERY_MAX17042=m
>> +CONFIG_INPUT_MAX77693_HAPTIC=m
>> +CONFIG_PWM_CLK=m
>> +
>> +# SHIFT6mq
>> +CONFIG_DRM_PANEL_VISIONOX_RM69299=y
>> +CONFIG_SND_SOC_TFA989X=m
> 
> I think overall we can be fairly liberal with adding
> more loadable modules to the common defconfig, but much
> less so the built-in drivers.
> 
>> +# SOC
>> +CONFIG_FORCE_NR_CPUS=y
>> +CONFIG_NR_CPUS=8
> 
> This would break other devices that have more CPUs, which in turn
> makes it impossible to combine the fragment with other fragments.

Yes, I just used the original data from the fragment, as we know it's 8 
cores, it's safe option. For the final fragment this will go away (if we 
talk about mobile generic fragment).

> 
>> +CONFIG_SCSI_UFS_QCOM=y
>> +CONFIG_QCOM_GSBI=y
>> +CONFIG_QCOM_LLCC=y
>> +CONFIG_QCOM_OCMEM=y
>> +CONFIG_QCOM_RMTFS_MEM=y
>> +CONFIG_QCOM_SOCINFO=y
>> +CONFIG_QCOM_WCNSS_CTRL=y
>> +CONFIG_QCOM_APR=y
>> +CONFIG_POWER_RESET_QCOM_PON=y
>> +CONFIG_QCOM_SPMI_TEMP_ALARM=y
>> +CONFIG_QCOM_LMH=y
>> +CONFIG_SCHED_CLUSTER=y
>> +CONFIG_SND_SOC_QDSP6_Q6VOICE=m
>> +CONFIG_SCSI_UFS_BSG=y
>> +CONFIG_PHY_QCOM_QMP_PCIE=y
>> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
>> +CONFIG_INTERCONNECT_QCOM_OSM_L3=y
> 
> Again, these should mosely be loadable modules.

Probably, some of these workarounds are here because of some issue in 
the kernel, which leads to boot failure.

There will be more of these bug-avoid changes.

We'll test how many of these are necessary.

The question is, if documented, could we push some of these into the 
initial fragments? I assume fixing some of these may take some time.

> 
>> +# Notification LED
>> +# Must be builtin as it won't be automatically modprobed
>> +CONFIG_LEDS_TRIGGER_PATTERN=y
> 
> This sounds like bug that we should fix and not work around.
> 
>> +# Graphics
>> +CONFIG_DRM=y
>> +CONFIG_FB_SIMPLE=y
> 
> I don't want to enable more fbdev drivers. Right now the
> only one we enable is FB_EFI, and we should probably replace
> that with DRM_SIMPLEDRM in order to turn off CONFIG_FB
> entirely.

Useful with debugging, but this can handle Mobian, NixOS Mobile, pmOS by 
their fragments, so that's fine to drop.

> 
>> +# Power management
>> +CONFIG_PM_AUTOSLEEP=y
>> +CONFIG_PM_WAKELOCKS=y
>> +
>> +# MGLRU
>> +CONFIG_LRU_GEN=y
>> +CONFIG_LRU_GEN_ENABLED=y
>> +
>> +# Usage clamping (scale CPU for specific tasks)
>> +CONFIG_UCLAMP_TASK=y
>> +CONFIG_UCLAMP_TASK_GROUP=y
> 
> We can discuss changing the defaults for these in the defconfig,
> but this doesn't seem to belong with the other stuff.

Great :)

> 
>> +# HID/Input
>> +CONFIG_LCD_CLASS_DEVICE=m
> 
> This is not an input option

Thanks, removed.

> 
>> +CONFIG_I2C_HID=y
>> +CONFIG_HID_GENERIC=m
>> +CONFIG_UHID=m
>> +CONFIG_USB_HID=m
>> +CONFIG_INPUT_EVDEV=y
>> +CONFIG_BT_HIDP=m
>> +CONFIG_INPUT_JOYDEV=m
>> +CONFIG_HID_ACCUTOUCH=m
>> +CONFIG_HID_ACRUX=m
>> +CONFIG_HID_ACRUX_FF=y
>> +CONFIG_HID_ALPS=m
>> +CONFIG_HID_APPLEIR=m
> 
> This looks like you are just enabling every single USB HID
> driver, which is probably not something we want in a commonly
> used fragment, though having a well-maintained fragment for
> popular pluggable USB devices may be useful for others as well.

Yeah, this part make sense for distro-specific.

> 
>> +# Qcom stuff
>> +CONFIG_RPMSG_CHAR=y
>> +CONFIG_QCOM_Q6V5_ADSP=m
>> +CONFIG_BT_RFCOMM=m
>> +CONFIG_BT_RFCOMM_TTY=y
>> +CONFIG_BT_BNEP=m
>> +CONFIG_BT_BNEP_MC_FILTER=y
>> +CONFIG_BT_BNEP_PROTO_FILTER=y
>> +CONFIG_BT_HS=y
>> +CONFIG_BT_LE=y
>> +CONFIG_HID_BATTERY_STRENGTH=y
>> +CONFIG_HIDRAW=y
>> +CONFIG_QCOM_COINCELL=m
>> +CONFIG_QCOM_FASTRPC=m
>> +CONFIG_QCOM_SPMI_VADC=y
>> +CONFIG_QCOM_SPMI_ADC5=y
>> +CONFIG_PHY_QCOM_QMP=y
>> +CONFIG_PHY_QCOM_QUSB2=y
>> +CONFIG_PHY_QCOM_QMP_UFS=y
>> +CONFIG_TYPEC=y
>> +CONFIG_PHY_QCOM_QMP_COMBO=y
>> +CONFIG_LEDS_CLASS_FLASH=y
>> +CONFIG_TCP_CONG_ADVANCED=y
>> +CONFIG_TCP_CONG_WESTWOOD=y
>> +CONFIG_DEFAULT_WESTWOOD=y
>> +CONFIG_BLK_DEV_RAM=y
>> +CONFIG_BLK_DEV_RAM_SIZE=8192
>> +CONFIG_BTRFS_FS=y
>> +CONFIG_BTRFS_FS_POSIX_ACL=y
>> +CONFIG_F2FS_FS=y
> 
> Most of these don't look like "Qcom stuff" to me. In particular
> BTRFS is probably not something you'd even want to enable on
> a phone, though that could be part of a generic distro config
> that we have discussed several times in the past.

Yeah, pmOS specific changes will be dropped.

> 
>> +# WLAN debugging
>> +CONFIG_ATH10K_DEBUG=y
>> +CONFIG_ATH10K_DEBUGFS=y
>> +CONFIG_ATH10K_SPECTRAL=y
> 
> This particular one seem arbitrary, but having a "debugging"
> fragment is something others may find helpful as well. The
> hard part there is figuring out which debug options are the
> most helpful for the least overhead, as everyone is debugging
> different bugs.

I was thinking having "fragment pack" for "early bringup-er", something 
like common things you need to verify, when you setting up
  - regulators
  - clocks
  - serial
  - framebuffer

When people are new to the kernel development and still don't know all, 
I think this may accelerate their progress.


> 
>> +# Disable all unrelated stuffs afaik
>> +CONFIG_ARCH_BLAIZE=n
>> +CONFIG_ARCH_SPARX5=n
>> +CONFIG_HIBERNATION=n
>> +CONFIG_FW_LOADER_USER_HELPER=n
>> +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
>> +CONFIG_BLK_DEV_NVME=n
> 
> It feels wrong to turn things off in the same fragment
> that turns other things on.

Here, would it make sense to do 3-4 categories, dropping things which 
CANNOT in general setups on devices such as:

  - servers (phone battery, vibrator, etc.)
  - desktops and laptops (embedded drivers, etc.)
  - mobile, e.g., phone and tablets (RAID array on PCIe, network routing 
chip, etc.)
  - basic embedded and routers

If we go by the Pareto principle (~ 80/20) with low effort and easy 
maintenance, we could manage smaller, more efficient images. 
Distributions (or people) who don't want to risk any inconvenience or 
have an obscure setup will just not use the fragments.

What do you think?

If there is a consensus on some parts, I'll prepare some basic small series.

David

P.S. Sorry for the late reply, Thunderbird decided to encrypt my Draft, 
but somehow forgot how to decrypt it...

> 
>        Arnd

-- 
David Heidelberg

Powered by blists - more mailing lists