Samsung SoC drivers for v6.16, part two
Add CPU hotplug support on Google GS101 by toggling respective bits in
secondary PMU intr block (Power Management Unit (PMU) Interrupt
Generation) from the main PMU driver.
* tag 'samsung-drivers-6.16-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
soc: samsung: exynos-pmu: enable CPU hotplug support for gs101
MAINTAINERS: Add google,gs101-pmu-intr-gen.yaml binding file
dt-bindings: soc: samsung: exynos-pmu: gs101: add google,pmu-intr-gen phandle
dt-bindings: soc: google: Add gs101-pmu-intr-gen binding documentation
Link: https://lore.kernel.org/r/20250516082037.7248-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
All attribute sets and messages are prefixed with tc-.
The C codegen also adds the family name to all structs.
We end up with names like struct tc_tc_act_attrs.
Remove the tc- prefixes to shorten the names.
This should not impact Python as the attr set names
are never exposed to user, they are only used to refer
to things internally, in the encoder / decoder.
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250520161916.413298-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There is a define in the uAPI header called tc_gen which expands
to the "generic" TC action fields. This helps other actions include
the base fields without having to deal with nested structs.
A couple of actions (sample, gact) do not define extra fields,
so the spec used a common tc-gen struct for both of them.
Unfortunately this struct does not exist in C. Let's use gact's
(generic act's) struct for basic actions.
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250520161916.413298-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tc-act-stats-attrs and tca-stats-attrs are almost identical.
The only difference is that the latter has sub-message decoding
for app, rather than declaring it as a binary attr.
tc-act-police-attrs and tc-police-attrs are identical but for
the TODO annotations.
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250520161916.413298-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Patch series "sysfs: add counters for lockups and stalls", v2.
Commits 9db89b4111 ("exit: Expose "oops_count" to sysfs") and
8b05aa2633 ("panic: Expose "warn_count" to sysfs") added counters for
oopses and warnings to sysfs, and these two patches do the same for
hard/soft lockups and RCU stalls.
All of these counters are useful for monitoring tools to detect whether
the machine is healthy. If the kernel has experienced a lockup or a
stall, it's probably due to a kernel bug, and I'd like to detect that
quickly and easily. There is currently no way to detect that, other than
parsing dmesg. Or observing indirect effects: such as certain tasks not
responding, but then I need to observe all tasks, and it may take a while
until these effects become visible/measurable. I'd rather be able to
detect the primary cause more quickly, possibly before everything falls
apart.
This patch (of 2):
There is /proc/sys/kernel/hung_task_detect_count, /sys/kernel/warn_count
and /sys/kernel/oops_count but there is no userspace-accessible counter
for hard/soft lockups. Having this is useful for monitoring tools.
Link: https://lkml.kernel.org/r/20250504180831.4190860-1-max.kellermann@ionos.com
Link: https://lkml.kernel.org/r/20250504180831.4190860-2-max.kellermann@ionos.com
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Cc:
Cc: Core Minyard <cminyard@mvista.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Joel Granados <joel.granados@kernel.org>
Cc: Song Liu <song@kernel.org>
Cc: Kees Cook <kees@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When there are CPU and memory hot un/plugs, the dm crypt keys may need to
be reloaded again depending on the solution for crash hotplug support.
Currently, there are two solutions. One is to utilizes udev to instruct
user space to reload the kdump kernel image and initrd, elfcorehdr and etc
again. The other is to only update the elfcorehdr segment introduced in
commit 2472627561 ("crash: add generic infrastructure for crash hotplug
support").
For the 1st solution, the dm crypt keys need to be reloaded again. The
user space can write true to /sys/kernel/config/crash_dm_crypt_key/reuse
so the stored keys can be re-used.
For the 2nd solution, the dm crypt keys don't need to be reloaded.
Currently, only x86 supports the 2nd solution. If the 2nd solution gets
extended to all arches, this patch can be dropped.
Link: https://lkml.kernel.org/r/20250502011246.99238-5-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
A configfs /sys/kernel/config/crash_dm_crypt_keys is provided for user
space to make the dm crypt keys persist for the kdump kernel. Take the
case of dumping to a LUKS-encrypted target as an example, here is the life
cycle of the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd uses
an user-input passphrase to de-crypt the LUKS volume keys or simply
TPM-sealed volume keys and then save the volume keys to specified
keyring (using the --link-vk-to-keyring API) and the keys will expire
within specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
Eventually the keys have to stay in the kdump reserved memory for the
kdump kernel to unlock encrypted volumes. During this process, some
measures like letting the keys expire within specified time are desirable
to reduce security risk.
This patch assumes,
1) there are 128 LUKS devices at maximum to be unlocked thus
MAX_KEY_NUM=128.
2) a key description won't exceed 128 bytes thus KEY_DESC_MAX_LEN=128.
And here is a demo on how to interact with
/sys/kernel/config/crash_dm_crypt_keys,
# Add key #1
mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
# Add key #1's description
echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description
# how many keys do we have now?
cat /sys/kernel/config/crash_dm_crypt_keys/count
1
# Add key# 2 in the same way
# how many keys do we have now?
cat /sys/kernel/config/crash_dm_crypt_keys/count
2
# the tree structure of /crash_dm_crypt_keys configfs
tree /sys/kernel/config/crash_dm_crypt_keys/
/sys/kernel/config/crash_dm_crypt_keys/
├── 7d26b7b4-e342-4d2d-b660-7426b0996720
│ └── description
├── count
├── fce2cd38-4d59-4317-8ce2-1fd24d52c46a
│ └── description
Link: https://lkml.kernel.org/r/20250502011246.99238-3-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
RISC-V SoC for v6.16
Sophgo:
Add support for SG2044 TOP syscon device. The SG2044 TOP
device provide PLL clock function in its area.
Add RTC support for CV1800 series SoC. The device
is called RTC, but contains control registers of other
HW blocks in its address space, most notably of
Power-on-Reset (PoR) module, DW8051 IP (MCU core),
accompanying SRAM, hence putting it in SoC subsystem.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* tag 'riscv-sophgo-soc-for-v6.16' of https://github.com/sophgo/linux:
soc: sophgo: cv1800: rtcsys: New driver (handling RTC only)
dt-bindings: soc: sophgo: add RTC support for Sophgo CV1800 series
soc: sophgo: sg2044: Add support for SG2044 TOP syscon device
Link: https://lore.kernel.org/r/MA0P287MB2262B041A26A0F5EAD1E296CFE91A@MA0P287MB2262.INDP287.PROD.OUTLOOK.COM
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Qualcomm driver updates for v6.16
Allow list QSEECOM for EFI variable services on on the Asus Zenbook A14,
and block list TZMEM on the SM7150 platform to avoid issues with rmtfs.
Extend the last-level cache (llcc) driver to support version 6 of the
hardware and enable SM8750 support.
Also add socinfo for the SM8750 platform.
Re-enable UCSI support on SC8280XP, now that the reported crash has been
dealt with, and filter the altmode notifications to avoid spurious
hotplug events being propagated to user space.
Add SM7150 support to pd-mapper.
* tag 'qcom-drivers-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: llcc-qcom: Add support for SM8750
soc: qcom: llcc-qcom: Add support for LLCC V6
dt-bindings: cache: qcom,llcc: Document SM8750 LLCC block
soc: qcom: socinfo: add SM8750 SoC ID
dt-bindings: arm: qcom,ids: add SoC ID for SM8750
dt-bindings: soc: qcom: qcom,rpm: add missing clock/-names properties
dt-bindings: soc: qcom,rpm: add missing clock-controller node
soc: qcom: smem: Update max processor count
firmware: qcom: tzmem: disable sm7150 platform
soc: qcom: pd-mapper: Add support for SM7150
soc: qcom: pmic_glink_altmode: fix spurious DP hotplug events
soc: qcom: smp2p: Fix fallback to qcom,ipc parse
soc: qcom: pmic_glink: enable UCSI on sc8280xp
firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A14
dt-bindings: soc: qcom,rpmh-rsc: Limit power-domains requirement
Link: https://lore.kernel.org/r/20250513215656.44448-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
On machines with multiple memory nodes, interleaving page allocations
across nodes allows for better utilization of each node's bandwidth.
Previous work by Gregory Price [1] introduced weighted interleave, which
allowed for pages to be allocated across nodes according to user-set
ratios.
Ideally, these weights should be proportional to their bandwidth, so that
under bandwidth pressure, each node uses its maximal efficient bandwidth
and prevents latency from increasing exponentially.
Previously, weighted interleave's default weights were just 1s -- which
would be equivalent to the (unweighted) interleave mempolicy, which goes
through the nodes in a round-robin fashion, ignoring bandwidth
information.
This patch has two main goals: First, it makes weighted interleave easier
to use for users who wish to relieve bandwidth pressure when using nodes
with varying bandwidth (CXL). By providing a set of "real" default
weights that just work out of the box, users who might not have the
capability (or wish to) perform experimentation to find the most optimal
weights for their system can still take advantage of bandwidth-informed
weighted interleave.
Second, it allows for weighted interleave to dynamically adjust to
hotplugged memory with new bandwidth information. Instead of manually
updating node weights every time new bandwidth information is reported or
taken off, weighted interleave adjusts and provides a new set of default
weights for weighted interleave to use when there is a change in bandwidth
information.
To meet these goals, this patch introduces an auto-configuration mode for
the interleave weights that provides a reasonable set of default weights,
calculated using bandwidth data reported by the system. In auto mode,
weights are dynamically adjusted based on whatever the current bandwidth
information reports (and responds to hotplug events).
This patch still supports users manually writing weights into the nodeN
sysfs interface by entering into manual mode. When a user enters manual
mode, the system stops dynamically updating any of the node weights, even
during hotplug events that shift the optimal weight distribution.
A new sysfs interface "auto" is introduced, which allows users to switch
between the auto (writing 1 or Y) and manual (writing 0 or N) modes. The
system also automatically enters manual mode when a nodeN interface is
manually written to.
There is one functional change that this patch makes to the existing
weighted_interleave ABI: previously, writing 0 directly to a nodeN
interface was said to reset the weight to the system default. Before this
patch, the default for all weights were 1, which meant that writing 0 and
1 were functionally equivalent. With this patch, writing 0 is invalid.
Link: https://lkml.kernel.org/r/20250520141236.2987309-1-joshua.hahnjy@gmail.com
[joshua.hahnjy@gmail.com: wordsmithing changes, simplification, fixes]
Link: https://lkml.kernel.org/r/20250511025840.2410154-1-joshua.hahnjy@gmail.com
[joshua.hahnjy@gmail.com: remove auto_kobj_attr field from struct sysfs_wi_group]
Link: https://lkml.kernel.org/r/20250512142511.3959833-1-joshua.hahnjy@gmail.comhttps://lore.kernel.org/linux-mm/20240202170238.90004-1-gregory.price@memverge.com/ [1]
Link: https://lkml.kernel.org/r/20250505182328.4148265-1-joshua.hahnjy@gmail.com
Co-developed-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>
Suggested-by: Yunjeong Mun <yunjeong.mun@sk.com>
Suggested-by: Oscar Salvador <osalvador@suse.de>
Suggested-by: Ying Huang <ying.huang@linux.alibaba.com>
Suggested-by: Harry Yoo <harry.yoo@oracle.com>
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com>
Reviewed-by: Honggyu Kim <honggyu.kim@sk.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joanthan Cameron <Jonathan.Cameron@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
TI K3 device tree updates for v6.16
Generic Fixups/Cleanups:
* am62*: emmc - drop disable-wp, Add bootphase tags to support MMC boot
SoC Specific features and Fixes:
AM62Ax:
* C7x and R5F support added
* Bug fix for emmc clock to point to default
* CPUFreq thermal throttling on thermal alert
AM62P5:
* Add RNG Node (common to J722s)
* Bug fix for emmc clock to point to default (common to J722S)
AM625:
* Wakeup R5 node
* Bug fix for emmc clock to point to default
* PRUSS-M support
* New GPU bindings
AM64:
* Switch to 64-bit address space for PCIe0
* Add PCIe control nodes for main_conf region
* Reserve timer nodes used by MCU F/w.
AM65:
* MMC: Add missing delay timing values for SDR and legacy modes
* Add compatible for AM65x syscon and PCIe control properties
(dtbs_check fixes)
J7200:
* PCIe control node to scm_conf, switch to 64-bit address space for PCIe1.
J721E:
* PCIe control node to scm_conf, switch to 64-bit address space for PCIe0,1.
J721S2:
* GPU node for Imagination Tech Rouge BXS GPU.
* PCIe control node to scm_conf, switch to 64-bit address space for PCIe1.
J722s/AM67A:
* Switch serdes status to be enabled by board file than at SoC level.
* Switch to 64-bit address space for PCIe0.
J784S4/J742S2/AM69:
* Add ASPCIE0 and enable output for PCIe1
* Fix length of serdes_ln_ctrl.
* Switch to 64-bit address space for PCIe0,1.
Board Specific:
AM62Ax:
* SK: co-processors C7x, R5, PWM support added
* phycore-som: co-processors C7x, R5
AM62P5:
* Add Toradex Verdin AM62P boards with Dahlia, Ivy, Mallow and Yavia support.
* SK: Add remote processor support, PWM
AM625:
* Add BeagleBoard.org PocketBeagle-2 support
* phycore-som: Enable R5F support
* Verdin: Add eeprom compatible fallback
* SK: Enable PWM, voltage supplies, clock, i2cmux rename for camera overlays
(dtbs_check fixes)
* BeaglePlay: Add voltage supplies for camera overlays (dtbs_check fixes)
* phyboard-lyra: Add cooling maps for fan
* emmc bug fixes: add non-removable flag for eMMC.
AM65:
* EVM: Add missing power supply description ofr Rocktech panel
(dtbs_check fixes)
J721E:
* EVM: Enable OSPI1
* EVM/SK: Dt nodes description for mandatory power suplpies for panel and
sensors (dtbs_check fixes)
J721S2/AM68:
* Add phyBOARD-Izar-AM68x
* am68-SK: Fix regulator hierarchy
J722s/AM67A:
* EVM: Add mux controls for CSI2, power regulator nodes and add overlays for
quad IMX219 and TEVI OV5640.
* BeagleY-AI: Add bootph for main_gpio1
J784S4/J742S2/AM69:
* usxgmii expansion board: Drop un-necessary pinctrl-names
* evm: Add overlay for USB0 Type-A option
* tag 'ti-k3-dt-for-v6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: (86 commits)
arm64: dts: ti: k3-j722s-evm: Add overlay for TEVI OV5640
arm64: dts: ti: k3-j722s-evm: Add overlay for quad IMX219
arm64: dts: ti: j722s-evm: Add MUX to control CSI2RX
arm64: dts: ti: j722s-evm: Add DT nodes for power regulators
arm64: dts: ti: k3-am62a-phycore-som: Reserve main_timer2 for C7x DSP
arm64: dts: ti: k3-am62a-phycore-som: Reserve main_rti4 for C7x DSP
arm64: dts: ti: k3-am62a-phycore-som: Enable Co-processors
arm64: dts: ti: k3-am62-phycore-som: Enable Co-processors
arm64: dts: ti: k3-am62x-phyboard-lyra-gpio-fan: Update cooling maps
arm64: dts: ti: k3-am62a: Enable CPU freq throttling on thermal alert
arm64: dts: ti: k3-j721e-common-proc-board: Enable OSPI1 on J721E
arm64: dts: ti: k3-j721s2: Add GPU node
arm64: dts: ti: k3-am62: New GPU binding details
arm64: dts: ti: k3-am62-main: Add PRUSS-M node
arm64: dts: ti: k3-am64: Reserve timers used by MCU FW
arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSP
arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP
arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors
arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors
arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors
...
Link: https://lore.kernel.org/r/20250512144807.yn64klchtmjjl6ac@protrude
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Convert the clock device tree bindings to yaml for the Altera SoCFPGA
Cyclone5, Arria5, and Arria10 chip families. Since the clock nodes are
subnodes to Altera SOCFPGA Clock Manager, the yaml was added to
socfpga-clk-manager.yaml.
Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Document the AD3530/AD3530R (8-channel) and AD3531/AD3531R (4-channel)
low-power, 16-bit, buffered voltage output DACs with software-
programmable gain controls. They provide full-scale output spans of 2.5V
or 5V for reference voltages of 2.5V. These devices operate on a single
2.7V to 5.5V supply and are guaranteed to be monotonic by design.
The "R" variants include a 2.5V, 5ppm/°C internal reference, which is
disabled by default.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://patch.msgid.link/20250429-togreg-v7-2-0af9c543b545@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The present sbrmi module only support reporting power via hwmon.
However, AMD data center range of processors support various
system management functionality using custom protocols defined in
Advanced Platform Management Link (APML) specification.
Register a miscdevice, which creates a device /dev/sbrmiX with an IOCTL
interface for the user space to invoke the APML Mailbox protocol, which
is already defined in sbrmi_mailbox_xfer().
The APML protocols depend on a set of RMI registers. Having an IOCTL
as a single entry point will help in providing synchronization among
these protocols as multiple transactions on RMI register set may
create race condition.
Support for other protocols will be added in subsequent patches.
APML mailbox protocol returns additional error codes written by
SMU firmware in the out-bound register 0x37. These errors include,
invalid core, message not supported over platform and
others. This additional error codes can be used to provide more
details to user space.
Open-sourced and widely used https://github.com/amd/esmi_oob_library
will continue to provide user-space programmable API.
Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>
Link: https://lore.kernel.org/r/20250428063034.2145566-7-akshay.gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Board files are deprecated by DT, and the last user of
nvmem_add_cell_table() was removed by commit 2af4fcc0d3 ("ARM:
davinci: remove unused board support") in v6.3. Hence remove all
support for nvmem cell tables, and update the documentation.
Device drivers can still register a single cell using
nvmem_add_one_cell() (which was not documented before).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250509122452.11827-2-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
