summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2026-07-09MAINTAINERS: Update my email address for the AW99706 backlight driverJunjie Cao1-1/+1
Switch my maintainer entry for the Awinic AW99706 WLED backlight driver from my personal Gmail address to junjie.cao@linux.dev. Update both MAINTAINERS and the device-tree binding maintainers field. Signed-off-by: Junjie Cao <junjie.cao@linux.dev> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706073307.1038430-1-junjie.cao@linux.dev Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Correct and extend hw_pattern documentationManuel Fombuena1-4/+3
Fix the repeat section: -1 is a valid value meaning infinite repeat, as accepted by the ledtrig-pattern sysfs interface; only 0 and values below -1 are rejected. The previous text incorrectly stated all negative numbers were invalid. Also remove the redundant trailing sentence since the behaviour is now covered inline. Add the brightness range (0-255) to the hw_pattern section, which was previously undocumented. Fixes: b1816b22381b ("Documentation:leds: Add leds-st1202.rst") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497B2FB4F5AC4B142790CE5C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09leds: st1202: Fix pattern duration prescaler and pattern_clear skip markerManuel Fombuena1-1/+1
The PATy_DUR register encodes duration as N × 22.2 ms, with register value 0 reserved as a pattern skip indicator (§7.10). The driver incorrectly subtracted 1 from the register value: value / ST1202_MILLIS_PATTERN_DUR_MIN - 1 This caused two problems: - All programmed durations were off by one step (~22 ms too short). - Writing the minimum duration (22 ms) produced register value 0, silently skipping the pattern step instead of setting a 22 ms duration. The maximum duration constant was also wrong at 5660 ms. The 8-bit register saturates at 255, giving a maximum of 5610 ms (22 ms × 255). Values above 5653 ms were already producing a uint8_t overflow and writing 0 to the hardware. Fix the formula by removing the erroneous subtraction, and derive the maximum from the register width so the relationship is explicit. Update the documentation to reflect the correct maximum. This exposes a secondary issue: pattern_clear() was calling st1202_duration_pattern_write() with ST1202_MILLIS_PATTERN_DUR_MIN to reset unused slots, accidentally relying on the broken formula to produce register value 0. With the corrected formula, the same call writes 0x01 (22 ms), leaving unused slots as valid 22 ms zero-PWM steps and making the LED appear off for 7 × 22 ms out of every cycle. Write 0 directly to the duration registers in pattern_clear() so unused slots are always explicitly marked as skip, independently of the conversion formula. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84971D3AF982F4F707A378F0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09drm/i915/doc: Document DP link capabilitiesImre Deak2-0/+12
Add documentation for the DP link capabilities interface. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-2-imre.deak@intel.com
2026-07-08Documentation/bpf: Add BPF signing and enforcement docDaniel Borkmann2-0/+498
Describe the BPF signing design end to end: why a trusted loader is needed, the signature(insns || metadata) contract, load-time verification via fd_array (exclusive + frozen maps), the binary BPF_SIG_{UNSIGNED,VERIFIED} verdict, and how [BPF] LSMs can enforce policy on it. This writes down the contract on the discussion points with the LSM / integrity folks [0][1]: by the time security_bpf_prog_load() is called, signature verification has fully completed and covers the instructions plus the frozen contents of every bound exclusive map; there is no intermediate "loader verified, payload pending" state to reason about; and what BPF_SIG_VERIFIED means at each hook is spelled out explicitly. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/bc823ddbaf63e0e177eb46d1cc15076e4e2e689d.camel@HansenPartnership.com [0] Link: https://lore.kernel.org/bpf/CAHC9VhSDkwGgPfrBUh7EgBKEJj_JjnY68c0YAmuuLT_i--GskQ@mail.gmail.com [1] Link: https://lore.kernel.org/bpf/20260708075343.358712-9-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-08ASoC: dt-bindings: dmic-codec: Add audio-graph port supportChancel Liu1-0/+4
Add port property referencing audio-graph-port.yaml to allow DMIC to be used with audio-graph-card and audio-graph-card2. Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Link: https://patch.msgid.link/20260707065725.312450-4-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08ASoC: dt-bindings: fsl,micfil: Add audio-graph port supportChancel Liu1-0/+4
Add port property referencing audio-graph-port.yaml to allow MICFIL to be used with audio-graph-card and audio-graph-card2. Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Link: https://patch.msgid.link/20260707065725.312450-3-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08ASoC: dt-bindings: wlf,wm8524: Add audio-graph port supportChancel Liu1-0/+4
Add port property referencing audio-graph-port.yaml to allow WM8524 to be used with audio-graph-card and audio-graph-card2. Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Link: https://patch.msgid.link/20260707065725.312450-2-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08docs: ABI: sysfs-kernel-slab: mark cpu_partial attributes deprecatedSeongjun Hong1-6/+12
The per-cpu slab and per-cpu partial slab mechanisms were removed when SLUB was fully converted to per-cpu sheaves in Linux 7.0. The cpu_slabs, slabs_cpu_partial and cpu_partial sysfs attributes were kept as stubs that always return 0 for backwards compatibility, but their documentation still described them as if they were functional. Update the three descriptions to state that the attributes are deprecated and always read 0, and note that they are retained only for compatibility. While here, fix a "partialli" typo in the slabs_cpu_partial description. Signed-off-by: Seongjun Hong <hsj0512@snu.ac.kr> Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Link: https://patch.msgid.link/20260701141755.85119-1-hsj0512@snu.ac.kr Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-08mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static keyLi RongQing1-0/+5
The mempool subsystem historically wrapped its debugging logic inside an merely defines compile-time defaults for SLUB and caused two flaws: 1. On production kernels where CONFIG_SLUB_DEBUG=y but CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely compiled out at compile time. 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed active even if a user explicitly disabled slub debugging at boot time. Clean up this mess by removing the #ifdef and switching to a runtime static key (mempool_debug_enabled), allowing mempool debugging to be toggled cleanly via its own boot parameter. Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Signed-off-by: Li RongQing <lirongqing@baidu.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Harry Yoo <harry@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Hao Li <hao.li@linux.dev> Cc: Christoph Lameter <cl@gentwo.org> Cc: David Rientjes <rientjes@google.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Matthew Wilcox <willy@infradead.org> Cc: Usama Arif <usama.arif@linux.dev> Reviewed-by: SeongJae Park <sj@kernel.org> Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Link: https://patch.msgid.link/20260604110318.2089-1-lirongqing@baidu.com Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-08MAINTAINERS: replace maintainer for Altera mSGDMA driverAdrian Ng Ho Yin1-1/+1
Olivier Dautricourt has stepped down as maintainer of the Altera msgDMA driver as he no longer has access to the hardware. Replace him with Adrian Ng Ho Yin as the new maintainer and update the status from "Odd Fixes" to "Maintained". Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/addaf51275355667045ec300fc8d725e2e273807.1782911845.git.adrian.ho.yin.ng@altera.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-08ABI: sysfs-bus-usb: fix braceManuel Ebner1-1/+1
Remove single ')' Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Link: https://patch.msgid.link/20260702184500.208211-4-manuelebner@mailbox.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-08dt-bindings: usb: renesas,usbhs: Document RZ/G3L SoCBiju Das1-0/+1
The USBHS IP block on RZ/G3L SoC is identitcal to the one found on the RZ/G3S device. Document the RZ/G3L USBHS IP block. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260707145135.247565-2-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-08ASoC: dt-bindings: qcom,sm8250: Add Eliza sound cardRavi Hothi1-0/+1
Add bindings for Eliza sound card, which is compatible with the existing SM8450. Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260703073434.2589657-3-ravi.hothi@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08ASoC: dt-bindings: qcom: Add Eliza LPASS macro codecsRavi Hothi4-0/+4
Add bindings for Qualcomm Eliza LPASS RX, TX, VA and WSA macro codecs, which are compatible with the existing SM8550 generation. Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com> Link: https://patch.msgid.link/20260703073434.2589657-2-ravi.hothi@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-08Merge drm/drm-next into drm-misc-nextThomas Zimmermann8-10/+55
Backmerging to get updates from v7.2-rc2 into drm-misc-next. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-07-08devlink: print controller prefix for non-zero controllerMoshe Shemesh1-0/+9
The controller prefix (c<N>) in phys_port_name is currently restricted to external host controllers. This layout sufficed when DPUs only had a single local controller and one or more external host controllers. However, newer devices can have multiple controllers within the DPU itself, even within a single host environment. To support these topologies, allow drivers to report the controller number regardless of the "external" flag status. Any non-zero controller number will now be explicitly reported, even for single-host or local DPU controllers. Existing ports with controller=0 are unaffected. Update documentation and kdoc to clarify that a non-zero controller number does not require the external flag to be set. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260702111726.816985-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08syscall_user_dispatch: Add kernel.syscall_user_dispatch sysctlGregory Price1-0/+17
Add a matching sysctl to go with CONFIG_SYSCALL_USER_DISPATCH. kernel.syscall_user_dispatch (default 1 - allow) controls whether userspace may arm syscall user dispatch (both via prctl and ptrace). Disarming is always permitted - same semantics as comparable knobs. Disabling while a task has armed syscall user dispatch does not cause it to become inactive - instead it remains active until the user attempts to disable/re-enable via prctl or ptrace. On the next attempt to re-enable, the prctl/ptrace call fails gracefully. The alternative would cause programs translating non-linux syscalls to interpret those syscalls as linux syscalls, resulting in undefined userland behavior. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260706140020.873735-3-gourry@gourry.net
2026-07-08riscv: hwprobe.rst: Document EXT_ZICFISS and EXT_ZICFILPGuodong Xu1-0/+10
RISCV_HWPROBE_EXT_ZICFISS and RISCV_HWPROBE_EXT_ZICFILP are defined in the hwprobe uAPI but are not documented in Documentation/arch/riscv/hwprobe.rst. Add documentation for them. Link: https://github.com/riscv/riscv-cfi/commit/302a2d45c2435940d9a63571c66bc038adc74133 Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-3-2c61f94a695a@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-08riscv: hwprobe.rst: Make indentation consistentAndrew Jones1-97/+97
A handful of vendor-extension entries indent continuation lines with a tab character, while the rest of hwprobe.rst uses spaces. In addition, many list items align their continuation lines under the 'm' of ':c:macro:' (column 7) rather than under the item text (column 4), so the file mixes several indentation styles. Replace the tabs with spaces and align every list item's continuation lines under the item text, giving the whole file one consistent style. Whitespace-only change, no functional change. [Guodong: extend from tabs->spaces to normalizing all continuation-line indentation across the file] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-2-2c61f94a695a@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-08dt-bindings: riscv: sort multi-letter Z extensions alphanumericallyGuodong Xu1-92/+92
The multi-letter extension enum is documented as being sorted alphanumerically (see the "multi-letter extensions, sorted alphanumerically" comment), but several Z entries have drifted out of order. Reorder the affected entries so the multi-letter Z list is sorted alphanumerically again. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-1-2c61f94a695a@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-07dt-bindings: arm: qcom: Add SM7325 Xiaomi 12 Lite 5G (taoyao)Stanislav Zaikin1-0/+1
Xiaomi 12 Lite 5G (xiaomi,taoyao) is a smartphone based on the SM7325 SoC. Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20260608143329.252033-2-zstaseg@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07Merge branch ↵Bjorn Andersson2-29/+106
'20260608-shikra-gcc-rpmcc-clks-v5-2-94cefe092ee3@oss.qualcomm.com' into clk-for-7.3 Merge Shikra RPM and global clock controller bindings through topic branch, to allow constants to be made available to DeviceTree branches as well.
2026-07-07dt-bindings: clock: qcom: Add Qualcomm Shikra SoC Global Clock ControllerImran Shaik1-0/+70
Add device tree bindings for the global clock controller on Qualcomm Shikra SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260608-shikra-gcc-rpmcc-clks-v5-2-94cefe092ee3@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCCImran Shaik1-29/+36
Add bindings documentation for RPM clock controller on Qualcomm Shikra SoC. The Qualcomm Shikra RPMCC has the clocks same as Agatti (QCM2290) RPMCC. Hence, add support to use the QCM2290 RPMCC compatible as fallback for Shikra RPMCC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260608-shikra-gcc-rpmcc-clks-v5-1-94cefe092ee3@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: cache: qcom,llcc: Document Maili SoCJingyi Wang1-29/+34
Add documentation for the Last Level Cache Controller (LLCC) bindings for Qualcomm Maili SoC which is fully compatible with the one found on Qualcomm Hawi. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260604-maili-llcc-v2-1-dd24f05bc197@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: soc: qcom,aoss-qmp: Document the Maili AOSS side channelChunkai Deng1-0/+1
Document the Always-on Subsystem side channel on Qualcomm Maili SoC. Signed-off-by: Chunkai Deng <chunkai.deng@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260604-maili-soc-binding-v2-3-21b5e9bd1aa5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: sram: Document qcom,maili-imem compatibleJingyi Wang1-0/+1
On Qualcomm Maili platform, IMEM is a block of SRAM shared across multiple IP blocks which can fall back to "mmio-sram". Document its compatible. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260604-maili-soc-binding-v2-2-21b5e9bd1aa5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: firmware: qcom,scm: Document SCM on Maili SOCJingyi Wang1-0/+2
Document SCM compatible for the Qualcomm Maili SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260604-maili-soc-binding-v2-1-21b5e9bd1aa5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: arm: qcom: Add Motorola Moto G2 (2014)David Wales1-0/+1
Document the Motorola Moto G2 (2014), which is a smartphone based on the Qualcomm MSM8226 SoC. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: David Wales <daviewales@disroot.org> Link: https://lore.kernel.org/r/20260605-device-motorola-titan-mainline-v4-1-08a7be31f05c@disroot.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07Docs/admin-guide/cgroup-v2: note blkcg_debug_stats gates io.latency statsGuopeng Zhang1-5/+8
The io.stat section says that enabling the io.latency controller exposes the depth, avg_lat and win stats in addition to the normal ones. However, these io.latency-specific stats are debug stats and are only emitted when the blkcg_debug_stats module parameter is enabled, which is disabled by default. Make this explicit so users do not expect these fields to appear in io.stat by default, and qualify the usage text that suggests using avg_lat to pick an io.latency target. Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-07Docs/admin-guide/cgroup-v1: document rdma.peak, rdma.events and ↵Guopeng Zhang1-0/+66
rdma.events.local The v1 RDMA controller documentation only describes rdma.max and rdma.current, but the controller exposes three more files -- rdma.peak, rdma.events and rdma.events.local -- which are already documented for v2. Mirror the v2 wording so the v1 documentation matches the files actually visible on a v1 mount. Co-developed-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-07Docs/admin-guide/cgroup-v2: drop stale misc interface file countGuopeng Zhang1-1/+2
The Miscellaneous controller documentation states it "provides 3 interface files", but misc_cg_files[] actually registers six (max, current, peak, capacity, events, events.local). Drop the stale count and let the file list that follows speak for itself. Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-07sched_ext: Documentation: Fix ops table header referenceLiang Luo1-3/+5
The "Where to Look" and "ABI Instability" sections state that the ops table is defined in include/linux/sched/ext.h. However, struct sched_ext_ops is actually defined in kernel/sched/ext/internal.h, along with the SCX_OPS_* flags; include/linux/sched/ext.h holds the core data structures (struct sched_ext_entity, struct scx_dispatch_q, ...) and the DSQ constants. Point the ops table references to the correct header. Signed-off-by: Liang Luo <luoliang@kylinos.cn> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-07dt-bindings: rockchip: grf: Narrow allowed reboot modesKrzysztof Kozlowski1-2/+5
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only a subset actually makes sense and is valid. Provide negative look-ahead pattern to disallow any modes not supported by the device, which tightens the binding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260701105849.197086-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-07-07dt-bindings: rockchip: pmu: Narrow definition of reboot-modeKrzysztof Kozlowski1-1/+7
The 'reboot-mode' child of PMU node must be a syscon-reboot-mode one, so add missing $ref to enforce the validation and disallow other reboot-mode handlers. Defining 'type: object' is on the other hand not necessary when other schema is referenced. This can be further restricted to match hardware/firmware: syscon-reboot-mode schema allows arbitrary "mode-.* properties but only a subset actually makes sense and is valid. Provide negative look-ahead pattern to disallow any modes not supported by the device, which tightens the binding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260701105849.197086-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-07-07cred: delete task_euid()Alice Ryhl2-7/+3
task_euid() is a very weird operation. You can see how weird it is by grepping for task_euid() - binder is its only user. task_euid() obtains the objective effective UID - it looks at the credentials of the task for purposes of acting on it as an object, but then accesses the effective UID (which the credentials.7 man page describes as "[...] used by the kernel to determine the permissions that the process will have when accessing shared resources [...]"). Since usage in Binder has now been removed, get rid of the resulting dead code. Changes to the zh_CN translation was carried out with the help of Gemini and Google Translate, and since adjusted as per Alex Shi's feedback. Suggested-by: Jann Horn <jannh@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07docs/bpf: Document BPF_STRICT_BUILD=0 to tolerate test build failuresRicardo B. Marlière1-1/+4
When the kernel config does not fully match the BPF selftest config fragment, some tests may fail to compile. BPF_STRICT_BUILD (defaulting to 1) makes any such failure fatal. Mention the option so that developers are aware they can set it to 0 to skip broken tests and keep the build going, which is particularly useful during bringup or when testing on constrained (e.g. distribution) configurations. Signed-off-by: Ricardo B. Marlière <rbm@suse.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706-b4-bpf_strict_build_docs-v1-1-5324d605c7b0@suse.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodesTapio Reijonen1-2/+90
The MAX310x is a family of one- (max3107, max3108), two- (max3109) and four-channel (max14830) UARTs. The binding pulls in /schemas/serial/rs485.yaml at the chip level, describing a single set of RS-485 properties - enough for the single-channel parts, but a multi-channel chip can wire RS-485 differently on each channel. Split the binding per compatible: - single-channel parts (max3107, max3108): the chip node is itself the serial port and carries the RS-485 properties, as before; - multi-channel parts (max3109, max14830): the chip node is only a container and is no longer a serial node; each channel is a "serial@N" subnode that carries the standard serial.yaml/rs485.yaml properties (and may host a serial slave device). max3109 has channels 0-1, max14830 has 0-3. This avoids a chip node that is simultaneously a serial node and the parent of serial nodes. The driver still reads chip-level RS-485 for single-channel and legacy device trees, so existing users are unaffected. Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260615-b4-max310x-rs485-dt-v3-2-7e79f064bdd7@vaisala.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07dt-bindings: interconnect: qcom: document the RPMh Network-On-Chip ↵Raviteja Laggyshetty1-0/+127
interconnect in Maili SoC Document the RPMh Network-On-Chip interconnect for the Qualcomm Maili SoC. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260622-maili_icc-v2-1-18b5ac08c04f@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-07dt-bindings: interconnect: qcom,osm-l3: Add EPSS L3 DT binding for Qualcomm ↵Raviteja Laggyshetty1-0/+2
Shikra SoC Document the EPSS L3 interconnect provider binding for Qualcomm Shikra SoC. The Shikra EPSS L3 block is similar to existing Qualcomm EPSS/OSM L3 providers, but supports only up to 12 frequency lookup table entries. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260603-shikra_epss_l3-v3-1-3c2e0b796e78@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-07Merge branch 'icc-x1e80100' into icc-nextGeorgi Djakov1-0/+72
This series enables QoS configuration for QNOC type device which can be found on X1E80100 platform. It enables QoS configuration for master ports with predefined priority and urgency forwarding. This helps in prioritizing the traffic originating from different interconnect masters at NOC (Network On Chip). The system may function normally without this feature. However, enabling QoS helps optimize latency and bandwidth across subsystems like CPU, GPU, and multimedia engines, which becomes important in high-throughput scenarios. This is a feature aimed at performance enhancement to improve system performance under concurrent workloads. * icc-x1e80100 dt-bindings: interconnect: qcom,x1e80100-rpmh: add clocks property to enable QoS interconnect: qcom: x1e80100: enable QoS configuration Link: https://patch.msgid.link/20260527-x1e80100_qos-v2-0-305c6539e6d2@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-07dt-bindings: interconnect: qcom,x1e80100-rpmh: add clocks property to enable QoSRaviteja Laggyshetty1-0/+72
Some interconnect nodes on X1E80100 have QoS registers located inside a block whose interface is clock-gated. For those nodes, driver must enable the corresponding clock(s) before accessing the registers. Add the 'clocks' property so the driver can obtain and enable the required clock(s). Only interconnects that have clock-gated QoS register interface use this property; it is not applicable to all interconnect nodes. Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260527-x1e80100_qos-v2-1-305c6539e6d2@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-07net: document NETDEV_UNREGISTER unlocked rationaleStanislav Fomichev1-0/+5
The lock-state table marks UNREGISTER as unlocked without saying why. Add a short note that many handlers release the lowers via dev_close(). Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260702224150.3730033-7-sdf@fomichev.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-07net: require instance lock for NETDEV_DOWN/GOING_DOWN notifiersStanislav Fomichev1-0/+2
Sprinkle a few asserts about ops lock: netif_close_many and __dev_notify_flags should now consistently run under the lock Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260702224150.3730033-6-sdf@fomichev.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-07dt-bindings: bus: Convert DA8XX MSTPRI to DT schemaEduard Bostina2-20/+37
Convert the Texas Instruments DA8XX Master Peripheral Priority Registers bindings to DT schema. Documentation: OMAP-L138 (DA850) http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf Signed-off-by: Eduard Bostina <egbostina@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260630124631.2991596-1-egbostina@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-07dt-bindings: interconnect: qcom,sc8280xp-rpmh: Add reg and clocks for QoSXilin Wu1-1/+98
Add the register range and clock properties needed for programming NoC QoS configuration on SC8280XP. Require a register range for the real NoC providers, require QoS clocks for aggre1_noc and aggre2_noc, and keep the virtual clk_virt and mc_virt providers without MMIO resources or clocks. Signed-off-by: Xilin Wu <sophon@radxa.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260507-sc8280xp-qos-v1-1-15135858cd98@radxa.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-07net/mlx5: Document devlink ratesCosmin Ratiu1-0/+33
It seems rates were not documented in the mlx5-specific file, so add examples on how to limit VFs and groups and also provide an example of the intended way to achieve cross-esw scheduling. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260701073254.754518-15-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-07devlink: Allow rate node parents from other devlinksCosmin Ratiu1-0/+2
This commit makes use of the building blocks previously added to implement cross-device rate nodes. A new 'supported_cross_device_rate_nodes' bool is added to devlink_ops which lets drivers advertise support for cross-device rate objects. If enabled and if there is a common shared devlink instance, then: - all rate objects will be stored in the top-most common nested instance and - rate objects can have parents from other devices sharing the same common instance. Storing rates in the common shared ancestor is safe, because it is reference counted by its nested devlink instances, so it's guaranteed to outlive them. Furthermore, the shared devlink infra guarantees a given nested devlink hierarchy is managed by the same driver. The parent devlink from info->ctx is not locked, so none of its mutable fields can be used. But parent setting only requires comparing devlink pointer comparisons. Additionally, since the shared devlink is locked, other rate operations cannot concurrently happen. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260701073254.754518-8-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-07devlink: Allow parent dev for rate-set and rate-newCosmin Ratiu1-4/+6
Currently, a devlink rate's parent device is assumed to be the same as the one where the devlink rate is created. This patch changes that to allow rate commands to accept an additional argument that specifies the parent dev. This will allow devlink rate groups with leafs from other devices. Example of the new usage with ynl: Creating a group on pci/0000:08:00.1 with a parent to an already existing pci/0000:08:00.1/group1: ./tools/net/ynl/pyynl/cli.py --spec \ Documentation/netlink/specs/devlink.yaml --do rate-new --json '{ "bus-name": "pci", "dev-name": "0000:08:00.1", "rate-node-name": "group2", "rate-parent-node-name": "group1", "parent-dev": { "bus-name": "pci", "dev-name": "0000:08:00.1" } }' Setting the parent of leaf node pci/0000:08:00.1/65537 to pci/0000:08:00.0/group1: ./tools/net/ynl/pyynl/cli.py --spec \ Documentation/netlink/specs/devlink.yaml --do rate-set --json '{ "bus-name": "pci", "dev-name": "0000:08:00.1", "port-index": 65537, "parent-dev": { "bus-name": "pci", "dev-name": "0000:08:00.0" }, "rate-parent-node-name": "group1" }' Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260701073254.754518-7-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-24 12:02:43 +0000