summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)AuthorFilesLines
2023-10-21power: reset: vexpress: Use device_get_match_data()Rob Herring1-7/+4
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>
2023-10-21Merge power-supply fixes for 6.6 cycleSebastian Reichel12-23/+35
Merge power-supply fixes for the 6.6 cycle, so that changes to the vexpress driver apply cleanly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-10-21power: supply: surface-charger: replace deprecated strncpy with strscpyJustin Stitt1-1/+1
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>
2023-10-21power: supply: surface_battery: replace deprecated strncpy with strscpyJustin Stitt1-1/+1
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>
2023-10-21power: supply: charger-manager: replace deprecated strncpy with strscpyJustin Stitt1-2/+4
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>
2023-10-21power: supply: bq25980: replace deprecated strncpy with strscpyJustin Stitt1-1/+1
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 bq->model_name to be NUL-terminated based on its usage with sysfs_emit and format strings: val->strval is assigned to bq->model_name in bq25980_get_charger_property(): | val->strval = bq->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 bq25980_get_charger_property(): | static const struct power_supply_desc bq25980_power_supply_desc = { ... | .get_property = bq25980_get_charger_property, Moreover, no NUL-padding is required as bq is zero-allocated in bq25980_charger.c: | bq = devm_kzalloc(dev, sizeof(*bq), 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 Similar-to: https://lore.kernel.org/all/20231020-strncpy-drivers-power-supply-bq24190_charger-c-v1-1-e896223cb795@google.com/ Similar-to: https://lore.kernel.org/all/20231020-strncpy-drivers-power-supply-bq2515x_charger-c-v1-1-46664c6edf78@google.com/ Signed-off-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-bq25980_charger-c-v1-1-7b93be54537b@google.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-10-21power: supply: bq256xx: replace deprecated strncpy with strscpyJustin Stitt1-1/+1
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 bq->model_name to be NUL-terminated based on its usage with sysfs_emit and format strings: val->strval is assigned to bq->model_name in bq256xx_get_charger_property(): | val->strval = bq->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 bq256xx_get_charger_property(): | static const struct power_supply_desc bq256xx_power_supply_desc = { ... | .get_property = bq256xx_get_charger_property, Moreover, no NUL-padding is required as bq is zero-allocated in bq256xx_charger.c: | bq = devm_kzalloc(dev, sizeof(*bq), 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 Similar-to: https://lore.kernel.org/all/20231020-strncpy-drivers-power-supply-bq24190_charger-c-v1-1-e896223cb795@google.com/ Similar-to: https://lore.kernel.org/all/20231020-strncpy-drivers-power-supply-bq2515x_charger-c-v1-1-46664c6edf78@google.com/ 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-bq256xx_charger-c-v1-1-2fad856124f9@google.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-10-21power: supply: bq2515x: replace deprecated strncpy with strscpyJustin Stitt1-1/+1
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>
2023-10-21power: supply: bq24190_charger: replace deprecated strncpy with strscpyJustin Stitt1-1/+1
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>
2023-10-13power: supply: cpcap: Drop non-DT driver matchingRob Herring1-11/+2
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>
2023-10-13power: reset: brcmstb: Depend on actual SoC dependenciesPeter Robinson1-1/+1
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>
2023-10-13power: reset: gpio-poweroff: make sys handler priority configurableStefan Eichenberger1-2/+7
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>
2023-10-13power: reset: gpio-poweroff: use sys-off handler APIStefan Eichenberger1-25/+12
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>
2023-10-13power: reset: gpio-poweroff: use a struct to store the module variablesStefan Eichenberger1-17/+31
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>
2023-10-04power: supply: rt5033_charger: Replace "&pdev->dev" by "charger->dev" in probeJakob Hauser1-7/+7
At the beginning of the probe function, "charger->dev" is set equal to "&pdev->dev". Therefore it's more clear to subsequently use "charger->dev" instead of "&pdev->dev". Signed-off-by: Jakob Hauser <jahau@rocketmail.com> Link: https://lore.kernel.org/r/39b4f00e010446e453905c8dc3ca1e47e9f2c5f8.1696165240.git.jahau@rocketmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-10-04power: supply: rt5033_charger: Simplify initialization of rt5033_charger_dataJakob Hauser1-17/+12
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>
2023-10-04power: supply: rt5033_charger: Add cable detection and USB OTG supplyJakob Hauser1-2/+285
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>
2023-09-30power: supply: core: remove opencoded string_lower()Thomas Weißschuh1-9/+3
string_lower from string_helpers.h can be used to modify the string in-place. Use it to get rid of the custom str_to_lower(). Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230929-power_supply-string_lower-v1-1-3141a2634d53@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-09-30power: supply: mm8013: Fix an error checking issue in mm8013_checkdevice()Dan Carpenter1-1/+1
There is a missing "ret = " assignment so this checks the same "ret" value twice. Fixes: c75f4bf6800b ("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>
2023-09-30power: supply: qcom_battmgr: fix enable request endiannessJohan Hovold1-3/+3
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: 29e8142b5623 ("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>
2023-09-30power: supply: qcom_battmgr: fix battery_id typeSebastian Reichel1-1/+1
qcom_battmgr_update_request.battery_id is written to using cpu_to_le32() and should be of type __le32, just like all other 32bit integer requests for qcom_battmgr. Cc: stable@vger.kernel.org # 6.3 Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309162149.4owm9iXc-lkp@intel.com/ Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230919124222.1155894-1-sebastian.reichel@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-09-24power: supply: mm8013: Fix error code in mm8013_probe()Harshit Mogalapalli1-1/+3
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: c75f4bf6800b ("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>
2023-09-22power: supply: axp20x_usb_power: Annotate struct axp20x_usb_power with ↵Kees Cook1-1/+1
__counted_by 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>
2023-09-22power: supply: axp20x_ac_power: Annotate struct axp20x_ac_power with ↵Kees Cook1-1/+1
__counted_by 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>
2023-09-20power: supply: rk817: Fix node refcount leakChris Morgan1-3/+12
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: 54c03bfd094f ("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>
2023-09-19power: supply: core: fix use after free in ueventSebastian Reichel1-0/+7
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: 27a2195efa8d ("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>
2023-09-19power: supply: pm8916_lbc: observe EXTCON config settingRandy Dunlap1-0/+1
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: f8d7a3d21160 ("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>
2023-09-18power: supply: wm97xx_battery: Convert to platform remove callback returning ↵Uwe Kleine-König1-3/+2
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: wm8350_power: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
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>
2023-09-18power: supply: wm831x_power: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
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>
2023-09-18power: supply: wm831x_backup: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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>
2023-09-18power: supply: twl4030_madc_battery: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: twl4030_charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: tps65217_charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: tps65090-charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: sc2731_charger: Convert to platform remove callback returning ↵Uwe Kleine-König1-4/+2
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: rx51_battery: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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>
2023-09-18power: supply: qcom_smbb: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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>
2023-09-18power: supply: pcf50633-charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: max8925_power: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
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>
2023-09-18power: supply: max77693_charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: max77650-charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: max14577_charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: lp8788-charger: Convert to platform remove callback returning ↵Uwe Kleine-König1-4/+2
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: isp1704_charger: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: ipaq_micro_battery: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: goldfish_battery: Convert to platform remove callback ↵Uwe Kleine-König1-3/+2
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: da9150-charger: Convert to platform remove callback returning ↵Uwe Kleine-König1-4/+2
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: da9052-battery: Convert to platform remove callback returning ↵Uwe Kleine-König1-4/+2
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>
2023-09-18power: supply: da9030_battery: Convert to platform remove callback returning ↵Uwe Kleine-König1-4/+2
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() 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>