| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Use device life-cycle managed ioremap function to simplify probe and
exit paths.
While here add __iomem to the returned pointer to fix a sparse warning.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <[email protected]>
Reviewed-by: Cristian Ciocaltea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <[email protected]>
Reviewed-by: Cristian Ciocaltea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
The driver uses regmap APIs so it should make sure they are available.
Fixes: c75f4bf6800b ("power: supply: Introduce MM8013 fuel gauge driver")
Cc: <[email protected]>
Signed-off-by: Thomas Weißschuh <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
The axp803 and axp813 chips can report the detected USB BC mode. SDP,
CDP, and DCP are supported.
Signed-off-by: Aren Moynihan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
When input_current_limit is set while USB BC is in progress, the BC
module will overwrite the value that was set when it finishes detection.
Signed-off-by: Aren Moynihan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed get function. This helps prevent
mistakes like releasing out of order in cleanup functions and
forgetting to release on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed get function. This helps prevent
mistakes like releasing out of order in cleanup functions and
forgetting to release on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed get function. This helps prevent
mistakes like releasing out of order in cleanup functions and
forgetting to release on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
This value only needs read once. Move that read into the function
that returns the value to keep the logic all in one place. This
also avoids doing this check every time we read in values in
the device update poll worker.
While here, correct this function's error message.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use the device lifecycle managed register function. This helps prevent
mistakes like unregistering out of order in cleanup functions and
forgetting to unregister on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use a device lifecycle managed action to free the device mutex.
This helps prevent mistakes like freeing out of order in cleanup
functions and forgetting to free on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use a device lifecycle managed action to free the IDA. This helps
prevent mistakes like freeing out of order in cleanup functions and
forgetting to free on error paths.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
We don't need to specify any ranges when allocating IDs so we can switch
to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.
Signed-off-by: Andrew Davis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
is up"
This reverts commit b43f7ddc2b7a5a90447d96cb4d3c6d142dd4a810.
The offending commit deferred power-supply class device registration
until the service-started notification is received.
This triggers a NULL pointer dereference during boot of the Lenovo
ThinkPad X13s and SC8280XP CRD as battery status notifications can be
received before the service-start notification:
Unable to handle kernel NULL pointer dereference at virtual address 00000000000005c0
...
Call trace:
_acquire+0x338/0x2064
acquire+0x1e8/0x318
spin_lock_irqsave+0x60/0x88
_supply_changed+0x2c/0xa4
battmgr_callback+0x1d4/0x60c [qcom_battmgr]
pmic_glink_rpmsg_callback+0x5c/0xa4 [pmic_glink]
qcom_glink_native_rx+0x58c/0x7e8
qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem]
__handle_irq_event_percpu+0xb0/0x2d4
handle_irq_event+0x4c/0xb8
As trying to serialise this is non-trivial and risks missing
notifications, let's revert to registration during probe so that the
driver data is all set up once the service goes live.
The warning message during resume in case the aDSP firmware is not
running that motivated the change can be considered a feature and should
not be suppressed.
Fixes: b43f7ddc2b7a ("power: supply: qcom_battmgr: Register the power supplies after PDR is up")
Signed-off-by: Johan Hovold <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
When building with a version of GCC prior to 8.x, there is an error
around non-constant initializer elements:
drivers/power/supply/bq24190_charger.c:1978:16: error: initializer element is not constant
.vbus_desc = bq24190_vbus_desc,
^~~~~~~~~~~~~~~~~
drivers/power/supply/bq24190_charger.c:1978:16: note: (near initialization for 'bq24190_chip_info_tbl[0].vbus_desc')
drivers/power/supply/bq24190_charger.c:1989:16: error: initializer element is not constant
.vbus_desc = bq24190_vbus_desc,
^~~~~~~~~~~~~~~~~
drivers/power/supply/bq24190_charger.c:1989:16: note: (near initialization for 'bq24190_chip_info_tbl[1].vbus_desc')
drivers/power/supply/bq24190_charger.c:2000:16: error: initializer element is not constant
.vbus_desc = bq24190_vbus_desc,
^~~~~~~~~~~~~~~~~
drivers/power/supply/bq24190_charger.c:2000:16: note: (near initialization for 'bq24190_chip_info_tbl[2].vbus_desc')
drivers/power/supply/bq24190_charger.c:2011:16: error: initializer element is not constant
.vbus_desc = bq24190_vbus_desc,
^~~~~~~~~~~~~~~~~
drivers/power/supply/bq24190_charger.c:2011:16: note: (near initialization for 'bq24190_chip_info_tbl[3].vbus_desc')
drivers/power/supply/bq24190_charger.c:2022:16: error: initializer element is not constant
.vbus_desc = bq24296_vbus_desc,
^~~~~~~~~~~~~~~~~
drivers/power/supply/bq24190_charger.c:2022:16: note: (near initialization for 'bq24190_chip_info_tbl[4].vbus_desc')
Clang versions prior to 17.x show a similar error:
drivers/power/supply/bq24190_charger.c:1978:16: error: initializer element is not a compile-time constant
.vbus_desc = bq24190_vbus_desc,
^~~~~~~~~~~~~~~~~
1 error generated.
Newer compilers have decided to accept these structures as compile time
constants as an extension. To resolve this issue for all supported
compilers, change the vbus_desc member in 'struct bq24190_chip_info' to
a pointer, as it is only ever passed by reference anyways, and adjust
the assignments accordingly.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1973
Fixes: b150a703b56f ("power: supply: bq24190_charger: Add support for BQ24296")
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Justin Stitt <[email protected]>
Link: https://lore.kernel.org/r/20240103-fix-bq24190_charger-vbus_desc-non-const-v1-1-115ddf798c70@kernel.org
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Merge power-supply fixes branch, which I never send for
the v6.7 cycle.
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
The BQ24296 is most similar to the BQ24196, but the:
1. OTG config is split from CHG config (REG01)
2. ICHG (Fast Charge Current limit) range is smaller (<=3008mA)
3. NTC fault is simplified to 2 bits
Signed-off-by: Hermes Zhang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Currently, a not-yet-entirely-initialized battmgr (e.g. with pd-mapper
not having yet started or ADSP not being up etc.) results in a couple of
zombie power supply devices hanging around.
This is particularly noticeable when trying to suspend the device (even
s2idle): the PSY-internal thermal zone is inaccessible and returns
-ENODEV, which causes log spam.
Register the power supplies only after we received some notification
indicating battmgr is ready to take off.
Signed-off-by: Konrad Dybcio <[email protected]>
Tested-by: Luca Weiss <[email protected]>
Link: https://lore.kernel.org/r/20231218-topic-battmgr_fixture_attempt-v1-1-6145745f34fe@linaro.org
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
devm_kasprintf and devm_kzalloc return a pointer to dynamically
allocated memory which can be NULL upon failure.
Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver")
Signed-off-by: Kunwu Chan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
When building with clang, there are two section mismatch warnings:
WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x7c (section: .text) -> at91_wakeup_status (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
Drop '__init' from at91_wakeup_status() to clear up the mismatch.
Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
Signed-off-by: Nathan Chancellor <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
This resolves checkpatch warning "quoted string split across lines" on:
1640: WARNING: quoted string split across lines
1641: WARNING: quoted string split across lines
The motive to use multiple MODULE_AUTHOR statements came from this
comment from "include/linux/module.h":
/*
* Author(s), use "Name <email>" or just "Name", for multiple
* authors use multiple MODULE_AUTHOR() statements/lines.
*/
#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
Signed-off-by: Charalampos Mitrodimas <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
These were mentioned by checkpatch:
Errors:
(1) code indent should use tabs where possible
(2) switch and case should be at the same indent
Warnings:
(1) Missing a blank line after declarations
Signed-off-by: Charalampos Mitrodimas <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
Use device life-cycle managed register function to simplify probe error
path and eliminate need for explicit remove function.
Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
smatch complains that there is a buffer overflow and clang complains
'ret' is never read.
Smatch error:
drivers/power/supply/bq256xx_charger.c:1578 bq256xx_hw_init() error:
buffer overflow 'bq256xx_watchdog_time' 4 <= 4
Clang static checker:
Value stored to 'ret' is never read.
Add check for buffer overflow and error code from regmap_update_bits().
Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver")
Signed-off-by: Su Hui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
RRT_ALRT register holds remaining battery time in minutes therefore it
needs to be scaled accordingly when exposing TIME_TO_EMPTY via sysfs
expressed in seconds
Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver")
Signed-off-by: Jan Palus <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Returning an error if unregister_restart_handler() failed has no effect
but triggering another error message. So converting this driver to
.remove_new() has no effect but to suppress the duplicated error message.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|
|
void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
|