diff mbox series

Input: axp20x-pek - add AXP313a support

Message ID 20260923105757.260-1-anykey196@gmail.com (mailing list archive)
State New
Headers
Series Input: axp20x-pek - add AXP313a support |

Commit Message

Влад СВН Sept. 23, 2026, 10:57 a.m. UTC 
The AXP313a MFD driver registers its power button cell as "axp313a-pek",
but the axp20x-pek platform id table only matches "axp20x-pek" and
"axp221-pek". The power button therefore never probes on boards using the
AXP313a PMIC (e.g. the OrangePi Zero 2W).

Add the missing id table entry. The register layout used by the driver
matches the AXP313a, so the generic axp20x_info is reused.

Tested on: OrangePi Zero 2W (Allwinner H618 + AXP313a), kernel 7.1.13.

Signed-off-by: Vladimir <anykey196@gmail.com>
---
 drivers/input/misc/axp20x-pek.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

sashiko-bot@kernel.org Sept. 23, 2026, 11:07 a.m. UTC | #1 
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] input: broken AXP313a sysfs attributes due to out-of-bounds regmap access
--

commit fbaeccab4996537ab99d0c8423e2cf36610e4b34
Author: Vladimir <anykey196@gmail.com>

Input: axp20x-pek - add AXP313a support
    
This commit adds the AXP313a PMIC platform ID to the axp20x-pek driver to
enable the power button. It uses the axp20x_info generic register layout.

> diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
> index 24f9e9d893de3..d4e2fc9a937ff 100644
> --- a/drivers/input/misc/axp20x-pek.c
> +++ b/drivers/input/misc/axp20x-pek.c
> @@ -393,6 +393,10 @@ static const struct platform_device_id axp_pek_id_match[] = {
>  		.name = "axp221-pek",
>  		.driver_data = (kernel_ulong_t)&axp221_info,
>  	},
> +	{
> +		.name = "axp313a-pek",
> +		.driver_data = (kernel_ulong_t)&axp20x_info,
[Severity: Medium]
Will reusing axp20x_info break the sysfs attributes startup and shutdown for
the AXP313a?

When these sysfs attributes are accessed, the driver calls:

axp20x_show_attr()
  regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);

axp20x_store_attr()
  regmap_update_bits(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, mask, idx);

Since AXP20X_PEK_KEY is 0x36, but the AXP313a regmap defines max_register
as 0x21, won't the regmap core block this out-of-bounds access and return
an error?

> +	},
>  	{ /* sentinel */ }
>  };
MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
Влад СВН Sept. 23, 2026, 11:23 a.m. UTC | #2 
This is already addressed in v2 [1]: the AXP313a no longer reuses
axp20x_info. It has its own axp313a_info without start-up/shutdown
times, and the startup/shutdown attributes are hidden through
is_visible(), so they are not created and no out-of-range access to
AXP20X_PEK_KEY happens.

ср, 23 сент. 2026 г. в 16:07, <sashiko-bot@kernel.org>:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] input: broken AXP313a sysfs attributes due to out-of-bounds regmap access
> --
>
> commit fbaeccab4996537ab99d0c8423e2cf36610e4b34
> Author: Vladimir <anykey196@gmail.com>
>
> Input: axp20x-pek - add AXP313a support
>
> This commit adds the AXP313a PMIC platform ID to the axp20x-pek driver to
> enable the power button. It uses the axp20x_info generic register layout.
>
> > diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
> > index 24f9e9d893de3..d4e2fc9a937ff 100644
> > --- a/drivers/input/misc/axp20x-pek.c
> > +++ b/drivers/input/misc/axp20x-pek.c
> > @@ -393,6 +393,10 @@ static const struct platform_device_id axp_pek_id_match[] = {
> >               .name = "axp221-pek",
> >               .driver_data = (kernel_ulong_t)&axp221_info,
> >       },
> > +     {
> > +             .name = "axp313a-pek",
> > +             .driver_data = (kernel_ulong_t)&axp20x_info,
> [Severity: Medium]
> Will reusing axp20x_info break the sysfs attributes startup and shutdown for
> the AXP313a?
>
> When these sysfs attributes are accessed, the driver calls:
>
> axp20x_show_attr()
>   regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
>
> axp20x_store_attr()
>   regmap_update_bits(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, mask, idx);
>
> Since AXP20X_PEK_KEY is 0x36, but the AXP313a regmap defines max_register
> as 0x21, won't the regmap core block this out-of-bounds access and return
> an error?
>
> > +     },
> >       { /* sentinel */ }
> >  };
> MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260923105757.260-1-anykey196@gmail.com?part=1
Влад СВН Sept. 23, 2026, 11:27 a.m. UTC | #3 
This is already addressed in v2 [1]: the AXP313a no longer reuses
axp20x_info. It has its own axp313a_info without start-up/shutdown
times, and the startup/shutdown attributes are hidden through
is_visible(), so they are not created and no out-of-range access to
AXP20X_PEK_KEY happens.
diff mbox series

Patch

diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index 24f9e9d89..d4e2fc9a9 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -393,6 +393,10 @@  static const struct platform_device_id axp_pek_id_match[] = {
 		.name = "axp221-pek",
 		.driver_data = (kernel_ulong_t)&axp221_info,
 	},
+	{
+		.name = "axp313a-pek",
+		.driver_data = (kernel_ulong_t)&axp20x_info,
+	},
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(platform, axp_pek_id_match);