- 14 May, 2019 1 commit
-
-
Lubomir Rintel authored
The endianness of data returned from the EC depends on the particular EC version determined at run time. Cast from little/big endian explicitey in the routine that flips endianness to the native one to make sparse happy. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 76311b9a ("power: supply: olpc_battery: Add OLPC XO 1.75 support") Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com>
-
- 10 May, 2019 1 commit
-
-
YueHaibing authored
Fix gcc build error while CONFIG_REGULATOR is not set drivers/power/supply/ucs1002_power.o: In function `ucs1002_probe': drivers/power/supply/ucs1002_power.c:593: undefined reference to `devm_regulator_register' drivers/power/supply/ucs1002_power.o:(.rodata+0x3b8): undefined reference to `regulator_enable_regmap' drivers/power/supply/ucs1002_power.o:(.rodata+0x3c0): undefined reference to `regulator_disable_regmap' drivers/power/supply/ucs1002_power.o:(.rodata+0x3c8): undefined reference to `regulator_is_enabled_regmap' Add Kconfig dependency to CONFIG_REGULATOR. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 9a2688e4 ("power: supply: Add driver for Microchip UCS1002") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- 09 May, 2019 1 commit
-
-
Axel Lin authored
Fix wrong return value checking for devm_regulator_register and devm_regmap_init_i2c. This looks like a copy-n-paste mistake. Fixes: 9a2688e4 ("power: supply: Add driver for Microchip UCS1002") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
- 03 May, 2019 3 commits
-
-
Andrey Smirnov authored
Add driver for Microchip UCS1002 Programmable USB Port Power Controller with Charger Emulation. The driver exposed a power supply device to control/monitor various parameter of the device as well as a regulator to allow controlling VBUS line. Signed-off-by:
-
Andrey Smirnov authored
Add bindings for Microchip UCS1002 Programmable USB Port Power Controller with Charger Emulation. Signed-off-by:
Rob Herring <robh+dt@kernel.org> Cc: Enric Balletbo Serra <enric.balletbo@collabora.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by:
-
Andrey Smirnov authored
Add POWER_SUPPLY_HEALTH_OVERCURRENT constant in order to allow singalling overcurrent condition via power supply health information. Signed-off-by:
-
- 02 May, 2019 1 commit
-
-
Phong Tran authored
The increment operator of pointer in be32_to_cpu() is not explicitly. It made the warning from clang: drivers/power/supply/power_supply_core.c:674:36: error: multiple unsequenced modifications to 'list' [-Werror,-Wunsequenced] drivers/power/supply/power_supply_core.c:675:41: error: multiple unsequenced modifications to 'list' [-Werror,-Wunsequenced] Link: https://github.com/ClangBuiltLinux/linux/issues/460Signed-off-by:
Phong Tran <tranmanphong@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
- 01 May, 2019 5 commits
-
-
Nick Crews authored
The existing POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties don't have documentation. I add that documentation here. v5 changes: - Split this commit out from the previous two commits. Signed-off-by:
Nick Crews <ncrews@chromium.org> Reviewed-by:
-
Nick Crews authored
Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand the existing CHARGE_CONTROL_* properties. I am adding them in order to support a new Chrome OS device, but these properties should be general enough that they can be used on other devices. When the charge_type is "Custom", the charge controller uses the POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some other algorithm. For example, in the use case that I am supporting, this means the battery begins charging when the percentage level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and charging ceases when the percentage level goes above POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD. v5 changes: - Add the other missing CHARGE_CONTROL_* properties documentation in a separate commit - Split up adding the charge types and adding the POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into two different commits. v4 changes: - Add documentation for the new properties, and add documentation for the the previously missing charge_control_limit and charge_control_limit_max properties. Signed-off-by:
-
Nick Crews authored
Add "Standard", "Adaptive", and "Custom" modes to the charge_type property, to expand the existing "Trickle" and "Fast" modes. I am adding them in order to support a new Chrome OS device, but these properties should be general enough that they can be used on other devices. The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are more tricky: "Adaptive" means that the charge controller uses some custom algorithm to change the charge type automatically, with no configuration needed. "Custom" means that the charge controller uses the POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some other algorithm. v5 changes: - Split up adding the charge types and adding the POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into two different commits. v4 changes: - Add documentation for the new properties, and add documentation for the the previously missing charge_control_limit and charge_control_limit_max properties. Signed-off-by:
-
Hans de Goede authored
The ACEPC T8 and T11 Cherry Trail Z8350 mini PCs use an AXP288 and as PCs, rather then portables, they does not have a battery. Still for some reason the AXP288 not only thinks there is a battery, it actually thinks it is discharging while the PC is running, slowly going to 0% full, causing userspace to shutdown the system due to the battery being critically low after a while. This commit adds the ACEPC T8 and T11 to the axp288 fuel-gauge driver blacklist, so that we stop reporting bogus battery readings on this device. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852 Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Krzysztof Kozlowski authored
User-space might be interested in receiving uevents when the charging starts/stops or if conditions of battery changes (e.g. over-temperature). Notify about changes in battery also when the flags change, not only SoC. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
-
- 18 Apr, 2019 14 commits
-
-
Sebastian Reichel authored
This immutable branch contains the changes required for OLPC 1.75 battery, which touches x86 and power-supply and is based on v5.1-rc1. Signed-off-by: -
Lubomir Rintel authored
The power framework gained ability to register groups of sysfs attributes in commit cef8fe6a ("power: supply: core: add support for custom sysfs attributes"). Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Lubomir Rintel authored
The battery and the protocol are essentially the same as OLPC XO 1.5, but the responses from the EC are LSB first. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Lubomir Rintel authored
This wouldn't work on the DT-based ARM platform. Let's read the EC version directly from the EC driver instead. This removes x86 specific bits that would prevent this driver from being used with the EC of ARM-based OLPC XO 1.75. Signed-off-by:
-
Lubomir Rintel authored
This simplifies the error handling. Signed-off-by:
-
Lubomir Rintel authored
The global variables for private data are not too nice. I'd like some more, and that would clutter the global name space even further. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Lubomir Rintel authored
Avoid using the x86 OLPC platform specific call to get the board version. That wouldn't work on FDT-based ARM MMP2 platform. Add the XO 1.5 compatible string too. This is actually not completely necessary as the battery nodes on XO 1.5 claim to be compatible with "olpc,xo1-battery", but there are, in fact, differencies. Signed-off-by:
-
Lubomir Rintel authored
The XO-1 and XO-1.5 batteries apparently differ in an ability to report ambient temperature. We need to use a different compatible string for the XO-1.5 battery. Previously olpc_dt_fixup() used the presence of the battery node's compatible property to decide whether the DT is up to date. Now we need to look for a particular value in the compatible string, to decide Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Lubomir Rintel authored
This makes the following patch more concise. Signed-off-by:
-
Lubomir Rintel authored
It was pointed out in a review, and checkpatch.pl complains about this. Breaking it down into multiple ofw evaluations works just as well and reads better. Signed-off-by:
-
Lubomir Rintel authored
The XO-1 and XO-1.5 batteries apparently differ in an ability to report ambient temperature. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Artur Rojek authored
Add a driver for battery present on Ingenic JZ47xx SoCs. Signed-off-by:
Artur Rojek <contact@artur-rojek.eu> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Artur Rojek authored
Add documentation for the ingenic-battery driver, used on JZ47xx SoCs. Signed-off-by:
-
Sebastian Reichel authored
Merge immutable branch containing the IIO changes required for the new Ingenic JZ47xx battery fuel gauge driver. Signed-off-by:
-
- 17 Apr, 2019 7 commits
-
-
Quentin Schulz authored
This adds support for AXP813 PMIC. It is almost the same as AXP22X but has a different current limit. Signed-off-by:
Quentin Schulz <quentin.schulz@bootlin.com> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Quentin Schulz authored
To prepare for a new PMIC, factor out the code responsible of returning the maximum current to axp20x_get_current_max. Signed-off-by:
-
Chen-Yu Tsai authored
On AXP221 and later AXP PMICs that have the N_VBUSEN pin, when this pin is high, either due to the PMIC driving it high or as an input, the VBUS detection related interrupt mechanisms are disabled. Previously this was worked around in the phy-sun4i-usb driver, which needed to sense VBUS changes and report them to the musb driver in a timely matter. However this workaround was only for the A31 and A33 type USB PHYs. To support newer platforms we would have to enable it for almost all the post-A31 SoCs. However, since this is actually the result of the PMIC's behavior, the workaround would be better if done in the PMIC driver, in this case the VBUS power supply driver. Add the same workqueue-based polling to the VBUS power supply driver. The polling interval is chosen to be the debounce interval from the USB PHY driver, as this short interval is needed in some cases, but the power supply driver would not know when. Signed-off-by:
-
Chen-Yu Tsai authored
The VBUS current limit value macros have VBUS typed as VBUC, while the bitmask macro is named correctly. Fix it. Fixes: 69fb4dca ("power: Add an axp20x-usb-power driver") Signed-off-by:
-
Chen-Yu Tsai authored
This adds the "x-powers,axp813-usb-power-supply" to the list of compatibles for AXP20X VBUS power supply driver. Reviewed-by:
-
Wen Yang authored
The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/power/supply/power_supply_core.c:601:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. ./drivers/power/supply/power_supply_core.c:604:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. ./drivers/power/supply/power_supply_core.c:632:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. ./drivers/power/supply/power_supply_core.c:635:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. ./drivers/power/supply/power_supply_core.c:653:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. ./drivers/power/supply/power_supply_core.c:664:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. ./drivers/power/supply/power_supply_core.c:673:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function. Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Signed-off-by:
-
Wen Yang authored
The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. 492 int ab8500_bm_of_probe(struct device *dev, 493 struct device_node *np, 494 struct abx500_bm_data *bm) 495 { 496 const struct batres_vs_temp *tmp_batres_tbl; 497 struct device_node *battery_node; ... 501 /* get phandle to 'battery-info' node */ 502 battery_node = of_parse_phandle(np, "battery", 0); ... 509 if (!btech) { 510 dev_warn(dev, "missing property battery-name/type\n"); 511 return -EINVAL; ---> leaked here 512 } ... 540 of_node_put(battery_node); ---> released here 541 542 return 0; 543 } Detected by coccinelle with the following warnings: ./drivers/power/supply/ab8500_bmdata.c:511:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 502, but without a corresponding object release within this function. Signed-off-by:
-
- 15 Apr, 2019 7 commits
-
-
Tony Lindgren authored
With loadable modules we may get the following during init: could not initialize VBUS or ID IIO: -517 Let's not print any pointless error messages for deferred probe. Signed-off-by:
Tony Lindgren <tony@atomide.com> Acked-by:
-
Tony Lindgren authored
With loadable modules we may get the following during init: could not initialize VBUS or ID IIO: -517 Let's not print any pointless error messages for deferred probe. Signed-off-by:
-
Tony Lindgren authored
We should not use measured current value for average since we have proper coulomb counter values available. Using measured current value should be only used when the value is queried at a higher rate than the 250 ms rate the coulomb counter is configured to run at. Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Tony Lindgren authored
The coulomb counter calibration is not CCO, it's CCM. And the CCM is nine bits wide signed register, so let's use sign_extend32() for it. Signed-off-by:
-
Tony Lindgren authored
The accumulator sample register is signed 32-bits wide register on droid 4. And only the earlier version of cpcap has a signed 24-bits wide register. We're currently passing it around as unsigned, so let's fix that and use sign_extend32() for the earlier revision. Signed-off-by:
-
Tony Lindgren authored
We need to check current instead of the charge counter to see if a charger is connected. The charge counter shows the cumulated value instead of the current charge current and can be negative or positive. Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Sebastian Reichel authored
Merge fixes branch into next branch for cpcap-battery patches. Signed-off-by:Sebastian Reichel <sre@collabora.com>
-
