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
