Linux Input/HID development
 help / color / mirror / Atom feed
* [PATCH] Input: axp20x-pek - add AXP313a support
@ 2026-09-23 10:52 Vladimir
  2026-09-23 11:02 ` sashiko-bot
  0 siblings, 1 reply; 8+ messages in thread
From: Vladimir @ 2026-09-23 10:52 UTC (permalink / raw)
  To: Chen-Yu Tsai, Samuel Holland; +Cc: linux-input, linux-sunxi, Vladnwx

From: Vladnwx <vladnwx@users.noreply.github.com>

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: Vladnwx <vladnwx@users.noreply.github.com>
---
 drivers/input/misc/axp20x-pek.c | 4 ++++
 1 file changed, 4 insertions(+)

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);
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH] Input: axp20x-pek - add AXP313a support
@ 2026-09-23 10:57 Vladimir
  2026-09-23 11:07 ` sashiko-bot
  0 siblings, 1 reply; 8+ messages in thread
From: Vladimir @ 2026-09-23 10:57 UTC (permalink / raw)
  To: Chen-Yu Tsai, Samuel Holland; +Cc: linux-input, linux-sunxi, Vladimir

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(+)

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);
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] Input: axp20x-pek - add AXP313a support
  2026-09-23 10:52 [PATCH] Input: axp20x-pek - add AXP313a support Vladimir
@ 2026-09-23 11:02 ` sashiko-bot
       [not found]   ` <CANHPwASJBzich3-2QV3FNNdKX+GHQGe2FuFWu2CUXCYya=-1zA@mail.gmail.com>
  2026-09-23 11:26   ` Влад СВН
  0 siblings, 2 replies; 8+ messages in thread
From: sashiko-bot @ 2026-09-23 11:02 UTC (permalink / raw)
  To: Vladimir; +Cc: dmitry.torokhov, linux-input, linux-sunxi

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] sysfs: broken startup/shutdown attributes for axp313a
--

commit 2573be3a312f98b032ff9523708d368661f8e004
Author: Vladnwx <vladnwx@users.noreply.github.com>

Input: axp20x-pek - add AXP313a support

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).

> 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 using axp20x_info result in broken sysfs attributes for AXP313a?

The AXP313a platform binding unconditionally exposes startup and shutdown
sysfs files because they are hardcoded in axp20x_groups. Reading or writing
these files attempts to access the AXP20X_PEK_KEY register (0x36) in
axp20x_show_attr() and axp20x_store_attr():

drivers/input/misc/axp20x-pek.c:axp20x_show_attr() {
	...
	ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
	...
}

drivers/input/misc/axp20x-pek.c:axp20x_store_attr() {
	...
	ret = regmap_update_bits(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY,
				 mask, idx);
	...
}

However, the AXP313a regmap configuration restricts max_register to
AXP313A_IRQ_STATE (0x21). The regmap core blocks accesses to registers beyond
max_register, meaning these sysfs accesses will definitively fail with -EIO.

Could the axp313a-pek driver be updated to avoid exposing these broken sysfs
attributes?

>  	{ /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(platform, axp_pek_id_match);

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Input: axp20x-pek - add AXP313a support
  2026-09-23 10:57 Vladimir
@ 2026-09-23 11:07 ` sashiko-bot
  2026-09-23 11:23   ` Влад СВН
  2026-09-23 11:27   ` Влад СВН
  0 siblings, 2 replies; 8+ messages in thread
From: sashiko-bot @ 2026-09-23 11:07 UTC (permalink / raw)
  To: Vladimir; +Cc: linux-input, dmitry.torokhov, linux-sunxi

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Input: axp20x-pek - add AXP313a support
       [not found]   ` <CANHPwASJBzich3-2QV3FNNdKX+GHQGe2FuFWu2CUXCYya=-1zA@mail.gmail.com>
@ 2026-09-23 11:22     ` Влад СВН
  0 siblings, 0 replies; 8+ messages in thread
From: Влад СВН @ 2026-09-23 11:22 UTC (permalink / raw)
  To: sashiko-reviews; +Cc: dmitry.torokhov, linux-input, linux-sunxi

Thanks. Correct: the AXP313a register map ends at AXP313A_IRQ_STATE
(0x21), so AXP20X_PEK_KEY (0x36) is unreachable and the
startup/shutdown sysfs files would always fail with -EIO.

v2 no longer reuses axp20x_info. The AXP313a gets its own axp313a_info
with no start-up/shutdown times, and those two attributes are hidden
via an is_visible() callback, so they are simply not created for this
variant.

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

ср, 23 сент. 2026 г. в 16:14, Влад СВН <anykey196@gmail.com>:
>
> Thanks. Correct: the AXP313a register map ends at AXP313A_IRQ_STATE (0x21), so AXP20X_PEK_KEY (0x36) is unreachable and the startup/shutdown sysfs files would always fail with -EIO.
>
> v2 no longer reuses axp20x_info. The AXP313a gets its own axp313a_info with no start-up/shutdown times, and those two attributes are hidden via an is_visible() callback, so they are simply not created for this variant.
>
> Tested on: OrangePi Zero 2W (Allwinner H618 + AXP313a).
>
> ср, 23 сент. 2026 г. в 16:02, <sashiko-bot@kernel.org>:
>>
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [Medium] sysfs: broken startup/shutdown attributes for axp313a
>> --
>>
>> commit 2573be3a312f98b032ff9523708d368661f8e004
>> Author: Vladnwx <vladnwx@users.noreply.github.com>
>>
>> Input: axp20x-pek - add AXP313a support
>>
>> 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).
>>
>> > 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 using axp20x_info result in broken sysfs attributes for AXP313a?
>>
>> The AXP313a platform binding unconditionally exposes startup and shutdown
>> sysfs files because they are hardcoded in axp20x_groups. Reading or writing
>> these files attempts to access the AXP20X_PEK_KEY register (0x36) in
>> axp20x_show_attr() and axp20x_store_attr():
>>
>> drivers/input/misc/axp20x-pek.c:axp20x_show_attr() {
>>         ...
>>         ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
>>         ...
>> }
>>
>> drivers/input/misc/axp20x-pek.c:axp20x_store_attr() {
>>         ...
>>         ret = regmap_update_bits(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY,
>>                                  mask, idx);
>>         ...
>> }
>>
>> However, the AXP313a regmap configuration restricts max_register to
>> AXP313A_IRQ_STATE (0x21). The regmap core blocks accesses to registers beyond
>> max_register, meaning these sysfs accesses will definitively fail with -EIO.
>>
>> Could the axp313a-pek driver be updated to avoid exposing these broken sysfs
>> attributes?
>>
>> >       { /* sentinel */ }
>> >  };
>> >  MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
>>
>> --
>> Sashiko AI review · https://sashiko.dev/#/patchset/20260923105215.1633-1-anykey196@gmail.com?part=1

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Input: axp20x-pek - add AXP313a support
  2026-09-23 11:07 ` sashiko-bot
@ 2026-09-23 11:23   ` Влад СВН
  2026-09-23 11:27   ` Влад СВН
  1 sibling, 0 replies; 8+ messages in thread
From: Влад СВН @ 2026-09-23 11:23 UTC (permalink / raw)
  To: sashiko-reviews; +Cc: linux-input, dmitry.torokhov, linux-sunxi

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Input: axp20x-pek - add AXP313a support
  2026-09-23 11:02 ` sashiko-bot
       [not found]   ` <CANHPwASJBzich3-2QV3FNNdKX+GHQGe2FuFWu2CUXCYya=-1zA@mail.gmail.com>
@ 2026-09-23 11:26   ` Влад СВН
  1 sibling, 0 replies; 8+ messages in thread
From: Влад СВН @ 2026-09-23 11:26 UTC (permalink / raw)
  To: sashiko-reviews; +Cc: dmitry.torokhov, linux-input, linux-sunxi

Thanks. Correct: the AXP313a register map ends at AXP313A_IRQ_STATE
(0x21), so AXP20X_PEK_KEY (0x36) is unreachable and the
startup/shutdown sysfs files would always fail with -EIO.

v2 no longer reuses axp20x_info. The AXP313a gets its own axp313a_info
with no start-up/shutdown times, and those two attributes are hidden
via an is_visible() callback, so they are simply not created for this
variant.

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Input: axp20x-pek - add AXP313a support
  2026-09-23 11:07 ` sashiko-bot
  2026-09-23 11:23   ` Влад СВН
@ 2026-09-23 11:27   ` Влад СВН
  1 sibling, 0 replies; 8+ messages in thread
From: Влад СВН @ 2026-09-23 11:27 UTC (permalink / raw)
  To: sashiko-reviews; +Cc: linux-input, dmitry.torokhov, linux-sunxi

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-09-23 11:27 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-23 10:52 [PATCH] Input: axp20x-pek - add AXP313a support Vladimir
2026-09-23 11:02 ` sashiko-bot
     [not found]   ` <CANHPwASJBzich3-2QV3FNNdKX+GHQGe2FuFWu2CUXCYya=-1zA@mail.gmail.com>
2026-09-23 11:22     ` Влад СВН
2026-09-23 11:26   ` Влад СВН
  -- strict thread matches above, loose matches on Subject: below --
2026-09-23 10:57 Vladimir
2026-09-23 11:07 ` sashiko-bot
2026-09-23 11:23   ` Влад СВН
2026-09-23 11:27   ` Влад СВН

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox