summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)Author
2024-01-19power: supply: bq24190_charger: Fix "initializer element is not constant" errorNathan Chancellor
When building with a version of GCC prior to 8.x, there is an error around non-constant initializer elements: drivers/power/supply/bq24190_charger.c:1978:16: error: initializer element is not constant .vbus_desc = bq24190_vbus_desc, ^~~~~~~~~~~~~~~~~ drivers/power/supply/bq24190_charger.c:1978:16: note: (near initialization for 'bq24190_chip_info_tbl[0].vbus_desc') drivers/power/supply/bq24190_charger.c:1989:16: error: initializer element is not constant .vbus_desc = bq24190_vbus_desc, ^~~~~~~~~~~~~~~~~ drivers/power/supply/bq24190_charger.c:1989:16: note: (near initialization for 'bq24190_chip_info_tbl[1].vbus_desc') drivers/power/supply/bq24190_charger.c:2000:16: error: initializer element is not constant .vbus_desc = bq24190_vbus_desc, ^~~~~~~~~~~~~~~~~ drivers/power/supply/bq24190_charger.c:2000:16: note: (near initialization for 'bq24190_chip_info_tbl[2].vbus_desc') drivers/power/supply/bq24190_charger.c:2011:16: error: initializer element is not constant .vbus_desc = bq24190_vbus_desc, ^~~~~~~~~~~~~~~~~ drivers/power/supply/bq24190_charger.c:2011:16: note: (near initialization for 'bq24190_chip_info_tbl[3].vbus_desc') drivers/power/supply/bq24190_charger.c:2022:16: error: initializer element is not constant .vbus_desc = bq24296_vbus_desc, ^~~~~~~~~~~~~~~~~ drivers/power/supply/bq24190_charger.c:2022:16: note: (near initialization for 'bq24190_chip_info_tbl[4].vbus_desc') Clang versions prior to 17.x show a similar error: drivers/power/supply/bq24190_charger.c:1978:16: error: initializer element is not a compile-time constant .vbus_desc = bq24190_vbus_desc, ^~~~~~~~~~~~~~~~~ 1 error generated. Newer compilers have decided to accept these structures as compile time constants as an extension. To resolve this issue for all supported compilers, change the vbus_desc member in 'struct bq24190_chip_info' to a pointer, as it is only ever passed by reference anyways, and adjust the assignments accordingly. Closes: https://github.com/ClangBuiltLinux/linux/issues/1973 Fixes: b150a703b56f ("power: supply: bq24190_charger: Add support for BQ24296") Signed-off-by: Nathan Chancellor <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>
2024-01-14Merge power-supply fixes for 6.7 cycleSebastian Reichel
Merge power-supply fixes branch, which I never send for the v6.7 cycle. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-12-25power: supply: bq24190_charger: Add support for BQ24296Hermes Zhang
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>
2023-12-25power: supply: qcom_battmgr: Register the power supplies after PDR is upKonrad Dybcio
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>
2023-12-24power: supply: Fix null pointer dereference in smb2_probeKunwu Chan
devm_kasprintf and devm_kzalloc return a pointer to dynamically allocated memory which can be NULL upon failure. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Link: https://lore.kernel.org/r/20231124075021.1335289-1-chentao@kylinos.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-12-24power: reset: at91: Drop '__init' from at91_wakeup_status()Nathan Chancellor
When building with clang, there are two section mismatch warnings: WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x7c (section: .text) -> at91_wakeup_status (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text) Drop '__init' from at91_wakeup_status() to clear up the mismatch. Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()") Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()") Signed-off-by: Nathan Chancellor <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>
2023-12-24power: supply: Use multiple MODULE_AUTHOR statementsCharalampos Mitrodimas
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>
2023-12-24power: supply: Fix indentation and some other warningsCharalampos Mitrodimas
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>
2023-12-24power: reset: gpio-restart: Use devm_register_sys_off_handler()Andrew Davis
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>
2023-11-16power: supply: bq256xx: fix some problem in bq256xx_hw_initSu Hui
smatch complains that there is a buffer overflow and clang complains 'ret' is never read. Smatch error: drivers/power/supply/bq256xx_charger.c:1578 bq256xx_hw_init() error: buffer overflow 'bq256xx_watchdog_time' 4 <= 4 Clang static checker: Value stored to 'ret' is never read. Add check for buffer overflow and error code from regmap_update_bits(). Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231116041822.1378758-1-suhui@nfschina.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-11-16power: supply: cw2015: correct time_to_empty units in sysfsJan Palus
RRT_ALRT register holds remaining battery time in minutes therefore it needs to be scaled accordingly when exposing TIME_TO_EMPTY via sysfs expressed in seconds Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver") Signed-off-by: Jan Palus <jpalus@fastmail.com> Link: https://lore.kernel.org/r/20231111221704.5579-1-jpalus@fastmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-11-15power: reset: at91-sama5d2_shdwc: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: at91-reset: Convert to platform remove callback returning voidUwe Kleine-König
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>
2023-11-15power: reset: tps65086-restart: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Returning an error if unregister_restart_handler() failed has no effect but triggering another error message. So converting this driver to .remove_new() has no effect but to suppress the duplicated error message. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: syscon-poweroff: Convert to platform remove callback returning ↵Uwe Kleine-König
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: rmobile-reset: Convert to platform remove callback returning voidUwe Kleine-König
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>
2023-11-15power: reset: restart-poweroff: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: regulator-poweroff: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: qnap-poweroff: Convert to platform remove callback returning voidUwe Kleine-König
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>
2023-11-15power: reset: mt6323-poweroff: Convert to platform remove callback returning ↵Uwe Kleine-König
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: ltc2952-poweroff: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: atc260x-poweroff: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: at91-poweroff: Convert to platform remove callback returning voidUwe Kleine-König
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>
2023-11-15power: reset: as3722-poweroff: Convert to platform remove callback returning ↵Uwe Kleine-König
void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <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>
2023-11-15power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()Uwe Kleine-König
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>
2023-11-15power: reset: at91-reset: Stop using module_platform_driver_probe()Uwe Kleine-König
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>
2023-11-15power: reset: at91-poweroff: Stop using module_platform_driver_probe()Uwe Kleine-König
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>
2023-11-15power: supply: bq27xxx: Stop and start delayed work in suspend and resumeMarek Vasut
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>
2023-11-15power: reset: pwr-mlxbf: support graceful reboot instead of emergency resetAsmaa Mnebhi
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>
2023-11-03Merge tag 'usb-6.7-rc1' of ↵Linus Torvalds
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 ...
2023-10-21power: reset: vexpress: Use device_get_match_data()Rob Herring
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 Reichel
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 Stitt
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 Stitt
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 Stitt
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 Stitt
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 Stitt
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 Stitt
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 Stitt
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-16Merge 6.6-rc6 into usb-nextGreg Kroah-Hartman
We need the USB and Thunderbolt fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-13power: supply: cpcap: Drop non-DT driver matchingRob Herring
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 Robinson
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 Eichenberger
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 Eichenberger
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 Eichenberger
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 Hauser
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 Hauser
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 Hauser
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-10-02power: supply: Fix tps65217-charger vs vbus irq conflictGrant B Adams
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>
2023-09-30power: supply: core: remove opencoded string_lower()Thomas Weißschuh
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>