Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23 |
|
#
ce38f3fc |
| 01-Apr-2023 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Use alt usb-id extcon on some x86 android tablets
x86 ACPI boards which ship with only Android as their factory image may have pretty broken ACPI tables. This includes
power: supply: axp288_charger: Use alt usb-id extcon on some x86 android tablets
x86 ACPI boards which ship with only Android as their factory image may have pretty broken ACPI tables. This includes broken _AEI ACPI GPIO event handlers, which are normally used to listen to the micro-USB ID pin and:
1. Switch the USB-mux to the host / device USB controllers 2. Disable Vbus path before enabling the 5V boost (AXP reg 0x30 bit 7) 3. Turn 5V Vboost on / off
On non broken systems where this is not done through an ACPI GPIO event handler, there is an ACPI INT3496 device describing the involved GPIOs which are handled by the extcon-intel-int3496 driver; and axp288-charger.ko listens to this extcon-device and disables the Vbus path when necessary.
On x86 Android boards, with broken ACPI GPIO event handlers, these are disabled by acpi_quirk_skip_gpio_event_handlers() and an intel-int3496 extcon device is manually instantiated by x86-android-tablets.ko .
Add support to the axp288-charger code for this setup, so that it properly disables the Vbus path when necessary. Note this uses acpi_quirk_skip_gpio_event_handlers() to identify these systems, to avoid the need to add a separate DMI match table for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10 |
|
#
58e4a2d2 |
| 17-Dec-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
extcon: Fix extcon_get_extcon_dev() error handling
The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV) when the
extcon: Fix extcon_get_extcon_dev() error handling
The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV) when the CONFIG_EXTCON option is disabled. This is very complicated for the callers to handle and a number of them had bugs that would lead to an Oops.
In real life, there are two things which prevented crashes. First, error pointers would only be returned if there was bug in the caller where they passed a NULL "extcon_name" and none of them do that. Second, only two out of the eight drivers will build when CONFIG_EXTCON is disabled.
The normal way to write this would be to return -EPROBE_DEFER directly when appropriate and return NULL when CONFIG_EXTCON is disabled. Then the error handling is simple and just looks like:
dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev)); if (IS_ERR(dev->edev)) return PTR_ERR(dev->edev);
For the two drivers which can build with CONFIG_EXTCON disabled, then extcon_get_extcon_dev() will now return NULL which is not treated as an error and the probe will continue successfully. Those two drivers are "typec_fusb302" and "max8997-battery". In the original code, the typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but now that function is a no-op. For the max8997-battery driver everything should continue working as is.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
show more ...
|
#
00d05666 |
| 24-Feb-2022 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Use acpi_quirk_skip_acpi_ac_and_battery()
Normally the native AXP288 fg/charger drivers are preferred but one some devices the ACPI drivers should be used instead.
Th
power: supply: axp288_charger: Use acpi_quirk_skip_acpi_ac_and_battery()
Normally the native AXP288 fg/charger drivers are preferred but one some devices the ACPI drivers should be used instead.
The ACPI battery/ac drivers use the acpi_quirk_skip_acpi_ac_and_battery() helper to determine if they should skip loading because native fuel-gauge/ charger drivers like the AXP288 drivers will be used.
The new acpi_quirk_skip_acpi_ac_and_battery() helper includes a list of exceptions for boards where the ACPI drivers should be used instead.
Use this new helper to avoid loading on such boards. Note this requires adding a Kconfig dependency on ACPI, this is not a problem because ACPI should be enabled on all boards with an AXP288 PMIC anyways.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
5ac121b8 |
| 08-Feb-2022 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288-charger: Set Vhold to 4.4V
The AXP288's recommended and factory default Vhold value (minimum input voltage below which the input current draw will be reduced) is 4.4V. This lin
power: supply: axp288-charger: Set Vhold to 4.4V
The AXP288's recommended and factory default Vhold value (minimum input voltage below which the input current draw will be reduced) is 4.4V. This lines up with other charger IC's such as the TI bq2419x/bq2429x series which use 4.36V or 4.44V.
For some reason some BIOS-es initialize Vhold to 4.6V or even 4.7V which combined with the typical voltage drop over typically low wire gauge micro-USB cables leads to the input-current getting capped below 1A (with a 2A capable dedicated charger) based on Vhold.
This leads to slow charging, or even to the device slowly discharging if the device is in heavy use.
As the Linux AXP288 drivers use the builtin BC1.2 charger detection and send the input-current-limit according to the detected charger there really is no reason not to use the recommended 4.4V Vhold.
Set Vhold to 4.4V to fix the slow charging issue on various devices.
There is one exception, the special-case of the HP X2 2-in-1s which combine this BC1.2 capable PMIC with a Type-C port and a 5V/3A factory provided charger with a Type-C plug which does not do BC1.2. These have their input-current-limit hardcoded to 3A (like under Windows) and use a higher Vhold on purpose to limit the current when used with other chargers. To avoid touching Vhold on these HP X2 laptops the code setting Vhold is added to an else branch of the if checking for these models.
Note this also fixes the sofar unused VBUS_ISPOUT_VHOLD_SET_MASK define, which was wrong.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14 |
|
#
5b5100c5 |
| 18-Oct-2021 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288-charger: Simplify axp288_get_charger_health()
Now that axp288_charger_usb_update_property() reads and caches all relevant registers, axp288_get_charger_health() can be simplifi
power: supply: axp288-charger: Simplify axp288_get_charger_health()
Now that axp288_charger_usb_update_property() reads and caches all relevant registers, axp288_get_charger_health() can be simplified by directly returning the health.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
9052ff9b |
| 18-Oct-2021 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288-charger: Remove unnecessary is_present and is_online helpers
Now that axp288_charger_usb_update_property() reads and caches all relevant registers, the axp288_charger_is_presen
power: supply: axp288-charger: Remove unnecessary is_present and is_online helpers
Now that axp288_charger_usb_update_property() reads and caches all relevant registers, the axp288_charger_is_present() and axp288_charger_is_online() helpers are not necessary anymore.
Directly check the cached input_status instead, allowing the removal of these 2 helpers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.14.13 |
|
#
db6e4362 |
| 13-Oct-2021 |
Wei Yongjun <weiyongjun1@huawei.com> |
power: supply: axp288_charger: Fix missing mutex_init()
The driver allocates the mutex but not initialize it. Use mutex_init() on it to initialize it correctly.
Fixes: ed229454856e ("power: supply:
power: supply: axp288_charger: Fix missing mutex_init()
The driver allocates the mutex but not initialize it. Use mutex_init() on it to initialize it correctly.
Fixes: ed229454856e ("power: supply: axp288-charger: Optimize register reading method") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.14.12 |
|
#
ed229454 |
| 12-Oct-2021 |
Kate Hsuan <hpa@redhat.com> |
power: supply: axp288-charger: Optimize register reading method
The original implementation access the charger the same register value several times to get the charger status, such as online, enable
power: supply: axp288-charger: Optimize register reading method
The original implementation access the charger the same register value several times to get the charger status, such as online, enabled, and bus limits. It takes a long time and bandwidth for every "status get" operation.
To reduce the access of the register and save bandwidth, this commit integrated every read operation into only one "register value get" operation and cache them in the variables. Once the "get properties" is requested from the user space, the cached information can be returned immediately.
I2C access between Linux kernel and P-Unit is improved by explicitly taking semaphore once for the entire set of register accesses in the new axp288_charger_usb_update_property() function. The I2C-Bus to the XPower AXP288 is shared between the Linux kernel and SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. If not explicitly taken by the I2C-Driver, then this semaphore is automatically taken by the I2C-bus-driver for each I2C-transfer. In other words, the semaphore will be locked and released several times for entire set of register accesses.
Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
4785574f |
| 17-Dec-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
extcon: Fix extcon_get_extcon_dev() error handling
[ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]
The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's
extcon: Fix extcon_get_extcon_dev() error handling
[ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]
The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV) when the CONFIG_EXTCON option is disabled. This is very complicated for the callers to handle and a number of them had bugs that would lead to an Oops.
In real life, there are two things which prevented crashes. First, error pointers would only be returned if there was bug in the caller where they passed a NULL "extcon_name" and none of them do that. Second, only two out of the eight drivers will build when CONFIG_EXTCON is disabled.
The normal way to write this would be to return -EPROBE_DEFER directly when appropriate and return NULL when CONFIG_EXTCON is disabled. Then the error handling is simple and just looks like:
dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev)); if (IS_ERR(dev->edev)) return PTR_ERR(dev->edev);
For the two drivers which can build with CONFIG_EXTCON disabled, then extcon_get_extcon_dev() will now return NULL which is not treated as an error and the probe will continue successfully. Those two drivers are "typec_fusb302" and "max8997-battery". In the original code, the typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but now that function is a no-op. For the max8997-battery driver everything should continue working as is.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
4785574f |
| 17-Dec-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
extcon: Fix extcon_get_extcon_dev() error handling
[ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]
The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's
extcon: Fix extcon_get_extcon_dev() error handling
[ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]
The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV) when the CONFIG_EXTCON option is disabled. This is very complicated for the callers to handle and a number of them had bugs that would lead to an Oops.
In real life, there are two things which prevented crashes. First, error pointers would only be returned if there was bug in the caller where they passed a NULL "extcon_name" and none of them do that. Second, only two out of the eight drivers will build when CONFIG_EXTCON is disabled.
The normal way to write this would be to return -EPROBE_DEFER directly when appropriate and return NULL when CONFIG_EXTCON is disabled. Then the error handling is simple and just looks like:
dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev)); if (IS_ERR(dev->edev)) return PTR_ERR(dev->edev);
For the two drivers which can build with CONFIG_EXTCON disabled, then extcon_get_extcon_dev() will now return NULL which is not treated as an error and the probe will continue successfully. Those two drivers are "typec_fusb302" and "max8997-battery". In the original code, the typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but now that function is a no-op. For the max8997-battery driver everything should continue working as is.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
83efc05c |
| 08-Feb-2022 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288-charger: Set Vhold to 4.4V
[ Upstream commit 5ac121b81b4051e7fc83d5b3456a5e499d5bd147 ]
The AXP288's recommended and factory default Vhold value (minimum input voltage below w
power: supply: axp288-charger: Set Vhold to 4.4V
[ Upstream commit 5ac121b81b4051e7fc83d5b3456a5e499d5bd147 ]
The AXP288's recommended and factory default Vhold value (minimum input voltage below which the input current draw will be reduced) is 4.4V. This lines up with other charger IC's such as the TI bq2419x/bq2429x series which use 4.36V or 4.44V.
For some reason some BIOS-es initialize Vhold to 4.6V or even 4.7V which combined with the typical voltage drop over typically low wire gauge micro-USB cables leads to the input-current getting capped below 1A (with a 2A capable dedicated charger) based on Vhold.
This leads to slow charging, or even to the device slowly discharging if the device is in heavy use.
As the Linux AXP288 drivers use the builtin BC1.2 charger detection and send the input-current-limit according to the detected charger there really is no reason not to use the recommended 4.4V Vhold.
Set Vhold to 4.4V to fix the slow charging issue on various devices.
There is one exception, the special-case of the HP X2 2-in-1s which combine this BC1.2 capable PMIC with a Type-C port and a 5V/3A factory provided charger with a Type-C plug which does not do BC1.2. These have their input-current-limit hardcoded to 3A (like under Windows) and use a higher Vhold on purpose to limit the current when used with other chargers. To avoid touching Vhold on these HP X2 laptops the code setting Vhold is added to an else branch of the if checking for these models.
Note this also fixes the sofar unused VBUS_ISPOUT_VHOLD_SET_MASK define, which was wrong.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
c02aa89b |
| 11-Aug-2021 |
Tang Bin <tangbin@cmss.chinamobile.com> |
power: supply: axp288_charger: Use the defined variable to clean code
Use the defined variable "dev" to make the code cleaner.
Co-developed-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Sig
power: supply: axp288_charger: Use the defined variable to clean code
Use the defined variable "dev" to make the code cleaner.
Co-developed-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
a0f1ccd9 |
| 18-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Fix HP Pavilion x2 10 DMI matching
Commit 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") added special handling for HP Pavi
power: supply: axp288_charger: Fix HP Pavilion x2 10 DMI matching
Commit 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") added special handling for HP Pavilion x2 10 models which use the weird combination of a Type-C connector and the non Type-C aware AXP288 PMIC.
This special handling was activated by a DMI match a the product-name of "HP Pavilion x2 Detachable". Recently I've learned that there are also older "HP Pavilion x2 Detachable" models with an AXP288 PMIC + a micro-usb connector where we should not activate the special handling for the Type-C connectors.
Extend the matching to also match on the DMI board-name and match on the 2 boards (one Bay Trail based one Cherry Trail based) of which we are certain that they use the AXP288 + Type-C connector combination.
Note the DSDT code from these older (AXP288 + micro-USB) models contains some AML code (which never runs under Linux) which reads the micro-USB connector id-pin and if it is pulled to ground, which would normally mean the port is in host mode!, then it sets the input-current-limit to 3A, it seems HP is using the micro-USB port as a charging only connector and identifies their own 3A capable charger though this hack which is a major violation of the USB specs. Note HP also hardcodes a 2A limit when the id-pin is not pulled to ground, which is also in violation of the specs.
I've no intention to add support for HP's hack to support 3A charging on these older models. By making the DMI matches for the Type-C equipped models workaround more tighter, these older models will be treated just like any other AXP288 + micro-USB equipped device and the input-current limit will follow the BC 1.2 spec (using the defacto standard values there where the BC 1.2 spec defines a range).
Fixes: 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1896924 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
67c91336 |
| 18-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Fix HP Pavilion x2 10 DMI matching
[ Upstream commit a0f1ccd96c7049377d892a4299b6d5e47ec9179d ]
Commit 9c80662a74cd ("power: supply: axp288_charger: Add special handl
power: supply: axp288_charger: Fix HP Pavilion x2 10 DMI matching
[ Upstream commit a0f1ccd96c7049377d892a4299b6d5e47ec9179d ]
Commit 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") added special handling for HP Pavilion x2 10 models which use the weird combination of a Type-C connector and the non Type-C aware AXP288 PMIC.
This special handling was activated by a DMI match a the product-name of "HP Pavilion x2 Detachable". Recently I've learned that there are also older "HP Pavilion x2 Detachable" models with an AXP288 PMIC + a micro-usb connector where we should not activate the special handling for the Type-C connectors.
Extend the matching to also match on the DMI board-name and match on the 2 boards (one Bay Trail based one Cherry Trail based) of which we are certain that they use the AXP288 + Type-C connector combination.
Note the DSDT code from these older (AXP288 + micro-USB) models contains some AML code (which never runs under Linux) which reads the micro-USB connector id-pin and if it is pulled to ground, which would normally mean the port is in host mode!, then it sets the input-current-limit to 3A, it seems HP is using the micro-USB port as a charging only connector and identifies their own 3A capable charger though this hack which is a major violation of the USB specs. Note HP also hardcodes a 2A limit when the id-pin is not pulled to ground, which is also in violation of the specs.
I've no intention to add support for HP's hack to support 3A charging on these older models. By making the DMI matches for the Type-C equipped models workaround more tighter, these older models will be treated just like any other AXP288 + micro-USB equipped device and the input-current limit will follow the BC 1.2 spec (using the defacto standard values there where the BC 1.2 spec defines a range).
Fixes: 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1896924 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33 |
|
#
aa86e907 |
| 14-Apr-2020 |
Tang Bin <tangbin@cmss.chinamobile.com> |
power: supply: axp288_charger: Omit superfluous error message
In the axp288_charger_probe(), when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message h
power: supply: axp288_charger: Omit superfluous error message
In the axp288_charger_probe(), when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22 |
|
#
9c80662a |
| 23-Feb-2020 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Add special handling for HP Pavilion x2 10
Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this
power: supply: axp288_charger: Add special handling for HP Pavilion x2 10
Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this case, because on most models with an AXP288 the ACPI AC / Battery code is either completely missing or relies on custom / proprietary ACPI OpRegions which Linux does not implement.
The native drivers mostly work fine, but there are 2 problems:
1. These model uses a Type-C connector for charging which the AXP288 does not support. As long as a Type-A charger (which uses the USB data pins for charger type detection) is used everything is fine. But if a Type-C charger is used (such as the charger shipped with the device) then the charger is not recognized.
So we end up slowly discharging the device even though a charger is connected, because we are limiting the current from the charger to 500mA. To make things worse this happens with the device's official charger.
Looking at the ACPI tables HP has "solved" the problem of the AXP288 not being able to recognize Type-C chargers by simply always programming the input-current-limit at 3000mA and relying on a Vhold setting of 4.7V (normally 4.4V) to limit the current intake if the charger cannot handle this.
2. If no charger is connected when the machine boots then it boots with the vbus-path disabled. On other devices this is done when a 5V boost converter is active to avoid the PMIC trying to charge from the 5V boost output. This is done when an OTG host cable is inserted and the ID pin on the micro-B receptacle is pulled low, the ID pin has an ACPI event handler associated with it which re-enables the vbus-path when the ID pin is pulled high when the OTG cable is removed. The Type-C connector has no ID pin, there is no ID pin handler and there appears to be no 5V boost converter, so we end up not charging because the vbus-path is disabled, until we unplug the charger which automatically clears the vbus-path disable bit and then on the second plug-in of the adapter we start charging.
The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI AC / Battery code which does not rely on custom / proprietary ACPI OpRegions. So one possible solution would be to blacklist the AXP288 native power_supply drivers and add the HP Pavilion x2 10 with AXP288 DMI ids to the list of devices which should use the ACPI AC / Battery code even though they have an AXP288 PMIC. This would require changes to 4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c, drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c.
Beside needing adding the same DMI matches to 4 different files, this approach also triggers problem 2. from above, but then when suspended, during suspend the machine will not wakeup because the vbus path is disabled by the AML code when not charging, so the Vbus low-to-high IRQ is not triggered, the CPU never wakes up and the device does not charge even though the user likely things it is charging, esp. since the charge status LED is directly coupled to an adapter being plugged in and does not reflect actual charging.
This could be worked by enabling vbus-path explicitly from say the axp288_charger driver's suspend handler.
So neither situation is ideal, in both cased we need to explicitly enable the vbus-path to work around different variants of problem 2 above, this requires a quirk in the axp288_charger code.
If we go the route of using the ACPI AC / Battery drivers then we need modifications to 3 other drivers; and we need to partially disable the axp288_charger code, while at the same time keeping it around to enable vbus-path on suspend.
OTOH we can copy the hardcoding of 3A input-current-limit (we never touch Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs changes regardless, then we concentrate all special handling of this interesting device model in the axp288_charger code. That is what this commit does.
Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
1802d0be |
| 27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 655 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3 |
|
#
c3422ad5 |
| 18-Mar-2019 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
power: supply: axp288_charger: Fix unchecked return value
Currently there is no check on platform_get_irq() return value in case it fails, hence never actually reporting any errors and causing unexp
power: supply: axp288_charger: Fix unchecked return value
Currently there is no check on platform_get_irq() return value in case it fails, hence never actually reporting any errors and causing unexpected behavior when using such value as argument for function regmap_irq_get_virq().
Fix this by adding a proper check, a message reporting any errors and returning *pirq*
Addresses-Coverity-ID: 1443940 ("Improper use of negative value") Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5 |
|
#
a95761d6 |
| 26-Nov-2018 |
Olliver Schinagl <oliver@schinagl.nl> |
power: supply: axp288: use the BIT() macro
Make use of the recommended BIT() macro for bit defines.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Priit Laes <plaes@plaes.org>
power: supply: axp288: use the BIT() macro
Make use of the recommended BIT() macro for bit defines.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
f2a42595 |
| 23-May-2018 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Fix initial constant_charge_current value
We should look at val which contains the value read from the register, not ret which is always 0 on a successful read.
Signe
power: supply: axp288_charger: Fix initial constant_charge_current value
We should look at val which contains the value read from the register, not ret which is always 0 on a successful read.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Fixes: eac53b3664f59 ("power: supply: axp288_charger: Drop platform_data dependency") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
#
efb440ec |
| 18-Apr-2018 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Do not bind when the charge function is not used
Some devices with an AXP288 PMIC do not have a battery at all, or use external charger and fuelgauge ICs instead of th
power: supply: axp288_charger: Do not bind when the charge function is not used
Some devices with an AXP288 PMIC do not have a battery at all, or use external charger and fuelgauge ICs instead of the AXP288 builtin functionality.
On such devices we should not bind to the charge function to avoid exporting a non working power_supply class device.
Cc: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
#
5b76ad50 |
| 18-Apr-2018 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Support 3500 and 4000 mA input current limit
The AXP288 supports an input-current-limit of up to 4000 mA, this commit adds support for the 3500 and 4000 mA settings wh
power: supply: axp288_charger: Support 3500 and 4000 mA input current limit
The AXP288 supports an input-current-limit of up to 4000 mA, this commit adds support for the 3500 and 4000 mA settings which were missing until now.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
Revision tags: v4.16, v4.15 |
|
#
165c2357 |
| 26-Dec-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Properly stop work on probe-error / remove
Properly stop any work we may have queued on probe-errors / remove.
Rather then adding a remove driver callback for this, a
power: supply: axp288_charger: Properly stop work on probe-error / remove
Properly stop any work we may have queued on probe-errors / remove.
Rather then adding a remove driver callback for this, and goto style error handling to probe, use a devm_action for this.
The devm_action gets registered before we register any of the extcon notifiers which may queue the work, devm does cleanup in reverse order, so this ensures that the notifiers are removed before we cancel the work.
Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
#
8c0a0a29 |
| 26-Dec-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Simplify extcon cable handling
Simplify extcon cable handling using the new devm_extcon_register_notifier_all function to listen to all cables in one go.
Reviewed-by:
power: supply: axp288_charger: Simplify extcon cable handling
Simplify extcon cable handling using the new devm_extcon_register_notifier_all function to listen to all cables in one go.
Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
#
81d56dd3 |
| 26-Dec-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: axp288_charger: Use the right property for the input current limit
Use the right property for the input current limit and make it writable.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
power: supply: axp288_charger: Use the right property for the input current limit
Use the right property for the input current limit and make it writable.
Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|