There may be other backup reset methods available, do not halt
here so that other reset methods can be tried.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240610142836.168603-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Function register_restart_handler() is deprecated. Using this new API
removes our need to keep and manage a struct notifier_block.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240610142836.168603-4-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Simplify probe by fetching the regmap and its arguments in one call.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240610142836.168603-3-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device_get_match_data() for finding the matching node and fetching
the match data all in one.
Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240610142836.168603-2-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The platform_driver_probe() helper is useful when the probe function
is in the _init section, that is not the case here. Use the normal
platform_driver_register() function.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240610142836.168603-1-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The OCP board used a BlueField's GPIO pin for entering
low power mode. That board was not commercialized and
has been dropped from production so all its code is unused.
The new hardware requirement is to trigger a graceful shutdown
when that GPIO pin is toggled. So replace the unused low power
mode with a graceful shutdown.
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
Reviewed-by: David Thompson <davthompson@nvidia.com>
Link: https://lore.kernel.org/r/20240611134327.30975-1-asmaa@nvidia.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
There are two charger current limit registers:
- Fast charge current limit (which controls current going from the
charger to the battery);
- CHGIN input current limit (which controls current going into the
charger through the cable).
Add the necessary functions to retrieve the CHGIN input limit (from CHARGER
regulator) and maximum fast charge current values, and expose them as power
supply properties.
Tested-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240816-max77693-charger-extcon-v4-3-050a0a9bfea0@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Commit 223a3b8283 ("power: supply: max17042_battery: use VFSOC for
capacity when no rsns") made it so that capacity on systems without
current sensing would be read from VFSOC instead of RepSOC. However,
the SOC threshold calculation still read RepSOC to get the SOC
regardless of the current sensing option state.
Fix this by applying the same conditional to determine which register
should be read.
This also seems to be the intended behavior as per the datasheet - SOC
alert config value in MiscCFG on setups without current sensing is set
to a value of 0b11, indicating SOC alerts being generated based on
VFSOC, instead of 0b00 which indicates SOC alerts being generated based
on RepSOC.
This fixes an issue on the Galaxy S3/Midas boards, where the alert
interrupt would be constantly retriggered, causing high CPU usage
on idle (around ~12%-15%).
Fixes: e5f3872d20 ("max17042: Add support for signalling change in SOC")
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240817-max17042-soc-threshold-fix-v1-1-72b45899c3cc@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Allow users to specify a maximum input current for the device. Some
devices allow up to 3.25A of input current (such as the AXP717), which
may be too much for some implementations.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240821215456.962564-7-macroalpha82@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Make reading of the vbus value and configuring of the iio channels
device specific, to allow additional devices (such as the AXP717) to
be supported by this driver.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240821215456.962564-5-macroalpha82@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Move the configuration of battery specific information and available
iio channels from the probe function to a device specific routine,
allowing us to use this driver for devices with slightly different
configurations (such as the AXP717).
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240821215456.962564-4-macroalpha82@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN and
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN values should be immutable
properties of the battery, but for this driver they are writable values
and used as the minimum and maximum values for charging. Remove the
DESIGN designation from these values.
Fixes: 46c202b5f2 ("power: supply: add battery driver for AXP20X and AXP22X PMICs")
Suggested-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240821215456.962564-3-macroalpha82@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Driver reads existing current value from two 8-bit registers, but then
compares only one of them with the new 16-bit value. clang W=1 is also
not happy:
twl4030_charger.c:243:16: error: variable 'cur_reg' set but not used [-Werror,-Wunused-but-set-variable]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240705113113.42851-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Allocate the memory with scoped/cleanup.h to reduce error handling and
make the code a bit simpler.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240705113113.42851-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
based on the alias from platform_device_id table.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20240819040831.2801543-1-ruanjinjie@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
- request the wlan-enable GPIO "as-is" to fix an issue with the wifi
module being already powered up before linux boots
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmbIWRwACgkQEacuoBRx
13JxNRAAjjBfb870YqOzyq9ipsr3UdUybBU7cGfqNgo2+On6ovZ256e3iqWUV1Zf
wS7QGUXh38OGkzj1K3/jGb08S8XyizrL/UWxJfLqYiXrbqAPldA7BrElFDUpjAeN
+tR6JjfgPNZWPPwo9W6I1axgreD2AZyDRb9FQi7x40UzgcnqQiOglzZ6U75HanjP
G9Jm36UbS7akok2/M6IQmDUSWDB8TBFGBswun76qyevePLdtcjqfj06ut3FtMG79
3xZ1w9BxwauXe1upSzSwsINO+2FKq+RvgnJOVFs5H/1+4E/jXzQt8Oro4kuuEkGd
yzCyOCQ//ub9DjKVlNAuG2siLW7QGPSuEXYyRr0AX67dLOC+tCWhnTDKX6d3SCQO
XN6e6pfkicL6nMm2TqPQ72gqLGbFlW5nGLZZtlPcQVC1/ux01z+/cBPVx3/Hw0+K
u3L2JBNi3TQPQrwHd3eCqPx/vCs4f/nudbCKKiWYJDMJiunoTNLjLF5LhKmDAZxm
7Gl1Zq+0/bOz9xY3RiyMd9nFVJjbHchLf7uRaRTqsrVQZPeBfXkMAa7vCJ+ImcD5
w6mA6Ew7512S2+62yY19L9ZFidBeB+QELTghDA2t3bdhcoOK4HWRYWznSsJ6PrMK
KRG9ZHYB6OOwU7JtxwBlqLTSsjB2BQky1QZlj/0H4vB0fM1Lxts=
=d/4T
-----END PGP SIGNATURE-----
Merge tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fix from Bartosz Golaszewski:
- request the wlan-enable GPIO "as-is" to fix an issue with the wifi
module being already powered up before linux boots
* tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: request the WLAN enable GPIO as-is
As pointed out by Stephen Boyd it is possible that during initialization
of the pmic_glink child drivers, the protection-domain notifiers fires,
and the associated work is scheduled, before the client registration
returns and as a result the local "client" pointer has been initialized.
The outcome of this is a NULL pointer dereference as the "client"
pointer is blindly dereferenced.
Timeline provided by Stephen:
CPU0 CPU1
---- ----
ucsi->client = NULL;
devm_pmic_glink_register_client()
client->pdr_notify(client->priv, pg->client_state)
pmic_glink_ucsi_pdr_notify()
schedule_work(&ucsi->register_work)
<schedule away>
pmic_glink_ucsi_register()
ucsi_register()
pmic_glink_ucsi_read_version()
pmic_glink_ucsi_read()
pmic_glink_ucsi_read()
pmic_glink_send(ucsi->client)
<client is NULL BAD>
ucsi->client = client // Too late!
This code is identical across the altmode, battery manager and usci
child drivers.
Resolve this by splitting the allocation of the "client" object and the
registration thereof into two operations.
This only happens if the protection domain registry is populated at the
time of registration, which by the introduction of commit '1ebcde047c54
("soc: qcom: add pd-mapper implementation")' became much more likely.
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Closes: https://lore.kernel.org/all/CAMi1Hd2_a7TjA7J9ShrAbNOd_CoZ3D87twmO5t+nZxC9sX18tA@mail.gmail.com/
Reported-by: Johan Hovold <johan@kernel.org>
Closes: https://lore.kernel.org/all/ZqiyLvP0gkBnuekL@hovoldconsulting.com/
Reported-by: Stephen Boyd <swboyd@chromium.org>
Closes: https://lore.kernel.org/all/CAE-0n52JgfCBWiFQyQWPji8cq_rCsviBpW-m72YitgNfdaEhQg@mail.gmail.com/
Fixes: 58ef4ece1e ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
Cc: stable@vger.kernel.org
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-1-eec53c750a04@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Enable support for controlling the power-up sequence of the PMU inside
the WCN6855 model.
Signed-off-by: Konrad Dybcio <konradybcio@kernel.org>
[Bartosz: split Konrad's bigger patch, write the commit message]
Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20240813190841.155067-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
If the WCN module is powered up before linux boots and the ath11k driver
probes at the same time as the power sequencing driver, we may end up
driving the wlan-enable GPIO low in the latter, breaking the start-up of
the WLAN module. Request the wlan-enable GPIO as-is so that if the WLAN
module is already starting/started, we leave it alone.
Fixes: 2f1630f437 ("power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets")
Reported-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Link: https://lore.kernel.org/r/20240813190751.155035-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Some newer ADSP firmware versions on X1E80100 report an extra __le32 at the
end of the battery information request payload, causing qcom_battmgr to
fail to initialize. Adjust the check to ignore the extra field in the info
payload so we can support both old and newer firmware versions.
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240712-x1e80100-battmgr-v1-1-a253d767f493@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The driver returns -ENODEV when the firmware battmrg service hasn't
started yet, while per-se -ENODEV is fine, we usually use -EAGAIN to
tell the user to retry again later. And the power supply core uses
-EGAIN when the device isn't initialized, let's use the same return.
This notably causes an infinite spam of:
thermal thermal_zoneXX: failed to read out thermal zone (-19)
because the thermal core doesn't understand -ENODEV, but only
considers -EAGAIN as a non-fatal error.
While it didn't appear until now, commit [1] fixes thermal core
and no more ignores thermal zones returning an error at first
temperature update.
[1] 5725f40698b9 ("thermal: core: Call monitor_thermal_zone() if zone temperature is invalid")
Link: https://lore.kernel.org/all/2ed4c630-204a-4f80-a37f-f2ca838eb455@linaro.org/
Cc: stable@vger.kernel.org
Fixes: 29e8142b56 ("power: supply: Introduce Qualcomm PMIC GLINK power supply")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Link: https://lore.kernel.org/r/20240715-topic-sm8x50-upstream-fix-battmgr-temp-tz-warn-v1-1-16e842ccead7@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Round constant_charge_voltage writes down to the first supported lower
value, rather then rounding them up to the first supported higher value.
This fixes e.g. writing 4250000 resulting in a value of 4350000 which
might be dangerous, instead writing 4250000 will now result in a safe
4200000 value.
Fixes: 843735b788 ("power: axp288_charger: axp288 charger driver")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240717200333.56669-2-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
info->max_cv is in millivolts, divide the microvolt value being written
to constant_charge_voltage by 1000 *before* clamping it to info->max_cv.
Before this fix the code always tried to set constant_charge_voltage
to max_cv / 1000 = 4 millivolt, which ends up in setting it to 4.1V
which is the lowest supported value.
Fixes: 843735b788 ("power: axp288_charger: axp288 charger driver")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240717200333.56669-1-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
* power-supply core
- new charging_orange_full_green RGB LED trigger
- simplify and cleanup power-supply LED trigger code
- expose power information via hwmon compatibility layer
* new hardware support
- enable battery support for Qualcomm Snapdragon X Elite
- new battery driver for Maxim MAX17201/MAX17205
- new battery driver for Lenovo Yoga C630 laptop (custom EC)
* cleanup 'struct i2c_device_id' initializations
* misc. small battery driver cleanups and fixes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAmadpdQACgkQ2O7X88g7
+poOIBAAm8B28rdJc35M0qj4akFp67z84wxGs0yR3KmwwUyIv5bHMZKXuSgOdMJ7
bVA/W5Lvzi/Mp6bF5lt4EbFt3QGIEG2odWMWcoc/PTdKaPYC7CcDBVGCZr7hQFJS
2THzaUuLVDQzVwBc62YcFh7AB+xQmJ/SaX+Ci2k//vFyQJ1EfBiOkoq6MjJXCPcT
hz21hXCQjGirNSsV4gxK1EwefrRomj4MVCHCf/E5i2tM2lNtO+HPu28UznJYEh9S
NB+M4Z0EADnfPWoBmB3emonYYlGlYC34kYb6nqcn6sUm9usU9JUMeZBT1yOstUMd
3p5V+uvUFQ9MGqXUgN8Qd5/ZfszCZzX2TaHDnWWRF4g7KTdSpcXOXrLW4gEO3TFf
BtUU0WvZLiwXjMPrtvdTIPJCFTStfLcIAtWEyUhdCLouR2nJsAIYyfMm5OOyktqK
KGeRaJhBp8c2bJTU1Xxj4FkO07z0iSY2EGDFCuEe4sBCN5EMA/ClwN/35P7Fwv30
0sRjzwS/gRkT1IiLRjqu8We3dVUxclkgsXhZ/5UuOzRqTzV7VH0xYdgn6iCOs0nz
RSLFo37DqjIYbAJGcv9E6/7TSy+lB1RVHQL1DsQVKOMTf4NW5REfSoMzbjPClj8u
qYTVoONCXLQEzo8oxuIly9m6eeExA3+2ulvDq00FuDb+pCVZ1ig=
=+h6p
-----END PGP SIGNATURE-----
Merge tag 'for-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull power supply and reset updates from Sebastian Reichel:
"Power-supply core:
- new charging_orange_full_green RGB LED trigger
- simplify and cleanup power-supply LED trigger code
- expose power information via hwmon compatibility layer
New hardware support:
- enable battery support for Qualcomm Snapdragon X Elite
- new battery driver for Maxim MAX17201/MAX17205
- new battery driver for Lenovo Yoga C630 laptop (custom EC)
Cleanups:
- cleanup 'struct i2c_device_id' initializations
- misc small battery driver cleanups and fixes"
* tag 'for-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply:
power: supply: sysfs: use power_supply_property_is_writeable()
power: supply: qcom_battmgr: Enable battery support on x1e80100
power: supply: add support for MAX1720x standalone fuel gauge
dt-bindings: power: supply: add support for MAX17201/MAX17205 fuel gauge
power: reset: piix4: add missing MODULE_DESCRIPTION() macro
power: supply: samsung-sdi-battery: Constify struct power_supply_maintenance_charge_table
power: supply: samsung-sdi-battery: Constify struct power_supply_vbat_ri_table
power: supply: lenovo_yoga_c630_battery: add Lenovo C630 driver
power: supply: ingenic: Fix some error handling paths in ingenic_battery_get_property()
power: supply: ab8500: Clean some error messages
power: supply: ab8500: Use iio_read_channel_processed_scale()
power: supply: ab8500: Fix error handling when calling iio_read_channel_processed()
power: supply: hwmon: Add support for power sensors
power: supply: ab8500: remove unused struct 'inst_curr_result_list'
power: supply: bd99954: remove unused struct 'battery_data'
power: supply: leds: Add activate() callback to triggers
power: supply: leds: Share trig pointer for online and charging_full
power: supply: leds: Add power_supply_[un]register_led_trigger()
power: supply: Drop explicit initialization of struct i2c_device_id::driver_data to 0
- fix an invalid pointer dereference in error path in pwrseq core
- reduce the Kconfig noise from PCI pwrctl choices
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmaaMYkACgkQEacuoBRx
13L0Uw/+JdFxMWwQYKwWs84rKaALFtH4+vKzdZlyonGtTCl8X4wr5JX/jqfjBPof
kO8FIKTIofWiiYkL3A5hvZbfuG9aINzOwle5nYhlSyeR5JN/ZJwVOKzfkFF1vcgK
XJdxBZjD8wIB/foouleLH1+DhQu5d9BuB+NsANCcVo4IqAupK618NEVwTqRmQEPf
M4JdmzVTRSVVnKS9RQ8MbXotfUSAI7GuvSCd+xs5SdTlBcgNNTLx4PUWhcLsSY5t
oJ1TCx4a7MrDaFxjt8IvtsfGl0F5+0GNljxvcgSC/bckTzP6WAJJnCf8EIPpq95z
HPx+7fvyKoScZbup+s2HEbRsqLUDQYFyZ8BjbkLBVn0NZSeJngFyEb2+A4JM/zK2
T2gGQk1Xe9HRwsWwi6Gd5wsL6kcknWdedh1B5m5zss2nIGXxO6Vw0Gz7U1dluS/P
x/Olg2Le4oOahyFnsY4byG9hpO2898m/QHs7NMeCDZA3BEdXP2/+eVlASL6JZ2hl
vRU8s6eheCBaI2iAUPF9Lc9+qtY4ry7b3DqCHDj11xxq+i4IwYErxs6ClsgpPBWZ
l/VEPOFJYzFi1Y448uzn5vNPjPE7AsKn2Fl5ZERl7wTi4x8ZlJpVKiA3Cj3OPW1A
hsuEOMJIVyZFEimexoIWK9sky9tY3mHsdhiE/AsF43Bj3aICTQE=
=I1ot
-----END PGP SIGNATURE-----
Merge tag 'pwrseq-fixes-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fixes from Bartosz Golaszewski:
"There's one fix for an invalid pointer dereference in error path
reported by smatch and two patches that address the noisy config
choices you reported earlier this week.
Summary:
- fix an invalid pointer dereference in error path in pwrseq core
- reduce the Kconfig noise from PCI pwrctl choices"
* tag 'pwrseq-fixes-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
arm64: qcom: don't select HAVE_PWRCTL when PCI=n
Kconfig: reduce the amount of power sequencing noise
power: sequencing: fix an invalid pointer dereference in error path
- Add new Trigger for Input Events
- Add new led_mc_set_brightness() call to adapt colour/brightness for mutli-colour LEDs
- Add new lled_mc_trigger_event() call to call the above based on given trigger conditions
- Add new led_get_color_name() call, a wrapper around the existing led_colors[] array
- Add a new flag to avoid automatic renaming of LED devices
- New Drivers
- Add support for Silergy SY7802 Flash LED Controller
- Add support for Texas Instruments LP5569 LED Controller
- Add support for ChromeOS EC LED Controller
- New Device Support
- Add support for KTD202{6,7} to Kinetic KTD2026/7 LEDs
- Fix-ups
- Replace ACPI/DT firmware helpers with agnostic variants
- Make use of resource managed devm_* API calls
- Device Tree binding adaptions/conversions/creation
- Constify/staticise applicable data structures
- Trivial; spelling, whitespace, coding-style adaptions
- Drop i2c_device_id::driver_data where the value is unused
- Utilise centrally provided helpers and macros to aid simplicity/duplication
- Use generic platform device properties instead of OF/ACPI specific ones
- Consolidate/de-duplicate various functionality
- Remove superfluous/duplicated/unused sections
- Make use of the new *_scoped() guard APIs
- Improve/simplify error handling
- Bug Fixes
- Flush pending brightness changes before activating the trigger
- Repair incorrect device naming preventing matches
- Prevent memory leaks by correctly free resources during error handling routines
- Repair locking issue causing circular dependency splats and lock-ups
- Unregister sysfs entries before deactivating triggers to prevent use-after issues
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Use correct return codes expected by the callers
- Omit set_brightness() error message for a LEDs that support only HW triggers
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmaWgMEACgkQUa+KL4f8
d2Glng//Sw3+ev7IFn4PmNfMHtKeWlJEerT8kyF0GdK05zn7ImlydkSVW5RvHN8B
J2A8cfXXkhggYoG2i4zjs1wtfPDXP9iJMhVaRnPPuWgYJpPrhUFSSkJKiauSKyGN
Tp3Vn6QaHM5Gs/THUidcTV0+USE6j9+DXdLjLASAi2YXqoGCC3KWcq4Hb6NdGM/Q
ajEuGnrO1HEF0dOaEgkYuNIXcADHzeeQlU0Y96bGv7qnUBw7LAIpH+AC1d49jcXS
gIJNxmtmn0QqCK0/lS74DmR9r2quofeYer6G5WDJVv72R8KIljFN16AGFLdC8ID/
3B4JnjQKpEyn344gmvqzx23dp3jqvCupgDcojR6RY7yIZTXSjg0R0OocKYQlDnNY
LoNZqZ9J2nNDWNlx7r7PXuIAm7Bb9kdY0/PWgXOwWsEb19DcxyAHE3+xGeyQF6f5
/s1bGZxQyfBnDZm8+XiJ6KTsiZ1t0MljG9y7xil6vtzJIJTynao9qzZipcrx7UuT
3UyoGa/Z4o95OkQye9n6tKGJJDKLJIZL7x4pGOW3HeHgfvJ1koyHr8WwhmK4Zoh/
xeHfHABuaMoulTsuGjtnRP4/UWOTEf2hh7FK1mSrpxSCvv+I9W4lTO9QBkXU8xuD
1oCekcTYWOwKhxaFX4jjaGEHXIWYzXDjE7hqroLzj8Ifhqe9xrc=
=0Kyu
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Frameworks:
- New trigger for Input Events
- New led_mc_set_brightness() call to adapt colour/brightness for
mutli-colour LEDs
- New lled_mc_trigger_event() call to call the above based on given
trigger conditions
- New led_get_color_name() call, a wrapper around the existing
led_colors[] array
- A new flag to avoid automatic renaming of LED devices
New Drivers:
- Silergy SY7802 Flash LED Controller
- Texas Instruments LP5569 LED Controller
- ChromeOS EC LED Controller
New Device Support:
- KTD202{6,7} support for Kinetic KTD2026/7 LEDs
Fix-ups:
- Replace ACPI/DT firmware helpers with agnostic variants
- Make use of resource managed devm_* API calls
- Device Tree binding adaptions/conversions/creation
- Constify/staticise applicable data structures
- Trivial; spelling, whitespace, coding-style adaptions
- Drop i2c_device_id::driver_data where the value is unused
- Utilise centrally provided helpers and macros to aid simplicity and
avoid duplication
- Use generic platform device properties instead of OF/ACPI specific
ones
- Consolidate/de-duplicate various functionality
- Remove superfluous/duplicated/unused sections
- Make use of the new *_scoped() guard APIs
- Improve/simplify error handling
Bug Fixes:
- Flush pending brightness changes before activating the trigger
- Repair incorrect device naming preventing matches
- Prevent memory leaks by correctly free resources during error
handling routines
- Repair locking issue causing circular dependency splats and
lock-ups
- Unregister sysfs entries before deactivating triggers to prevent
use-after issues
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Use correct return codes expected by the callers
- Omit set_brightness() error message for a LEDs that support only HW
triggers"
* tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (65 commits)
leds: leds-lp5569: Enable chip after chip configuration
leds: leds-lp5569: Better handle enabling clock internal setting
leds: leds-lp5569: Fix typo in driver name
leds: flash: leds-qcom-flash: Test the correct variable in init
leds: leds-lp55xx: Convert mutex lock/unlock to guard API
leds: leds-lp5523: Convert to sysfs_emit API
leds: leds-lp5569: Convert to sysfs_emit API
Revert "leds: led-core: Fix refcount leak in of_led_get()"
leds: leds-lp5569: Add support for Texas Instruments LP5569
leds: leds-lp55xx: Drop deprecated defines
leds: leds-lp55xx: Support ENGINE program up to 128 bytes
leds: leds-lp55xx: Generalize sysfs master_fader
leds: leds-lp55xx: Generalize sysfs engine_leds
leds: leds-lp55xx: Generalize sysfs engine_load and engine_mode
leds: leds-lp55xx: Generalize stop_engine function
leds: leds-lp55xx: Generalize turn_off_channels function
leds: leds-lp55xx: Generalize set_led_current function
leds: leds-lp55xx: Generalize multicolor_brightness function
leds: leds-lp55xx: Generalize led_brightness function
leds: leds-lp55xx: Generalize firmware_loaded function
...
- add the pwrseq core framework
- add the first power sequencing driver: pwrseq-qcom-wcn
- add power control (pwrctl) changes to PCI core
- add the first PCI pwrctl power sequencing driver
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmaQ72wACgkQEacuoBRx
13K4fg//Qd8vxOH06/VSJRCwEvilUfYgDe/WiqTcBXL+8cK/3B0fUhfD83wgMnJn
/yw2GgS5OjAvYe47nvM4T5M/XMpQ967XTED9cXxJWpBwcee+LZ6hsBGlPuSRunpo
DQ4EuDh8wQ4j8Gw5pXj7dgtCN7zx4Idj+amh9i2ep+/7ZqT9UFqe294Tq9pX0X+a
rhOrTooQo4uiwpSAh6k1db3o1VpVDhlx+m2CCQV6V5F3r7eiPv2tQE2B8GvlJlY/
KjGECsbxKMch6dtKQumRnn3R07v1b3SlQOQOSP99blNv8dfDBOKS0dFPI4se2n2b
FvKCtmfC9QD9MPvTFKGSIZTTLMInfGpniLyxMD3Ubu+l26AA7eLpv4BICExFo71c
5gM/Xm8ypsrW7WadhAsl0mNS1CpbFZ2jNTBtuBrP5AFTMOvPqmYbN0VjRgYbX0Yw
qXyu540iP8t8c0eTqRyrabhXFEehTso5cJGqtKvIARuoK1rF+wOPxTBU+RHjJWg/
xp7ckCGP+VymcD1xNGpHPweHxwu0z2RMI4zYg2i6WOjWz6FY/V2x1Pf3PGlXF7pq
yaTMqK5tiGizCF2/RNFGDFQ8re0qtZfh6/mNtT45GGbUBaYltPGQFdFhsaI6rwEi
LMO7M387u0fPJlS0/ib8I+S5ZfKo65xjC/jQSuUL8WfQf85Ck9k=
=rI5g
-----END PGP SIGNATURE-----
Merge tag 'pwrseq-updates-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing updates from Bartosz Golaszewski:
"This has been in development since last year's Linux Plumbers
Conference and was inspired by the need to enable support upstream for
Bluetooth/WLAN chips on Qualcomm platforms.
The main problem we're fixing is powering up devices which are
represented as separate objects in the kernel (binding to different
drivers) but which share parts of the power-up sequence and thus need
some kind of a mediator who knows the possible interactions and can
assure they don't interfere with neither device's bring up. An example
of such an inter-driver interaction is the WCN family of BT/WLAN chips
from Qualcomm of which some models require the user to observe a
certain delay between driving the bt-enable and wlan-enable GPIOs.
This is not a new problem but up to this point all attempts at
addressing it ended up hitting one wall or another and being dropped.
The main obstacle was the fact that most these attempts tried to
introduce the concept of a "power sequence" into the device-tree
bindings which breaks the main DT rule: describe the hardware, not its
behavior. The solution I proposed focuses on making the power
sequencer drivers interpret the actual HW description flexibly. More
details on that are in the linked cover letter.
The second problem fixed here is powering up PCI devices before they
are detected on the bus. This is achieved by creating special platform
devices for device-tree nodes describing hard-wired PCI devices which
bind to the so-called PCI power control drivers which enable required
resources and trigger a bus rescan once the controlled device is up
then setup the correct devlink hierarchy for power-management.
By combining the two new frameworks we implemented the power
sequencing PCI power control driver which is capable of powering up
the WLAN modules of the QCom WCN family of chipsets.
All this has spent a significant amount of time in linux-next and
enabled WLAN/BT support on several Qualcomm platforms. To further
prove that this is useful and needed: right after this was picked up
into next, I was sent a series using the subsystem for a similar
use-case on Amlogic platforms.
This contains the core power sequencing framework, the first driver,
PCI changes using the pwrseq library (blessed by Bjorn Helgaas) and
some fixes that came later"
* tag 'pwrseq-updates-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
PCI/pwrctl: only call of_platform_populate() if CONFIG_OF is enabled
power: sequencing: simplify returning pointer without cleanup
PCI/pwrctl: Add a PCI power control driver for power sequenced devices
PCI/pwrctl: Add PCI power control core code
PCI/pwrctl: Create platform devices for child OF nodes of the port node
PCI/pwrctl: Reuse the OF node for power controlled devices
PCI: Hold the rescan mutex when scanning for the first time
power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
power: sequencing: implement the pwrseq core
The C standard is vague about the signedness of enums, but in this case
here, they are treated as unsigned so the error handling does not work.
Use an int type to fix this.
Fixes: c6ed48ef52 ("power: supply: add ChromeOS EC based charge control driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/ZoWKEs4mCqeLyTOB@stanley.mountain
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The x1e80100, being a compute platform, provides functionality for the
exact same power supplies as sc8280xp. Add the compatible and assign
the sc8280xp match data.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240621-x1e80100-power-supply-qcom-battmgr-v1-1-40cb89a0c144@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The MAX17201 monitors a single cell pack. The MAX17205 monitors and
balances a 2S or 3S pack or monitors a multiple-series cell pack. Both
devices use a I2C interface.
Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com>
Link: https://lore.kernel.org/r/20240702090308.8848-3-dima.fedrau@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Clang warns (or errors with CONFIG_WERROR=y):
drivers/power/supply/cros_charge-control.c:319:2: error: array index 3 is past the end of the array (that has type 'struct attribute *[3]') [-Werror,-Warray-bounds]
319 | priv->attributes[_CROS_CHCTL_ATTR_COUNT] = NULL;
| ^ ~~~~~~~~~~~~~~~~~~~~~~
drivers/power/supply/cros_charge-control.c:49:2: note: array 'attributes' declared here
49 | struct attribute *attributes[_CROS_CHCTL_ATTR_COUNT];
| ^
1 error generated.
In earlier revisions of the driver, the attributes array in
cros_chctl_priv had four elements with four distinct assignments but
during review, the number of elements was changed to three through use
of an enum and the assignments became a for loop, except for this one,
which is now out of bounds. This assignment is no longer necessary
because the size of the attributes array no longer accounts for it, so
just remove it to clear up the warning.
Fixes: c6ed48ef52 ("power: supply: add ChromeOS EC based charge control driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240702-cros_charge-control-fix-clang-array-bounds-warning-v1-1-ae04d995cd1d@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Framework laptops implement a custom charge control EC command.
The upstream CrOS EC command is also present and functional but can get
overridden by the custom one.
Until Framework make both commands compatible or remove their custom
one, don't load the driver on those machines.
If the user knows they are not going to use the custom command they can
use a module parameter to load cros_charge-control anyways.
Note that the UEFI setup configuration for battery control also uses
their custom command.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-5-8f649d018c52@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The ChromeOS Embedded Controller implements a command to control charge
thresholds and behaviour.
Use it to implement the standard Linux charge_control_start_threshold,
charge_control_end_threshold and charge_behaviour sysfs UAPIs.
The driver is designed to be probed via the cros_ec mfd device.
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-4-8f649d018c52@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/power/reset/piix4-poweroff.o
Add the missing invocation of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240608-md-drivers-power-reset-v1-1-08dbc1a546a2@quicinc.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
'struct power_supply_maintenance_charge_table' is not modified in this
driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
In order to do it, some code also needs to be adjusted to this new const
qualifier.
On a x86_64, with allmodconfig:
Before:
======
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o
After:
=====
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
4087 4552 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/6caafd0ac2556a40405273b1a4badc508ea8e9b0.1719125040.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
'struct power_supply_vbat_ri_table' are not modified in this driver.
Constifying these structures moves some data to a read-only section, so
increase overall security.
In order to do it, some code also needs to be adjusted to this new const
qualifier.
On a x86_64, with allmodconfig:
Before:
======
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
955 7664 0 8619 21ab drivers/power/supply/samsung-sdi-battery.o
After:
=====
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/d01818abd880bf435d1106a9a6cc11a7a8a3e661.1719125040.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
On the Lenovo Yoga C630 WOS laptop the EC provides access to the adapter
and battery status. Add the driver to read power supply status on the
laptop.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240621-yoga-ec-driver-v8-1-daae67d0233d@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
If iio_read_channel_processed() fails, 'val->intval' is not updated, but it
is still *1000 just after. So, in case of error, the *1000 accumulate and
'val->intval' becomes erroneous.
So instead of rescaling the value after the fact, use the dedicated scaling
API. This way the result is updated only when needed. In case of error, the
previous value is kept, unmodified.
This should also reduce any inaccuracies resulting from the scaling.
Finally, this is also slightly more efficient as it saves a function call
and a multiplication.
Fixes: fb24ccfbe1 ("power: supply: add Ingenic JZ47xx battery driver.")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Artur Rojek <contact@artur-rojek.eu>
Link: https://lore.kernel.org/r/51e49c18574003db1e20c9299061a5ecd1661a3c.1719121781.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
There is an useless extra comma at the end of some error messages, remove
them.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/e7ac0fa83c6100cbe4e0efa90cf99291c2423b10.1719037737.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Instead of rescaling current or voltage channels after the fact, use the
dedicated scaling API. This should reduce any inaccuracies resulting from
the scaling.
This is also slightly more efficient as it saves a function call and a
multiplication.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/5668d73b92eb6318c7f094a9a8fa914c909485ca.1719037737.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The ab8500_charger_get_[ac|vbus]_[current|voltage]() functions should
return an error code on error.
Up to now, an un-initialized value is returned.
This makes the error handling of the callers un-reliable.
Return the error code instead, to fix the issue.
Fixes: 97ab78bac5 ("power: supply: ab8500_charger: Convert to IIO ADC")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/f9f65642331c9e40aaebb888589db043db80b7eb.1719037737.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This adds the power sequencing driver for the PMU modules present on the
Qualcomm WCN Bluetooth and Wifi chipsets. It uses the pwrseq subsystem
and knows how to match the sequencer to the consumer device by verifying
the relevant properties and DT layout. Using this driver will allow the
BT and WLAN drivers to respect the required delays between enabling the
two modules.
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD, SM8650-QRD & SM8650-HDK
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240605123850.24857-3-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Implement the power sequencing subsystem allowing devices to share
complex powering-up and down procedures. It's split into the consumer
and provider parts but does not implement any new DT bindings so that
the actual power sequencing is never revealed in the DT representation.
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD, SM8650-QRD & SM8650-HDK
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240605123850.24857-2-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Commit 3a93da231c ("power: supply: rt5033: Use devm_power_supply_register() helper")
reworked the driver to use devm. While at it, the i2c_set_clientdata
was dropped along with the remove callback. Unfortunately other parts
of the driver also rely on i2c clientdata so this causes kernel oops.
Bring the call back to fix the driver.
Fixes: 3a93da231c ("power: supply: rt5033: Use devm_power_supply_register() helper")
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20240605-rt5033-null-clientdata-v1-1-558d710eeb4d@trvn.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Currently, more than seven power supply drivers are supporting
POWER_SUPPLY_PROP_POWER_NOW, but their power readings are not being
reported through the hwmon subsystem.
Fix this by adding support for power sensors to the power supply
hwmon integration.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20240528222115.791511-1-W_Armin@gmx.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
'inst_curr_result_list' is unused since the original
commit 13151631b5 ("ab8500-fg: A8500 fuel gauge driver").
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240528000634.196707-3-linux@treblig.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
'battery_data' is unused since the original
commit 0902f83664 ("power: supply: Support ROHM bd99954 charger").
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20240528000634.196707-2-linux@treblig.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add an activate() callback to the power-supply LED triggers so that
the LED being activated will properly reflect the current power-supply
state for power-supply devices which are already fully registered
when the trigger gets activated.
This fixes e.g. wrong LED state (1) when the LED gets registered
after the power-supply device.
1) Until the psy driver has a reason to call power_supply_changed()
which may take quite a while
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531134702.166145-4-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Either 5 different LED triggers are registered for battery power-supply
devices or a single online LED trigger is used for non battery power-supply
devices.
These 5 / 1 LED trigger(s) are never used at the same time. So there is
no need for a separate LED trigger pointer for the online trigger. Rename
the first battery trigger from charging_full_trig to just trig and use this
for the online trigger too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531134702.166145-3-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add power_supply_[un]register_led_trigger() helper functions.
The primary goal of this is as a preparation patch for adding an activate
callback to the power-supply LED triggers to ensure that power-supply
LEDs get the correct initial value when the LED gets registered after
the power_supply has been registered (this will use the psy back pointer).
There also is quite a lot of code duplication in the existing LED trigger
registration in the form of the kasprintf() for the name-template for each
trigger + related error handling. This duplication is removed by these
new helpers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531134702.166145-2-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmZZ1mAACgkQUa+KL4f8
d2FTKA//T3n1ouAmIGtIBKLmfWgDCfo+ryfLUrcSPdpD/u+E27wwm8TyGC6Rau40
sRDnP9Yf2otgu1TB1UEKfjIq28si81BFdVWkCYz5ycPhTGzYXb0aQ+rfqcBCTtyj
cYPM9OYaF898jPRlahUtpcJlw8UYzbUSjD6bxYCAc6WeBINha6iaOGbhBzY/ELvi
WC/cLZ06iVb4h1uEMAPoRTg6SFuONfWYXsDk9lVbL+ig6Dmk7LWSX5A+ly4fdzX6
6fR6DbUpmdAI17SSCDx2G7TgIfX1gFnDg0BVpHk7Z3xbX00H8tsUSVXnd/gSGn+4
Yj5ys2eHxB3WCSyGTOV38ur8quTt61XwyYFHmeaNt7gZ+BI5QcYDtBZrJlkCrDEg
FocXpbmRz2Zki9wjsHqatDAS46ku/P3cF4ssb+/yQB73s9L0OSt8/+1ml79tYnU6
s9jmKlUOT8I6iR8p1fmRHsq8oQchyrj2Vrxax6SJtfrsF0h4CqUMftKMOK5wSbkC
VK420lM/x45dU3FsgjTIikszy3PCYit3GRQKQL4bUJwegyQi2MDyMaga7c/1UwSY
mo3TE77PK+SEPOq3HzkQiolLlM9Iq1w9N3OEUFN+Y3epaz87sOqaClYLWNpJ3eFu
EFDRAJDJx1huRy11slw0fnH39i0XJQz8kklxSZ1dA18URpNJPz0=
=nAvT
-----END PGP SIGNATURE-----
Merge tag 'ib-leds-platform-power-v6.11'
Immutable branch between LEDs, Power and RGB due for the v6.11 merge
window.
Merge it to provide functionality required by power-supply specific
LED handler cleanups depending on the newly added (multi-colour) LED
features.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add a charging_orange_full_green LED trigger and the trigger is based on
led_mc_trigger_event() which can set an RGB LED when the trigger is
triggered. The LED will show orange when the battery status is charging.
The LED will show green when the battery status is full.
Link: https://lore.kernel.org/linux-leds/f40a0b1a-ceac-e269-c2dd-0158c5b4a1ad@gmail.com/
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
[hdegoede@redhat.com change color order to RGB]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531114124.45346-7-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also remove commas after the sentinel entries.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240522164830.61646-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
further deprecate class based I2C device instantiation. All users are
converted, too. Other that that, Andi collected a number if I2C host
driver patches. Those merges have their own description.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmZLFfoACgkQFA3kzBSg
KbaTlxAAq+VXWNEEK41X6SNVnzwm1H9zoq/vg92rQ1oKh/AUfO6W4pJTg3OQz0gT
4x5Z4yeRZwtWE7zdTQlQUdUvcj490cTUF9f7gTTeH0uhFCyECzOZSIpa4kG+A/mI
JUCCVLMziq6rIscYFdomvKSzwitzhoCuLVsOthYgK3TvbbGH6FHe4h6MDP/u3ok7
seL7ZhqsudL26fFv5+U9095xM0OLDB1R7+DJXaibS6hY1/+WX3qMWHjCF7tf4gAr
bHg/LaDNIiW2pwj7LFhaLrQzchxV/zPKRJYlO05M4mn9hxyVM9ztKtGPLRqglZEX
yPqD857/Rac4y30PihWSVf4uG9pJWY0BEMjucuL0DZLX98C8kqJKK1SSi1FMd5qf
ROAlCMQt+pSVcO6V9cEVIxzpJ2ZhAT4NM2T7yaGrdt6WX9W/an9hNqPcMUBVU6G2
Fzk960eftI/V+IRGswHuBD4w4duIlxUMWd5961UdI0LqzQrhzyNq3IZu/jpw49DH
ZnJ/0UPkV9FfZvZpglf/ztlUESkCqWFjbxOfiejHCnUrvla5JGQTPXVTyP9p38X9
cxevlLgdsKz4F9WqEzpeI7L0HrxpTI863lmhFy+LuWYjYUfYSqIbiB0lWuCP+9Fy
Cjnfp8KRp0lJD206Yyj4WC1B8xi1G44MkB2seGH7GtejM4I9A+U=
=viLd
-----END PGP SIGNATURE-----
Merge tag 'i2c-for-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c updates from Wolfram Sang:
"i2c core removes an argument from the i2c_mux_add_adapter() call to
further deprecate class based I2C device instantiation. All users are
converted, too.
Other that that, Andi collected a number if I2C host driver patches.
Those merges have their own description"
* tag 'i2c-for-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (72 commits)
power: supply: sbs-manager: Remove class argument from i2c_mux_add_adapter()
i2c: mux: Remove class argument from i2c_mux_add_adapter()
i2c: synquacer: Fix an error handling path in synquacer_i2c_probe()
i2c: acpi: Unbind mux adapters before delete
i2c: designware: Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
i2c: pxa: use 'time_left' variable with wait_event_timeout()
i2c: s3c2410: use 'time_left' variable with wait_event_timeout()
i2c: rk3x: use 'time_left' variable with wait_event_timeout()
i2c: qcom-geni: use 'time_left' variable with wait_for_completion_timeout()
i2c: jz4780: use 'time_left' variable with wait_for_completion_timeout()
i2c: synquacer: use 'time_left' variable with wait_for_completion_timeout()
i2c: stm32f7: use 'time_left' variable with wait_for_completion_timeout()
i2c: stm32f4: use 'time_left' variable with wait_for_completion_timeout()
i2c: st: use 'time_left' variable with wait_for_completion_timeout()
i2c: omap: use 'time_left' variable with wait_for_completion_timeout()
i2c: imx-lpi2c: use 'time_left' variable with wait_for_completion_timeout()
i2c: hix5hd2: use 'time_left' variable with wait_for_completion_timeout()
i2c: exynos5: use 'time_left' variable with wait_for_completion_timeout()
i2c: digicolor: use 'time_left' variable with wait_for_completion_timeout()
i2c: amd-mp2-plat: use 'time_left' variable with wait_for_completion_timeout()
...
Commit 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based
device instantiation") removed the last call to i2c_mux_add_adapter()
with a non-null class argument. Therefore the class argument can be
removed.
Note: Class-based device instantiation is a legacy mechanism which
shouldn't be used in new code, so we can rule out that this argument
may be needed again in the future.
This driver was forgotten by the patch in the Fixes tag.
Fixes: fec1982d70 ("i2c: mux: Remove class argument from i2c_mux_add_adapter()")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The of_match shall correspond to the name of the regulator subnode,
or the deprecated `regulator-compatible` property must be used:
failing to do so, the regulator won't probe (and the driver will
as well not probe).
Since the devicetree binding for this driver is actually correct
and wants DTs to use the "usb-otg-vbus-regulator" subnode name,
fix this driver by aligning the `of_match` string to what the DT
binding wants.
Fixes: 0402e8ebb8 ("power: supply: mt6360_charger: add MT6360 charger support")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20240410084405.1389378-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The rt9455_boost_voltage_values[] array is only used when USB PHY
support is enabled, causing a W=1 warning otherwise:
drivers/power/supply/rt9455_charger.c:200:18: error: 'rt9455_boost_voltage_values' defined but not used [-Werror=unused-const-variable=]
Enclose the definition in the same #ifdef as the references to it.
Fixes: e86d69dd78 ("power_supply: Add support for Richtek RT9455 battery charger")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20240403080702.3509288-10-arnd@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Most of the functions that read values return a status and put the value
itself in an a function parameter. Update health reading to match.
As health is not checked for changes as part of the update loop, remove
the read of this from the periodic update loop. This saves I2C/1W
bandwidth. It also means we do not have to cache it, fresh values are
read when requested.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240325203129.150030-6-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Most of the functions that read values return a status and put the value
itself in an a function parameter. Update cycle count reading to match.
As cycle count is not checked for changes as part of the update loop,
remove the read of this from the periodic update loop. This saves I2C/1W
bandwidth. It also means we do not have to cache it, fresh values are
read when requested.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240325203129.150030-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Most of the functions that read values return a status and put the value
itself in an a function parameter. Update energy reading to match.
As energy is not checked for changes as part of the update loop,
remove the read of this from the periodic update loop. This saves
I2C/1W bandwidth. It also means we do not have to cache it, fresh
values are read when requested.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240325203129.150030-4-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Most of the functions that read values return a status and put the value
itself in an a function parameter. Update charge reading to match.
As charge state is not checked for changes as part of the update loop,
remove the read of this from the periodic update loop. This saves
I2C/1W bandwidth. It also means we do not have to cache it, fresh
values are read when requested.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240325203129.150030-3-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Most of the functions that read values return a status and put the value
itself in an a function parameter. Update time reading to match.
As time is not checked for changes as part of the update loop, remove
the read of the this from the periodic update loop. This saves
I2C/1W bandwidth. It also means we do not have to cache it, fresh
values are read when requested.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240325203129.150030-2-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Most of the functions that read values return a status and put the value
itself in an a function parameter. Update temperature reading to match.
As temp is not checked for changes as part of the update loop, remove
the read of the temperature from the periodic update loop. This saves
I2C/1W bandwidth. It also means we do not have to cache it, fresh
values are read when requested.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240325203129.150030-1-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The function power_supply_show_charge_behaviour() is not needed and can
be removed completely.
Removing the function also saves a spurious read of the property from
the driver on each call.
The convulted logic was a leftover from an earlier patch revision.
Some restructuring made this cleanup possible.
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/all/9e035ae4-cb07-4f84-8336-1a0050855bea@redhat.com/
Fixes: 4e61f1e9d5 ("power: supply: core: fix charge_behaviour formatting")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240329-power-supply-simplify-v1-1-416f1002739f@weissschuh.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
* 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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAmXyI98ACgkQ2O7X88g7
+prwAQ/+OyQSOwPQYvPe46YFVKwN+cDyEqgqwu3ndHgbx3x/VNbRDzsykQVIKp1/
H57CzESX6tHA+gdnXBGCHSVBEGuBy3broJi4FBI6DuLmHM0ezIDoYrzScS+yanza
0cmYDjqUDGfcyAO5xstjXY+yEZ3Dju2pd+uNM66b73FDh1Ch6wj96KTWTSUOO0zb
O8vbSqfltE6FeqKrtVH3itodiGP5rEcEGypiwl9DG0PCbqKGbgm7TWW7vNcHvMUl
BYZnJeVmrtHa18uAt6JtO5xB9pb6dst2GZf3cMtLBeAUDvO5mzz4MxEk3FczPnIQ
sBEBn4GCpgvctIt7I2TPmG+sjNTCv2BX6SWEtmQECMK8w+J9LlEM3Y0dwzP/c87z
9nrnYDbK/RBtI/C6FEOb5Eb/IYR/2J6l7B1dJOKFgqZI/HnFRn4U+dUJWL/LL9Vg
QH2hUkiply/7F6ziq7LRFfvDDohZbRnrlBuEjYII5GPyFVBLU2pjtw6wBWsqYUG9
cm3+BAx+idHjuOP9rxLWBUOBIFhqUkkAjZscTM7FUbEtgXbb7bGQcnjvSBZN/k4O
4bhW9PFjDa6Isioy3dM+TRmxbn06r8fLa330rcCIhD1kf1zTM8M0sNGM0HixE/+t
MThYC1dmXl5gQ59OlW3wa192mzim1iTFx1mkXSvlAOzRbGcFY20=
=II3q
-----END PGP SIGNATURE-----
Merge tag 'for-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
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>
As reported by the kernel test robot, 'power_supply_attr_group' is defined
but not used when CONFIG_SYSFS is not set. Sebastian suggested that the
correct fix implemented by this patch, instead of my attempt in commit
ea4367c40c ("power: supply: core: move power_supply_attr_group into #ifdef
block"), is to define power_supply_attr_groups in power_supply_sysfs.c and
expose it in the power_supply.h header. For the case where CONFIG_SYSFS=n,
define it as NULL.
Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Fixes: ea4367c40c ("power: supply: core: move power_supply_attr_group into #ifdef block")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202403021518.SUQzk3oA-lkp@intel.com/
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240303-class_cleanup-power-v2-1-e248b7128519@marliere.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Technically the sysfs attributes should be initialized
before the class is registered, since that will use them.
As a nice side effect this nicely simplifies the code,
since it allows dropping the helper variable.
Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240301-psy-class-cleanup-v1-2-aebe8c4b6b08@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Introduce power_supply_for_each_device(), which is a wrapper
for class_for_each_device() using the power_supply_class and
going through all devices.
This allows making the power_supply_class itself a local
variable, so that drivers cannot mess with it and simplifies
the code slightly.
Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240301-psy-class-cleanup-v1-1-aebe8c4b6b08@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Since commit 43a7206b09 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the power_supply_class structure to be declared at build
time placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240301-class_cleanup-power-v1-1-97e0b7bf9c94@marliere.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Provide the Online property. This chip does not have specific flags to
indicate the presence of an input voltage, but this is implied by all valid
charging states. Fault states also only occur when VBUS is present, so set
Online true for those as well.
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Link: https://lore.kernel.org/r/20240229063721.2592069-2-absicsz@gmail.com
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>
The static global variable sysc_base2 is no longer used outside the
probe method and the reset handler, so it can be converted to a local
variable, and passed to the reset handler via its callback data.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/35f04935c48ae55dc562071e0a1d6fca65234a58.1708944642.git.geert+renesas@glider.be
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>
The ROCK Pi X is a single board computer without batteries using the
AXP288 PMIC where the EFI code does not disable the charger part of
the PMIC causing us to report a discharging battery with a continuously
consumed battery charge to userspace.
Add it to the deny-list to avoid the bogus battery status reporting.
Signed-off-by: Guoyi Zhang <kuoi@bioarchlinux.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240221083425.440108-1-kuoi@bioarchlinux.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The registers related to reset generation are located in the second
register block. However, the conversion to device life-cycle managed
ioremap function accidentally changed the mapping to the first register
block.
Fixes: 0867276eb1 ("power: reset: rmobile-reset: Use devm_platform_ioremap_resource() helper")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/3b267fb1b303f63248934a1a77bee319e1c44879.1708458882.git.geert+renesas@glider.be
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The devm_platform_ioremap_resource() function returns error points. It
never returns NULL. Update the check accordingly.
Fixes: 7ddfd33c6e ("power: reset: xgene-reboot: Use devm_platform_ioremap_resource() helper")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/fe1b90d0-7234-4e03-accc-69a119f6a7eb@moroto.mountain
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>
Use device life-cycle managed register function to simplify probe and
exit paths.
This also makes our data struct per-device and not global, which allows
for more than one instance of this device.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240212162831.67838-20-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Currently all these device data elements are top level global variables.
Move these into a struct. This will be used in the next patch when
the global variable usage is removed. Doing this in two steps makes
the patches easier to read.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240212162831.67838-19-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-18-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-17-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-16-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-15-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-14-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use this helper to register sys_off handler. Drivers should move away from
setting pm_power_off directly as it only allows for one handler. The new
way allows for trying multiple if the first one doesn't work.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-13-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240212162831.67838-12-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-11-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed ioremap function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-10-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-9-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240212162831.67838-8-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
We only need one member of the struct tps65086_restart, pass that
tps65086_restart_notify() directly. Remove that struct and its
allocation.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-7-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-6-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240212162831.67838-4-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240212162831.67838-3-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe and
exit paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240212162831.67838-2-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The driver uses regmap APIs so it should make sure they are available.
Fixes: c75f4bf680 ("power: supply: Introduce MM8013 fuel gauge driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240204-mm8013-regmap-v1-1-7cc6b619b7d3@weissschuh.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The axp803 and axp813 chips can report the detected USB BC mode. SDP,
CDP, and DCP are supported.
Signed-off-by: Aren Moynihan <aren@peacevolution.org>
Link: https://lore.kernel.org/r/20240130203714.3020464-5-aren@peacevolution.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <aren@peacevolution.org>
Link: https://lore.kernel.org/r/20240130203714.3020464-4-aren@peacevolution.org
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>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240129190246.73067-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240129190246.73067-4-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240129190246.73067-3-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240129190246.73067-2-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-22-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-21-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-20-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-19-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-18-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-17-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-15-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-14-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-13-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-12-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-11-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-7-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-6-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-4-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-3-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123163653.384385-2-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123150914.308510-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123150914.308510-4-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123150914.308510-3-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123150914.308510-2-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <afd@ti.com>
Link: https://lore.kernel.org/r/20240123150914.308510-1-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This reverts commit b43f7ddc2b.
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: b43f7ddc2b ("power: supply: qcom_battmgr: Register the power supplies after PDR is up")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240123160053.18331-1-johan+linaro@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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: b150a703b5 ("power: supply: bq24190_charger: Add support for BQ24296")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240103-fix-bq24190_charger-vbus_desc-non-const-v1-1-115ddf798c70@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <chenhuiz@axis.com>
Link: https://lore.kernel.org/r/20231208034708.1248389-3-Hermes.Zhang@axis.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <konrad.dybcio@linaro.org>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231218-topic-battmgr_fixture_attempt-v1-1-6145745f34fe@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
devm_kasprintf and devm_kzalloc return a pointer to dynamically
allocated memory which can be NULL upon failure.
Fixes: 8648aeb5d7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver")
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Link: https://lore.kernel.org/r/20231124075021.1335289-1-chentao@kylinos.cn
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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: dde74a5de8 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
Fixes: 099806de68 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <charmitro@posteo.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <charmitro@posteo.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use device life-cycle managed register function to simplify probe error
path and eliminate need for explicit remove function.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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: 32e4978bb9 ("power: supply: bq256xx: Introduce the BQ256XX charger driver")
Signed-off-by: Su Hui <suhui@nfschina.com>
Link: https://lore.kernel.org/r/20231116041822.1378758-1-suhui@nfschina.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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: b4c7715c10 ("power: supply: add CellWise cw2015 fuel gauge driver")
Signed-off-by: Jan Palus <jpalus@fastmail.com>
Link: https://lore.kernel.org/r/20231111221704.5579-1-jpalus@fastmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20231105094712.3706799-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20231105094712.3706799-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-30-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-29-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-28-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-27-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-26-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-25-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20231104211501.3676352-24-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-23-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-22-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20231104211501.3676352-21-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231104211501.3676352-20-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
On today's platforms the benefit of platform_driver_probe() isn't that
relevant any more. It allows to drop some code after booting (or module
loading) for .probe() and discard the .remove() function completely if
the driver is built-in. This typically saves a few 100k.
The downside of platform_driver_probe() is that the driver cannot be
bound and unbound at runtime which is ancient and so slightly
complicates testing. There are also thoughts to deprecate
platform_driver_probe() because it adds some complexity in the driver
core for little gain. Also many drivers don't use it correctly. This
driver for example misses to mark the driver struct with __ref which is
needed to suppress a (W=1) modpost warning.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20231104211501.3676352-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
On today's platforms the benefit of platform_driver_probe() isn't that
relevant any more. It allows to drop some code after booting (or module
loading) for .probe() and discard the .remove() function completely if
the driver is built-in. This typically saves a few 100k.
The downside of platform_driver_probe() is that the driver cannot be
bound and unbound at runtime which is ancient and so slightly
complicates testing. There are also thoughts to deprecate
platform_driver_probe() because it adds some complexity in the driver
core for little gain. Also many drivers don't use it correctly. This
driver for example misses to mark the driver struct with __ref which is
needed to suppress a (W=1) modpost warning.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20231104211501.3676352-18-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
On today's platforms the benefit of platform_driver_probe() isn't that
relevant any more. It allows to drop some code after booting (or module
loading) for .probe() and discard the .remove() function completely if
the driver is built-in. This typically saves a few 100k.
The downside of platform_driver_probe() is that the driver cannot be
bound and unbound at runtime which is ancient and so slightly
complicates testing. There are also thoughts to deprecate
platform_driver_probe() because it adds some complexity in the driver
core for little gain. Also many drivers don't use it correctly. This
driver for example misses to mark the driver struct with __ref which is
needed to suppress a (W=1) modpost warning.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20231104211501.3676352-17-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver uses delayed work to perform periodic battery state read out.
This delayed work is not stopped across suspend and resume cycle. The
read out can occur early in the resume cycle. In case of an I2C variant
of this hardware, that read out triggers I2C transfer. That I2C transfer
may happen while the I2C controller is still suspended, which produces a
WARNING in the kernel log.
Fix this by introducing trivial PM ops, which stop the delayed work before
the system enters suspend, and schedule the delayed work right after the
system resumes.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20231104154920.68585-1-marex@denx.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Replace the soft reset with a graceful reboot.
An acpi event will be triggered by the irq in the pwr-mlxbf.c
to trigger the graceful reboot.
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
Link: https://lore.kernel.org/r/20231030203058.8056-1-asmaa@nvidia.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Here is the "big" set of USB and Thunderbolt changes for 6.7-rc1.
Nothing really major in here, just lots of constant development for new
hardware. Included in here are:
- Thunderbolt (i.e. USB4) fixes for reported issues and support for
new hardware types and devices
- USB typec additions of new drivers and cleanups for some existing
ones
- xhci cleanups and expanded tracing support and some platform
specific updates
- USB "La Jolla Cove Adapter (LJCA)" support added, and the gpio, spi,
and i2c drivers for that type of device (all acked by the respective
subsystem maintainers.)
- lots of USB gadget driver updates and cleanups
- new USB dwc3 platforms supported, as well as other dwc3 fixes and
cleanups
- USB chipidea driver updates
- other smaller driver cleanups and additions, full details in the
shortlog
All of these have been in the linux-next tree for a while with no
reported problems, EXCEPT for some merge conflicts that you will run
into in your tree. 2 of them are in device-tree files, which will be
trivial to resolve (accept both sides), and the last in the
drivers/gpio/gpio-ljca.c file, in the remove callback, resolution should
be pretty trivial (take the version in this branch), see here:
https://lore.kernel.org/all/20231016134159.11d8f849@canb.auug.org.au/
for details, or I can provide a resolved merge point if needed.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZUStew8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykxgQCggUyfGo+JVV8XZVu5A9KwT6nr7mUAmwUgFxhZ
khK77t0KqF4hjXryeaHa
=iPd+
-----END PGP SIGNATURE-----
Merge tag 'usb-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/Thunderbolt updates from Greg KH:
"Here is the "big" set of USB and Thunderbolt changes for 6.7-rc1.
Nothing really major in here, just lots of constant development for
new hardware. Included in here are:
- Thunderbolt (i.e. USB4) fixes for reported issues and support for
new hardware types and devices
- USB typec additions of new drivers and cleanups for some existing
ones
- xhci cleanups and expanded tracing support and some platform
specific updates
- USB "La Jolla Cove Adapter (LJCA)" support added, and the gpio,
spi, and i2c drivers for that type of device (all acked by the
respective subsystem maintainers.)
- lots of USB gadget driver updates and cleanups
- new USB dwc3 platforms supported, as well as other dwc3 fixes and
cleanups
- USB chipidea driver updates
- other smaller driver cleanups and additions, full details in the
shortlog
All of these have been in the linux-next tree for a while with no
reported problems"
* tag 'usb-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (167 commits)
usb: gadget: uvc: Add missing initialization of ssp config descriptor
usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility
usb: raw-gadget: report suspend, resume, reset, and disconnect events
usb: raw-gadget: don't disable device if usb_ep_queue fails
usb: raw-gadget: properly handle interrupted requests
usb:cdnsp: remove TRB_FLUSH_ENDPOINT command
usb: gadget: aspeed_udc: Convert to platform remove callback returning void
dt-bindings: usb: fsa4480: Add compatible for OCP96011
usb: typec: fsa4480: Add support to swap SBU orientation
dt-bindings: usb: fsa4480: Add data-lanes property to endpoint
usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()
Revert "dt-bindings: usb: Add bindings for multiport properties on DWC3 controller"
Revert "dt-bindings: usb: qcom,dwc3: Add bindings for SC8280 Multiport"
thunderbolt: Fix one kernel-doc comment
usb: gadget: f_ncm: Always set current gadget in ncm_bind()
usb: core: Remove duplicated check in usb_hub_create_port_device
usb: typec: tcpm: Add additional checks for contaminant
arm64: dts: rockchip: rk3588s: Add USB3 host controller
usb: dwc3: add optional PHY interface clocks
dt-bindings: usb: add rk3588 compatible to rockchip,dwc3
...
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20231009172923.2457844-19-robh@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect ac->name to be NUL-terminated based on its usage with format
strings:
surface_charger.c:
190: ac->psy_desc.name = ac->name;
...
power_supply_core.c:
174: dev_dbg(&psy->dev, "%s: Found supply : %s\n",
175: psy->desc->name, epsy->desc->name);
Moreover, NUL-padding is not required as ac is already zero-allocated
before being passed to spwr_ac_init():
surface_charger.c:
240: ac = devm_kzalloc(&sdev->dev, sizeof(*ac), GFP_KERNEL);
241: if (!ac)
242: return -ENOMEM;
243:
244: spwr_ac_init(ac, sdev, p->registry, p->name);
... this means any future NUL-byte assignments (like the ones that
strncpy() does) are redundant.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt for the more idiomatic strscpy() usage of:
(dest, src, sizeof(dest))
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-surface_charger-c-v1-1-93ddbf668e10@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect bat->name to be NUL-terminated based on its usage with
strcmp():
power_supply_core.c:
445: return strcmp(psy->desc->name, name) == 0;
... and also by the manual `... - 1` for the length argument of the
original strncpy() invocation.
Furthermore, no NUL-padding is needed as bat is zero-allocated before
calling spwr_battery_init():
826: bat = devm_kzalloc(&sdev->dev, sizeof(*bat), GFP_KERNEL);
827: if (!bat)
828: return -ENOMEM;
829:
830: spwr_battery_init(bat, sdev, p->registry, p->name);
... this means any further NUL-byte assignments (like the ones that
strncpy() does) are redundant.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt to use the more idiomatic strscpy() usage of:
(dest, src, sizeof(dest)).
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-surface_battery-c-v2-1-29ed16b2caf1@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect cm->psy_name_buf to be NUL-terminated based on its usage with
format strings:
1522: cm->charger_psy_desc.name = cm->psy_name_buf;
...
1587: dev_err(&pdev->dev, "Cannot register charger-manager with name \"%s\"\n",
1587: cm->charger_psy_desc.name);
Moreover, NUL-padding is not required as `cm` is already zero-allocated
and thus any future NUL-byte assignments (like what strncpy() will do)
are redundant:
1437: cm = devm_kzalloc(&pdev->dev, sizeof(*cm), GFP_KERNEL);
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt for the more idiomatic strscpy() usage of:
strscpy(dest, src, sizeof(dest)).
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-charger-manager-c-v1-1-698f73bcad2a@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect bq2515x->model_name to be NUL-terminated based on its usage with
sysfs_emit and format strings:
val->strval is assigned to bq2515x->model_name in
bq2515x_mains_get_property():
| val->strval = bq2515x->model_name;
... then in power_supply_sysfs.c we use value.strval with a format string:
| ret = sysfs_emit(buf, "%s\n", value.strval);
we assigned value.strval via:
| ret = power_supply_get_property(psy, psp, &value);
... which invokes psy->desc->get_property():
| return psy->desc->get_property(psy, psp, val);
with bq2515x_mains_get_property():
| static const struct power_supply_desc bq2515x_mains_desc = {
...
| .get_property = bq2515x_mains_get_property,
Moreover, no NUL-padding is required as bq2515x is zero-allocated in
bq2515x_charger.c:
| bq2515x = devm_kzalloc(dev, sizeof(*bq2515x), GFP_KERNEL);
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt to use the more idiomatic strscpy() usage of (dest, src,
sizeof(dest)) as this more closely ties the destination buffer and the
length.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Similar-to: https://lore.kernel.org/all/20231020-strncpy-drivers-power-supply-bq24190_charger-c-v1-1-e896223cb795@google.com/
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-bq2515x_charger-c-v1-1-46664c6edf78@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect bdi->model_name to be NUL-terminated based on its usage with
sysfs_emit and format strings:
val->strval is assigned to bdi->model_name in
bq24190_charger_get_property():
1186 | val->strval = bdi->model_name;
... then in power_supply_sysfs.c we use value.strval with a format string:
311 | ret = sysfs_emit(buf, "%s\n", value.strval);
we assigned value.strval via:
285 | ret = power_supply_get_property(psy, psp, &value);
... which invokes psy->desc->get_property():
1210 | return psy->desc->get_property(psy, psp, val);
with bq24190_charger_get_property():
1320 | static const struct power_supply_desc bq24190_charger_desc = {
...
1325 | .get_property = bq24190_charger_get_property,
Moreover, no NUL-padding is required as bdi is zero-allocated in
bq24190_charger.c:
1798 | bdi = devm_kzalloc(dev, sizeof(*bdi), GFP_KERNEL);
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-bq24190_charger-c-v1-1-e896223cb795@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Only DT based probing is used for the Motorola CPCAP charger driver, so
drop the !CONFIG_OF parts and redundant of_match_device() call.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231009172923.2457844-20-robh@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Depend on the explicit SoC defines rather than generic
architectures like most of the rest of the HW drivers do.
This makes the drivers only available for the HW and for
compile testing.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: linux-pm@vger.kernel.org
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20231009135833.17880-3-pbrobinson@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add a priority property equal to gpio-restart to allow increasing the
priority of the gpio-poweroff handler.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20231006130428.11259-5-francesco@dolcini.it
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use the new sys-off handler API for gpio-poweroff. This allows us to
have more than one poweroff handler and prioritise them.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20231006130428.11259-3-francesco@dolcini.it
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use a struct to store the module variables. This is required to later
move to notifier_blocks where we can have several instances.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20231006130428.11259-2-francesco@dolcini.it
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Currently the struct "rt5033_charger_data" is initialized rather complicated.
The cause lies inside of the struct "rt5033_charger", where struct
"rt5033_charger_data" is implemented as a pointer *chg.
Therefore, inside of struct "rt5033_charger" change the struct
"rt5033_charger_data" to non-pointer "chg". It is then initialized right
away and can be accessed more easily.
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
Link: https://lore.kernel.org/r/0aff8c2a18cf4b88ec3333f6679a8419dd76ca29.1696165240.git.jahau@rocketmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Implement cable detection by extcon and handle the driver according to the
connector type.
There are basically three types of action: "set_charging", "set_otg" and
"set_disconnect".
A forth helper function to "unset_otg" was added because this is used in both
"set_charging" and "set_disconnect". In the first case it covers the rather
rare event that someone changes from OTG to charging without disconnect. In
the second case, when disconnecting, the values are set back to the ones from
initialization to return into a defined state.
Additionally, there is "set_mivr". When connecting to e.g. a laptop/PC, the
minimum input voltage regulation (MIVR) shall prevent a voltage drop if the
cable or the supply is weak. The MIVR value is set to 4600MV, same as in the
Android driver [1]. When disconnecting, MIVR is set back to DISABLED.
In the function rt5033_get_charger_state(): When in OTG mode, the chip
reports status "charging". Change this to "discharging" because there is
no charging going on in OTG mode [2].
Yang Yingliang detected missing mutex_unlock() in some error path and
suggested a fix [3]. The suggestion was squashed into this patch.
[1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L499
[2] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L686-L687
[3] https://lore.kernel.org/linux-pm/20230822030207.644738-1-yangyingliang@huawei.com
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Co-developed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
Link: https://lore.kernel.org/r/cc4e37e510abbb0cdfa7faa8408da48c2cb448a4.1696165240.git.jahau@rocketmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Enabling the tps65217-charger driver/module causes an interrupt conflict
with the vbus driver resulting in a probe failure.
The conflict is resolved by changing both driver's threaded interrupt
request function from IRQF_ONESHOT to IRQF_SHARED.
Signed-off-by: Grant B Adams <nemith592@gmail.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230823085430.6610-2-nemith592@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a missing "ret = " assignment so this checks the same "ret"
value twice.
Fixes: c75f4bf680 ("power: supply: Introduce MM8013 fuel gauge driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/c46b4408-bf1d-408d-9e6b-16b0ad272532@moroto.mountain
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add the missing endianness conversion when sending the enable request so
that the driver will work also on a hypothetical big-endian machine.
This issue was reported by sparse.
Fixes: 29e8142b56 ("power: supply: Introduce Qualcomm PMIC GLINK power supply")
Cc: stable@vger.kernel.org # 6.3
Cc: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20230929101649.20206-1-johan+linaro@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The value of ret is zero when passed to dev_error_probe(), we are passing
zero to dev_err_probe() is a success which is incorrect.
Fix this by getting the error code using PTR_ERR().
Fixes: c75f4bf680 ("power: supply: Introduce MM8013 fuel gauge driver")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202309190838.eu8WS6sz-lkp@intel.com/
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Link: https://lore.kernel.org/r/20230923114807.2829188-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct axp20x_usb_power.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230922175358.work.774-kees@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct axp20x_ac_power.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230922175355.work.006-kees@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Dan Carpenter reports that the Smatch static checker warning has found
that there is another refcount leak in the probe function. While
of_node_put() was added in one of the return paths, it should in
fact be added for ALL return paths that return an error and at driver
removal time.
Fixes: 54c03bfd09 ("power: supply: Fix refcount leak in rk817_charger_probe")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Closes: https://lore.kernel.org/linux-pm/dc0bb0f8-212d-4be7-be69-becd2a3f9a80@kili.mountain/
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20230920145644.57964-1-macroalpha82@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
power_supply_uevent() which is called to emit a udev event on device
deletion attempts to use the power_supply_battery_info structure,
which is device-managed and has been freed before this point.
Fix this by not generating all battery/charger properties when the
device is about to be removed. This also avoids generating errors
when trying to access the hardware in hot-unplug scenarios.
==================================================================
BUG: KASAN: slab-use-after-free in power_supply_battery_info_has_prop (power_supply_core.c:872)
Read of size 4 at addr 0000000062e59028 by task python3/27
Call Trace:
power_supply_battery_info_has_prop (power_supply_core.c:872)
power_supply_uevent (power_supply_sysfs.c:504)
dev_uevent (drivers/base/core.c:2590)
kobject_uevent_env (lib/kobject_uevent.c:558)
kobject_uevent (lib/kobject_uevent.c:643)
device_del (drivers/base/core.c:3266 drivers/base/core.c:3831)
device_unregister (drivers/base/core.c:3730 drivers/base/core.c:3854)
power_supply_unregister (power_supply_core.c:1608)
devm_power_supply_release (power_supply_core.c:1515)
release_nodes (drivers/base/devres.c:506)
devres_release_group (drivers/base/devres.c:669)
i2c_device_remove (drivers/i2c/i2c-core-base.c:629)
device_remove (drivers/base/dd.c:570)
device_release_driver_internal (drivers/base/dd.c:1274 drivers/base/dd.c:1295)
device_driver_detach (drivers/base/dd.c:1332)
unbind_store (drivers/base/bus.c:247)
...
Allocated by task 27:
devm_kmalloc (drivers/base/devres.c:119 drivers/base/devres.c:829)
power_supply_get_battery_info (include/linux/device.h:316 power_supply_core.c:626)
__power_supply_register (power_supply_core.c:1408)
devm_power_supply_register (power_supply_core.c:1544)
bq256xx_probe (bq256xx_charger.c:1539 bq256xx_charger.c:1727) bq256xx_charger
i2c_device_probe (drivers/i2c/i2c-core-base.c:584)
really_probe (drivers/base/dd.c:579 drivers/base/dd.c:658)
__driver_probe_device (drivers/base/dd.c:800)
device_driver_attach (drivers/base/dd.c:1128)
bind_store (drivers/base/bus.c:273)
...
Freed by task 27:
kfree (mm/slab_common.c:1073)
release_nodes (drivers/base/devres.c:503)
devres_release_all (drivers/base/devres.c:536)
device_del (drivers/base/core.c:3829)
device_unregister (drivers/base/core.c:3730 drivers/base/core.c:3854)
power_supply_unregister (power_supply_core.c:1608)
devm_power_supply_release (power_supply_core.c:1515)
release_nodes (drivers/base/devres.c:506)
devres_release_group (drivers/base/devres.c:669)
i2c_device_remove (drivers/i2c/i2c-core-base.c:629)
device_remove (drivers/base/dd.c:570)
device_release_driver_internal (drivers/base/dd.c:1274 drivers/base/dd.c:1295)
device_driver_detach (drivers/base/dd.c:1332)
unbind_store (drivers/base/bus.c:247)
...
==================================================================
Reported-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Fixes: 27a2195efa ("power: supply: core: auto-exposure of simple-battery data")
Tested-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When CONFIG_EXTCON=m and CONFIG_CHARGER_PM8916_LBC=y, there are
build errors. Fix them by having CHARGER_PM8916_LBC depend on the
setting of EXTCON.
aarch64-linux-ld: drivers/power/supply/pm8916_lbc.o: in function `pm8916_lbc_charger_state_changed_irq':
pm8916_lbc.c:(.text+0xe8): undefined reference to `extcon_set_state_sync'
aarch64-linux-ld: drivers/power/supply/pm8916_lbc.o: in function `pm8916_lbc_charger_probe':
pm8916_lbc.c:(.text+0x638): undefined reference to `devm_extcon_dev_allocate'
aarch64-linux-ld: pm8916_lbc.c:(.text+0x650): undefined reference to `devm_extcon_dev_register'
aarch64-linux-ld: pm8916_lbc.c:(.text+0x688): undefined reference to `extcon_set_state_sync'
Fixes: f8d7a3d211 ("power: supply: Add driver for pm8916 lbc")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Nikita Travkin <nikita@trvn.ru>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: linux-pm@vger.kernel.org
Link: https://lore.kernel.org/r/20230918205825.25864-1-rdunlap@infradead.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-33-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-32-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-31-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-30-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-29-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-28-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-27-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-26-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-25-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-24-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-23-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-22-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-21-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-20-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-18-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-17-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-16-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-15-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-14-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-13-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-12-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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() is 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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230918133700.1254499-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
pm8916 LBC is a Linear Battery Charger hardware block in pm8916 PMIC.
This block implements simple CC/CV charging for Li-Po batteries.
The hardware has internal state machine to switch between modes and
works mostly autonomously, only needing the limits and targets to be
set to operate.
This driver allows setting limits and enabling the LBC block, monitoring
it's state.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20230915-pm8916-bms-lbc-v3-4-f30881e951a0@trvn.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver adds basic support for VM-BMS found in pm8916.
VM-BMS is a very basic fuel-gauge hardware block that is, sadly,
incapable of any gauging. The hardware supports measuring OCV in
sleep mode, where the battery is not in use, or measuring average
voltage over time when the device is active.
This driver implements basic value readout from this block.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20230915-pm8916-bms-lbc-v3-3-f30881e951a0@trvn.ru
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Ensure that the dynamically created power supply device sets its
->of_node if the driver supplies one. This brings it in line with
several other subsystems (see git grep 'of_node =.*parent.*of_node') and
allows easier identification of the device from udev rules and similar.
Before this patch:
/sys/class/power_supply# ls -l bq256xx-battery/of_node
ls: cannot access 'bq256xx-battery/of_node': No such file or directory
# ls -l bq256xx-battery/hwmon1/of_node
ls: cannot access 'bq256xx-battery/hwmon1/of_node': No such file or directory
After:
/sys/class/power_supply# ls -l bq256xx-battery/of_node
lrwxrwxrwx 1 root root 0 May 17 09:14 bq256xx-battery/of_node ->
../../../../../../../../firmware/devicetree/base/virtio@1/i2c/bq25619@09
# ls -l bq256xx-battery/hwmon1/of_node
lrwxrwxrwx 1 root root 0 May 17 09:14 bq256xx-battery/hwmon1/of_node ->
../../../../../../../../../firmware/devicetree/base/virtio@1/i2c/bq25619@09
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20230915-power-of-v2-1-ca54c441867e@axis.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
It is spurious to bail-out on a wait_for_completion_timeout() call that
does NOT timeout.
Reverse the logic to return -ETIMEDOUT instead, in case of tiemout.
Fixes: 6f7f70e3a8 ("power: supply: rt9467: Add Richtek RT9467 charger driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/2ed01020fa8a135c36dbaa871095ded47d926507.1676464968.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Similar to the rk817 codec alias that was missing, the rk817 charger
driver is missing a module alias as well. This absence prevents the
driver from autoprobing on OF systems when it is built as a module.
Add the right MODULE_ALIAS to fix this.
Fixes: 11cb8da018 ("power: supply: Add charger driver for Rockchip RK817")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Reviewed-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20230612143651.959646-2-frattaroli.nicolas@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The driver reads battery properties every 8 seconds. In order to prevent
problems with wrong property values right after resume, trigger an
update of those properties on resuming the system and restart the
8-second interval from there.
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Link: https://lore.kernel.org/r/20230601-rk817_query_at_resume-v1-1-630b0adefbd9@mweigand.net
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This function is supposed to return 0 for success instead of returning
the val->intval. This makes it the same as the other case statements
in this function.
Fixes: 81196e2e57 ("power: supply: ucs1002: fix some health status issues")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/687f64a4-4c6e-4536-8204-98ad1df934e5@moroto.mountain
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Since fuel gauge does not support thermal monitoring,
some vendors may couple this fuel gauge with thermal/adc
sensor to monitor battery cell exact temperature.
Add this feature by adding optional iio thermal channel.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Iskren Chernev <me@iskren.info>
Link: https://lore.kernel.org/r/20230731073613.10394-4-clamor95@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Optionally pass status property from supplier if has support
for it. If cell is online assume it is present as well.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Iskren Chernev <me@iskren.info>
Link: https://lore.kernel.org/r/20230731073613.10394-3-clamor95@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Some cleanups:
* Remove trailing comma in the terminator entry for OF/ID/ACPI table.
* Drop a space from terminator entry for OF table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230902193331.83672-3-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add struct bq2425x_chip_info to make enum bq2425x_chip and it's name in
sync and replace chip->info in struct bq24257_device and add struct
bq2425x_chip_info as match data for OF/ACPI/ID tables.
Simpilfy probe() by replacing acpi_match_device() and id lookup for
retrieving match data by using i2c_get_match_data().
Drop bq2425x_chip_name as there is no user and also drop the comment
related to syncing chip and name as it is taken care by struct
bq2425x_chip_info.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230902193331.83672-2-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Some cleanups:
* Remove trailing comma in the terminator entry for OF/ID table.
* Drop a space from terminator entry for OF table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230902200518.91585-3-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add struct bq2515x_info and replace device_id->info in struct
bq2515x_device.
Simpilfy bq2515x_read_properties() and probe() by adding struct
bq2425x_chip_info as match data for OF/ID tables and use
i2c_get_match_data for retrieving match data instead of ID lookup.
Drop enum bq2515x_id as there is no user.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230902200518.91585-2-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Just like syscon-reboot device, the syscon-poweroff is supposed to be a
child of syscon node, thus we can take the same approach as
syscon-poweroff: deprecate the 'regmap' field in favor of taking it from
the parent's node.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230901120057.47018-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Using CONFIG_ prefix for macros is not a good practice.
Use CONFIG_ prefix in Kconfig only.
Signed-off-by: Przemyslaw Chwiala <przemekchwiala@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20230720123102.154699-1-przemekchwiala@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
There is no need to call the dev_err_probe() function directly to print
a custom message when handling an error from platform_get_irq_byname()
function as it is going to display an appropriate error message
in case of a failure.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230727113550.2599335-1-ruanjinjie@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
There is no possible for platform_get_irq() to return 0,
and the return value of platform_get_irq() is more sensible
to show the error reason.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230731113959.1957820-1-ruanjinjie@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The syscon_poweroff_register() doesn't do anything special, so it can use the
builtin_platform_driver() macro to eliminate boilerplate code.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230807131951.3443880-6-yangyingliang@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The axxia_reset_init() doesn't do anything special, so it can use the
builtin_platform_driver() macro to eliminate boilerplate code.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230807131951.3443880-5-yangyingliang@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The xgene_reboot_init() doesn't do anything special, so it can use the
builtin_platform_driver() macro to eliminate boilerplate code.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230807131951.3443880-4-yangyingliang@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The msm_restart_init() doesn't do anything special, so it can use the
builtin_platform_driver() macro to eliminate boilerplate code.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230807131951.3443880-3-yangyingliang@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The st_reset_init() doesn't do anything special, so it can use the
builtin_platform_driver() macro to eliminate boilerplate code.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230807131951.3443880-2-yangyingliang@huawei.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When building with clang 18 I see the following warning:
| drivers/power/reset/vexpress-poweroff.c:124:10: warning: cast to smaller integer type 'enum vexpress_reset_func' from 'const void *' [-Wvoid-pointer-to-enum-cast]
| 124 | switch ((enum vexpress_reset_func)match->data) {
This is due to the fact that `match->data` is a void* while `enum vexpress_reset_func`
has the size of an int. This leads to truncation and possible data loss.
Link: https://github.com/ClangBuiltLinux/linux/issues/1910
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Some errors are being logged that are really due to deferrals,
which is confusing to users. Use dev_err_probe() to handle when to log
at error level versus debug. This also has the added bonuses of logging
to devices_deferred and printing the error value.
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Tested-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20230817214218.638846-1-ahalaney@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Documentation/process/license-rules.rst and checkpatch expect the SPDX
identifier syntax for multiple licenses to use capital "OR". Correct it
to keep consistent format and avoid copy-paste issues.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230823085601.116562-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The BlueField power handling driver (pwr-mlxbf.c) provides
functionality for both BlueField-2 and BlueField-3 based
platforms. This driver also depends on the SoC-specific
BlueField GPIO driver, whether gpio-mlxbf2 or gpio-mlxbf3.
This patch extends the Kconfig definition to include the
dependency on the gpio-mlxbf3 driver, if applicable.
Signed-off-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
Link: https://lore.kernel.org/r/20230823133743.31275-1-davthompson@nvidia.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
CHARGER_RT5033 should honor the EXTCON setting to prevent these
build errors:
riscv64-linux-ld: drivers/power/supply/rt5033_charger.o: in function `.L33':
rt5033_charger.c:(.text.rt5033_charger_probe+0x578): undefined reference to `extcon_find_edev_by_node'
riscv64-linux-ld: drivers/power/supply/rt5033_charger.o: in function `.L0 ':
rt5033_charger.c:(.text.rt5033_charger_probe+0x64e): undefined reference to `devm_extcon_register_notifier_all'
riscv64-linux-ld: drivers/power/supply/rt5033_charger.o: in function `.L96':
rt5033_charger.c:(.text.rt5033_charger_extcon_work+0x32): undefined reference to `extcon_get_state'
Fixes: 12cc585f36b8 ("power: supply: rt5033_charger: Add cable detection and USB OTG supply")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jakob Hauser <jahau@rocketmail.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Lee Jones <lee@kernel.org>
Cc: linux-pm@vger.kernel.org
Link: https://lore.kernel.org/r/20230828224201.26823-1-rdunlap@infradead.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Make similar OF and ID table to extend support for ID match
using i2c_match_data(). Currently it works only for OF match
tables as the field is wrong for ID match.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230831171235.58477-1-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Some cleanups:
* Remove trailing comma in the terminator entry for OF/ID/ACPI table.
* Drop a space from terminator entry for OF table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230902202505.97609-3-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use i2c_get_match_data() for OF/ID/ACPI match instead of ID lookup by
replacing OF/ACPI/ID match data from enum bq256xx_id to
struct bq256xx_chip_info.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230902202505.97609-2-biju.das.jz@bp.renesas.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When mt6370_chg_field_get() suceeds, ret is set to zero and returning
zero when flash led is still in strobe mode looks incorrect.
Fixes: 233cb8a47d ("power: supply: mt6370: Add MediaTek MT6370 charger driver")
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: ChiaEn Wu <chiaen_wu@richtek.com>
Link: https://lore.kernel.org/r/20230906084815.2827930-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
I had the following weird phenomena on a mobile phone: while
the capacity in /sys/class/power_supply/ab8500_fg/capacity
would reflect the actual charge and capacity of the battery,
only 1/3 of the value was shown on the battery status
indicator and warnings for low battery appeared.
It turns out that UPower, the Freedesktop power daemon,
will average all the power supplies of type "battery" in
/sys/class/power_supply/* if there is more than one battery.
For the AB8500, there was "battery" ab8500_fg, ab8500_btemp
and ab8500_chargalg. The latter two don't know anything
about the battery, and should not be considered. They were
however averaged and with the capacity of 0.
Flag ab8500_btemp and ab8500_chargalg with type "unknown"
so they are not averaged as batteries.
Remove the technology prop from ab8500_btemp as well, all
it does is snoop in on knowledge from another supply.
After this the battery indicator shows the right value.
Cc: Stefan Hansson <newbyte@disroot.org>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
All of the remaining callers of thermal_zone_device_register()
can use thermal_tripless_zone_device_register(), so make them
do so in order to allow the former to be dropped.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
The INHIBIT_CHARGE status bit means the battery has reached a
pre-programmed charge limit which is some voltage offset below the
target float voltage. This should be reported as a STATUS_FULL rather
than UNKNOWN, fix it.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Link: https://lore.kernel.org/r/20230802-pmi8998-charger-fixes-v1-2-a8f1e8b84c1e@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
These property were intended to allow the power supply to be treated as a
cooling device, however the cooling device interface has been dropped
from the psy core code. They now just duplicate the CURRENT_NOW and
CURRENT_MAX properties and are generally confusing, drop them.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Link: https://lore.kernel.org/r/20230802-pmi8998-charger-fixes-v1-1-a8f1e8b84c1e@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Due to lack of maintenance and stall of development for a few years now,
and since no new features will ever be added upstream, remove support
for OX810 and OX820 restart feature.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
When the power supply device being registered supports a temperature
readout, the core registers a thermal zone for it. The thermal core
would register a hwmon device for that unless told otherwise.
When CONFIG_POWER_SUPPLY_HWMON is enabled, the power supply core creates
a hwmon device. This results in a second entry, one which has a better
name than the one registered through the thermal framework. It could
potentially have readouts other than temperature.
To simplify the result, tell the thermal framework to not register a
hwmon device if CONFIG_POWER_SUPPLY_HWMON is enabled. The result is
one hwmon device with all the readings the device supports.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Introduce a list of generic reset sources and use them to export the
power on reason through sysfs. Update the ABI documentation to describe
this new interface.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
[Miquel Raynal: Follow-up on Kamel's work, 4 years later]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Don't populate the read-only array on the stack, instead make it
static const.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Adds a check of the FORCE_20PCT bit when getting the precharge
current value.
According to the bit description for the FORCE_20PCT bit, when
FORCE_20PCT is true, the precharge current target is 50% of
what is configured in the IPRECHG bit field.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Acked-by: David Lechner <david@lechnology.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
* Add new Qualcomm PMI8998/PM660 SMB2 charger
* bq256xx: support systems without thermistors
* cros_pchg: fix peripheral device status after system resume
* axp20x_usb_power: add support for AXP192
* qcom-pon: add support for pm8941
* at91-reset: prepare to expose reset reason to sysfs
* switch all I2C drivers back to use .probe instead of .probe_new
* convert some more DT bindings to YAML
* misc. cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAmSjPRsACgkQ2O7X88g7
+ppEgw//SzE/6dgc5e2OG+qtHb2vnjUrmoz9w0/sGZuTVFhnvZ4ofpEyOrRR8/kV
rUT6dqEPh3p/tHIyiLdcAG2JyA3QZ3G8rekdIUOj++vWn4S97FQsqBxwL/46D0om
c7S+SDrCo/XKnJvRIiC8a+0HzAsjVUdaWdvzkEovrF5MRS1HeX4GXadaW/c6pdxN
NfOZBR2F+JXHlC/nmBtpmQCJvikooz6DPvZd6Tiv9dlywOHNO7NSlcueuuhSofYp
/j7BAXq/V+jEynNTPnaBwnO5aA1XPMpC/nOo4HuHjJbrHoXCt5bMhabA9bIlaplN
9bilfxmqqfaMkpWQOhF8qmz+s496WELcmGqGBZXvNBgn/85qYTPxue4JVe1D7ldh
TjvGUBZkVUwkce052BZrPZCUTYhlrTBJ/6xpuGeUrPa3C9ib8e9Wm6C13zI2vsJV
EeVxgt79cNkdioZ0GfibQTg+bJ7oa8BtwWEk0UaC9jfaPQGfNum05FHRik1a+A7R
vehaoIYiCCMaXuHSZoqqjEocdnxXQCNkViMuYNqhN5Bcb0YdlMF6r0T2fa4HND0Y
CU8uCofqTc67/RazqCsIRHNXDi6cJOYmdnSc1q7pYCO9/KmoMdP0xIFPB2Mca7uI
2rMooSE77ssYGc1gOW9GWuMNEdvJXNufJJzr5LLdMbhIh0ecy04=
=9vtE
-----END PGP SIGNATURE-----
Merge tag 'for-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull power supply and reset updates from Sebastian Reichel:
- Add new Qualcomm PMI8998/PM660 SMB2 charger
- bq256xx: support systems without thermistors
- cros_pchg: fix peripheral device status after system resume
- axp20x_usb_power: add support for AXP192
- qcom-pon: add support for pm8941
- at91-reset: prepare to expose reset reason to sysfs
- switch all I2C drivers back to use .probe instead of .probe_new
- convert some more DT bindings to YAML
- misc cleanups
* tag 'for-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (28 commits)
MAINTAINERS: add documentation file for Microchip SAMA5D2 shutdown controller
dt-bindings: power: reset: atmel,sama5d2-shdwc: convert to yaml
dt-bindings: power: reset: atmel,at91sam9260-shdwc: convert to yaml
power: reset: at91-reset: change the power on reason prototype
power: reset: qcom-pon: add support for pm8941-pon
dt-bindings: power: reset: qcom-pon: define pm8941-pon
power: supply: add Qualcomm PMI8998 SMB2 Charger driver
dt-bindings: power: supply: qcom,pmi8998-charger: add bindings for smb2 driver
power: supply: rt9467: Make charger-enable control as logic level
power: supply: Switch i2c drivers back to use .probe()
power: reset: add HAS_IOPORT dependencies
dt-bindings: power: supply: axp20x: Add AXP192 compatible
power: supply: axp20x_usb_power: Add support for AXP192
power: supply: axp20x_usb_power: Remove variant IDs from VBUS polling check
power: supply: axp20x_usb_power: Use regmap field for VBUS disabling
power: supply: axp20x_usb_power: Use regmap fields for USB BC feature
power: supply: axp20x_usb_power: Use regmap fields for VBUS monitor feature
power: supply: axp20x_usb_power: Simplify USB current limit handling
power: supply: hwmon: constify pointers to hwmon_channel_info
power: supply: twl4030_madc_battery: Refactor twl4030_madc_bat_ext_changed()
...
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
- New Device Support
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
- New Functionality
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
- Fix-ups
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
- Bug Fixes
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmSinb0ACgkQUa+KL4f8
d2FYfg//WWLVfXRuRpY9ueOxvWj65WVPQSQ+wzF/vRTweogR+lN0qxNPH6yT943z
ap2EBxpWf84zCifYG4yhTEYDHQT+nH1fIz6xaK29DK8sCQi4WdRpHuE2pE30R/tf
Q7SyZi9DlWyoqNiqgNNCl7vkTaHpO3trxoxfEfN2YIB0npLf8yyWRz4feVXXsYtg
41S4Mo7oTxphd7OLvw9PKogdTbT29vBMXen8jzv5g8FObj1Gheg0frq2t2W+bfAl
27cJJJS7he4/WLCDzXVQfB46Nva5NpqHiANbgOAApDGx3hFCzZFTCg6K7+VucpjY
bNz3pqmslT5uJxMjqNz8fCSzwWTjyKLHBeGsIT/4HBXD4DnfFbWz9HYkorfNgsu2
lKEp0SYhSmmuS8IVzJvqDqXg6k21hGpuR9P+dI7teoClh0qLTMCz2L2c9p2zNfth
0W+WeLYQ67QTRH9EcHo3dlZH/mP/J1jGmUDbF+DFI6bHsg2iahZUA6ixD18E7sWE
RwtCnb3xyn7eoDe3LwJdKtJMyrX59MbFWqozij2NNhvduXc+m1kH/DX5CSaBUVwf
RtfDZwWHf4qK4CipuuqOLd5fiUArJ3TSHBxXkoo0Wz7NYXK9k86eIZgWrgdEbvuA
oHmSousS19Eiscjtzxl7OjvDJMRc0rTJfD7LzYoHQBL4Vpnd8VI=
=9kd5
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"New Drivers:
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
New Device Support:
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
New Functionality:
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
Fix-ups:
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
Bug Fixes:
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues"
* tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits)
leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks
leds: sgm3140: Add richtek,rt5033-led compatible
dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible
dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks"
dt-bindings: leds: Drop unneeded quotes
leds: Fix config reference for AW200xx driver
leds: leds-mt6323: Add support for WLEDs and MT6332
leds: leds-mt6323: Add support for MT6331 leds
leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro
leds: leds-mt6323: Drop MT6323_ prefix from macros and defines
leds: leds-mt6323: Specify registers and specs in platform data
dt-bindings: leds: leds-mt6323: Document mt6332 compatible
dt-bindings: leds: leds-mt6323: Document mt6331 compatible
leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches
leds: simatic-ipc-leds-gpio: Split up into multiple drivers
leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table
leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables
leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative
leds: cht-wcove: Remove unneeded semicolon
leds: cht-wcove: Fix an unsigned comparison which can never be negative
...
- Add support for TI TPS6594/TPS6593/LP8764 PMICs
- Add support for Samsung RT5033 Battery Charger
- Add support for Analog Devices MAX77540 and MAX77541 PMICs
- New Device Support
- Add support for SPI to Rockchip RK808 (and friends)
- Add support for AXP192 PMIC to X-Powers AXP20X
- Add support for AXP313a PMIC to X-Powers AXP20X
- Add support for RK806 to Rockchip RK8XX
- Removed Device Support
- Removed MFD support for Richtek RT5033 Battery
- Fix-ups
- Remove superfluous code
- Switch I2C drivers from .probe_new() to .probe()
- Convert over to managed resources (devm_*(), etc)
- Use dev_err_probe() for returning errors from .probe()
- Add lots of Device Tree bindings / support
- Improve cache efficiency by switching to Maple
- Use own exported namespaces (NS)
- Include missing and remove superfluous headers
- Start using / convert to the new shutdown sys-off API
- Trivial: variable / define renaming
- Make use of of_property_read_reg() when requesting DT 'reg's
- Bug Fixes
- Fix chip revision readout due to incorrect data masking
- Amend incorrect register and mask values used for charger state
- Hide unused functionality at compile time
- Fix resource leaks following error handling routines
- Return correct error values and fix error handling in general
- Repair incorrect device names - used for device matching
- Remedy broken module auto-loading
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmSinHkACgkQUa+KL4f8
d2Gj3A/9EimIwZKau8OeHCVue1mNrEVkVsCiWIZF1eHliufNbH0g3+9gzTB1yQfL
PmE2tN+vxdHNPJKzPnrmEEdJpm+rV6RikUD3I1mVN0wPSXDmZPx9kYuJD8SmMtZo
aDLQIMwqY0ZijGgAoVWmRtYo5praWSFvyutiD1yYEI4yAz/QcLoNvWjt3qb0H+fq
Un1LYErrLxLar0GllzQa5lzoNEAoSBvO1TmS8z4Cm5uiU6Orahh2DlsE/Do40GSc
5YYntAEsuJ1Bkg7JB+bxdU4BJnJskqzaasLIe3Fc4rXf6zdh/21EpmhpFGY+BS8s
51f+NjViMwi+3uiBe5g8f/pIy6dIpkfvdukzbqDhDwqXnexftpy3+i99PJiWludR
Xpr6s+g6zpxLAoKzHNA1jm5B3I0IPJEBoWe8jAalIcGIQBdjiF9UAkas3z9NTEoa
8TrjW1Abxow1TB9ouT0kE7hvQk2UpYLEbNdDAByE4mM33d5AF7UpcEBrhmbFDA/E
12q5EMoV9uXIzf+LS2TdYroo8SVYHufiIoiwU6QPJzWVVFJ3lrU3pA1Oe+aICMNu
90EVDI1Ve37WTJfN9+FAlncaWF99AEqZwrES25QrKhMQO4w6LS35shlzTzpUcB4k
q+upr81cWLz0t7fmjgn4yVa1CWzaQ19nylqXF/Nb4RP/6ZiP2Dw=
=EmOj
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Drivers:
- Add support for TI TPS6594/TPS6593/LP8764 PMICs
- Add support for Samsung RT5033 Battery Charger
- Add support for Analog Devices MAX77540 and MAX77541 PMICs
New Device Support:
- Add support for SPI to Rockchip RK808 (and friends)
- Add support for AXP192 PMIC to X-Powers AXP20X
- Add support for AXP313a PMIC to X-Powers AXP20X
- Add support for RK806 to Rockchip RK8XX
Removed Device Support:
- Removed MFD support for Richtek RT5033 Battery
Fix-ups:
- Remove superfluous code
- Switch I2C drivers from .probe_new() to .probe()
- Convert over to managed resources (devm_*(), etc)
- Use dev_err_probe() for returning errors from .probe()
- Add lots of Device Tree bindings / support
- Improve cache efficiency by switching to Maple
- Use own exported namespaces (NS)
- Include missing and remove superfluous headers
- Start using / convert to the new shutdown sys-off API
- Trivial: variable / define renaming
- Make use of of_property_read_reg() when requesting DT 'reg's
Bug Fixes:
- Fix chip revision readout due to incorrect data masking
- Amend incorrect register and mask values used for charger state
- Hide unused functionality at compile time
- Fix resource leaks following error handling routines
- Return correct error values and fix error handling in general
- Repair incorrect device names - used for device matching
- Remedy broken module auto-loading"
* tag 'mfd-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (51 commits)
dt-bindings: mfd: max77541: Add ADI MAX77541/MAX77540
iio: adc: max77541: Add ADI MAX77541 ADC Support
regulator: max77541: Add ADI MAX77541/MAX77540 Regulator Support
dt-bindings: regulator: max77541: Add ADI MAX77541/MAX77540 Regulator
mfd: Switch two more drivers back to use struct i2c_driver::probe
dt-bindings: mfd: samsung,s5m8767: Simplify excluding properties
mfd: stmpe: Only disable the regulators if they are enabled
mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support
dt-bindings: mfd: gateworks-gsc: Remove unnecessary fan-controller nodes
mfd: core: Use of_property_read_reg() to parse "reg"
mfd: stmfx: Nullify stmfx->vdd in case of error
mfd: stmfx: Fix error path in stmfx_chip_init
mfd: intel-lpss: Add missing check for platform_get_resource
mfd: stpmic1: Add PMIC poweroff via sys-off handler
mfd: stpmic1: Fixup main control register and bits naming
dt-bindings: mfd: qcom,tcsr: Add the compatible for IPQ8074
mfd: tps65219: Add support for soft shutdown via sys-off API
mfd: pm8008: Drop bogus i2c module alias
mfd: pm8008: Fix module autoloading
mfd: tps65219: Add GPIO cell instance
...
It is quite uncommon to use a driver helper with parameters like *pdev
and __iomem *base. It is much cleaner and close to today's standards to
provide the per-device driver structure and then access its
internals. Let's do this with the helper which returns the power on
reason. While we change the parameters, we can as well rename the
function from at91_reset_status() to at91_reset_reason() to be more
accurate with what the helper actually does, and finally because we don't
really need the pdev argument in this helper besides for printing the
reset reason, we can move the dev_info() call into the probe.
All these modifications prepare the introduction of a sysfs entry to
access this information. This way the diff will be much smaller. Thus,
there is no intended functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
For PM8941 we don't have a defined field to store the reset reason.
Support wrapping pwrkey and resin, but without writing the reset
reason.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add a driver for the SMB2 charger block found in the Qualcomm PMI8998
and PM660.
This driver is capable of utilising Qualcomm's Automatic Power Source
Detection (APSD) BC1.2 implementation, as well as Automatic Input
Current Limiting (AICL) to configure the maximum input current
limit of DCP (wall) chargers.
Quick Charge is not currently supported.
Most devices using the smb2 charger have a secondary dedicated charger
chip which is used in parallel to enable faster charger without
overheating. However, not all do, as a result to ensure safety until
these are supported, the maximum current is limited to ~1A via the
FAST_CHARGE_CURRENT_CFG register.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Tested-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The rt5033-battery fuelgauge can't get a status by itself. The rt5033-charger
can, let's get this value.
To get the charger as a "supplier" from the devicetree, the "of_node" needs
to be initiated.
Additionally, in the probe function replace dev_err() with dev_err_probe(),
this will avoid printing an error for -EPROBE_DEFER when the battery driver
probes before the charger driver.
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/a2015d257b145108a3ecdf107a3040362c887fc5.1684182964.git.jahau@rocketmail.com
Move struct rt5033_battery from the mfd header into the battery driver because
it's not used by others.
Within struct rt5033_battery, remove the line "struct rt5033_dev *rt5033;"
because it doesn't get used.
In rt5033.h, remove #include <linux/power_supply.h>, it's not necessary
anymore.
In rt5033_battery.c, remove #include <linux/mfd/rt5033.h>, it's not necessary
anymore either. Instead add #include <linux/regmap.h> and
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/736e1cbee257853cb3d1da6f05c184e9a053263b.1684182964.git.jahau@rocketmail.com
This patch adds device driver of Richtek RT5033 PMIC. The driver supports
switching charger. rt5033 charger provides three charging modes. The charging
modes are pre-charge mode, fast charge mode and constant voltage mode. They
vary in charge rate, the charge parameters can be controlled by i2c interface.
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/9556d4ebb30fd321e37aa0eb343554122e4720c9.1684182964.git.jahau@rocketmail.com
The current coding make 'charger-enable-gpio' control as real hardware
level. This conflicts with the default binding example. For driver
behavior, no need to use real hardware level, just logic level is
enough. This change can make this flexibility keep in dts gpio active
level about this pin.
Fixes: 6f7f70e3a8 ("power: supply: rt9467: Add Richtek RT9467 charger driver")
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Merge series from Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>:
A "known issue" during implementation of SE DMA for spi geni driver was
that it does DMA map/unmap internally instead of in spi framework.
Current patches remove this hiccup and also clean up code a bit.
Testing revealed no regressions and results with 1000 iterations of
reading from EC showed no loss of performance.
Results
=======
Before - Iteration 999, min=5.10, max=5.17, avg=5.14, ints=25129
After - Iteration 999, min=5.10, max=5.20, avg=5.15, ints=25153
After commit b8a1a4cd5a ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
