* [PATCH 00/19] crypto: cmh - add CRI CryptoManager Hub driver
From: Saravanakrishnan Krishnamoorthy @ 2026-06-25 17:33 UTC (permalink / raw)
To: Albert Ou, Alex Ousherovitch, Conor Dooley, David S. Miller,
Herbert Xu, Jonathan Corbet, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Saravanakrishnan Krishnamoorthy,
Shuah Khan
Cc: Alexandre Ghiti, devicetree, Joel Wittenauer, linux-api,
linux-crypto, linux-doc, linux-kernel, linux-kselftest,
linux-riscv, Shuah Khan, sipsupport, Thi Nguyen
From: Alex Ousherovitch <aousherovitch@rambus.com>
crypto: cmh - add CRI CryptoManager Hub hardware crypto accelerator
This series adds a driver for the CRI CryptoManager Hub (CMH), a
hardware cryptographic accelerator IP from Cryptography Research at
Rambus Inc. (https://www.rambus.com/cryptographyresearch/).
CMH provides a broad set of symmetric, asymmetric, and post-quantum
cryptographic algorithms accelerated in hardware, accessed via a
mailbox-based Virtual Command Queue (VCQ) interface.
The hardware is a platform device matched via device tree
(compatible = "cri,cmh"). It exposes a single MMIO register region
(SIC) with per-mailbox doorbell, status, and command registers.
Each mailbox has DMA-coherent queue memory for VCQ command
submission and completion.
Driver architecture:
In-kernel users /dev/cmh_mgmt (ioctl)
(dm-crypt, IPsec, kTLS, fscrypt) (key management)
| |
v v
+----------------------------------------------------+
| Kernel Crypto API + hwrng (72 total) |
| ahash | skcipher | aead | akcipher | sig | kpp |
+----------------------------------------------------+
| |
v v
+------------------+ +------------------------+
| Transaction Mgr |--->| Key / Mgmt subsystem |
| (kthread, CMQ) | | (datastore, ioctl ops) |
+------------------+ +------------------------+
|
v
+------------------+ +-------------------+
| MQI (VCQ pack, |---->| Response Handler |
| DMA map, submit)| | (threaded IRQ, |
+------------------+ | watchdog, unmap) |
| +-------------------+
v ^
+-----------+ +-----------+
| Hardware |--- IRQ ----->| Hardware |
| (mailbox) | | (mailbox) |
+-----------+ +-----------+
The transaction manager runs as a dedicated kthread that pulls
requests from a central command queue, packs VCQ entries, maps DMA
buffers, and submits to the least-loaded mailbox. Completion is
handled by per-mailbox threaded IRQs. The driver returns
-EINPROGRESS for async crypto requests and supports the
CRYPTO_TFM_REQ_MAY_BACKLOG flag for queue-full backpressure.
Registered algorithms (72 total):
Type Count Algorithms
--------- ----- --------------------------------------------------
ahash 15 SHA-{224,256,384,512}, SHA3-{224,256,384,512},
SHAKE-{128,256}, cSHAKE-{128,256},
KMAC-{128,256}, SM3
ahash(HMAC) 8 HMAC-SHA-{224,256,384,512},
HMAC-SHA3-{224,256,384,512}
ahash(MAC) 4 CMAC(AES), CMAC(SM4), XCBC(SM4), Poly1305
skcipher 11 AES-{ECB,CBC,CTR,CFB,XTS},
SM4-{ECB,CBC,CTR,CFB,XTS}, ChaCha20
aead 6 AES-{GCM,CCM}, SM4-{GCM,CCM},
rfc7539(chacha20,poly1305),
rfc7539esp(chacha20,poly1305)
akcipher 1 RSA (2048--4096 bit; 512/1024 legacy/test)
sig 23 ECDSA P-{256,384,521}, SM2 (verify-only),
ML-DSA-{44,65,87},
SLH-DSA (12 parameter sets),
LMS, LMS-HSS, XMSS, XMSS-MT
kpp 3 ECDH P-{256,384}, X25519
hwrng 1 DRBG-backed /dev/hwrng
Ioctl-only algorithms (not registered with the crypto API at all):
- EdDSA (Ed25519, Ed448): sign and verify
- ML-KEM (ML-KEM-512/768/1024): no standard kernel KEM API exists
The driver also exposes /dev/cmh_mgmt, a misc device providing 44
ioctl commands. Relative to the in-kernel crypto API these fall into
two groups; the distinction matters because some commands name the
same primitives the driver also registers, and that overlap is
deliberate and bounded:
(1) Operations with no crypto API representation - the large
majority. The crypto API has no transform type or verb for
these, so a character device is the only available UAPI:
- hardware key lifecycle: create, import, export, derive,
destroy, enumerate (keystore CRUD) - no keystore verb
- KIC key derivation (HKDF, AES-CMAC-KDF, DKEK)
- asymmetric key generation (RSA, EC, EdDSA, ML-DSA, SLH-DSA)
and public-key derivation - the crypto API has no keygen verb
- ML-KEM encapsulate/decapsulate - no kernel KEM API exists
- SM2 encrypt/decrypt and key exchange (multi-step GM/T 0003)
- EdDSA sign/verify - not registered with the crypto API
- EAC Chip Authentication and DRBG (re)configuration
(2) Hardware-held-key operations on algorithms that ARE also
registered (RSA decrypt, ECDSA/ML-DSA/SLH-DSA sign, ECDH). These
name the same primitives as the registered akcipher/sig/kpp
transforms, but the crypto API's set_priv_key()/set_secret()
accept only raw key bytes supplied by the caller; they cannot
reference a private key that is generated inside, and never
leaves, the hardware datastore - the central security property of
this device. The ioctl path keeps the private key
hardware-resident, while the registered transforms serve raw-key
in-kernel users. The two paths are complementary, not redundant.
The device requires CAP_SYS_ADMIN.
/dev/cmh_mgmt is built conditionally on CONFIG_CRYPTO_DEV_CMH_MGMT
(default n); when disabled the ioctl interface is absent while all
kernel crypto API algorithms remain registered.
The ML-DSA sig algorithms are registered at priority 5001. The
kernel's crypto/mldsa.c registers at priority 5000 with verify-only
(sign returns -EOPNOTSUPP). Our driver provides full HW-accelerated
sign + verify, so the higher priority ensures the hardware
implementation is preferred when the driver is loaded.
Power management uses DEFINE_SIMPLE_DEV_PM_OPS. On suspend the
transaction manager drains in-flight requests (configurable 10s
timeout, returns -ECANCELED on timeout), stops the kthread, and
masks IRQs. On resume it re-verifies SIC/boot status and restarts
the kthread.
Dependencies:
- Kernel 7.1+ (based on Herbert Xu's cryptodev-2.6 tree, 7.1.0-rc2)
- sig_alg backend (upstream since 6.13)
- CRYPTO_AHASH_REQ_VIRT (native support, no fallback needed)
- CMH eSW loaded independently by hardware before driver probe
The driver registers all algorithms through the standard in-kernel
crypto API; in-kernel users (dm-crypt, fscrypt, IPsec, etc.) consume
them directly. Key provisioning and hardware-held-key operations are
exposed to user space via /dev/cmh_mgmt ioctls.
Public hardware documentation:
Product brief: https://go.rambus.com/ch-7xx-and-cc-7xx-product-brief
No public datasheets are currently available. The driver was
developed against the CRI CryptoManager Hub Hardware Reference
Manual (Rambus Inc. confidential). Detailed hardware reference is
available under NDA from Rambus Inc.; contact the maintainers listed
in MAINTAINERS for access during review.
Tested on RISC-V and ARM64 QEMU emulation with the CMH hardware
model (QEMU TCG, 512 MiB RAM). Also exercised on Xilinx VMK180
FPGA board with real CMH IP.
- testmgr: 41 CMH algorithm registrations matched by upstream
test vectors, all pass; 30 names report "No test for" (PQC
families, KMAC, cSHAKE - no upstream vectors yet).
- kselftest tools/testing/selftests/drivers/crypto/cmh:
6 pass, 0 fail.
checkpatch.pl --strict: 0 errors, 0 warnings, 0 checks on all
files (the only output is the expected per-file "does MAINTAINERS
need updating?" reminder, satisfied by the MAINTAINERS patch).
sparse (C=2): 0 warnings.
W=1 -Werror: clean.
make dt_binding_check: clean (dtschema validates the
cri,cmh.yaml binding).
Tested with the following debug options enabled simultaneously
(submit-checklist "Test your code" item 1):
CONFIG_PROVE_LOCKING, CONFIG_PROVE_RCU, CONFIG_DEBUG_LOCK_ALLOC,
CONFIG_DEBUG_OBJECTS_RCU_HEAD, CONFIG_SLUB_DEBUG,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_ATOMIC_SLEEP.
Result: no lockdep warnings, no ODEBUG splats, no slab corruption.
Additionally tested (separate passes - mutually exclusive configs):
- CONFIG_KASAN + CONFIG_UBSAN + CONFIG_DEBUG_KMEMLEAK + CONFIG_KFENCE:
no sanitizer findings; KMEMLEAK scan reports 0 unreferenced objects.
- CONFIG_KCSAN (arm64; riscv64 lacks HAVE_ARCH_KCSAN):
0 data-race reports attributed to the driver.
Stack usage: worst-case under 1 KB on both riscv64 and arm64
(scripts/checkstack.pl). Hardware command buffers live in
per-request context (heap-allocated by the crypto framework).
Alex Ousherovitch (19):
dt-bindings: crypto: add Rambus CryptoManager Hub
crypto: cmh - add core platform driver
crypto: cmh - add key provisioning and management
crypto: cmh - add SHA-2/SHA-3/SHAKE ahash
crypto: cmh - add HMAC ahash
crypto: cmh - add CSHAKE/KMAC ahash
crypto: cmh - add SM3 ahash
crypto: cmh - add AES skcipher/aead/cmac
crypto: cmh - add SM4 skcipher/aead/cmac/xcbc
crypto: cmh - add ChaCha20-Poly1305
crypto: cmh - add DRBG hwrng
crypto: cmh - add RSA akcipher
crypto: cmh - add ECDSA/SM2 sig
crypto: cmh - add ECDH/X25519 kpp
crypto: cmh - add ML-KEM/ML-DSA (QSE)
crypto: cmh - add SLH-DSA/LMS/XMSS (HCQ)
Documentation: ioctl: add CMH ioctl documentation and register 'J'
selftests: crypto: cmh - add kselftest for management ioctl
MAINTAINERS: add Rambus CryptoManager Hub (CMH)
base-commit: 6ea0ce3a19f9c37a014099e2b0a46b27fa164564
--
2.43.7
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: display: bridge: Document Renesas RZ/G3L LVDS encoder
From: Biju @ 2026-06-25 17:23 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Luca Ceresoli, Tommaso Merciai, dri-devel, devicetree,
linux-kernel, linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das,
Krzysztof Kozlowski
In-Reply-To: <20260625172359.292631-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Document the LVDS encoder IP found on the RZ/G3L SoC. It supports
single-link mode. LVDS and the DSI interface share a peripheral clock and
the MIPI_DSI_PRESET_N reset signal. However, the LVDS module cannot be
used at the same time as MIPI-DSI.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v4->v5:
* Collected tag.
v3->v4:
* Dropped the tags as it is a rework dropping parent node that contains
simple-mfd and syscon.
v2->v3:
* Collected tag.
v2->v2[1]:
* No change.
[1] https://lore.kernel.org/all/20260524195829.960401F000E9@smtp.kernel.org/
v1->v2:
* Collected tag.
---
.../bridge/renesas,r9a08g046-lvds.yaml | 120 ++++++++++++++++++
1 file changed, 120 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,r9a08g046-lvds.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,r9a08g046-lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,r9a08g046-lvds.yaml
new file mode 100644
index 000000000000..4cd7b688fbf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,r9a08g046-lvds.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/renesas,r9a08g046-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G3L LVDS Encoder
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+ - Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
+
+description: |
+ This binding describes the LVDS encoder embedded in the Renesas RZ/G3L
+ SoC. The encoder can operate in LVDS Single-link mode with 4 lanes
+ (Data) + 1 lane (Clock).
+
+properties:
+ compatible:
+ const: renesas,r9a08g046-lvds
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: PHY clock
+ - description: Dot clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: phyclk
+ - const: dotclk
+
+ resets:
+ items:
+ - description: LVDS_RESET_N
+ - description: MIPI_DSI_PRESET_N
+ - description: MIPI_DSI_CMN_RSTB
+ - description: MIPI_DSI_ARESET_N
+
+ reset-names:
+ items:
+ - const: lvdrst
+ - const: prst
+ - const: rst
+ - const: arst
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input channel, directly connected to the Display Unit.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: |
+ Output channel, directly connected to the LVDS panel or bridge.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a08g046-cpg.h>
+
+ lvds@108a0000 {
+ compatible = "renesas,r9a08g046-lvds";
+ reg = <0x108a0000 0x10000>;
+ clocks = <&cpg CPG_MOD R9A08G046_MIPI_DSI_PCLK>,
+ <&cpg CPG_MOD R9A08G046_LVDS_PLLCLK>,
+ <&cpg CPG_MOD R9A08G046_LVDS_CLK_DOT0>;
+ clock-names = "pclk", "phyclk", "dotclk";
+ resets = <&cpg R9A08G046_LVDS_RESET_N>,
+ <&cpg R9A08G046_MIPI_DSI_PRESET_N>,
+ <&cpg R9A08G046_MIPI_DSI_CMN_RSTB>,
+ <&cpg R9A08G046_MIPI_DSI_ARESET_N>;
+ reset-names = "lvdrst", "prst", "rst", "arst";
+ power-domains = <&cpg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint = <&du_out_lvds0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+...
--
2.43.0
^ permalink raw reply related
* [PATCH v5 0/2] Add support for Renesas RZ/G3L LVDS encoder
From: Biju @ 2026-06-25 17:23 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Simona Vetter, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Luca Ceresoli, Tommaso Merciai, dri-devel, devicetree,
linux-kernel, linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Add support for the RZ/G3L LVDS encoder driver. It operates in single-link
mode with 4 lanes (Data) + 1 lane (Clock) and supports pixel clock rates
from 25 to 87 MHz. The LVDS module cannot be used at the same time as
MIPI-DSI. However, LVDS and the DSI interface share a peripheral clock and
the MIPI_DSI_PRESET_N reset signal. Also, the MIPI_DSI_CMN_RSTB and
MIPI_DSI_ARESET_N reset signals must be asserted before using the LVDS
module.
v4->v5:
* Collected the tags.
* Added Kconfig functional dependency for DRM_RZG2L_DU
* Dropped DRM_PANEL from DRM_RZG3L_LVDS config
* Dropped unused headers of_device.h,of_graph.h and drm_panel.h
* Dropped the unused macro LVDS_CMN_RST_PHY0_SEL_CH0
* Used plain number for macro LVDS_0_PHY_CH_IO_EN0_MSK
* Retained the tag as the above changes are trivial.
v3->v4:
* Reworked bindings, dropping parent node containing simple-mfd and
syson.
* Dropped the tags
* Dropped the header files clk.h and syscon.h
* Dropped next_bridge check in attach().
* Dropped syscon for getting regmap.
* Replaced the below macros to match the hardware manual:
LVDS_0_CTL_FMT_SEL_MSK->LVDS_0_CTL_FMT_SEL0_MSK
LVDS_0_PHY_CH_IO_EN_MSK->LVDS_0_PHY_CH_IO_EN0_MSK
Replaced LVDS_0_PHY_CH_IO_EN->LVDS_0_PHY_CH_IO_EN0
* Replaced atomic_reset()->atomic_create_state().
v2->v3:
* Collected tags.
v2->v2[1]:
* Dropped patch#1 as it is accepted.
* Replace drm_atomic_state with drm_atomic_commit in
rzg3l_lvds_atomic_{en,dis}able().
* Drop local variable ret and dev_err() messages in
rzg3l_lvds_atomic_enable(); use WARN_ON() instead to
capture unexpected failures since atomic_enable should not fail.
* Drop local variable next_bridge from rzg3l_lvds_probe().
[1] https://lore.kernel.org/all/20260524194457.479681-1-biju.das.jz@bp.renesas.com/
v1->v2:
* Collected the tags for binding patches.
* Dropped unused function rzg3l_lvds_is_connected() and removed the
corresponding header file rzg3l_lvds.h
* Dropped next_bridge from struct rzg3l_lvds instead using bridge's
next_bridge.
* Replaced pm_runtime_resume_and_get()->pm_runtime_get_sync() as
atomic_enable doesn't fail and for each enable there always will be an
atomic_disable() call.
* Started using DEFINE_RUNTIME_DEV_PM_OPS for PM callback.
* Replaced rzg3l_lvds_parse_dt() with devm_drm_of_get_bridge() in probe()
* Started using reset_control_bulk_*() in rzg3l_lvds_pm_runtime_{suspend,
resume}().
Biju Das (2):
dt-bindings: display: bridge: Document Renesas RZ/G3L LVDS encoder
drm: renesas: rz-du: Add support for RZ/G3L LVDS encoder
.../bridge/renesas,r9a08g046-lvds.yaml | 120 ++++++++
drivers/gpu/drm/renesas/rz-du/Kconfig | 13 +
drivers/gpu/drm/renesas/rz-du/Makefile | 1 +
drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c | 282 ++++++++++++++++++
.../gpu/drm/renesas/rz-du/rzg3l_lvds_regs.h | 25 ++
5 files changed, 441 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,r9a08g046-lvds.yaml
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg3l_lvds_regs.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Dmitry Torokhov @ 2026-06-25 16:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: David Heidelberg, Krzysztof Kozlowski, Konrad Dybcio, Rob Herring,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <f81e4d83-90d9-47c8-aee9-319df3f8b0fb@kernel.org>
Hi Krzysztof,
On Thu, Jun 25, 2026 at 10:23:54AM +0200, Krzysztof Kozlowski wrote:
> On 25/06/2026 06:53, Dmitry Torokhov wrote:
> > On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
> >> On 24/06/2026 06:28, Dmitry Torokhov wrote:
> >>> Hi David,
> >>>
> >>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
> >>>> On 28/05/2026 00:13, David Heidelberg wrote:
> >>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
> >>>>>> Hi David,
> >>>>>>
> >>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
> >>>>>>> From: David Heidelberg <david@ixit.cz>
> >>>>>>>
> >>>>>>> We know the driver is reporting s3706b, introduce the compatible so we
> >>>>>>> can more easily introduce quirks for weird touchscreen replacements in
> >>>>>>> followup series.
> >>>>>>>
> >>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>>>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
> >>>>>>> ---
> >>>>>>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
> >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>>>>>> b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>>>>>> index 6b7378cf4d493..148164d456a5a 100644
> >>>>>>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> >>>>>>> @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
> >>>>>>> };
> >>>>>>> };
> >>>>>>> &i2c12 {
> >>>>>>> status = "okay";
> >>>>>>> clock-frequency = <400000>;
> >>>>>>> synaptics-rmi4-i2c@20 {
> >>>>>>> - compatible = "syna,rmi4-i2c";
> >>>>>>> + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
> >>>>>>
> >>>>>> So I believe we established that this device (s3706b) does not in fact
> >>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
> >>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
> >>>>>
> >>>>> The vendor supplies s3706b which does implement the RMI4 properly.
> >>>>>
> >>>>> The 3rd party replacement impersonating original parts may not implement
> >>>>> it properly, but I don't address this issue in this initial submission.
> >>>>>
> >>>>> With this compatible we know which original part is used by the vendor
> >>>>> and installed in the phones, so later we can deduct specific sequences
> >>>>> for the replacement aftermarket parts to keep phone touchscreen working
> >>>>> same as they do on Android without affecting other devices.
> >>>>
> >>>> Hello Dmitry.
> >>>>
> >>>> May I ask what is currently preventing this series from moving forward?
> >>>>
> >>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
> >>>> and am now on the 9th iteration (this patchset). At this point, the series
> >>>> has been under discussion for well over a year, with relatively little
> >>>> feedback and increasingly long gaps between review rounds.
> >>>>
> >>>> The current approach is based on the guidance I have received so far,
> >>>> including suggestions from the device-tree maintainers. When concerns were
> >>>> raised, I tried to address them and rework the series accordingly.
> >>>>
> >>>> What I am struggling with is understanding what specific issue still needs
> >>>> to be resolved before these patches can be accepted. If there are remaining
> >>>> requirements, objections to the approach, or technical concerns that I have
> >>>> not addressed, I would appreciate having them stated explicitly so I can
> >>>> work on them.
> >>>>
> >>>> I also split out the straightforward, self-contained changes in the hope
> >>>> that at least those could progress independently while I continued working
> >>>> on any follow-up requirements. However, even those patches do not appear to
> >>>> be moving forward.
> >>>>
> >>>> Could you please clarify what outcome you would like to see from this
> >>>> series, and what concrete changes would be required to get it accepted?
> >>>
> >>> I am still confused about how you want to differentiate between the full
> >>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
> >>> mentioned, implements RMI4 protocol properly, so we do not need to
> >>> actually have it documented neither in binding nor in DTS.
> >>
> >> --- part 1 ---
> >>
> >> This series addresses identification within device-tree. It's normal
> >> recommended practice.
> >>
> >> If we know, the device ships specific, but **compliant** variant, we just
> >> put it as compatible = "more-specific", "less-specific"; in this case
> >> "syna,rmi4-s3706b", "syna,rmi4-i2c"
> >>
> >> This approach is used everywhere. This has nothing to do with after-market parts.
> >
> > We do this in many cases, sometimes when a part has different timings or
> > maybe additional functionality compared to the base model.
>
> Generic expectation is to have always dedicated front compatible for
> every device. rmi4-i2c is not really specific enough, more like a
> family, thus a specific device compatible is essential by the DT rules.
Essential in what way? What will break if such compatible is not there?
We have lived without it for many years and will continue live happily
without it for years to come.
We keep having this conversation each time there is self-describing
protocol that does not require knowledge of a specific part number:
i2c-hid, rmi4, spi-hid coming over soon.
We might need a device-specific compatible if we need to implement
particular power on sequence/adjust timings, and that's when it starts
making sense to introduce one.
>
> It does not matter if that specific compatible is ever used.
>
> >
> > How does this new compatible for controller that fully implements RMI4
> > protocol help here?
>
> It does not matter. This is a different device, thus it needs
> front-specific compatible.
Different from what?
$ git grep syna,rmi4 -- arch/ | wc -l
43
Do you have plans to list each and every chip currently covered by
syna,rmi4* ?
>
> Also, the commit msg actually did mention how this helps: allowing
> further quirks (I did not verify that in practice, but explanation is
> plausible).
Well, the devil is in the details. And that is what I am trying to
understand.
>
> >
> >>
> >> --- part 2 (irrelevant for this series) ---
> >>
> >>>
> >>> The issue you have with after-market parts that are not compliant and we
> >>> need to figure out how to deal with them. Inside the driver I
> >>
> >> As was suggested by device-tree folks, this is the first step, there isn't
> >> better one available. If there is, please suggest one, and I'll apply it.
> >
> > Was it clearly communicated to DT folks that the compatible you are
> > adding is fully compatible with the base "syna,rmi4-i2c" but other ones
> > will not be compatible?
>
> That was not communicated but also did not have to. You can install in
> your board whatever you wish, e.g. replacing foo device with bar being
> something completely different and incompatible. Does not matter really
> if this is after-market or a person just swapped things.
>
> DT does not solve that problem simply, because we describe static
> hardware configuration.
But the core issue that David is trying to solve is the fact that these
headsets do not work well with aftermarket parts with the upstream
kernels. It is not a theoretical problem for him, it is something that
he's been trying to solve for a while.
However from my POV I need to make sure the changes to the driver do not
affect or limit well-behaved devices implementing RMI4 protocol
properly.
>
> >
> >>
> >>> essentially need a"incomplete protocol" flag that we can use to
> >>> implement additional checks or skip known to be not implemented
> >>> functions/queries. In DT we could introduce something like
> >>> "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
> >>> and neither one should be a fallback for the other.
> >>>
> >>> This of course needs buy-in from DT maintainers.
> >>
> >> As you can see, this still holds Acked-by and Reviewed-by from the relevant
> >> people - Krzysztof and Konrad.
> >
> > I see that but the commit does not explain how exactly you are planning
> > to deal with knockoffs.
>
> I think it does not have to. David does not need to solve all possible
> problems. He is solving his problems and not preventing the other
> problems to be solved in the future. Unless you expect that the second
> part - future problems - will be blocked by this code.
Well, as I mentioned above my understanding is that David really wants
to solve the issue with after market parts not working properly.
>
> But then I think no one ever solved in DT a problem of replacement of
> valid parts with after-market incompatible parts. Therefore I do not
> even know what solution I could suggest to David.
>
> >
> >>
> >>>
> >>> Does this make sense?
> >>
> >> For the scope we're discussing it doesn't seems so.
> >>
> >> This discussion should be associated with the last revision of the full
> >> series I sent 3 months ago. We're in very unflattering state, where:
> >>
> >> 2018 - these aftermarket touchscreen worked on Android well enough for
> >> people to have working touch (let's say with slightly worse experience then
> >> the original).
> >>
> >> 2026 in the mainline, we cannot even more forward and report to user-space
> >> there is aftermarket non-compliant piece of hardware installed.
> >>
> >> Actionable steps I suggest after this series lands:
> >>
> >> 1. don't do any changes, but since we know what 3rd party touchscreen do
> >> incorrectly deviating from the standard, REPORT it to the userspace, so USER
> >> know, their device (phone/tablet) doesn't have original part.
> >>
> >> 2. then figure out, IF we can reasonably well workaround it and HOW to do it
> >>
> >> These two steps present some progress which could be discussed and could
> >> lead us somewhere, what do you think?
> >
> > So since we know that these devices can come with controllers that do
> > not implement RMI4 fully, can we:
> >
> > 1. Establish a new compatible that is separate from syna,rmi4-i2c? As I
> > mentioned, it could be oneplus,rmi4-i2c or event a concrete controller
> > vendor,id combo. The point that it should be completely separate from
> > the current compatible and not use the current compatible as a fallback.
>
> Board/machine level compatible already gives you that.
> after-market-incompatible-parts is not a problem of this s3706b, if I
> understood correctly. It feels to me more of a problem of the board:
> people install into this board some incompatible replacement parts.
So is the suggestion to check if the board matches "oneplus,enchilada",
"oneplus,fajitas" with of_machine_compatible_match()?
>
> I would understand that this is not a board/machine level problem, if
> multiple different boards with s3706b were affected. Is this the case?
David?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: mt8516/mt8167: Move compatibles from mt66xx to mt6795
From: Luca Leonardo Scorcia @ 2026-06-25 16:47 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-mediatek, Sean Wang, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260625-cameo-siamese-cd78c349519c@spud>
Hi,
> I've not done a very through analysis, but this seems like a massive ABI
> break.
> The change you're trying to make here will mean that new kernels will
> not work with older devicetrees AFAICT.
Correct, that's the reason I sent it as an RFC (I mentioned this in
the cover letter). I am new to kernel work and I'm not sure how to
deal with this change. On one hand I am almost certain now that the
upstream driver has never been used in actual devices, since the older
code was only partially merged and also, as Sashiko correctly pointed
out in [1], it had serious errors when matched against the data sheet:
Sashiko:
> Does this configuration cause a regression in pin multiplexing across the SoC?
> The legacy driver used a 4-bit shift per pin to pack 5 pins per 32-bit
> register. By passing 3 as the width here, the framework calculates mode
> offsets using 3 bits per pin. This causes pinmux writes to align with
> the wrong bits and can overwrite the configurations of adjacent pins.
Data sheet here clearly shows 3 bits per pin are used to choose the
pin function.
On the other hand I know that breaking the ABI is a big no. But what
would be an appropriate solution? Maybe duplicating the driver with a
different name, something like mediatek,mt8167-pinctrl-v2? Is there
another driver I could have a look at to learn how to approach this
problem?
Sashiko also pointed out some other minor issues with the register
maps I already fixed locally after confirming with the data sheet, but
did not provide clues about how to solve the ABI breakage.
[1] https://sashiko.dev/#/message/20260625111629.6CD701F000E9%40smtp.kernel.org
Thank you for your time!
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH v2] spi: dt-bindings: microchip,pic32mzda-sqi: Convert to DT schema
From: Conor Dooley @ 2026-06-25 16:34 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-spi,
devicetree, linux-kernel
In-Reply-To: <20260625060903.14661-1-challauday369@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor
From: Conor Dooley @ 2026-06-25 16:34 UTC (permalink / raw)
To: hehuan1
Cc: linux, robh, krzk+dt, conor+dt, p.zabel, linux-hwmon, devicetree,
linux-kernel, ningyu, linmin, pinkesh.vaghela, luyulin,
dongxuyang
In-Reply-To: <20260625061147.1631-1-hehuan1@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-25 16:33 UTC (permalink / raw)
To: Joey Lu
Cc: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625094449.708386-2-a0987203069@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]
On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> The verisilicon,dc binding was originally written for the T-Head TH1520
> SoC carrying a DC8200, and hard-codes five clocks, three resets and two
> output ports.
>
> Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the binding.
> The DCUltraLite uses only two clocks (core, pix0) and one reset (core),
> with a single output port.
>
> Use allOf/if blocks to express per-variant constraints rather than
> hard-coding the DC8200 topology at the top level. Each compatible's
> block constrains the clock and reset item counts; the nuvoton block
> additionally overrides clock-names to the two names it actually uses.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../bindings/display/verisilicon,dc.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> index 9dc35ab973f2..1e751f3c7ce8 100644
> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> @@ -17,6 +17,7 @@ properties:
> items:
> - enum:
> - thead,th1520-dc8200
> + - nuvoton,ma35d1-dcu
> - const: verisilicon,dc # DC IPs have discoverable ID/revision registers
>
> reg:
> @@ -77,6 +78,62 @@ required:
> - clock-names
> - ports
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: thead,th1520-dc8200
> + then:
> + properties:
> + clocks:
> + minItems: 5
> + maxItems: 5
> +
> + clock-names:
> + minItems: 5
> + maxItems: 5
All the maxItems here repeat the maximum constraint and do nothing.
Since you didn't change the minimum constraint at the top level, your
minItems also do nothing.
> +
> + resets:
> + minItems: 3
> + maxItems: 3
> +
> + reset-names:
> + minItems: 3
> + maxItems: 3
> +
> + required:
> + - resets
> + - reset-names
Both conditional sections have this, but the original binding doesn't
require these for the thead device. This is a functional change
therefore and shouldn't be in a patch calling itself "generalise for
single ended variants".
FWIW, adding your new compatible shouldn't really be in a patch with
that subject either, it really should say "add support for nuvoton
ma35d1" or something.
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nuvoton,ma35d1-dcu
> + then:
> + properties:
> + clocks:
> + minItems: 2
Anything that updates the minimum constraint should be done at the top
level of this schema. The conditional section should then tighten the
constraint, in this case that means only having maxItems.
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: core
> + - const: pix0
Does this even work when the top level schema thinks clock 2 should be
called axi?
> +
> + resets:
> + minItems: 1
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: core
This is just maxItems: 1.
pw-bot: changes-requested
Thanks,
Conor.
> +
> + required:
> + - resets
> + - reset-names
> +
> additionalProperties: false
>
> examples:
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: mt8516/mt8167: Move compatibles from mt66xx to mt6795
From: Conor Dooley @ 2026-06-25 16:28 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Sean Wang, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260625104742.113803-2-l.scorcia@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
On Thu, Jun 25, 2026 at 12:46:30PM +0200, Luca Leonardo Scorcia wrote:
> Pinctrl settings for MediaTek mt8516-mt8167 SoCs use two reg base
> addresses, one for GPIO and the other for EINT, as it is common in the
> "Paris" pinctrl platform that is described in the MediaTek mt6795 docs.
>
> Move the binding compatible for these two SoCs from mt66xx to the mt6796
> one as a prerequisite for migrating the pinctrl driver to the
> pinctrl-paris platform.
I've not done a very through analysis, but this seems like a massive ABI
break.
The change you're trying to make here will mean that new kernels will
not work with older devicetrees AFAICT.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml | 2 --
> .../devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml | 5 ++++-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> index 1468c6f87cfa..0cff2a352b1f 100644
> --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> @@ -22,9 +22,7 @@ properties:
> - mediatek,mt7623-pinctrl
> - mediatek,mt8127-pinctrl
> - mediatek,mt8135-pinctrl
> - - mediatek,mt8167-pinctrl
> - mediatek,mt8173-pinctrl
> - - mediatek,mt8516-pinctrl
>
> reg:
> maxItems: 1
> diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
> index 9a937f414cc9..c703de72e1d5 100644
> --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
> @@ -15,7 +15,10 @@ description:
>
> properties:
> compatible:
> - const: mediatek,mt6795-pinctrl
> + enum:
> + - mediatek,mt6795-pinctrl
> + - mediatek,mt8167-pinctrl
> + - mediatek,mt8516-pinctrl
>
> gpio-controller: true
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
From: Conor Dooley @ 2026-06-25 16:24 UTC (permalink / raw)
To: Chi-Wen Weng
Cc: jic23, robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy,
linux-arm-kernel, linux-iio, devicetree, linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-2-cwweng.linux@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
On Thu, Jun 25, 2026 at 07:06:37PM +0800, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
>
> Add devicetree binding for the Enhanced ADC controller found on
> Nuvoton MA35D1 SoCs.
>
> The controller has one register region, one interrupt and one functional
> clock. ADC inputs are described using standard channel child nodes,
> including optional differential channel pairs.
>
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: ti: Add bindings for PHYTEC AM67x based hardware
From: Conor Dooley @ 2026-06-25 16:22 UTC (permalink / raw)
To: Nathan Morrisson
Cc: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <20260625160214.4001298-1-nmorrisson@phytec.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: xlnx,axi-dma: Restore xlnx,flush-fsync as u32
From: Conor Dooley @ 2026-06-25 16:21 UTC (permalink / raw)
To: Suraj Gupta
Cc: vkoul, Frank.Li, robh, krzk+dt, conor+dt, michal.simek,
radhey.shyam.pandey, dmaengine, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625161016.1249570-1-suraj.gupta2@amd.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: sashiko-bot @ 2026-06-25 16:21 UTC (permalink / raw)
To: Flaviu Nistor; +Cc: linux-hwmon, robh, conor+dt, devicetree
In-Reply-To: <20260625160423.17882-1-flaviu.nistor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The threaded interrupt handlers modify alarm state flags without locking, creating a race condition with sysfs reads that can result in lost alarm events.
--
commit 7c977021bab8a6a8bb249ac3b4ad711dbe88c4ff
Author: Flaviu Nistor <flaviu.nistor@gmail.com>
dt-bindings: hwmon: chipcap2: Add label property
This commit adds support for an optional label property similar to other
hwmon devices. This allows assigning distinct names to each CHIPCAP2
sensor instance on boards with multiple sensors.
> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> index 17351fdbefce6..56b0cecfca5fb 100644
> --- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> @@ -45,6 +45,8 @@ properties:
> - const: low
> - const: high
>
> + label: true
> +
> vdd-supply:
[ ... ]
While reviewing the hwmon driver code for this hardware, I noticed a
potential locking issue in the interrupt handling.
> --- a/drivers/hwmon/chipcap2.c
> +++ b/drivers/hwmon/chipcap2.c
[ ... ]
> static irqreturn_t cc2_low_interrupt(int irq, void *data)
> {
> struct cc2_data *cc2 = data;
>
> if (cc2->process_irqs) {
> hwmon_notify_event(cc2->hwmon, hwmon_humidity,
> hwmon_humidity_min_alarm, CC2_CHAN_HUMIDITY);
> cc2->rh_alarm.low_alarm = true;
^^^^
[Severity: High]
This isn't a bug introduced by this patch, but the threaded interrupt
handler modifies the min alarm flag without acquiring a lock. Could this
create a race condition where an active alarm gets overwritten?
> }
>
> return IRQ_HANDLED;
> }
>
> static irqreturn_t cc2_high_interrupt(int irq, void *data)
> {
> struct cc2_data *cc2 = data;
>
> if (cc2->process_irqs) {
> hwmon_notify_event(cc2->hwmon, hwmon_humidity,
> hwmon_humidity_max_alarm, CC2_CHAN_HUMIDITY);
> cc2->rh_alarm.high_alarm = true;
^^^^
[Severity: High]
This is a pre-existing issue, but the max alarm flag is also modified
here without locking.
> }
>
> return IRQ_HANDLED;
> }
>
> static int cc2_humidity_min_alarm_status(struct cc2_data *data, long *val)
> {
> long measurement, min_hyst;
> int ret;
>
> ret = cc2_read_hyst_and_measure(data, CC2_R_ALARM_L_OFF, &min_hyst,
> &measurement);
> if (ret < 0)
> return ret;
>
> if (data->rh_alarm.low_alarm) {
> *val = (measurement < min_hyst) ? 1 : 0;
> data->rh_alarm.low_alarm = *val;
^^^^
[Severity: High]
This isn't a bug introduced by this patch, but the sysfs read thread
performs an unprotected read-modify-write on the alarm state flag here.
If a sysfs read of the alarm status evaluates the current measurement
over the I2C bus, and cc2_low_interrupt() concurrently receives an
alarm setting low_alarm to true, could the sysfs thread subsequently
overwrite the active alarm flag with 0 based on stale measurement data?
The hwmon subsystem documentation mentions that hwmon_lock() or custom
locking should be used to serialize sysfs operations with interrupt
handling.
> } else {
> *val = 0;
> }
>
> return 0;
> }
>
> static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
> {
> long measurement, max_hyst;
> int ret;
>
> ret = cc2_read_hyst_and_measure(data, CC2_R_ALARM_H_OFF, &max_hyst,
> &measurement);
> if (ret < 0)
> return ret;
>
> if (data->rh_alarm.high_alarm) {
> *val = (measurement > max_hyst) ? 1 : 0;
> data->rh_alarm.high_alarm = *val;
^^^^
[Severity: High]
This is a pre-existing issue, but the max alarm sysfs read also writes
back the max alarm flag without locking. Does this present the same risk
of lost alarm events if cc2_high_interrupt() runs concurrently?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625160423.17882-1-flaviu.nistor@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: patchwork-bot+netdevbpf @ 2026-06-25 16:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andersson, mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt,
jie.luo, andrew+netdev, davem, edumazet, kuba, pabeni,
quic_leiwei, quic_suruchia, quic_pavir, linux-kernel,
linux-arm-msm, linux-clk, devicetree, netdev
In-Reply-To: <20260623073307.36483-2-krzysztof.kozlowski@oss.qualcomm.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 09:33:08 +0200 you wrote:
> Emails to the maintainer of Qualcomm PPE Ethernet driver (Luo Jie
> <quic_luoj@quicinc.com>) bounce permanently (full mailbox), because the
> "quicinc.com" addresses were deprecated for public work. All Qualcomm
> contributors are aware of that and were asked to fix their addresses.
>
> Driver is not supported - in terms of how netdev understands supported
> commitment - if maintainer does not care to receive the patches for its
> code, so demote it to "maintained" to reflect true status.
>
> [...]
Here is the summary with links:
- [net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
https://git.kernel.org/netdev/net/c/efd7fb21bad8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
From: patchwork-bot+netdevbpf @ 2026-06-25 16:20 UTC (permalink / raw)
To: Rob Herring
Cc: niklas.soderlund, andrew+netdev, davem, edumazet, kuba, pabeni,
krzk+dt, conor+dt, geert+renesas, magnus.damm, sergei.shtylyov,
netdev, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260624150250.131966-2-robh@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 24 Jun 2026 10:02:50 -0500 you wrote:
> Fix the Micrel PHY in the example which shouldn't have the
> fallback "ethernet-phy-ieee802.3-c22" compatible:
>
> Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 \
> (ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long
> from schema $id: http://devicetree.org/schemas/net/micrel.yaml
>
> [...]
Here is the summary with links:
- [net] dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
https://git.kernel.org/netdev/net/c/14eb1d2c03b3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: riscv: Add generic CBQRI controller binding
From: Conor Dooley @ 2026-06-25 16:19 UTC (permalink / raw)
To: Drew Fustini
Cc: 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, linux-kernel, linux-riscv,
x86, devicetree, linux-rt-devel, linux-doc
In-Reply-To: <20260624-dfustini-atl-sc-cbqri-dt-v2-7-2f8049fd902b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 5686 bytes --]
On Wed, Jun 24, 2026 at 06:38:35PM -0700, Drew Fustini wrote:
> Document the generic compatibles for capacity and bandwidth controllers
> that implement the RISC-V CBQRI specification. The binding also
> describes the common riscv,cbqri-rcid and riscv,cbqri-mcid properties,
> and the optional riscv,cbqri-cache phandle that links a capacity
> controller to the cache whose capacity it allocates.
>
> Assisted-by: Claude:claude-opus-4-8
> Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Drew Fustini <fustini@kernel.org>
> ---
> .../devicetree/bindings/riscv/riscv,cbqri.yaml | 97 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 98 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/riscv,cbqri.yaml b/Documentation/devicetree/bindings/riscv/riscv,cbqri.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..5d6be645381780e187b39e60c3bb487fdf2cfb69
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/riscv,cbqri.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/riscv,cbqri.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V Capacity and Bandwidth QoS Register Interface (CBQRI) controller
> +
> +description: |
> + The RISC-V CBQRI specification defines capacity-controller and
> + bandwidth-controller register blocks that allocate cache capacity and memory
> + bandwidth to resource-control IDs (RCIDs) and monitor usage per
> + monitoring-counter ID (MCID):
> + https://github.com/riscv-non-isa/riscv-cbqri/blob/main/riscv-cbqri.pdf
> +
> + Allocation and monitoring share one register block, and a controller may
> + implement either or both. A driver discovers which at runtime from the
> + capabilities register, so the compatible names only the controller type. It
> + does not distinguish allocation-only, monitoring-only or combined
> + controllers, and no property declares monitoring support.
> +
> +maintainers:
> + - Drew Fustini <fustini@kernel.org>
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - description: Tenstorrent Ascalon Shared Cache
> + const: tenstorrent,ascalon-sc-cbqri
> + - const: riscv,cbqri-capacity-controller
> + - enum:
> + - riscv,cbqri-capacity-controller
> + - riscv,cbqri-bandwidth-controller
Please modify this, as has been done for other riscv spec related
bindings, to let people get away without using device-specific
compatibles.
In this case, you can just delete the first entry from this enum, since
it already has a user and only have to implement this feedback for the
second entry.
pw-bot: changes-requested
> +
> + reg:
> + maxItems: 1
> + description:
> + The CBQRI controller register block.
> +
> + riscv,cbqri-rcid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The maximum number of RCIDs the controller supports. RCIDs are the
> + resource-control IDs that allocation operations target.
> +
> + riscv,cbqri-mcid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The maximum number of MCIDs the controller supports. MCIDs are the
> + monitoring-counter IDs that usage-monitoring operations target. Present
> + on controllers that implement monitoring.
> +
> + riscv,cbqri-cache:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to the cache node whose capacity this controller allocates.
> + Applies to capacity controllers that back a CPU cache. The cache level
> + and the harts sharing it are taken from that node's cache topology.
Architecturally, is it impossible for a capacity controller to control
more than one cache?
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: tenstorrent,ascalon-sc-cbqri
> + then:
> + required:
> + - riscv,cbqri-rcid
> + - riscv,cbqri-cache
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + l2_cache: l2-cache {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-unified;
> + cache-size = <0xc00000>;
> + cache-sets = <512>;
> + cache-block-size = <64>;
> + };
> +
> + cache-controller@a21a00c0 {
> + compatible = "tenstorrent,ascalon-sc-cbqri",
> + "riscv,cbqri-capacity-controller";
Is this or is this not a cache controller?
The compatible and fact that the property points to an actual cache
controller suggests that this is not.
Cheers,
Conor.
> + reg = <0xa21a00c0 0xf40>;
> + riscv,cbqri-rcid = <16>;
> + riscv,cbqri-cache = <&l2_cache>;
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9e1092165046c773771b055869030bc1bdb64b16..64a95a4d795a57033d3f36200d98cfb4a013ab94 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23298,6 +23298,7 @@ M: Drew Fustini <fustini@kernel.org>
> R: yunhui cui <cuiyunhui@bytedance.com>
> L: linux-riscv@lists.infradead.org
> S: Supported
> +F: Documentation/devicetree/bindings/riscv/riscv,cbqri.yaml
> F: arch/riscv/include/asm/qos.h
> F: arch/riscv/include/asm/resctrl.h
> F: arch/riscv/kernel/qos.c
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: sashiko-bot @ 2026-06-25 16:17 UTC (permalink / raw)
To: Nathan Morrisson; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260625160214.4001298-2-nmorrisson@phytec.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The PCF8574 GPIO expanders specify `IRQ_TYPE_LEVEL_LOW`, which is unsupported by the K3 GPIO controller and will cause probe failure.
- [Medium] The `reset-gpios` for `pcie0_rc` is specified as `GPIO_ACTIVE_HIGH`, which inverses the standard PCIe PERST# active-low logic.
- [Medium] Mismatch between `mcasp1` serializer configuration and its pin multiplexing: AXR2 is configured for RX but is not pinned out.
- [Medium] Button 'key-menu' connected to PCF8574 uses GPIO_ACTIVE_HIGH, causing inverted logic.
- [Low] Typo in the micbias voltage property for the `tlv320aic3110` audio codec.
--
commit 736b51d7a471b4b2aa4f1281a1e87be6e988051c
Author: Nathan Morrisson <nmorrisson@phytec.com>
arm64: dts: ti: Add support for the phyCORE-AM67x
Add support for the PHYTEC phyCORE-AM67x SoM and the corresponding
phyBOARD-Rigel carrier board. The phyCORE-AM67x SoM uses the TI AM67x SoC
and can come with different sizes and models of DDR, eMMC, and SPI NOR
Flash.
Link: https://www.phytec.com/product/phycore-am67x/
Link: https://www.phytec.com/product/phyboard-am67x-development-kit/
> diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> new file mode 100644
> index 0000000000000..7853d4f5d3b95
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
[ ... ]
> + keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_keys_pins_default>;
[ ... ]
> + key-menu {
> + label = "menu";
> + linux,code = <KEY_MENU>;
> + gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
[Severity: Medium]
Does this configuration cause the button to register as permanently pressed?
The key-menu button is connected to gpio_exp1, which is a PCF8574 expander.
These pins have internal weak pull-ups, meaning their default resting state
is HIGH, and buttons typically pull them to GND (LOW). Specifying
GPIO_ACTIVE_HIGH inverses the logical state unless a strong external
pull-down resistor is present.
> + };
> + };
[ ... ]
> +&main_pmx0 {
[ ... ]
> + main_mcasp1_pins_default: main-mcasp1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0090, PIN_INPUT, 2) /* (P27) GPMC0_BE0n_CLE.MCASP1_ACLKX */
> + J722S_IOPAD(0x0098, PIN_INPUT, 2) /* (V21) GPMC0_WAIT0.MCASP1_AFSX */
> + J722S_IOPAD(0x008c, PIN_OUTPUT, 2) /* (N23) GPMC0_WEn.MCASP1_AXR0 */
> + >;
> + };
[Severity: Medium]
Will audio capture on the mcasp1 interface fail here because the data pin
is not connected?
The mcasp1 node below configures serial-dir index 2 to RX, enabling
MCASP1_AXR2. However, the corresponding pin configuration for MCASP1_AXR2
is missing from main_mcasp1_pins_default. The pin remains in its default
state, meaning the controller receives no data.
[ ... ]
> +&main_i2c1 {
[ ... ]
> + audio_codec: audio-codec@18 {
> + compatible = "ti,tlv320aic3110";
> + reg = <0x18>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&audio_ext_refclk1_pins_default>;
> + #sound-dai-cells = <0>;
> + ai3xx-micbias-vg = <2>;
[Severity: Low]
Is there a typo in the micbias voltage property name?
The ti,tlv320aic3110 codec driver expects the property ai31xx-micbias-vg.
Using ai3xx-micbias-vg causes the driver to ignore this configuration and
fall back to the default 2.0V bias, which could cause incorrect microphone
gain or distortion.
> + reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
[ ... ]
> + gpio_exp0: gpio@20 {
> + compatible = "nxp,pcf8574";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp0_int_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
[Severity: High]
Will this expander fail to probe due to an unsupported interrupt type?
The K3 GPIO controller driver (gpio-davinci.c) strictly supports only
edge-triggered interrupts and returns -EINVAL for level types in its
irq_set_type callback. This would prevent the expanders and all attached
devices from probing.
> + gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
[ ... ]
> +&pcie0_rc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_pcie_pins_default>;
> + num-lanes = <1>;
> + phys = <&serdes1_pcie_link>;
> + phy-names = "pcie-phy";
> + reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
[Severity: Medium]
Could this cause the PCIe endpoint to fail enumeration by keeping the
reset line asserted?
The standard PCIe PERST# signal is active-low. Specifying GPIO_ACTIVE_HIGH
causes the host controller to invert this logic, driving the line high when
it intends to assert reset, and low when it releases it. Unless the board
has a physical inverter on this line, the endpoint will remain in reset.
> + status = "okay";
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625160214.4001298-1-nmorrisson@phytec.com?part=2
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: ti: Add bindings for PHYTEC AM67x based hardware
From: sashiko-bot @ 2026-06-25 16:15 UTC (permalink / raw)
To: Nathan Morrisson; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260625160214.4001298-1-nmorrisson@phytec.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a tab character for indentation in a YAML file, which is forbidden by the YAML specification and breaks schema validation.
--
commit 969d143e093fd0e0c150cfa118a1a7839d600df9
Author: Nathan Morrisson <nmorrisson@phytec.com>
dt-bindings: arm: ti: Add bindings for PHYTEC AM67x based hardware
This commit adds device tree bindings for the AM67x based phyCORE-AM67x SoM
and phyBOARD-Rigel.
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
> index 2a6a9441c23de..9abe252fc7080 100644
> --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
> @@ -215,6 +215,13 @@ properties:
> - ti,j722s-evm
> - const: ti,j722s
>
> + - description: K3 AM67 SoC PHYTEC phyBOARD-Rigel
> + items:
> + - enum:
> + - phytec,am6754-phyboard-rigel
[Severity: Low]
Does this line use a tab character for indentation? YAML syntax strictly
forbids the use of tabs for indentation, which will cause dt_binding_check
to fail with a parsing syntax error.
> + - const: phytec,am67-phycore-som
> + - const: ti,j722s
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625160214.4001298-1-nmorrisson@phytec.com?part=1
^ permalink raw reply
* Re: [PATCH v3 4/4] edac: xilinx: Add EDAC support for Versal XilSem
From: Pandey, Radhey Shyam @ 2026-06-25 16:13 UTC (permalink / raw)
To: Rama devi Veggalam, bp, tony.luck, michal.simek, robh, krzk+dt,
conor+dt
Cc: linux-kernel, linux-edac, devicetree, james.morse, mchehab, rric,
git
In-Reply-To: <20260624212545.2850787-5-rama.devi.veggalam@amd.com>
> Xilinx Versal Soft Error Mitigation (XilSEM) is responsible for reporting
> and optionally correcting soft errors in Configuration Memory of Versal.
> The Configuration Memory includes Configuration RAM and
> Network on Chip (NoC) peripheral interconnect (NPI) Registers.
>
> The Configuration RAM (CRAM) memory is used for storing configuration
> data for the programmable logic (PL) fabric. The NPI registers are used
> for configuring the memory controllers, miscellaneous integrated hardware,
> NoC interface units in the Veral device.
>
> Add support to handle correctable and uncorrectable error events
> from XilSEM.
>
> Add sysfs interface for XilSEM scan operations
> initialize, start, stop scan, error inject, read ECC, scan status and
> configuration values.
>
> Signed-off-by: Rama devi Veggalam <rama.devi.veggalam@amd.com>
> ---
<snip>
> static int mc_probe(struct platform_device *pdev)
> {
> - void __iomem *ddrmc_baseaddr, *ddrmc_noc_baseaddr;
> + void __iomem *ddrmc_baseaddr, *ddrmc_noc_baseaddr, *sem_baseaddr;
> struct edac_mc_layer layers[2];
> struct mem_ctl_info *mci;
> u8 num_chans, num_csrows;
> struct edac_priv *priv;
> u32 edac_mc_id, regval;
> + u32 family_code;
> int rc;
>
> ddrmc_baseaddr = devm_platform_ioremap_resource_byname(pdev, "base");
> @@ -1094,6 +2365,10 @@ static int mc_probe(struct platform_device *pdev)
> if (!get_ecc_state(ddrmc_baseaddr))
> return -ENXIO;
>
> + sem_baseaddr = devm_platform_ioremap_resource_byname(pdev, "semrtca");
> + if (IS_ERR(sem_baseaddr))
> + return PTR_ERR(sem_baseaddr);
> +
As mentioned by Krzysztof in DT review this change breaks existing
system. Please ioremap this semrtca resource only for xilSEM support.
We can make use of compatible based match data.
> /* Allocate ID number for the EMIF controller */
> edac_mc_id = emif_get_id(pdev->dev.of_node);
>
> @@ -1124,9 +2399,29 @@ static int mc_probe(struct platform_device *pdev)
> priv = mci->pvt_info;
> priv->ddrmc_baseaddr = ddrmc_baseaddr;
> priv->ddrmc_noc_baseaddr = ddrmc_noc_baseaddr;
> + priv->sem_baseaddr = sem_baseaddr;
> priv->ce_cnt = 0;
> priv->ue_cnt = 0;
> priv->mc_id = edac_mc_id;
> + priv->xsem_rtca = NULL;
> +
> + /* Allocate and initialize XilSem RTCA structure */
> + priv->xsem_rtca = devm_kzalloc(&pdev->dev,
> + sizeof(struct xsem_rtca_priv),
> + GFP_KERNEL);
> + if (!priv->xsem_rtca) {
> + edac_printk(KERN_ERR, EDAC_MC,
> + "Failed to allocate xsem_rtca\n");
> + rc = -ENOMEM;
> + goto free_edac_mc;
> + }
> +
> + priv->xsem_rtca->slr_info = devm_kzalloc(&pdev->dev, sizeof(struct xsem_ssit_status),
> + GFP_KERNEL);
> + if (!priv->xsem_rtca->slr_info) {
> + rc = -ENOMEM;
> + goto free_edac_mc;
> + }
>
> mc_init(mci, pdev);
>
> @@ -1147,6 +2442,41 @@ static int mc_probe(struct platform_device *pdev)
> goto del_mc;
> }
>
> + /* Create XilSem sysfs attributes only if XilSem is available */
> + rc = xsem_edac_create_sysfs_attributes(mci);
> + if (rc) {
> + edac_printk(KERN_ERR, EDAC_MC,
> + "Failed to create sysfs entries\n");
> + goto remove_sysfs;
> + }
> +
> + /*
> + * Firmware driver returns -ENODEV if it is not probed. In this case
> + * defer XilSEM error event registration.
> + */
> + rc = zynqmp_pm_get_family_info(&family_code);
> + if (rc) {
> + if (rc == -ENODEV)
> + rc = -EPROBE_DEFER;
> +
> + goto del_mc;
> + }
> + if (family_code == PM_VERSAL_FAMILY_CODE) {
> + priv->xsem_rtca->sw_event_node_id = VERSAL_EVENT_ERROR_SW_ERR;
> + priv->xsem_rtca->cram_ce_mask = XPM_VERSAL_EVENT_ERROR_MASK_XSEM_CRAM_CE_5;
> + priv->xsem_rtca->cram_ue_mask = XPM_VERSAL_EVENT_ERROR_MASK_XSEM_CRAM_UE_6;
> + priv->xsem_rtca->npi_ue_mask = XPM_VERSAL_EVENT_ERROR_MASK_XSEM_NPI_UE_7;
> + } else {
> + edac_printk(KERN_ERR, EDAC_MC, "Invalid Device family code %d\n", family_code);
> + }
> +
> + rc = xlnx_register_event(PM_NOTIFY_CB, priv->xsem_rtca->sw_event_node_id,
> + priv->xsem_rtca->cram_ce_mask | priv->xsem_rtca->cram_ue_mask |
> + priv->xsem_rtca->npi_ue_mask,
> + false, xsem_err_callback, mci);
> + if (rc)
> + goto del_mc;
> +
> #ifdef CONFIG_EDAC_DEBUG
> create_debugfs_attributes(mci);
> setup_address_map(priv);
> @@ -1154,6 +2484,8 @@ static int mc_probe(struct platform_device *pdev)
> enable_intr(priv);
> return rc;
>
> +remove_sysfs:
> + xsem_edac_remove_sysfs_attributes(mci);
> del_mc:
> edac_mc_del_mc(&pdev->dev);
> free_edac_mc:
> @@ -1173,9 +2505,21 @@ static void mc_remove(struct platform_device *pdev)
> debugfs_remove_recursive(priv->debugfs);
> #endif
>
> + /* Unregister XilSem events if they were registered */
> + if (priv->xsem_rtca) {
> + xlnx_unregister_event(PM_NOTIFY_CB, priv->xsem_rtca->sw_event_node_id,
> + priv->xsem_rtca->cram_ce_mask |
> + priv->xsem_rtca->cram_ue_mask |
> + priv->xsem_rtca->npi_ue_mask,
> + xsem_err_callback, mci);
> + }
> xlnx_unregister_event(PM_NOTIFY_CB, VERSAL_EVENT_ERROR_PMC_ERR1,
> XPM_EVENT_ERROR_MASK_DDRMC_CR |
> XPM_EVENT_ERROR_MASK_DDRMC_NCR, err_callback, mci);
> + /* Remove XilSem sysfs attributes if they were created */
> + if (priv->xsem_rtca)
> + xsem_edac_remove_sysfs_attributes(mci);
> +
> edac_mc_del_mc(&pdev->dev);
> edac_mc_free(mci);
> }
^ permalink raw reply
* Re: [PATCH 1/2] regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
From: Conor Dooley @ 2026-06-25 16:13 UTC (permalink / raw)
To: cy_huang
Cc: Mark Brown, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Liam Girdwood, Yoon Dong Min, edward_kim, devicetree,
linux-kernel
In-Reply-To: <d111d67d40cc182a2ab8c6292e4ffff9c7dad9ba.1782353659.git.cy_huang@richtek.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: gpu: img,powervr-*: Add maintainer entries
From: Conor Dooley @ 2026-06-25 16:11 UTC (permalink / raw)
To: Matt Coster
Cc: imagination, linux-kernel, Alessio Belle, Luigi Santivetti,
Frank Binns, Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree
In-Reply-To: <20260625-maintainer-updates-v1-3-35112b2f038e@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Thu, Jun 25, 2026 at 03:03:39PM +0100, Matt Coster wrote:
> These entries already exist in MAINTAINERS, add them here so downstream
> users of the bindings also see them.
They only "already exist" because of the patch before this. The commit
message should reflect that this is a functional change in
maintainership not a correction to match a longstanding thing.
pw-bot: changes-requested
Thanks,
Conor.
>
> Signed-off-by: Matt Coster <matt.coster@imgtec.com>
> ---
> Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 4 +++-
> Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index a1f54dbae3f3..91e4ff61b394 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -8,7 +8,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> title: Imagination Technologies PowerVR and IMG Rogue GPUs
>
> maintainers:
> - - Frank Binns <frank.binns@imgtec.com>
> + - Matt Coster <matt.coster@imgtec.com>
> + - Alessio Belle <alessio.belle@imgtec.com>
> + - Luigi Santivetti <luigi.santivetti@imgtec.com>
>
> properties:
> compatible:
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
> index f5898b04381c..3e7df7344430 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
> @@ -9,7 +9,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> title: Imagination Technologies PowerVR SGX GPUs
>
> maintainers:
> - - Frank Binns <frank.binns@imgtec.com>
> + - Matt Coster <matt.coster@imgtec.com>
> + - Alessio Belle <alessio.belle@imgtec.com>
> + - Luigi Santivetti <luigi.santivetti@imgtec.com>
>
> properties:
> compatible:
>
> --
> 2.48.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] dt-bindings: dma: xlnx,axi-dma: Restore xlnx,flush-fsync as u32
From: Suraj Gupta @ 2026-06-25 16:10 UTC (permalink / raw)
To: vkoul, Frank.Li, robh, krzk+dt, conor+dt, michal.simek,
radhey.shyam.pandey
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel
The DT schema conversion incorrectly changed xlnx,flush-fsync from a u32
property to a boolean. The original binding documented values 1, 2, and 3
to select which VDMA channel(s) flush on frame sync.
Restore the uint32 type with the documented enum values and fix the
example accordingly.
Fixes: 2d5c2952b972 ("dt-bindings: dma: xlnx,axi-dma: Convert to DT schema")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml
index 340ae9e91cb0..95b951eea1b7 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml
@@ -81,8 +81,13 @@ properties:
description: Should be the number of framebuffers as configured in h/w.
xlnx,flush-fsync:
- type: boolean
- description: Tells which channel to Flush on Frame sync.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3]
+ description:
+ Tells which channel to flush on frame sync.
+ 1 - flush both channels
+ 2 - flush mm2s channel
+ 3 - flush s2mm channel
xlnx,sg-length-width:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -251,7 +256,7 @@ examples:
"m_axi_s2mm_aclk", "m_axis_mm2s_aclk",
"s_axis_s2mm_aclk";
xlnx,num-fstores = <8>;
- xlnx,flush-fsync;
+ xlnx,flush-fsync = <1>;
xlnx,addrwidth = <32>;
dma-channel-mm2s {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] hwmon: (chipcap2) Add support for label
From: sashiko-bot @ 2026-06-25 16:08 UTC (permalink / raw)
To: Flaviu Nistor; +Cc: linux-hwmon, conor+dt, robh, devicetree
In-Reply-To: <20260625160423.17882-2-flaviu.nistor@gmail.com>
> Add support for label sysfs attribute similar to other hwmon devices.
> This is particularly useful for systems with multiple sensors on the
> same board, where identifying individual sensors is much easier since
> labels can be defined via device tree.
>
> Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625160423.17882-1-flaviu.nistor@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v14 3/5] rpmsg: core: match rpmsg device IDs by prefix
From: sashiko-bot @ 2026-06-25 16:06 UTC (permalink / raw)
To: Shenwei Wang; +Cc: imx, conor+dt, robh, Frank.Li, devicetree
In-Reply-To: <20260625155432.815185-4-shenwei.wang@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Forcing global prefix matching on all rpmsg drivers without a 'longest-prefix match' rule can cause unintended device binding and collisions.
- [Medium] Module auto-loading via udev is broken for dynamically suffixed devices because module alias generation remains exact and lacks a trailing wildcard.
--
commit 7cf465d01393f57a212484ddaf8a931c40ec4179
Author: Shenwei Wang <shenwei.wang@nxp.com>
rpmsg: core: match rpmsg device IDs by prefix
This commit updates the rpmsg device matching logic to compare only the
length of the id->name string. This allows id_table entries to act as
prefixes, enabling drivers to bind to dynamically suffixed devices.
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index e7f7831d37f89..f95bfc9965d4c 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -414,7 +414,9 @@ ATTRIBUTE_GROUPS(rpmsg_dev);
> static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> const struct rpmsg_device_id *id)
> {
> - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> +
> + return strncmp(id->name, rpdev->id.name, len) == 0;
> }
[Severity: High]
Will this change cause unintended driver binding for existing drivers that
expect an exact match?
Because this modifies the global match behavior for all rpmsg drivers without
an opt-in flag or longest-prefix match logic, a shorter existing prefix could
hijack a new device.
For example, if a remote processor creates a channel named rpmsg-tty-control,
would it be incorrectly matched by an existing driver registered as rpmsg-tty?
Looking at rpmsg_dev_match(), the iteration returns on the first successful
match:
drivers/rpmsg/rpmsg_core.c:rpmsg_dev_match() {
...
for (i = 0; ids[i].name[0]; i++)
if (rpmsg_id_match(rpdev, &ids[i])) {
rpdev->id.driver_data = ids[i].driver_data;
return 1;
}
...
}
Could this result in a collision if multiple IDs share the same prefix?
[Severity: Medium]
Does this change break module auto-loading via udev for dynamically suffixed
devices?
When a dynamically suffixed device is registered, rpmsg_uevent() emits the
exact name:
drivers/rpmsg/rpmsg_core.c:rpmsg_uevent() {
...
return add_uevent_var(env, "MODALIAS=" RPMSG_DEVICE_MODALIAS_FMT,
rpdev->id.name);
}
However, the module alias generated by file2alias.c does not append a
wildcard for prefix matching:
scripts/mod/file2alias.c:do_rpmsg_entry() {
...
module_alias_printf(mod, false, RPMSG_DEVICE_MODALIAS_FMT, *name);
}
Since module_alias_printf() is called with append_wildcard set to false, the
generated alias will be an exact match (e.g., rpmsg:rpmsg-io-) which won't
match the uevent string (e.g., MODALIAS=rpmsg:rpmsg-io-1).
Will this prevent the module from loading automatically?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625155432.815185-1-shenwei.wang@oss.nxp.com?part=3
^ permalink raw reply
* Re: [PATCH v14 5/5] arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
From: sashiko-bot @ 2026-06-25 16:06 UTC (permalink / raw)
To: Shenwei Wang; +Cc: devicetree, robh, Frank.Li, conor+dt, imx
In-Reply-To: <20260625155432.815185-6-shenwei.wang@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added `rpmsg-gpio` nodes are nested too deeply in the device tree for the `gpio-rpmsg` driver to discover them, causing an unconditional probe failure.
--
commit 9072997f8f4ba10a42ddca328c65744333555ac3
Author: Shenwei Wang <shenwei.wang@nxp.com>
arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
This patch adds an RPMSG bus node and its GPIO subnodes to the device tree
for the i.MX platform. It aims to enable remote device communication and
GPIO control via RPMSG.
> diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> index 1de3ad60c6aa7..f1b984eb1203a 100644
> --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> @@ -190,6 +190,31 @@ scmi_sensor: protocol@15 {
> cm33: remoteproc-cm33 {
> compatible = "fsl,imx8ulp-cm33";
> status = "disabled";
> +
> + rpmsg {
> + rpmsg-io {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rpmsg_gpioa: gpio@0 {
[Severity: Medium]
Does nesting these nodes cause the gpio-rpmsg driver to fail to probe?
Looking at rpmsg_find_child_by_compat_reg() in drivers/gpio/gpio-rpmsg.c,
the driver only searches the direct children of the remoteproc node:
for_each_available_child_of_node(parent, child) {
if (!of_device_is_compatible(child, compat))
continue;
Since for_each_available_child_of_node() is not recursive, the driver
fails to find the nested gpio@0 and gpio@1 nodes under rpmsg/rpmsg-io/.
This causes an -ENODEV return, preventing the driver from probing.
> + compatible = "rpmsg-gpio";
> + reg = <0>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625155432.815185-1-shenwei.wang@oss.nxp.com?part=5
^ 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