Re: [PATCH] Input: mtk-pmic-keys - match loop with count

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Switching to `for_each_available_child_of_node_scoped` shifts the hardware mapping index if a preceding node is disabled, leading to incorrect physical key configuration.
--

commit 999599e1545f7dcb987f1a3ede455f57f6a980e6
Author: Rosen Penev <rosenp@gmail.com>

Input: mtk-pmic-keys - match loop with count

This commit changes the child node iteration in mtk_pmic_keys_probe() to
only iterate over available child nodes, preventing an out-of-bounds array
access if a disabled node exists alongside available ones.

> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index c78d9f6d97c4f..5d4ebbafd2765 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
> @@ -363,7 +363,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
>  		return -EINVAL;
>  	}
>  
> -	for_each_child_of_node_scoped(node, child) {
> +	for_each_available_child_of_node_scoped(node, child) {

[Severity: High]
Does this change in iteration cause a regression with the positional mapping
of keys to hardware?

The driver maps device tree child nodes to physical key hardware (IRQ and
registers) based strictly on the loop iteration index (index = 0 for
powerkey, index = 1 for homekey).

Before this patch, for_each_child_of_node_scoped() iterated over all defined
child nodes, ensuring that positional mapping was maintained even if the first
node (e.g., powerkey) had status = "disabled".

By changing the iterator to for_each_available_child_of_node_scoped(),
disabled nodes are now skipped. If the powerkey node is disabled in the
device tree, it is skipped, and the homekey node becomes the first available
child. It is then processed with index = 0.

Consequently, the driver would configure the powerkey hardware registers
and request the powerkey IRQ, but bind them to the properties
(like linux,keycodes) of the homekey node.

Could this result in the physical powerkey incorrectly emitting the homekey's
code, while the physical homekey remains uninitialized?

>  		keys->keys[index].regs = &mtk_pmic_regs->keys_regs[index];
>  
>  		keys->keys[index].irq =

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527004543.22875-1-rosenp@gmail.com?part=1