Re: [PATCH v10 2/9] dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
From: sashiko-bot@kernel.org
Date: 2026-09-02 19:50:55
Also in:
linux-devicetree
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Driver blindly assumes DT child node ordering corresponds to specific physical keys (Power vs Home). -- commit 60da1299ae1ca5678f1be4e16da6d490bbacc023 Author: Fabien Parent [off-list ref] dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys This commit adds the binding documentation for the MT6392 PMIC keys to the mediatek,pmic-keys device tree binding schema.
quoted hunk ↗ jump to hunk
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml index 140a862ecfbeb..ff720588128be 100644 --- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml +++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml@@ -31,6 +31,7 @@ properties: - mediatek,mt6357-keys - mediatek,mt6358-keys - mediatek,mt6359-keys + - mediatek,mt6392-keys - mediatek,mt6397-keys
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the bindings
for these PMIC keys, I noticed a pre-existing issue in the corresponding
driver implementation that consumes these device tree nodes.
Does the driver blindly assume device tree child node ordering corresponds to
specific physical keys?
Looking at mtk_pmic_keys_probe() in drivers/input/keyboard/mtk-pmic-keys.c:
for_each_child_of_node_scoped(node, child) {
keys->keys[index].regs = &mtk_pmic_regs->keys_regs[index];
keys->keys[index].irq =
platform_get_irq_byname(pdev, irqnames[index]);
...
Because for_each_child_of_node_scoped() yields child nodes in an undefined
order, could this sequential assignment swap the physical Power and Home keys
(index 0 vs index 1) if a device tree author defines the home node before the
power node, or if an external bootloader/overlay reorders them?
Since the device tree is a strict ABI, relying on undefined node ordering
might lead to functionally broken hardware (such as the physical power button
acting as the home button). Would it make sense to explicitly check the child
node name or use a specific property to identify which node corresponds to
which key instead of relying on the iteration index?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902193351.185771-1-l.scorcia@gmail.com?part=2