The OCP board used a BlueField's GPIO pin for entering
low power mode. That board was not commercialized and
has been dropped from production so all its code is unused.
The new hardware requirement is to trigger a graceful shutdown
when that GPIO pin is toggled. So replace the unused low power
mode with a graceful shutdown.
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
Reviewed-by: David Thompson <davthompson@nvidia.com>
Link: https://lore.kernel.org/r/20240611134327.30975-1-asmaa@nvidia.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Commit 223a3b8283 ("power: supply: max17042_battery: use VFSOC for
capacity when no rsns") made it so that capacity on systems without
current sensing would be read from VFSOC instead of RepSOC. However,
the SOC threshold calculation still read RepSOC to get the SOC
regardless of the current sensing option state.
Fix this by applying the same conditional to determine which register
should be read.
This also seems to be the intended behavior as per the datasheet - SOC
alert config value in MiscCFG on setups without current sensing is set
to a value of 0b11, indicating SOC alerts being generated based on
VFSOC, instead of 0b00 which indicates SOC alerts being generated based
on RepSOC.
This fixes an issue on the Galaxy S3/Midas boards, where the alert
interrupt would be constantly retriggered, causing high CPU usage
on idle (around ~12%-15%).
Fixes: e5f3872d20 ("max17042: Add support for signalling change in SOC")
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240817-max17042-soc-threshold-fix-v1-1-72b45899c3cc@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Pull power sequencing fix from Bartosz Golaszewski:
- request the wlan-enable GPIO "as-is" to fix an issue with the wifi
module being already powered up before linux boots
* tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: request the WLAN enable GPIO as-is
If the WCN module is powered up before linux boots and the ath11k driver
probes at the same time as the power sequencing driver, we may end up
driving the wlan-enable GPIO low in the latter, breaking the start-up of
the WLAN module. Request the wlan-enable GPIO as-is so that if the WLAN
module is already starting/started, we leave it alone.
Fixes: 2f1630f437 ("power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets")
Reported-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Link: https://lore.kernel.org/r/20240813190751.155035-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Pull power supply fixes from Sebastian Reichel:
"rt5033:
- fix driver regression causing kernel oops
axp288-charger:
- fix charge voltage setup
qcom-battmgr:
- fix thermal zone spamming errors
- fix init on Qualcomm X Elite"
* tag 'for-v6.11-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply:
power: supply: qcom_battmgr: Ignore extra __le32 in info payload
power: supply: qcom_battmgr: return EAGAIN when firmware service is not up
power: supply: axp288_charger: Round constant_charge_voltage writes down
power: supply: axp288_charger: Fix constant_charge_voltage writes
power: supply: rt5033: Bring back i2c_set_clientdata
info->max_cv is in millivolts, divide the microvolt value being written
to constant_charge_voltage by 1000 *before* clamping it to info->max_cv.
Before this fix the code always tried to set constant_charge_voltage
to max_cv / 1000 = 4 millivolt, which ends up in setting it to 4.1V
which is the lowest supported value.
Fixes: 843735b788 ("power: axp288_charger: axp288 charger driver")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240717200333.56669-1-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Pull power sequencing fixes from Bartosz Golaszewski:
"There's one fix for an invalid pointer dereference in error path
reported by smatch and two patches that address the noisy config
choices you reported earlier this week.
Summary:
- fix an invalid pointer dereference in error path in pwrseq core
- reduce the Kconfig noise from PCI pwrctl choices"
* tag 'pwrseq-fixes-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
arm64: qcom: don't select HAVE_PWRCTL when PCI=n
Kconfig: reduce the amount of power sequencing noise
power: sequencing: fix an invalid pointer dereference in error path
Pull LED updates from Lee Jones:
"Core Frameworks:
- New trigger for Input Events
- New led_mc_set_brightness() call to adapt colour/brightness for
mutli-colour LEDs
- New lled_mc_trigger_event() call to call the above based on given
trigger conditions
- New led_get_color_name() call, a wrapper around the existing
led_colors[] array
- A new flag to avoid automatic renaming of LED devices
New Drivers:
- Silergy SY7802 Flash LED Controller
- Texas Instruments LP5569 LED Controller
- ChromeOS EC LED Controller
New Device Support:
- KTD202{6,7} support for Kinetic KTD2026/7 LEDs
Fix-ups:
- Replace ACPI/DT firmware helpers with agnostic variants
- Make use of resource managed devm_* API calls
- Device Tree binding adaptions/conversions/creation
- Constify/staticise applicable data structures
- Trivial; spelling, whitespace, coding-style adaptions
- Drop i2c_device_id::driver_data where the value is unused
- Utilise centrally provided helpers and macros to aid simplicity and
avoid duplication
- Use generic platform device properties instead of OF/ACPI specific
ones
- Consolidate/de-duplicate various functionality
- Remove superfluous/duplicated/unused sections
- Make use of the new *_scoped() guard APIs
- Improve/simplify error handling
Bug Fixes:
- Flush pending brightness changes before activating the trigger
- Repair incorrect device naming preventing matches
- Prevent memory leaks by correctly free resources during error
handling routines
- Repair locking issue causing circular dependency splats and
lock-ups
- Unregister sysfs entries before deactivating triggers to prevent
use-after issues
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Use correct return codes expected by the callers
- Omit set_brightness() error message for a LEDs that support only HW
triggers"
* tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (65 commits)
leds: leds-lp5569: Enable chip after chip configuration
leds: leds-lp5569: Better handle enabling clock internal setting
leds: leds-lp5569: Fix typo in driver name
leds: flash: leds-qcom-flash: Test the correct variable in init
leds: leds-lp55xx: Convert mutex lock/unlock to guard API
leds: leds-lp5523: Convert to sysfs_emit API
leds: leds-lp5569: Convert to sysfs_emit API
Revert "leds: led-core: Fix refcount leak in of_led_get()"
leds: leds-lp5569: Add support for Texas Instruments LP5569
leds: leds-lp55xx: Drop deprecated defines
leds: leds-lp55xx: Support ENGINE program up to 128 bytes
leds: leds-lp55xx: Generalize sysfs master_fader
leds: leds-lp55xx: Generalize sysfs engine_leds
leds: leds-lp55xx: Generalize sysfs engine_load and engine_mode
leds: leds-lp55xx: Generalize stop_engine function
leds: leds-lp55xx: Generalize turn_off_channels function
leds: leds-lp55xx: Generalize set_led_current function
leds: leds-lp55xx: Generalize multicolor_brightness function
leds: leds-lp55xx: Generalize led_brightness function
leds: leds-lp55xx: Generalize firmware_loaded function
...
Pull power sequencing updates from Bartosz Golaszewski:
"This has been in development since last year's Linux Plumbers
Conference and was inspired by the need to enable support upstream for
Bluetooth/WLAN chips on Qualcomm platforms.
The main problem we're fixing is powering up devices which are
represented as separate objects in the kernel (binding to different
drivers) but which share parts of the power-up sequence and thus need
some kind of a mediator who knows the possible interactions and can
assure they don't interfere with neither device's bring up. An example
of such an inter-driver interaction is the WCN family of BT/WLAN chips
from Qualcomm of which some models require the user to observe a
certain delay between driving the bt-enable and wlan-enable GPIOs.
This is not a new problem but up to this point all attempts at
addressing it ended up hitting one wall or another and being dropped.
The main obstacle was the fact that most these attempts tried to
introduce the concept of a "power sequence" into the device-tree
bindings which breaks the main DT rule: describe the hardware, not its
behavior. The solution I proposed focuses on making the power
sequencer drivers interpret the actual HW description flexibly. More
details on that are in the linked cover letter.
The second problem fixed here is powering up PCI devices before they
are detected on the bus. This is achieved by creating special platform
devices for device-tree nodes describing hard-wired PCI devices which
bind to the so-called PCI power control drivers which enable required
resources and trigger a bus rescan once the controlled device is up
then setup the correct devlink hierarchy for power-management.
By combining the two new frameworks we implemented the power
sequencing PCI power control driver which is capable of powering up
the WLAN modules of the QCom WCN family of chipsets.
All this has spent a significant amount of time in linux-next and
enabled WLAN/BT support on several Qualcomm platforms. To further
prove that this is useful and needed: right after this was picked up
into next, I was sent a series using the subsystem for a similar
use-case on Amlogic platforms.
This contains the core power sequencing framework, the first driver,
PCI changes using the pwrseq library (blessed by Bjorn Helgaas) and
some fixes that came later"
* tag 'pwrseq-updates-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
PCI/pwrctl: only call of_platform_populate() if CONFIG_OF is enabled
power: sequencing: simplify returning pointer without cleanup
PCI/pwrctl: Add a PCI power control driver for power sequenced devices
PCI/pwrctl: Add PCI power control core code
PCI/pwrctl: Create platform devices for child OF nodes of the port node
PCI/pwrctl: Reuse the OF node for power controlled devices
PCI: Hold the rescan mutex when scanning for the first time
power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
power: sequencing: implement the pwrseq core
Clang warns (or errors with CONFIG_WERROR=y):
drivers/power/supply/cros_charge-control.c:319:2: error: array index 3 is past the end of the array (that has type 'struct attribute *[3]') [-Werror,-Warray-bounds]
319 | priv->attributes[_CROS_CHCTL_ATTR_COUNT] = NULL;
| ^ ~~~~~~~~~~~~~~~~~~~~~~
drivers/power/supply/cros_charge-control.c:49:2: note: array 'attributes' declared here
49 | struct attribute *attributes[_CROS_CHCTL_ATTR_COUNT];
| ^
1 error generated.
In earlier revisions of the driver, the attributes array in
cros_chctl_priv had four elements with four distinct assignments but
during review, the number of elements was changed to three through use
of an enum and the assignments became a for loop, except for this one,
which is now out of bounds. This assignment is no longer necessary
because the size of the attributes array no longer accounts for it, so
just remove it to clear up the warning.
Fixes: c6ed48ef52 ("power: supply: add ChromeOS EC based charge control driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240702-cros_charge-control-fix-clang-array-bounds-warning-v1-1-ae04d995cd1d@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Framework laptops implement a custom charge control EC command.
The upstream CrOS EC command is also present and functional but can get
overridden by the custom one.
Until Framework make both commands compatible or remove their custom
one, don't load the driver on those machines.
If the user knows they are not going to use the custom command they can
use a module parameter to load cros_charge-control anyways.
Note that the UEFI setup configuration for battery control also uses
their custom command.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-5-8f649d018c52@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
'struct power_supply_maintenance_charge_table' is not modified in this
driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
In order to do it, some code also needs to be adjusted to this new const
qualifier.
On a x86_64, with allmodconfig:
Before:
======
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o
After:
=====
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
4087 4552 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/6caafd0ac2556a40405273b1a4badc508ea8e9b0.1719125040.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
'struct power_supply_vbat_ri_table' are not modified in this driver.
Constifying these structures moves some data to a read-only section, so
increase overall security.
In order to do it, some code also needs to be adjusted to this new const
qualifier.
On a x86_64, with allmodconfig:
Before:
======
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
955 7664 0 8619 21ab drivers/power/supply/samsung-sdi-battery.o
After:
=====
$ size drivers/power/supply/samsung-sdi-battery.o
text data bss dec hex filename
4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/d01818abd880bf435d1106a9a6cc11a7a8a3e661.1719125040.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
If iio_read_channel_processed() fails, 'val->intval' is not updated, but it
is still *1000 just after. So, in case of error, the *1000 accumulate and
'val->intval' becomes erroneous.
So instead of rescaling the value after the fact, use the dedicated scaling
API. This way the result is updated only when needed. In case of error, the
previous value is kept, unmodified.
This should also reduce any inaccuracies resulting from the scaling.
Finally, this is also slightly more efficient as it saves a function call
and a multiplication.
Fixes: fb24ccfbe1 ("power: supply: add Ingenic JZ47xx battery driver.")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Artur Rojek <contact@artur-rojek.eu>
Link: https://lore.kernel.org/r/51e49c18574003db1e20c9299061a5ecd1661a3c.1719121781.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This adds the power sequencing driver for the PMU modules present on the
Qualcomm WCN Bluetooth and Wifi chipsets. It uses the pwrseq subsystem
and knows how to match the sequencer to the consumer device by verifying
the relevant properties and DT layout. Using this driver will allow the
BT and WLAN drivers to respect the required delays between enabling the
two modules.
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD, SM8650-QRD & SM8650-HDK
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240605123850.24857-3-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
