- 29 Jun, 2021 8 commits
-
-
Hans de Goede authored
It turns out that the "T3 MRD" DMI_BOARD_NAME value is used in a lot of different Cherry Trail x5-z8300 / x5-z8350 based Mini-PC / HDMI-stick models from Ace PC / Meegopad / MinisForum / Wintel (and likely also other vendors). Most of the other DMI strings on these boxes unfortunately contain various generic values like "Default string" or "$(DEFAULT_STRING)", so we cannot match on them. These devices do have their chassis-type correctly set to a value of "3" (desktop) which is a pleasant surprise, so also match on that. This should avoid the quirk accidentally also getting applied to laptops / tablets (which do actually have a battery). Although in my quite large database of Bay and Cherry Trail based devices DMIdecode dumps I don't have any laptops / tables with a board-name of "T3 MRD", so this should not be an issue. BugLink: https://askubuntu.com/questions/1206714/how-can-a-mini-pc-be-stopped-from-being-detected-as-a-laptop-with-a-battery/Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com>
-
Hans de Goede authored
As documented in the updated "Naming" chapter of Documentation/process/coding-style.rst, usage of the work blacklist should be avoided where possible. Rename the list of devices which have no battery to the axp288_no_battery_list, which also more accurately describes the contents of the list. Signed-off-by:
-
Andy Shevchenko authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr() does not have any sense (this also allows ACPI matching via PRP0001, even though it might be not relevant here). This fixes compile warning (!CONFIG_OF): drivers/power/supply/bq24190_charger.c:1972:34: warning: ‘bq24190_of_match’ defined but not used [-Wunused-const-variable=] Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Yu Jiahua authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Signed-off-by:
Yu Jiahua <yujiahua1@huawei.com> Signed-off-by:
-
Zou Wei authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
-
Zou Wei authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
-
Zou Wei authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
-
Sebastian Reichel authored
-
- 04 Jun, 2021 13 commits
-
-
Carl Philipp Klemm authored
This avoids reimplementing the detection logic twice and removes the possibility of activating charging with 500mA even if a battery is not detected. Signed-off-by:
Carl Philipp Klemm <philipp@uvos.xyz> Signed-off-by:
-
Carl Philipp Klemm authored
This invalidates empty->counter_uah and charge_full when charge_now indicates that they are grossly wrong and adds some tolerance to POWER_SUPPLY_PROP_CHARGE_FULL to allow for inaccuracies in the charge counter and manufacturing tolerances in the battery. Signed-off-by:
-
Hermann Lauer authored
Allow disabling and re-enabling battery charging of an axp209 PMIC through a writable status property. With the current driver code charging is always on. This works on the axp209 of Banana {Pi M1+,Pro} and should work on all AXP chips. Signed-off-by: Hermann.Lauer@uni-heidelberg.de Signed-off-by: -
Krzysztof Kozlowski authored
There are no platforms using the driver with platform data (no board files with the driver), so the dead code can be dropped. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The driver was reporting POWER_SUPPLY_PROP_ONLINE via platform data functions or '1' if no platform data was provided. Since there are no platforms using the driver with platform data (no board files with the driver), the online property can be simplified to always return '1'. Signed-off-by:
-
Krzysztof Kozlowski authored
The driver was reporting POWER_SUPPLY_PROP_STATUS via platform data functions. Without platform data, the max17040_get_status() functions returns early with POWER_SUPPLY_STATUS_UNKNOWN. Since there are no platforms using the driver with platform data (no board files with the driver), the status property was always unknown. Signed-off-by:
-
Zhen Lei authored
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
Bixuan Cui authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
Bixuan Cui <cuibixuan@huawei.com> Signed-off-by:
-
Stephan Gerhold authored
The fuel gauge in the RT5033 PMIC has its own I2C bus and interrupt line. Therefore, it is not actually part of the RT5033 MFD and needs its own of_match_table to probe properly. Also, given that it's independent of the MFD, there is actually no need to make the Kconfig depend on MFD_RT5033. Although the driver uses the shared <linux/mfd/rt5033.h> header, there is no compile or runtime dependency on the RT5033 MFD driver. Cc: Beomho Seo <beomho.seo@samsung.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Fixes: b847dd96 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
-
Stephan Gerhold authored
The RT5033 PMIC provides a simple fuel gauge via I2C. Add a DT schema to describe how to set it up in the device tree. Note that although RT5033 is a MFD with lots of functionality (also charger, regulator, LEDs, ...) the fuel gauge has a separate I2C bus and is not part of the MFD. Cc: Beomho Seo <beomho.seo@samsung.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Matti Vaittinen authored
The only known BD70528 use-cases are such that the PMIC is controlled from separate MCU which is not running Linux. I am not aware of any Linux driver users. Furthermore, it seems there is no demand for this IC. Let's ease the maintenance burden and drop the driver. We can always add it back if there is sudden need for it. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge falling - but instead rely on Devicetree to configure it. The Maxim 14577/77836 datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Iskren Chernev <iskren.chernev@gmail.com> Acked-by:
-
Krzysztof Kozlowski authored
Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge falling - but instead rely on Devicetree to configure it. The Maxim 17047/77693 datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. The interrupt line is shared between PMIC and RTC driver, so using level sensitive interrupt is here especially important to avoid races. With an edge configuration in case if first PMIC signals interrupt followed shortly after by the RTC, the interrupt might not be yet cleared/acked thus the second one would not be noticed. Signed-off-by:
-
- 03 Jun, 2021 15 commits
-
-
Maximilian Luz authored
The ac->state field is __le32, not u32. So change the variable we're temporarily storing it in to __le32 as well. Reported-by:
kernel test robot <lkp@intel.com> Fixes: e61ffb34 ("power: supply: Add AC driver for Surface Aggregator Module") Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by:
-
Ikjoon Jang authored
Currently sbs-battery supports three string properties - manufacturer, model_name, and chemistry. Buffers for those properties are currently defined as global variables. This patch moves those global variables into struct sbs_info and cache/reuse them as they are all constant values. Signed-off-by:
Ikjoon Jang <ikjn@chromium.org> Tested-by:
Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by:
-
Andreas Kemnade authored
Adds properties for setting the maximum current to USB, ADP and Battery supplies. USB and ADP limits are reset to OTP values upon replugging. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Signed-off-by:
-
Andreas Kemnade authored
The RC5T619 can detect SDP, CDP and DCP chargers, so let's add support for it. Signed-off-by:
-
Linus Walleij authored
This driver is including the legacy GPIO header <linux/gpio.h> but not using any symbols from it. Delete the include. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
David Heidelberg <david@ixit.cz> Signed-off-by:
-
Linus Walleij authored
The PM2301 was only used in tandem with AB9540, part of U9540, a platform that was cancelled and never deployed in products. Delete it. Signed-off-by:
-
Guenter Roeck authored
The result of container_of() operations is never NULL unless the element is the first element of the embedded structure, which is not the case here. The NULL check is therefore unnecessary and misleading. Remove it. This change was made automatically with the following Coccinelle script. @@ type t; identifier v; statement s; @@ <+... ( t v = container_of(...); | v = container_of(...); ) ... when != v - if (\( !v \| v == NULL \) ) s ...+> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Krzysztof Kozlowski authored
Only one header (smartreflex.h) in include/linux/power/ is not related to battery or charger drivers. All others should be covered by power supply maintainers entry so patches to them will reach respective people and lists. Signed-off-by:
-
Krzysztof Kozlowski authored
The ab8500.h header in linux/power is not referenced/included, so can be safely removed. Signed-off-by:
-
Linus Walleij authored
This setting is read directly from the device tree in the ab8500_charger.c code. Signed-off-by:
-
Linus Walleij authored
The vendor code tree supplies platform data to enable he USB charging for AB8500 and AB8500 and disable the AC charging on the AB8505. This was missed when the driver was submitted to the mainline kernel. Fix this by doing what the vendor kernel does: always register the USB charger, do not register the AC charger on the AB8505. Signed-off-by:
-
Linus Walleij authored
Sometimes the code will crash because we haven't enabled AC or USB charging and thus not created the corresponding psy device. Fix it by checking that it is there before notifying. Signed-off-by:
-
Linus Walleij authored
The code was calling ab8500_bm_of_probe() in four different spots effectively overwriting the same configuration three times. This was done because probe order was uncertain. Since we now used componentized probe, call it only once while probing the main charging component. Signed-off-by:
-
Linus Walleij authored
The driver has problems with the different components of the charging code racing with each other to probe(). This results in all four subdrivers populating battery information to ascertain that it is populated for their own needs for example. Fix this by using component probing and thus expressing to the kernel that these are dependent components. The probes can happen in any order and will only acquire resources such as state container, regulators and interrupts and initialize the data structures, but no execution happens until the .bind() callback is called. The charging driver is the main component and binds first, then bind in order the three subcomponents: ab8500-fg, ab8500-btemp and ab8500-chargalg. Do some housekeeping while we are moving the code around. Like use devm_* for IRQs so as to cut down on some boilerplate. Signed-off-by:
-
Jian Xin authored
fix misspelled 'interrupts' Signed-off-by:
Jian Xin <xinjian@yulong.com> Signed-off-by:
-
- 13 May, 2021 4 commits
-
-
Maximilian Luz authored
The battery subsystem of the Surface Aggregator Module EC requires us to register the battery notifier with instance ID 0. However, battery events are actually sent with the instance ID corresponding to the device, which is nonzero. Thus, the strict-matching approach doesn't work here and will discard events that the driver is expected to handle. To fix this we have to fall back on notifier matching by target-category only and have to manually check the instance ID in the notifier callback. Fixes: 167f77f7 ("power: supply: Add battery driver for Surface Aggregator Module") Signed-off-by:
-
Zou Wei authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
-
Zou Wei authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
-
Krzysztof Kozlowski authored
Switch to Canonical address in S3C power supply driver, just like in other entries. Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
