diff mbox series

Input: axp20x-pek - add AXP313a support

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

Commit Message

Влад СВН Sept. 23, 2026, 10:52 a.m. UTC 
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(+)

Comments

sashiko-bot@kernel.org Sept. 23, 2026, 11:02 a.m. UTC | #1 
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);
Влад СВН Sept. 23, 2026, 11:22 a.m. UTC | #2 
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
Влад СВН Sept. 23, 2026, 11:26 a.m. UTC | #3 
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).
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);