* [PATCH 2/8] riscv: Detect the Ssqosid extension
From: Drew Fustini @ 2026-06-19 18:29 UTC (permalink / raw)
To: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, Drew Fustini
Cc: linux-kernel, linux-riscv, x86, devicetree, linux-rt-devel,
linux-doc
In-Reply-To: <20260619-dfustini-atl-sc-cbqri-dt-v1-0-e79a7723fab0@kernel.org>
Ssqosid is the RISC-V Quality-of-Service (QoS) Identifiers specification
which defines the Supervisor Resource Management Configuration (srmcfg)
register.
Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
Co-developed-by: Kornel Dulęba <mindal@semihalf.com>
Signed-off-by: Kornel Dulęba <mindal@semihalf.com>
Signed-off-by: Drew Fustini <fustini@kernel.org>
---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ef8e5f55c8d..b83dae5cebb9 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -112,6 +112,7 @@
#define RISCV_ISA_EXT_ZCLSD 103
#define RISCV_ISA_EXT_ZICFILP 104
#define RISCV_ISA_EXT_ZICFISS 105
+#define RISCV_ISA_EXT_SSQOSID 106
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index f46aa5602d74..668a7e71ff1c 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -582,6 +582,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
__RISCV_ISA_EXT_SUPERSET(ssnpm, RISCV_ISA_EXT_SSNPM, riscv_xlinuxenvcfg_exts),
+ __RISCV_ISA_EXT_DATA(ssqosid, RISCV_ISA_EXT_SSQOSID),
__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
__RISCV_ISA_EXT_DATA(svade, RISCV_ISA_EXT_SVADE),
__RISCV_ISA_EXT_DATA_VALIDATE(svadu, RISCV_ISA_EXT_SVADU, riscv_ext_svadu_validate),
--
2.43.0
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: riscv: Add Ssqosid extension description
From: Drew Fustini @ 2026-06-19 18:29 UTC (permalink / raw)
To: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, Drew Fustini
Cc: linux-kernel, linux-riscv, x86, devicetree, linux-rt-devel,
linux-doc
In-Reply-To: <20260619-dfustini-atl-sc-cbqri-dt-v1-0-e79a7723fab0@kernel.org>
Document the ratified Supervisor-mode Quality of Service ID (Ssqosid)
extension v1.0.
Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Drew Fustini <fustini@kernel.org>
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 2b0a8a93bb21..1c6f091518d4 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -232,6 +232,12 @@ properties:
ratified at commit d70011dde6c2 ("Update to ratified state")
of riscv-j-extension.
+ - const: ssqosid
+ description: |
+ The standard Ssqosid extension for Quality of Service ID is
+ ratified as v1.0 in commit d9c616497fde ("Merge pull
+ request #7 from ved-rivos/Ratified") of riscv-ssqosid.
+
- const: ssstateen
description: |
The standard Ssstateen extension for supervisor-mode view of the
--
2.43.0
^ permalink raw reply related
* [PATCH 0/8] riscv: Add Ssqosid and initial CBQRI resctrl support
From: Drew Fustini @ 2026-06-19 18:29 UTC (permalink / raw)
To: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, Drew Fustini
Cc: linux-kernel, linux-riscv, x86, devicetree, linux-rt-devel,
linux-doc
This series adds initial RISC-V QoS support: the Ssqosid extension [1]
(srmcfg CSR), the CBQRI controller interface [2] integrated with resctrl
[3], and DT-based platform driver for cache controllers. It has been
tested both on the Tenstorrent Ascalon Shared Cache controller as well
as a Qemu implementation [4].
Note that this series only implements support for resctrl CAT using
CBQRI capacity allocation control. cc_block_mask maps onto resctrl's
existing cbm schema. However, cc_cunits is not supported as there is no
existing equivalent for capacity units in the resctrl schemata.
I had previously been iterating on an RFC series [5] that did a full
implementation of CBQRI including capacity monitoring, bandwidth
allocation and monitoring, as well as a parser for the ACPI RQSC table.
The bandwidth controls for CBQRI do not fit well into resctrl's existing
throttle based MB schemata. I believe that the path forward is
Reinette's generic schema description proof of concept [6] but that will
take time to mature. My plan is to rebase the full support of CBQRI on
to the generic schema once it is ready.
[1] https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
[2] https://github.com/riscv-non-isa/riscv-cbqri/releases/tag/v1.0
[3] https://docs.kernel.org/filesystems/resctrl.html
[4] https://github.com/riscv-non-isa/riscv-rqsc/blob/main/src/
[5] https://lore.kernel.org/linux-riscv/20260601-ssqosid-cbqri-rqsc-v7-0-v6-16-baf00f50028a@kernel.org/
[6] https://lore.kernel.org/all/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/
---
Drew Fustini (8):
dt-bindings: riscv: Add Ssqosid extension description
riscv: Detect the Ssqosid extension
riscv: Add support for srmcfg CSR from Ssqosid extension
riscv_cbqri: Add capacity controller probe and allocation device ops
riscv_cbqri: resctrl: Add cache allocation via capacity block mask
riscv: Enable resctrl filesystem for Ssqosid
dt-bindings: riscv: Add generic CBQRI controller binding
riscv_cbqri: Add CBQRI cache capacity-allocation platform driver
.../devicetree/bindings/riscv/extensions.yaml | 6 +
.../devicetree/bindings/riscv/riscv,cbqri.yaml | 109 +++
MAINTAINERS | 15 +
arch/riscv/Kconfig | 20 +
arch/riscv/include/asm/csr.h | 5 +
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/asm/processor.h | 3 +
arch/riscv/include/asm/qos.h | 86 +++
arch/riscv/include/asm/resctrl.h | 152 ++++
arch/riscv/include/asm/switch_to.h | 3 +
arch/riscv/kernel/Makefile | 2 +
arch/riscv/kernel/cpufeature.c | 1 +
arch/riscv/kernel/qos.c | 91 +++
drivers/resctrl/Kconfig | 44 ++
drivers/resctrl/Makefile | 7 +
drivers/resctrl/cbqri_capacity.c | 132 ++++
drivers/resctrl/cbqri_devices.c | 511 ++++++++++++++
drivers/resctrl/cbqri_internal.h | 110 +++
drivers/resctrl/cbqri_resctrl.c | 774 +++++++++++++++++++++
include/linux/riscv_cbqri.h | 47 ++
20 files changed, 2119 insertions(+)
---
base-commit: 4fa3f5fabb30bf00d7475d5a33459ea83d639bf9
change-id: 20260610-dfustini-atl-sc-cbqri-dt-410c8e2711dd
Best regards,
--
Drew Fustini <fustini@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: install DT overlays via dtbs_install
From: sashiko-bot @ 2026-06-19 18:15 UTC (permalink / raw)
To: Vishwas Udupa; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260619180951.325272-1-vishwas.udupa@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message inaccurately claims to add 'all DT overlays defined in this Makefile' while intentionally omitting EL2 overlays.
--
commit fbeb39cf8d645f798555d038d5b4a1e5e3393c7a
Author: Vishwas Udupa <vishwas.udupa@oss.qualcomm.com>
arm64: dts: qcom: install DT overlays via dtbs_install
This commit adds explicit install targets for Device Tree overlays (.dtbo)
in the qcom Makefile so they can be packaged alongside normal DTBs via the
standard dtbs_install flow.
> Even when final DTBs are produced at build time, some distributions rely on
> standalone DTBOs for runtime selection and application by bootloaders or
> firmware. Without explicit install targets, DTBOs are not picked up by the
> standard dtbs_install flow and therefore cannot be packaged alongside DTBs.
>
> Add explicit dtb-$(CONFIG_ARCH_QCOM) entries for all DT overlays defined in
> this Makefile so they are installed via dtbs_install, matching existing
> DTB install behaviour.
[Severity: Medium]
Is this description accurate? The commit message states that all DT overlays
defined in the Makefile are added, but the patch appears to systematically
omit EL2 overlays.
[ ... ]
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
[ ... ]
> lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
>
> dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
> lemans-evk-ifp-mezzanine-dtbs := lemans-evk.dtb lemans-evk-ifp-mezzanine.dtbo
> dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtbo
For example, lemans-evk-ifp-mezzanine.dtbo is explicitly added here, but
the adjacent lemans-el2.dtbo is conspicuously skipped. Similar omissions
occur for monaco-el2.dtbo and x1-el2.dtbo further down in the patch.
Could the commit message be updated to clarify that EL2 overlays are
intentionally excluded from standalone installation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619180951.325272-1-vishwas.udupa@oss.qualcomm.com?part=1
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: install DT overlays via dtbs_install
From: Vishwas Udupa @ 2026-06-19 18:09 UTC (permalink / raw)
To: andersson
Cc: vudupa, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, lminier, Vishwas Udupa
In-Reply-To: <20260428123725.3457865-1-vudupa@qti.qualcomm.com>
Overlay binaries (.dtbo) are currently only built implicitly as
dependencies of composite firmware images and are therefore absent from the
kernel install output.
Even when final DTBs are produced at build time, some distributions rely on
standalone DTBOs for runtime selection and application by bootloaders or
firmware. Without explicit install targets, DTBOs are not picked up by the
standard dtbs_install flow and therefore cannot be packaged alongside DTBs.
Add explicit dtb-$(CONFIG_ARCH_QCOM) entries for all DT overlays defined in
this Makefile so they are installed via dtbs_install, matching existing
DTB install behaviour.
Signed-off-by: Vishwas Udupa <vishwas.udupa@oss.qualcomm.com>
---
Changes in v2:
- Address review feedback from Krzysztof Kozlowski
- Drop inclusion of EL2 DTBOs
- Link to v1: https://lore.kernel.org/all/20260428123725.3457865-1-vudupa@qti.qualcomm.com/
arch/arm64/boot/dts/qcom/Makefile | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e7306419..44ed2b591363 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -7,7 +7,9 @@ apq8016-sbc-usb-host-dtbs := apq8016-sbc.dtb apq8016-sbc-usb-host.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sar2130p-qar2130p.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3-camera-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3-camera-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-usb-host.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-usb-host.dtbo
dtb-$(CONFIG_ARCH_QCOM) += apq8016-schneider-hmibsc.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8039-t2.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8094-sony-xperia-kitakami-karin_windy.dtb
@@ -47,13 +49,16 @@ lemans-evk-camera-csi1-imx577-dtbs := lemans-evk.dtb lemans-evk-camera-csi1-imx5
lemans-evk-camera-dtbs := lemans-evk.dtb lemans-evk-camera.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera-csi1-imx577.dtb
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera-csi1-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera.dtb
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera.dtbo
lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
lemans-evk-ifp-mezzanine-dtbs := lemans-evk.dtb lemans-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += mahua-crd.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-arduino-monza.dtb
@@ -61,12 +66,14 @@ dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
monaco-evk-camera-imx577-dtbs := monaco-evk.dtb monaco-evk-camera-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtbo
monaco-evk-el2-dtbs := monaco-evk.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-el2.dtb
monaco-evk-ifp-mezzanine-dtbs := monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
@@ -175,7 +182,9 @@ qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vis
qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-minipc-g1iot.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
@@ -199,6 +208,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1.dtb
qrb2210-rb1-vision-mezzanine-dtbs := qrb2210-rb1.dtb qrb2210-rb1-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1-vision-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qrb4210-rb2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5.dtb
@@ -206,6 +216,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5.dtb
qrb5165-rb5-vision-mezzanine-dtbs := qrb5165-rb5.dtb qrb5165-rb5-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5-vision-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qrb5165-rb5-vision-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qru1000-idp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sa8155p-adp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sa8295p-adp.dtb
@@ -308,6 +319,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
sdm845-db845c-navigation-mezzanine-dtbs := sdm845-db845c.dtb sdm845-db845c-navigation-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sdm845-google-crosshatch.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm845-google-blueline.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyln.dtb
@@ -372,7 +384,9 @@ sm8550-hdk-rear-camera-card-dtbs := sm8550-hdk.dtb sm8550-hdk-rear-camera-card.d
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-display-card-rear-camera-card.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-display-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-display-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-rear-camera-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk-rear-camera-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
@@ -386,7 +400,9 @@ sm8650-hdk-rear-camera-card-dtbs := sm8650-hdk.dtb sm8650-hdk-rear-camera-card.d
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card-rear-camera-card.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-rear-camera-card.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-rear-camera-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
@@ -395,12 +411,14 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8750-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += talos-evk.dtb
talos-evk-usb1-peripheral-dtbs := talos-evk.dtb talos-evk-usb1-peripheral.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-usb1-peripheral.dtb
+dtb-$(CONFIG_ARCH_QCOM) += talos-evk-usb1-peripheral.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-camera-imx577.dtbo
talos-evk-camera-imx577-dtbs := talos-evk.dtb talos-evk-camera-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-camera-imx577.dtb
talos-evk-lvds-auo,g133han01-dtbs := \
talos-evk.dtb talos-evk-lvds-auo,g133han01.dtbo
dtb-$(CONFIG_ARCH_QCOM) += talos-evk-lvds-auo,g133han01.dtb
+dtb-$(CONFIG_ARCH_QCOM) += talos-evk-lvds-auo,g133han01.dtbo
x1e001de-devkit-el2-dtbs := x1e001de-devkit.dtb x1-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += x1e001de-devkit.dtb x1e001de-devkit-el2.dtb
x1e78100-lenovo-thinkpad-t14s-el2-dtbs := x1e78100-lenovo-thinkpad-t14s.dtb x1-el2.dtbo
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 07/10] ACPI: APEI: introduce GHES helper
From: Julian Braha @ 2026-06-19 17:46 UTC (permalink / raw)
To: Ahmed Tiba, Rafael J. Wysocki, Tony Luck, Borislav Petkov,
Hanjun Guo, Mauro Carvalho Chehab, Shuai Xue, Len Brown,
Saket Dumbre, Davidlohr Bueso, Jonathan Cameron, Dave Jiang,
Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, linux-acpi, acpica-devel, linux-cxl, devicetree,
linux-edac, linux-doc, Dmitry.Lamerov
In-Reply-To: <81dd6d0d-427f-49ae-9573-fbe84dc2185a@arm.com>
On 6/19/26 16:45, Ahmed Tiba wrote:
> GHES_CPER_HELPERS is intended for both the ACPI GHES path and the DT
> firmware-first provider, so I do not want to tie it to ACPI.
So what's the plan to fix the build error when ACPI is disabled:
https://lore.kernel.org/all/0f131ee4-d335-45d2-b6ae-49c18df1353b@gmail.com/
- Julian Braha
^ permalink raw reply
* Re: [PATCH v4 08/16] spi: cadence-quadspi: add PHY tuning support
From: Mark Brown @ 2026-06-19 17:33 UTC (permalink / raw)
To: Santhosh Kumar K
Cc: robh, krzk+dt, conor+dt, miquel.raynal, richard, vigneshr,
pratyush, mwalle, takahiro.kuwano, linux-spi, devicetree,
linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <20260618073725.84733-9-s-k6@ti.com>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Thu, Jun 18, 2026 at 01:07:17PM +0530, Santhosh Kumar K wrote:
> The Cadence QSPI controller supports a delay-line PHY for high-speed
> operation. Without calibration the PHY is unused and read capture relies
> on a fixed delay, limiting throughput at frequencies above the base
> operating speed.
> +static int cqspi_get_phy_pattern_offset(struct device *dev, u32 *offset)
> +{
> + struct device_node *np, *flash_np = NULL, *part_np;
> + const __be32 *reg;
> + int len;
> +
> + if (!dev || !dev->of_node)
> + return -EINVAL;
> +
> + for_each_child_of_node(dev->of_node, np) {
> + if (of_node_name_prefix(np, "flash")) {
> + flash_np = np;
> + break;
> + }
> + }
This isn't going to do the right thing if there's more than one flash,
that doesn't seem a super sensible hardware configuration but I'm not
sure I see anything stopping it being set up and system integrators do
enjoy differentiating.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 07/10] rust: driver: store pointers in `DeviceId`
From: Gary Guo @ 2026-06-19 17:12 UTC (permalink / raw)
To: sashiko-reviews, Gary Guo
Cc: dri-devel, devicetree, conor+dt, robh, linux-pci,
Danilo Krummrich, ojeda, Alexandre Courbot
In-Reply-To: <20260619170508.8E9351F00A3E@smtp.kernel.org>
On Fri Jun 19, 2026 at 6:05 PM BST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Arbitrary Memory Dereference / Privilege Escalation via PCI dynamic IDs (`new_id`)
> - [High] Undefined Behavior via unconditional null reference creation when `driver_data` is 0
> --
>
> commit 01871465d12a97f7be006ca329ebda24f458cf1e
> Author: Gary Guo <gary@garyguo.net>
>
> rust: driver: store pointers in `DeviceId`
>
> This commit changes Rust device IDs to store pointers directly in the
> driver_data field, matching the behavior of C drivers. It works around
> the limitation of missing provenance during const evaluation by wrapping
> raw IDs in MaybeUninit.
>
>> diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
>> index 84852a2d9ad78..59453588df0e7 100644
>> --- a/rust/kernel/device_id.rs
>> +++ b/rust/kernel/device_id.rs
> [ ... ]
>> @@ -47,15 +50,48 @@ pub unsafe trait RawDeviceIdIndex: RawDeviceId {
>> /// The offset (in bytes) to the context/data field in the raw device ID.
>> const DRIVER_DATA_OFFSET: usize;
>>
>> - /// The index stored at `DRIVER_DATA_OFFSET` of the implementor of the [`RawDeviceIdIndex`]
>> - /// trait.
>> - fn index(&self) -> usize;
>> + /// Obtain the data pointer stored inside the device ID.
>> + ///
>> + /// # Safety
>> + ///
>> + /// `&Self` must be stored inside a `IdArray<Self, U>`.
>> + unsafe fn info_unchecked<U>(&self) -> &'static U {
>> + // SAFETY: By safety requirement of the trait, this is `self.driver_data as *const U` and by
>> + // the safety requirement of the function, this is stored in `IdArray<Self, U>` so is
>> + // convertible to `&'static U`.
>> + unsafe {
>> + core::ptr::from_ref(self)
>> + .byte_add(Self::DRIVER_DATA_OFFSET)
>> + .cast::<&U>()
>> + .read()
>> + }
>> + }
>
> [Severity: High]
> Does this code create an unconditional null reference in Rust if the
> driver_data or driver_info field is 0?
>
> Creating a null reference is immediate undefined behavior in Rust, even for
> zero-sized types. This 0 value can occur in paths like:
>
> 1. IdArray::new_without_index() leaving driver_data fields as 0.
>
> 2. When userspace adds a dynamic USB ID via the sysfs new_id interface using
> fewer than 5 fields (omitting refVendor), USB core initializes driver_info
> to 0.
>
> [ ... ]
>> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
>> index a3dd48f763532..a630c7fc6a853 100644
>> --- a/rust/kernel/pci.rs
>> +++ b/rust/kernel/pci.rs
> [ ... ]
>> @@ -110,10 +110,13 @@ extern "C" fn probe_callback(
>> // SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `struct pci_device_id` and
>> // does not add additional invariants, so it's safe to transmute.
>> let id = unsafe { &*id.cast::<DeviceId>() };
>> - let info = T::ID_TABLE.info(id.index());
>> +
>> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>` or
>> + // `pci_device_id_any` which has 0 as driver_data.
>> + let info = unsafe { id.info_unchecked_opt::<T::IdInfo>() };
>
> [Severity: Critical]
> Can this allow an arbitrary memory dereference or bypass kernel lockdown?
>
> The PCI subsystem supports dynamic IDs via the sysfs new_id interface
> (drivers/pci/pci-driver.c), which parses up to 7 arguments, the last being
> driver_data (%lx).
>
> This allows a privileged user (root) to supply an arbitrary pointer value.
> The code here will blindly cast this integer to an Option<&'static U> via
> info_unchecked_opt() and dereference it if non-zero, allowing arbitrary
> kernel memory access.
False positive because dyn ID requires the data to be matching one of the
existing data.
>
> [ ... ]
>> diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
>> index 500b5e0ba4ea9..8aeff50117552 100644
>> --- a/rust/kernel/usb.rs
>> +++ b/rust/kernel/usb.rs
> [ ... ]
>> @@ -89,7 +89,8 @@ extern "C" fn probe_callback(
>> // does not add additional invariants, so it's safe to transmute.
>> let id = unsafe { &*id.cast::<DeviceId>() };
>>
>> - let info = T::ID_TABLE.info(id.index());
>> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>`.
>> + let info = unsafe { id.info_unchecked::<T::IdInfo>() };
>> let data = T::probe(intf, id, info);
>
> [Severity: High]
> Does this code trigger undefined behavior when the underlying USB device ID
> driver_info field is 0?
>
> When the id is constructed using IdArray::new_without_index() or when
> dynamically added via sysfs new_id with fewer fields, the driver_info is 0.
> /sys/bus/
> This probe unconditionally expects a valid non-null reference and creates
> one even for 0-initialized IDs via info_unchecked().
Looks like I need to convert USB code to use `Option<&Self::IdInfo>` too, like
what I did to PCI.
Best,
Gary
^ permalink raw reply
* [PATCH v2 0/2] Add support for StarFive JHB100 SPI
From: Changhuang Liang @ 2026-06-19 14:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Mark Brown
Cc: linux-spi, linux-kernel, devicetree, Changhuang Liang
The StarFive JHB100 SPI is based on the Synopsys DesignWare SSI version 2.00.
changes since v1:
PATCH 1:
- Add "starfive,jhb100-spi" and support falling back to
"snps,dwc-ssi-2.00a" or "snps,dwc-ssi-1.01a".
- using subject lines reflecting the style for the
spi subsystem.
v1: https://lore.kernel.org/all/20260612125856.8530-1-changhuang.liang@starfivetech.com/
Changhuang Liang (2):
spi: dt-bindings: snps,dw-apb-ssi: Add starfive,jhb100-spi
spi: dw: Add support for snps,dwc-ssi-2.00a
Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 6 ++++++
drivers/spi/spi-dw-mmio.c | 1 +
2 files changed, 7 insertions(+)
--
2.25.1
^ permalink raw reply
* Re: [PATCH 06/10] rust: driver: remove `$module_table_name` from `module_device_table`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: conor+dt, ojeda, dri-devel, linux-pci, robh, Danilo Krummrich,
devicetree, Alexandre Courbot
In-Reply-To: <20260618-id_info-v1-6-96af1e559ef9@garyguo.net>
> Wrap the generated code in a `const _: ()` block to avoid symbol conflict.
> This removes the need of creating a new identifier.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=6
^ permalink raw reply
* Re: [PATCH 01/10] rust: driver: remove `IdTable::id`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, Alexandre Courbot, linux-pci, devicetree,
conor+dt, dri-devel, ojeda, robh
In-Reply-To: <20260618-id_info-v1-1-96af1e559ef9@garyguo.net>
> This is unused.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=1
^ permalink raw reply
* Re: [PATCH 07/10] rust: driver: store pointers in `DeviceId`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: dri-devel, devicetree, conor+dt, robh, linux-pci,
Danilo Krummrich, ojeda, Alexandre Courbot
In-Reply-To: <20260618-id_info-v1-7-96af1e559ef9@garyguo.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Arbitrary Memory Dereference / Privilege Escalation via PCI dynamic IDs (`new_id`)
- [High] Undefined Behavior via unconditional null reference creation when `driver_data` is 0
--
commit 01871465d12a97f7be006ca329ebda24f458cf1e
Author: Gary Guo <gary@garyguo.net>
rust: driver: store pointers in `DeviceId`
This commit changes Rust device IDs to store pointers directly in the
driver_data field, matching the behavior of C drivers. It works around
the limitation of missing provenance during const evaluation by wrapping
raw IDs in MaybeUninit.
> diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
> index 84852a2d9ad78..59453588df0e7 100644
> --- a/rust/kernel/device_id.rs
> +++ b/rust/kernel/device_id.rs
[ ... ]
> @@ -47,15 +50,48 @@ pub unsafe trait RawDeviceIdIndex: RawDeviceId {
> /// The offset (in bytes) to the context/data field in the raw device ID.
> const DRIVER_DATA_OFFSET: usize;
>
> - /// The index stored at `DRIVER_DATA_OFFSET` of the implementor of the [`RawDeviceIdIndex`]
> - /// trait.
> - fn index(&self) -> usize;
> + /// Obtain the data pointer stored inside the device ID.
> + ///
> + /// # Safety
> + ///
> + /// `&Self` must be stored inside a `IdArray<Self, U>`.
> + unsafe fn info_unchecked<U>(&self) -> &'static U {
> + // SAFETY: By safety requirement of the trait, this is `self.driver_data as *const U` and by
> + // the safety requirement of the function, this is stored in `IdArray<Self, U>` so is
> + // convertible to `&'static U`.
> + unsafe {
> + core::ptr::from_ref(self)
> + .byte_add(Self::DRIVER_DATA_OFFSET)
> + .cast::<&U>()
> + .read()
> + }
> + }
[Severity: High]
Does this code create an unconditional null reference in Rust if the
driver_data or driver_info field is 0?
Creating a null reference is immediate undefined behavior in Rust, even for
zero-sized types. This 0 value can occur in paths like:
1. IdArray::new_without_index() leaving driver_data fields as 0.
2. When userspace adds a dynamic USB ID via the sysfs new_id interface using
fewer than 5 fields (omitting refVendor), USB core initializes driver_info
to 0.
[ ... ]
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index a3dd48f763532..a630c7fc6a853 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
[ ... ]
> @@ -110,10 +110,13 @@ extern "C" fn probe_callback(
> // SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `struct pci_device_id` and
> // does not add additional invariants, so it's safe to transmute.
> let id = unsafe { &*id.cast::<DeviceId>() };
> - let info = T::ID_TABLE.info(id.index());
> +
> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>` or
> + // `pci_device_id_any` which has 0 as driver_data.
> + let info = unsafe { id.info_unchecked_opt::<T::IdInfo>() };
[Severity: Critical]
Can this allow an arbitrary memory dereference or bypass kernel lockdown?
The PCI subsystem supports dynamic IDs via the sysfs new_id interface
(drivers/pci/pci-driver.c), which parses up to 7 arguments, the last being
driver_data (%lx).
This allows a privileged user (root) to supply an arbitrary pointer value.
The code here will blindly cast this integer to an Option<&'static U> via
info_unchecked_opt() and dereference it if non-zero, allowing arbitrary
kernel memory access.
[ ... ]
> diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
> index 500b5e0ba4ea9..8aeff50117552 100644
> --- a/rust/kernel/usb.rs
> +++ b/rust/kernel/usb.rs
[ ... ]
> @@ -89,7 +89,8 @@ extern "C" fn probe_callback(
> // does not add additional invariants, so it's safe to transmute.
> let id = unsafe { &*id.cast::<DeviceId>() };
>
> - let info = T::ID_TABLE.info(id.index());
> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>`.
> + let info = unsafe { id.info_unchecked::<T::IdInfo>() };
> let data = T::probe(intf, id, info);
[Severity: High]
Does this code trigger undefined behavior when the underlying USB device ID
driver_info field is 0?
When the id is constructed using IdArray::new_without_index() or when
dynamically added via sysfs new_id with fewer fields, the driver_info is 0.
This probe unconditionally expects a valid non-null reference and creates
one even for 0-initialized IDs via info_unchecked().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=7
^ permalink raw reply
* Re: [PATCH 05/10] rust: driver: centralize device ID handling
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, ojeda, robh, conor+dt, linux-pci, devicetree,
Alexandre Courbot, dri-devel
In-Reply-To: <20260618-id_info-v1-5-96af1e559ef9@garyguo.net>
> Move the `IdArray` creation from individual buses to be handled by shared
> code in `device_id.rs`.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=5
^ permalink raw reply
* Re: [PATCH 04/10] rust: net/phy: remove expansion from doc
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: robh, devicetree, Alexandre Courbot, linux-pci, dri-devel,
conor+dt, Danilo Krummrich, ojeda
In-Reply-To: <20260618-id_info-v1-4-96af1e559ef9@garyguo.net>
> The expansion serves little purpose and it can easily diverge.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=4
^ permalink raw reply
* Re: [PATCH 08/10] rust: driver: remove open-coded matching logic
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Alexandre Courbot, linux-pci, devicetree, robh, Danilo Krummrich,
conor+dt, dri-devel, ojeda
In-Reply-To: <20260618-id_info-v1-8-96af1e559ef9@garyguo.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing `#[inline]` annotation on `id_info`.
- [Low] Leftover FFI wrapper `acpi_of_match_device` and its backing C helpers are unused.
--
commit 8ad64c5f4617fb456cb113763d7136737e7f51e2
Author: Gary Guo <gary@garyguo.net>
rust: driver: remove open-coded matching logic
This commit replaces the open-coded ACPI and OF matching logic with a single
call to device_get_match_data(), as device ID info now includes pointers
instead of indices.
> diff --git a/rust/kernel/driver.rs b/rust/kernel/driver.rs
> index 824899d76fed2..a881f5ef99ecf 100644
> --- a/rust/kernel/driver.rs
> +++ b/rust/kernel/driver.rs
[ ... ]
> @@ -325,117 +324,22 @@ pub trait Adapter {
[ ... ]
> - #[cfg(CONFIG_ACPI)]
> - {
> - use core::ptr;
> - use device::property::FwNode;
> -
> - let mut raw_id = ptr::null();
> -
> - let fwnode = dev.fwnode().map_or(ptr::null_mut(), FwNode::as_raw);
> -
> - // SAFETY: `fwnode` is a pointer to a valid `fwnode_handle`. A null pointer will be
> - // passed through the function.
> - let adev = unsafe { bindings::to_acpi_device_node(fwnode) };
> -
> - // SAFETY:
> - // - `adev` is a valid pointer to `acpi_device` or is null. It is guaranteed to be
> - // valid as long as `dev` is alive.
> - // - `table` has static lifetime, hence it's valid for read.
> - if unsafe { acpi_of_match_device(adev, table.as_ptr(), &raw mut raw_id) } {
[Severity: Low]
Since the manual ACPI matching is being removed here, are the FFI wrapper
acpi_of_match_device() and its backing C helpers (such as
rust_helper_acpi_of_match_device() and rust_helper_to_acpi_device_node()
in rust/helpers/acpi.c) now completely unused? Should they be removed
in this patch to avoid leaving dead code behind?
[ ... ]
> - fn id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> {
> - let id = Self::acpi_id_info(dev);
> - if id.is_some() {
> - return id;
> - }
> -
> - let id = Self::of_id_info(dev);
> - if id.is_some() {
> - return id;
> - }
> + ///
> + /// # Safety
> + ///
> + /// The caller must ensure that the `dev` matched data is of type `Self::IdInfo`.
> + unsafe fn id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> {
> + // SAFETY: `dev` is guaranteed to be valid while it's alive, and so is `dev.as_raw()`.
> + let data = unsafe { bindings::device_get_match_data(dev.as_raw()) };
[Severity: Low]
This isn't a bug, but according to the Rust subsystem coding guidelines,
functions in abstractions that are small or simply forward to a binding
call should be annotated with #[inline]. Since this function consists of a
single FFI call and a cast, should an #[inline] annotation be added here?
>
> - None
> + // SAFETY: Per safety requirement, `data` is of type `Self::IdInfo`.
> + unsafe { data.cast::<Self::IdInfo>().as_ref() }
> }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=8
^ permalink raw reply
* Re: [PATCH 09/10] rust: driver: remove duplicate ID table
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, conor+dt, dri-devel, linux-pci,
Alexandre Courbot, ojeda, robh, devicetree
In-Reply-To: <20260618-id_info-v1-9-96af1e559ef9@garyguo.net>
> Previously, `IdArray` contains both device ID table and info table so we
> keep a separate copy for MODULE_DEVICE_TABLE for hotplug (which needs to be
> just the device ID table). With the info being changed to be carried via
> pointers, `IdArray` is now layout compatible with raw ID table and hence
> there is no longer a need to keep the distinction.
>
> Deduplicate the code, and remove the redundant copy for hotplug purpose by
> just giving the `IdArray` instance a proper symbol name.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=9
^ permalink raw reply
* Re: [PATCH 03/10] rust: pci: use `Option<&IdInfo>` for device ID info
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: ojeda, dri-devel, Danilo Krummrich, conor+dt, linux-pci,
devicetree, robh, Alexandre Courbot
In-Reply-To: <20260618-id_info-v1-3-96af1e559ef9@garyguo.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The dynamic ID matching in the PCI core returns a pointer to a dynamically allocated ID without holding a lock or reference, leading to a Use-After-Free if the ID is concurrently removed via sysfs.
--
commit d1889a1b7c5b08bca9b93c95bb95cf7a983ddfea
Author: Gary Guo <gary@garyguo.net>
rust: pci: use Option<&IdInfo> for device ID info
This commit updates the Rust PCI probe functions to accept an Option<&IdInfo>
instead of a direct reference. This allows the driver to handle situations
where the driver_data is 0, such as when driver_override is used.
[ ... ]
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index 5071cae6543fd..0e055e4df99ee 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
> @@ -113,7 +113,7 @@ extern "C" fn probe_callback(
> let info = T::ID_TABLE.info(id.index());
>
> from_result(|| {
> - let data = T::probe(pdev, info);
> + let data = T::probe(pdev, Some(info));
[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing
Use-After-Free in the C PCI core that impacts this callback.
In the C subsystem, pci_match_device() searches for dynamic IDs under
drv->dynids.lock and returns a pointer to the interior of dynid after
dropping the lock:
drivers/pci/pci-driver.c:pci_match_device() {
...
found_id = &dynid->id;
break;
}
}
spin_unlock(&drv->dynids.lock);
if (found_id)
return found_id;
}
Concurrently, if a user removes the ID via sysfs, remove_id_store() frees
it unconditionally:
drivers/pci/pci-driver.c:remove_id_store() {
...
list_del(&dynid->node);
kfree(dynid);
}
When local_pci_probe() calls the driver's probe callback, it passes this
potentially dangling id pointer. Since the Rust probe_callback() receives
this pointer from C, will dereferencing it (such as when calling id.index()
just above this change) trigger a Use-After-Free crash?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=3
^ permalink raw reply
* Re: [PATCH 10/10] RFC: rust: driver: support map-like syntax for ID table
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: robh, dri-devel, conor+dt, ojeda, linux-pci, Danilo Krummrich,
Alexandre Courbot, devicetree
In-Reply-To: <20260618-id_info-v1-10-96af1e559ef9@garyguo.net>
> The device ID table and its associated info is really just a map. Add a
> syntax to `module_device_table` macro that reflects that.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=10
^ permalink raw reply
* Re: [PATCH 02/10] rust: driver: simplify `IdArray::new_without_index`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: devicetree, linux-pci, Alexandre Courbot, robh, ojeda, dri-devel,
Danilo Krummrich, conor+dt
In-Reply-To: <20260618-id_info-v1-2-96af1e559ef9@garyguo.net>
> This method can very easily construct the `IdArray` on its own without
> delegating to `Self::build`. Doing so also simplifies the phy device table
> macro because it does not need to construct tuples anymore.
>
> This also allows simplification of `new` and `build` which removes the
> `unsafe`.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=2
^ permalink raw reply
* Re: [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Eric Biggers @ 2026-06-19 16:45 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Andy Gross, Harshal Dev, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <53b1fa61-9692-42fd-a295-98bbeacbcd9a@oss.qualcomm.com>
On Fri, Jun 19, 2026 at 02:13:28PM +0530, Kuldeep Singh wrote:
> On 21-05-2026 18:47, Kuldeep Singh wrote:
> > This patchseries attempt to enable sdhc-ice, rng and qce on shikra
> > platform similar to other platforms.
> >
> > Previously, the 3 dt-bindigs/DT changes were sent as individual series
> > and with feedback received, clubbed them together as all belong to same
> > crypto subsystem.
> >
> > Here's link to old patchsets.
> > QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
>
> Hi Eric,
>
> As selftests issues for QCE are now fixed[1], so shikra series should be
> good to proceed? as your concerns[2] are now addressed.
> I am waiting for merge window to end and will send next rev post that.
>
> [1]
> https://lore.kernel.org/linux-arm-msm/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com/
> [2] https://lore.kernel.org/lkml/20260522024912.GC5937@quark/
If you think that then it sounds like you need to read what I actually
said. The fixes are appreciated but don't change the big picture.
- Eric
^ permalink raw reply
* Re: [PATCH RFC 3/3] dt-bindings: iio: adc: Add burn-out current properties
From: Kurt Borja @ 2026-06-19 16:46 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <0831356f-76ff-4eed-befa-7a35ffce921d@baylibre.com>
On Fri Jun 19, 2026 at 9:28 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Some ADCs incorporate burn-out current sources that provide current to
>> the channel's input pins for open-circuit or short-circuit detection.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index 106b1e317411d5..6b63aac9ac04dd 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -106,6 +106,20 @@ properties:
>> This array describes the current configuration of the excitation current
>> sources or the single matched current for all sources.
>>
>> + burn-out-current-microamp:
>> + description:
>> + Burn-out current sources provide current to the channel's input pins for
>> + open-circuit or short-circuit detection.
>> +
>> + burn-out-current-polarity:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + Burn-out current sources provide current to the channel's input pins for
>> + open-circuit or short-circuit detection.
>> + enum:
>> + - pull-up
>> + - pull-down
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
>
> This doesn't really work with chips that just have and enable bit to
> enable or disable the feature.
Maybe those devices can use burn-out-current-microamp with a const
value? Is that okay or should another approach be taken?
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 2/3] dt-bindings: iio: adc: Add excitation current sources properties
From: Kurt Borja @ 2026-06-19 16:44 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <073b0a89-65af-4a21-837d-851d35e3e294@baylibre.com>
On Fri Jun 19, 2026 at 9:27 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Some ADCs incorporate current sources that provide excitation current to
>> resistive temperature devices (RTDs), thermistors diodes and other
>> resistive sensors that require constant current biasing.
>>
>> The maxItems constraint of 16 is arbitrary but should be big enough for
>> most devices.
>
> I wouldn't put an arbitrary limit here. The bindings that include it
> can extend it to add a limit that makes sense instead.
I agree.
This was partly a misunderstanding. I thought -microamp properties fall
back to uint32 not uint32-array but it's the other way around right?
>
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index c74c2084fdb68c..106b1e317411d5 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -83,6 +83,29 @@ properties:
>> This array describes either a single reference source or a positive and
>> negative reference sources.
>>
>> + excitation-channels:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + maxItems: 16
>> + minItems: 1
>> + description:
>> + Excitation current sources provide current to resistive temperature
>> + devices (RTDs), thermistors diodes and other resistive sensors that
>> + require constant current biasing.
>> +
>> + This array describes the mux configuration of the excitation current
>> + sources.
>> +
>> + excitation-current-microamp:
>> + maxItems: 16
>> + minItems: 1
>> + description:
>> + Excitation current sources provide current to resistive temperature
>> + devices (RTDs), thermistors diodes and other resistive sensors that
>> + require constant current biasing.
>> +
>> + This array describes the current configuration of the excitation current
>> + sources or the single matched current for all sources.
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 1/3] dt-bindings: iio: adc: Add reference-source property
From: Kurt Borja @ 2026-06-19 16:42 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <736962f9-50b9-4884-88b1-94bfd7cd8abf@baylibre.com>
On Fri Jun 19, 2026 at 9:24 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Some ADCs have configurable voltage reference sources for each channel.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index b9bc02b5b07a4c..c74c2084fdb68c 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -73,6 +73,16 @@ properties:
>> device design and can interact with other characteristics such as
>> settling time.
>>
>> + reference-source:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + maxItems: 2
>> + minItems: 1
>> + description:
>> + Indicates the voltage reference source or sources for this channel.
>> +
>> + This array describes either a single reference source or a positive and
>> + negative reference sources.
>
> Do you actually know of any devices that allow independently selecting
> the positive and negative sources? I don't think I've ever seen anything
> like that.
The ADS1262 allows it, check the REFMUX register. Only ADC1 allows it
though, ADC2 has a single reference select.
Maybe I can get away with only one for both ADCs without restricting too
much.
> Also, this should be string, not uint32.
Sure!
>
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-19 16:35 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <7b93cd3a-8aae-494a-a0fa-540bafcbccaf@baylibre.com>
On Fri Jun 19, 2026 at 9:23 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Hi all,
>>
>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>> I was made aware by David [2] that at least two more chip families,
>> ads1220 [3] and ads1x2c14, share very similar features (though these
>> chips are not really compatible between them). After that, I found one
>> more chip with the same features which is already upstream, the
>> AD4170-4.
>>
>> As David explained in [2], these chips are intended to be used with
>> RTDs, thermocouples or other resistive sensors so they share the
>> following per-channel features:
>>
>> - Configurable reference selection
>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>> - Excitation current sources (usually called IDACs TI) for sensor
>> current biasing
>>
>> Given that these three features are present in all four devices and
>> three of these drivers are still under review, my proposal is to have
>> these features be described in adc.yaml and have this series merged
>> before the three others [1] [2] [3].
>>
>> This series is sent as RFC because I still don't have much experience
>> with dt-bindings and I don't know if this approach or the properties are
>> general enough to be described like this.
>
> Generally, we don't propose bindings without users in the same series.
> I was going to wait to see what feedback Jonathan gave on my series
> before proposing this.
Makes sense. In this case I think it would be useful for the three
series to have this first, but not up to me.
>
>>
>> No dependencies between properties were provided because not all devices
>> may be able to configure each one of them.
>>
>> [1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
>> [2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
>> [3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Kurt Borja (3):
>> dt-bindings: iio: adc: Add reference-source property
>> dt-bindings: iio: adc: Add excitation current sources properties
>> dt-bindings: iio: adc: Add burn-out current properties
>>
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 47 ++++++++++++++++++++++
>> 1 file changed, 47 insertions(+)
>> ---
>> base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
>> change-id: 20260618-new-channel-props-4fbd52020da2
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 1/3] dt-bindings: iio: adc: Add reference-source property
From: Kurt Borja @ 2026-06-19 16:30 UTC (permalink / raw)
To: Conor Dooley, Kurt Borja
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260619-proton-distract-de92d6b9b600@spud>
Hi Conor,
On Fri Jun 19, 2026 at 9:14 AM -05, Conor Dooley wrote:
> On Thu, Jun 18, 2026 at 07:33:01PM -0500, Kurt Borja wrote:
>> Some ADCs have configurable voltage reference sources for each channel.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index b9bc02b5b07a4c..c74c2084fdb68c 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -73,6 +73,16 @@ properties:
>> device design and can interact with other characteristics such as
>> settling time.
>>
>> + reference-source:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + maxItems: 2
>> + minItems: 1
>> + description:
>> + Indicates the voltage reference source or sources for this channel.
>> +
>> + This array describes either a single reference source or a positive and
>> + negative reference sources.
>
> I have no idea from this description what this actually refers to. Is it
> a pin? A supply? A channel?
It can be pins but also can be internal vref sources. Not always a
supply though, in some applications a resistor is connected to the
reference source pins.
If there is a next version I'll clarify it.
>
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
>> --
>> 2.54.0
>>
--
Thanks,
~ Kurt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox