30 May, 2018
1 commit
-
[ Upstream commit 66ec32fc7cd116dab5c02603ea8ec28ff92da3b5 ]
max17042_get_status uses the core power_supply_am_i_supplied. That
function relies on DT properties to figure out the power supply
topology, and will error out without DT.Fixes max17042 battery status being reported as "unknown".
Signed-off-by: Pierre Bourdon
Signed-off-by: Andre Heider
Signed-off-by: Sebastian Reichel
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
29 Aug, 2017
3 commits
-
Fix drivers/power/supply/max17042_battery.c:1059:6:
warning: 'acpi_id' may be used uninitialized in this function.No idea why my gcc version did not catch this.
Reported-by: kbuild test robot
Signed-off-by: Hans de Goede
Signed-off-by: Sebastian Reichel -
On some x86/ACPI boards the DSDT defines an ACPI event handler for
the max17047 IRQ, this causes several problems:1) We need to share the IRQ to avoid an error getting it
2) Even of we are willing to share, we may fail to share because some
DSDTs claim it exclusivly3) If we are unable to share the IRQ, or the IRQ is only listed as an
ACPI event source and not in the max1704 firmware node, then the
charge threshold IRQ (which is used to give an IRQ every 1 percent
charge change) becomes a problem, the ACPI event handler will not
update this to the next 1 percent threshold, so the IRQ keeps firing
and we get an IRQ storm pegging 1 CPU core.This happens despite the max17042 driver not setting the charge
threshold because Windows uses it and leaves it set on reboot.So if we are unable to get the IRQ we need to reprogram the
charge threshold to its disabled setting.This commit fixes al of the above, while at it it also makes the error
msg when being unable to get the IRQ consistent with other messages.Signed-off-by: Hans de Goede
Signed-off-by: Sebastian Reichel -
Some x86 devices enumerate a max17047 fuel-gauge through a MAX17047
ACPI firmware-node, add support for this.Signed-off-by: Hans de Goede
Signed-off-by: Sebastian Reichel
01 May, 2017
11 commits
-
Add support for the SCOPE property, always return SCOPE_SYSTEM,
as the max170xx is used for the main battery on all known systems
with a max170xx.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
At least upower prefers the more precise charge_now sysfs value over
capacity and the max17042 has the info, so lets export it.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
The info is there, lets export it as a property.
Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
The PROP_CHARGE_FULL code was hardcoded for the default sense
resistor of 0.010 Ohm, make it use r_sns which contains the
actual sense resistor value in micro-Ohms instead.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
The info is there, so lets export it, like we already do for VOLT_MAX.
Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
The max17042 is intended for Li-Ion or Li-Po batteries, add a TECHNOLOGY
attribute to reflect this. Note this is hardcoded to Li-Ion as there is
no way to tell the difference, and Lithium-Ion Polymer batteries are
a sub-family of Lithium-Ion so Li-Ion technically is correct for both.Using Li-Ion for both is already done by many drivers and is much
better then not providing any technology info at all.Suggested-by: Wolfgang Wiedmeyer
Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
If our supplier changes status, chances are we've changed status too,
let any listeners know about this.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
Userspace prefers the driver having a status property over having to guess
itself. Specifically this will properly make the GNOME3 UI (and likely
others) properly show discharging / charging / full status, instead
of always showing discharging as status.Note that in the case there is no charger driver supplying the max17042,
then a status of unknown will get returned. At least upower treats
this the same as not having a status attribute, so in this case nothing
changes from a userspace pov.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
Some x86 machines use a max17047 fuel-gauge and x86 might be missing
platform_data if not provided by SFI.This commit adds default platform_data as fallback option so that the
driver can work on boards where no platform_data is provided.Since not all boards have a thermistor hooked up, set temp_min to 0 and
change the health checks from temp < temp_min to
not trigger on such boards (where temp reads 0).Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
The temp alert values are 8-bit 2's complement, so sign-extend them
before reporting them back to the caller.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel -
Use sign_extend32 to sign-extend variables where necessary instead of
DIY code.Signed-off-by: Hans de Goede
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel
16 Aug, 2016
1 commit
-
Power Supply Fixes for 4.8 cycle
11 Aug, 2016
1 commit
-
This moves all power supply drivers from drivers/power/
to drivers/power/supply/. The intention is a cleaner
source tree, since drivers/power/ also contains frameworks
unrelated to power supply, like adaptive voltage scaling.Signed-off-by: Sebastian Reichel