Pull power supply and reset updates from Sebastian Reichel:
"New features:
- axp20x_usb_power: report USB type
Cleanups:
- convert lots of drivers to use devm_power_supply_register()
- convert lots of reset drivers to use devm_register_sys_off_handler()
- constify device_type and power_supply_class
- axp20x_usb_power: use correct property to report input current limit
- mm8013: correct handling of "not charging" status register
- core: fix charge_behaviour formatting
- minor fixes cleanups"
* tag 'for-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (66 commits)
power: supply: core: fix charge_behaviour formatting
power: supply: core: ease special formatting implementations
power: supply: mm8013: fix "not charging" detection
power: supply: move power_supply_attr_groups definition back to sysfs
power: supply: core: simplify power_supply_class_init
power: supply: core: add power_supply_for_each_device()
power: supply: core: make power_supply_class constant
power: supply: bq2415x_charger: report online status
power: supply: core: move power_supply_attr_group into #ifdef block
power: supply: core: Fix power_supply_init_attrs() stub
power: supply: bq27xxx: Report charge full state correctly
power: reset: rmobile-reset: Make sysc_base2 local
power: supply: core: constify the struct device_type usage
power: supply: axp288_fuel_gauge: Deny ROCK Pi X
power: reset: rmobile-reset: Map correct MMIO resource
power: reset: xgene-reboot: Fix a NULL vs IS_ERR() test
power: supply: axp288_fuel_gauge: Add STCK1A* Intel Compute Sticks to the deny-list
power: reset: syscon-poweroff: Use devm_register_sys_off_handler(POWER_OFF)
power: reset: syscon-poweroff: Move device data into a struct
power: reset: restart-poweroff: Use devm_register_sys_off_handler(POWER_OFF)
...
This property is documented to have a special format which exposes all
available behaviours and the currently active one at the same time. For
this special format some helpers are provided.
When the charge_behaviour property was added in
1b0b6cc803 ("power: supply: add charge_behaviour attributes"), it did
not update the default logic in in power_supply_sysfs.c to use the
format helpers. Thus by default only the currently active behaviour
is printed. This fixes the default logic to follow the documented
format.
There is currently only one in-tree drivers exposing charge behaviours -
thinkpad_acpi, which is not affected by the change, as it directly uses
the helpers and does not use the power_supply_sysfs.c logic.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240303-power_supply-charge_behaviour_prop-v2-3-8ebb0a7c2409@weissschuh.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When building with CONFIG_SYSFS=n, the build error below is triggered:
ld: drivers/power/supply/power_supply_core.o:(.data+0x0): undefined
reference to `power_supply_attr_group'
The problem is that power_supply_attr_group is needed in
power_supply_core.c but defined in power_supply_sysfs.c, which is only
targeted with CONFIG_SYSFS=y. Therefore, move the extern declaration into
the #ifdef block that checks for CONFIG_SYSFS, and define an empty static
const struct otherwise. This is safe because the macro __ATRIBUTE_GROUPS in
power_supply_core.c will expand into an empty attribute_group array.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/all/20240227214916.GA3699076@dev-arch.thelio-3990X/
Fixes: 7b46b60944 ("power: supply: core: constify the struct device_type usage")
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lore.kernel.org/r/20240228-device_cleanup-power-v1-1-52c0321c48e1@marliere.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When building without CONFIG_SYSFS, there is an error because of a
recent refactoring that failed to update the stub of
power_supply_init_attrs():
drivers/power/supply/power_supply_core.c: In function 'power_supply_class_init':
drivers/power/supply/power_supply_core.c:1630:9: error: too few arguments to function 'power_supply_init_attrs'
1630 | power_supply_init_attrs();
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/power/supply/power_supply_core.c:25:
drivers/power/supply/power_supply.h:25:20: note: declared here
25 | static inline void power_supply_init_attrs(struct device_type *dev_type) {}
| ^~~~~~~~~~~~~~~~~~~~~~~
Update the stub function to take no parameters like the rest of the
refactoring, which resolves the build error.
Fixes: 7b46b60944 ("power: supply: core: constify the struct device_type usage")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240227-fix-power_supply_init_attrs-stub-v1-1-43365e68d4b3@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When reporting the charging status, the existing code reports the battery
as full only when the reported current flowing is exactly 0mA, which is
unlikely in practice.
Fix the reporting by giving priority to the battery's full state
indication/flag.
Tested on the Nokia N900 with bq27200 fuel gauge.
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Link: https://lore.kernel.org/r/20240226193722.2173624-1-absicsz@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Since commit aed65af1cc ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the
power_supply_dev_type variable to be a constant structure as well, placing
it into read-only memory which can not be modified at runtime.
In order to accomplish that, export power_supply_attr_group in
power_supply.h and use it with the macro __ATTRIBUTE_GROUPS when defining
power_supply_dev_type in power_supply_core.c. Therefore the attribute group
is no longer static. Lastly, because power_supply_attr_groups is no longer
dynamically associated to power_supply_dev_type in
power_supply_init_attrs(), make the function receive zero arguments.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240224-device_cleanup-power-v2-1-465ff94b896c@marliere.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Besides the existing STK1A* Cherry Trail based Intel Compute Sticks
already on the deny-list, Intel also made Bay Trail based Compute Sticks
which have a product name of STCK1A* and wich also report a non
existing battery with a random battery charge.
Instead of adding 3 new deny-list entries for the 3 variants of the STCK1A*
sticks consolidate the 2 Cherry Trail STK1AW32SC and STK1A32SC variants
into a single entry with a partial match for STK1A* and add a single new
STCK1A* match for the Bay Trail variants.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240212090014.13719-1-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The bq27xxx i2c-client may not have an IRQ, in which case
client->irq will be 0. bq27xxx_battery_i2c_probe() already has
an if (client->irq) check wrapping the request_threaded_irq().
But bq27xxx_battery_i2c_remove() unconditionally calls
free_irq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------
[ 190.310843] Trying to free already-free IRQ 0
[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add
an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring
probe() to fix this.
Fixes: 444ff00734 ("power: supply: bq27xxx: Fix I2C IRQ race on remove")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240215155133.70537-1-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
On the axp803 and axp813 chips register 0x30 bits 0-1 is the default
current limit that gets applied after the pmic detects a CDP or DCP
port. The correct field to set is 0x35 bits 4-7.
This field only has nine values (out of the 16 possible if it used all
the bits), so introduce a field size variable to take that into account.
Signed-off-by: Aren Moynihan <aren@peacevolution.org>
Link: https://lore.kernel.org/r/20240130203714.3020464-3-aren@peacevolution.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The current_max property is supposed to be read-only, and represent the
maximum current the supply can provide. input_current_limit is the
limit that is currently set, which is what we have here.
When determining what value to write to the register, we need to pick a
reasonable value if the requested limit doesn't exactly match one
supported by the hardware. If the requested limit is less than the
lowest value we can set, round up to the lowest value. Otherwise round
down to the nearest value supported by hardware.
Also add a dev field to the axp20x_usb_power struct, so we can use
dev_dbg and dev_err in more places.
Signed-off-by: Aren Moynihan <aren@peacevolution.org>
Link: https://lore.kernel.org/r/20240130203714.3020464-2-aren@peacevolution.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
