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 |
|
#
90f039c3 |
| 12-Sep-2023 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaint
[ Upstream commit bbaa6ffa5b6c9609d3b3c431c389b407eea5441f ]
AMD PMF driver can cause the following warning: [ 196.1595
power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaint
[ Upstream commit bbaa6ffa5b6c9609d3b3c431c389b407eea5441f ]
AMD PMF driver can cause the following warning: [ 196.159546] ------------[ cut here ]------------ [ 196.159556] Voluntary context switch within RCU read-side critical section! [ 196.159571] WARNING: CPU: 0 PID: 9 at kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x43d/0x560 [ 196.159604] Modules linked in: nvme_fabrics ccm rfcomm snd_hda_scodec_cs35l41_spi cmac algif_hash algif_skcipher af_alg bnep joydev btusb btrtl uvcvideo btintel btbcm videobuf2_vmalloc intel_rapl_msr btmtk videobuf2_memops uvc videobuf2_v4l2 intel_rapl_common binfmt_misc hid_sensor_als snd_sof_amd_vangogh hid_sensor_trigger bluetooth industrialio_triggered_buffer videodev snd_sof_amd_rembrandt hid_sensor_iio_common amdgpu ecdh_generic kfifo_buf videobuf2_common hp_wmi kvm_amd sparse_keymap snd_sof_amd_renoir wmi_bmof industrialio ecc mc nls_iso8859_1 kvm snd_sof_amd_acp irqbypass snd_sof_xtensa_dsp crct10dif_pclmul crc32_pclmul mt7921e snd_sof_pci snd_ctl_led polyval_clmulni mt7921_common polyval_generic snd_sof ghash_clmulni_intel mt792x_lib mt76_connac_lib sha512_ssse3 snd_sof_utils aesni_intel snd_hda_codec_realtek crypto_simd mt76 snd_hda_codec_generic cryptd snd_soc_core snd_hda_codec_hdmi rapl ledtrig_audio input_leds snd_compress i2c_algo_bit drm_ttm_helper mac80211 snd_pci_ps hid_multitouch ttm drm_exec [ 196.159970] drm_suballoc_helper snd_rpl_pci_acp6x amdxcp drm_buddy snd_hda_intel snd_acp_pci snd_hda_scodec_cs35l41_i2c serio_raw gpu_sched snd_hda_scodec_cs35l41 snd_acp_legacy_common snd_intel_dspcfg snd_hda_cs_dsp_ctls snd_hda_codec libarc4 drm_display_helper snd_pci_acp6x cs_dsp snd_hwdep snd_soc_cs35l41_lib video k10temp snd_pci_acp5x thunderbolt snd_hda_core drm_kms_helper cfg80211 snd_seq snd_rn_pci_acp3x snd_pcm snd_acp_config cec snd_soc_acpi snd_seq_device rc_core ccp snd_pci_acp3x snd_timer snd soundcore wmi amd_pmf platform_profile amd_pmc mac_hid serial_multi_instantiate wireless_hotkey hid_sensor_hub sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log cdc_ether usbnet r8152 mii hid_generic nvme i2c_hid_acpi i2c_hid nvme_core i2c_piix4 xhci_pci amd_sfh drm xhci_pci_renesas nvme_common hid [ 196.160382] CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.6.0-rc1 #4 [ 196.160397] Hardware name: HP HP EliteBook 845 14 inch G10 Notebook PC/8B6E, BIOS V82 Ver. 01.02.00 08/24/2023 [ 196.160405] Workqueue: events power_supply_changed_work [ 196.160426] RIP: 0010:rcu_note_context_switch+0x43d/0x560 [ 196.160440] Code: 00 48 89 be 40 08 00 00 48 89 86 48 08 00 00 48 89 10 e9 63 fe ff ff 48 c7 c7 10 e7 b0 9e c6 05 e8 d8 20 02 01 e8 13 0f f3 ff <0f> 0b e9 27 fc ff ff a9 ff ff ff 7f 0f 84 cf fc ff ff 65 48 8b 3c [ 196.160450] RSP: 0018:ffffc900001878f0 EFLAGS: 00010046 [ 196.160462] RAX: 0000000000000000 RBX: ffff88885e834040 RCX: 0000000000000000 [ 196.160470] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 196.160476] RBP: ffffc90000187910 R08: 0000000000000000 R09: 0000000000000000 [ 196.160482] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 196.160488] R13: 0000000000000000 R14: ffff888100990000 R15: ffff888100990000 [ 196.160495] FS: 0000000000000000(0000) GS:ffff88885e800000(0000) knlGS:0000000000000000 [ 196.160504] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 196.160512] CR2: 000055cb053c8246 CR3: 000000013443a000 CR4: 0000000000750ef0 [ 196.160520] PKRU: 55555554 [ 196.160526] Call Trace: [ 196.160532] <TASK> [ 196.160548] ? show_regs+0x72/0x90 [ 196.160570] ? rcu_note_context_switch+0x43d/0x560 [ 196.160580] ? __warn+0x8d/0x160 [ 196.160600] ? rcu_note_context_switch+0x43d/0x560 [ 196.160613] ? report_bug+0x1bb/0x1d0 [ 196.160637] ? handle_bug+0x46/0x90 [ 196.160658] ? exc_invalid_op+0x19/0x80 [ 196.160675] ? asm_exc_invalid_op+0x1b/0x20 [ 196.160709] ? rcu_note_context_switch+0x43d/0x560 [ 196.160727] __schedule+0xb9/0x15f0 [ 196.160746] ? srso_alias_return_thunk+0x5/0x7f [ 196.160765] ? srso_alias_return_thunk+0x5/0x7f [ 196.160778] ? acpi_ns_search_one_scope+0xbe/0x270 [ 196.160806] schedule+0x68/0x110 [ 196.160820] schedule_timeout+0x151/0x160 [ 196.160829] ? srso_alias_return_thunk+0x5/0x7f [ 196.160842] ? srso_alias_return_thunk+0x5/0x7f [ 196.160855] ? acpi_ns_lookup+0x3c5/0xa90 [ 196.160878] __down_common+0xff/0x220 [ 196.160905] __down_timeout+0x16/0x30 [ 196.160920] down_timeout+0x64/0x70 [ 196.160938] acpi_os_wait_semaphore+0x85/0x200 [ 196.160959] acpi_ut_acquire_mutex+0x9e/0x280 [ 196.160979] acpi_ex_enter_interpreter+0x2d/0xb0 [ 196.160992] acpi_ns_evaluate+0x2f0/0x5f0 [ 196.161005] acpi_evaluate_object+0x172/0x490 [ 196.161018] ? acpi_os_signal_semaphore+0x8a/0xd0 [ 196.161038] acpi_evaluate_integer+0x52/0xe0 [ 196.161055] ? kfree+0x79/0x120 [ 196.161071] ? srso_alias_return_thunk+0x5/0x7f [ 196.161089] acpi_ac_get_state.part.0+0x27/0x80 [ 196.161110] get_ac_property+0x5c/0x70 [ 196.161127] ? __pfx___power_supply_is_system_supplied+0x10/0x10 [ 196.161146] __power_supply_is_system_supplied+0x44/0xb0 [ 196.161166] class_for_each_device+0x124/0x160 [ 196.161184] ? acpi_ac_get_state.part.0+0x27/0x80 [ 196.161203] ? srso_alias_return_thunk+0x5/0x7f [ 196.161223] power_supply_is_system_supplied+0x3c/0x70 [ 196.161243] amd_pmf_get_power_source+0xe/0x20 [amd_pmf] [ 196.161276] amd_pmf_power_slider_update_event+0x49/0x90 [amd_pmf] [ 196.161310] amd_pmf_pwr_src_notify_call+0xe7/0x100 [amd_pmf] [ 196.161340] notifier_call_chain+0x5f/0xe0 [ 196.161362] atomic_notifier_call_chain+0x33/0x60 [ 196.161378] power_supply_changed_work+0x84/0x110 [ 196.161394] process_one_work+0x178/0x360 [ 196.161412] ? __pfx_worker_thread+0x10/0x10 [ 196.161424] worker_thread+0x307/0x430 [ 196.161440] ? __pfx_worker_thread+0x10/0x10 [ 196.161451] kthread+0xf4/0x130 [ 196.161467] ? __pfx_kthread+0x10/0x10 [ 196.161486] ret_from_fork+0x43/0x70 [ 196.161502] ? __pfx_kthread+0x10/0x10 [ 196.161518] ret_from_fork_asm+0x1b/0x30 [ 196.161558] </TASK> [ 196.161562] ---[ end trace 0000000000000000 ]---
Since there's no guarantee that all the callbacks can work in atomic context, switch to use blocking_notifier_call_chain to relax the constraint.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by: Allen Zhong <allen@atr.me> Fixes: 4c71ae414474 ("platform/x86/amd/pmf: Add support SPS PMF feature") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217571 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230913033233.602986-1-kai.heng.feng@canonical.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.5.2, v6.1.51, v6.5.1 |
|
#
cbcd51e8 |
| 30-Aug-2023 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
thermal: Use thermal_tripless_zone_device_register()
All of the remaining callers of thermal_zone_device_register() can use thermal_tripless_zone_device_register(), so make them do so in order to al
thermal: Use thermal_tripless_zone_device_register()
All of the remaining callers of thermal_zone_device_register() can use thermal_tripless_zone_device_register(), so make them do so in order to allow the former to be dropped.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
show more ...
|
Revision tags: 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 |
|
#
b52d51d8 |
| 13-Jun-2023 |
Chen-Yu Tsai <wenst@chromium.org> |
power: supply: core: Avoid duplicate hwmon device from thermal framework
When the power supply device being registered supports a temperature readout, the core registers a thermal zone for it. The t
power: supply: core: Avoid duplicate hwmon device from thermal framework
When the power supply device being registered supports a temperature readout, the core registers a thermal zone for it. The thermal core would register a hwmon device for that unless told otherwise.
When CONFIG_POWER_SUPPLY_HWMON is enabled, the power supply core creates a hwmon device. This results in a second entry, one which has a better name than the one registered through the thermal framework. It could potentially have readouts other than temperature.
To simplify the result, tell the thermal framework to not register a hwmon device if CONFIG_POWER_SUPPLY_HWMON is enabled. The result is one hwmon device with all the readings the device supports.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29 |
|
#
95339f40 |
| 16-May-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
power: supply: Fix logic checking if system is running from battery
The logic used for power_supply_is_system_supplied() counts all power supplies and assumes that the system is running from AC if t
power: supply: Fix logic checking if system is running from battery
The logic used for power_supply_is_system_supplied() counts all power supplies and assumes that the system is running from AC if there is either a non-battery power-supply reporting to be online or if no power-supplies exist at all.
The second rule is for desktop systems, that don't have any battery/charger devices. These systems will incorrectly report to be powered from battery once a device scope power-supply is registered (e.g. a HID device), since these power-supplies increase the counter.
Apart from HID devices, recent dGPUs provide UCSI power supplies on a desktop systems. The dGPU by default doesn't have anything plugged in so it's 'offline'. This makes power_supply_is_system_supplied() return 0 with a count of 1 meaning all drivers that use this get a wrong judgement.
To fix this case adjust the logic to also examine the scope of the power supply. If the power supply is deemed a device power supply, then don't count it.
Cc: Evan Quan <Evan.Quan@amd.com> Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.1.28 |
|
#
44c524b6 |
| 08-May-2023 |
Huacai Chen <chenhuacai@loongson.cn> |
power: supply: Fix power_supply_get_battery_info() if parent is NULL
After commit 27a2195efa8d26447c ("power: supply: core: auto-exposure of simple-battery data") we call power_supply_get_battery_in
power: supply: Fix power_supply_get_battery_info() if parent is NULL
After commit 27a2195efa8d26447c ("power: supply: core: auto-exposure of simple-battery data") we call power_supply_get_battery_info() in __power_supply_register(), but it causes test_battery crash with NULL pointer:
[ 7.524846] __power_supply_register: Expected proper parent device for 'test_battery' [ 7.524856] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000278, era == 9000000002fb279c, ra == 9000000003173434 [ 7.524862] Oops[#1]: [ 7.524866] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.3.0+ #524 [ 7.524870] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 7.524872] pc 9000000002fb279c ra 9000000003173434 tp 90000001001f0000 sp 90000001001f3c00 [ 7.524875] a0 0000000000000000 a1 0000000000000000 a2 0000000000000000 a3 9000000004553e13 [ 7.524878] a4 9000000004553e16 a5 ffffffffffffffff a6 9000000003fd0948 a7 0000000000000030 [ 7.524881] t0 9000000003173434 t1 90000000035e2c00 t2 0000000000000001 t3 00000000fffff2b0 [ 7.524883] t4 0000000000000007 t5 fffffffffffffffe t6 0000000000000000 t7 0000000000000010 [ 7.524886] t8 00000000000000b4 u0 00000001c0840c76 s9 0000000000000000 s0 0000000000000000 [ 7.524889] s1 900000000370c458 s2 0000000000000001 s3 9000000101f81000 s4 9000000101f81038 [ 7.524891] s5 9000000101f813a0 s6 900000000370c398 s7 9000000003eebd18 s8 90000000037c0070 [ 7.524894] ra: 9000000003173434 power_supply_get_battery_info+0xe4/0x710 [ 7.591224] ERA: 9000000002fb279c __dev_fwnode+0x8/0x20 [ 7.853583] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 7.859740] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 7.864073] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 7.868839] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 7.873430] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 7.878884] BADV: 0000000000000278 [ 7.882346] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 7.888056] Modules linked in: [ 7.891088] Process swapper/0 (pid: 1, threadinfo=0000000091357ee8, task=00000000313d98cb) [ 7.899307] Stack : 00000000000000b4 900000000279aca8 0000000000000001 0000000000000000 [ 7.907274] 0000000000000049 0000000000000408 9000000100008c00 90000000035b6370 [ 7.915238] 900000000b801080 90000000029a440c 9000000003eb4680 9000000003eb4680 [ 7.923202] 9000000101f81038 900000000357cdcc 0000000000000001 900000000370c458 [ 7.931166] 9000000101f81000 90000000037c0070 9000000003eebd18 900000000370c398 [ 7.939131] 90000000045f4530 9000000101f81038 0000000000000000 0000000000000001 [ 7.947095] 900000000370c458 9000000101f81000 0000000000000000 9000000003173e64 [ 7.955059] 0000000000000026 9000000003de3880 9000000100562040 900000000357e07c [ 7.963023] 000000000000026f 0000000000000001 90000001001f3d68 fffffffffffffff5 [ 7.970987] 90000000036d2ca8 90000000027429d8 90000000037c0030 0000000000000001 [ 7.978951] ... [ 7.981379] Call Trace: [ 7.981382] [<9000000002fb279c>] __dev_fwnode+0x8/0x20 [ 7.988916] [<9000000003173434>] power_supply_get_battery_info+0xe4/0x710 [ 7.995666] [<9000000003173e64>] __power_supply_register+0x404/0x580 [ 8.001984] [<900000000379d368>] test_power_init+0x6c/0x124 [ 8.007527] [<90000000026e08f8>] do_one_initcall+0x58/0x1ec [ 8.013066] [<9000000003761614>] kernel_init_freeable+0x290/0x310 [ 8.019127] [<90000000035b40e8>] kernel_init+0x24/0x11c [ 8.024324] [<90000000026e2048>] ret_from_kernel_thread+0xc/0xa4 [ 8.030295] [ 8.031769] Code: 4c000020 0015002c 03400000 <28c9e08c> 40000d80 02c06184 4c000020 28ca0084 4c000020
Root cause: psy->dev.parent is NULL in power_supply_get_battery_info(), so change the else branch to be 'else if (psy->dev.parent)' and return -ENOENT if psy->dev.parent is NULL.
Fixes: 27a2195efa8d26447c ("power: supply: core: auto-exposure of simple-battery data") Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16 |
|
#
ec4f7b7f |
| 07-Mar-2023 |
Nick Alcock <nick.alcock@oracle.com> |
power: supply: remove MODULE_LICENSE in non-modules
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to
power: supply: remove MODULE_LICENSE in non-modules
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as modules.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
show more ...
|
#
27a2195e |
| 17-Mar-2023 |
Sebastian Reichel <sre@kernel.org> |
power: supply: core: auto-exposure of simple-battery data
Automatically expose data from the simple-battery firmware node for all battery drivers.
Reviewed-by: Linus Walleij <linus.walleij@linaro.o
power: supply: core: auto-exposure of simple-battery data
Automatically expose data from the simple-battery firmware node for all battery drivers.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
show more ...
|
#
1aaba11d |
| 13-Mar-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
driver core: class: remove module * from class_create()
The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did s
driver core: class: remove module * from class_create()
The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time.
Cc: "Rafael J. Wysocki" <rafael@kernel.org> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.15 |
|
#
3d4e1bad |
| 01-Mar-2023 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
thermal/core: Use the thermal zone 'devdata' accessor in remaining drivers
The thermal zone device structure is exposed to the different drivers and obviously they access the internals while that sh
thermal/core: Use the thermal zone 'devdata' accessor in remaining drivers
The thermal zone device structure is exposed to the different drivers and obviously they access the internals while that should be restricted to the core thermal code.
In order to self-encapsulate the thermal core code, we need to prevent the drivers accessing directly the thermal zone structure and provide accessor functions to deal with.
Use the devdata accessor introduced in the previous patch.
No functional changes intended.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> #mlxsw Acked-by: Gregory Greenman <gregory.greenman@intel.com> #iwlwifi Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> #power_supply Acked-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> #ahci Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.1.14 |
|
#
bfaecf46 |
| 23-Feb-2023 |
qinyu <qinyu32@huawei.com> |
power: supply: fix null pointer check order in __power_supply_register
There is an null pointer check order issue here: if we have to check !desc and !desc->name anyway, check it before dereferencin
power: supply: fix null pointer check order in __power_supply_register
There is an null pointer check order issue here: if we have to check !desc and !desc->name anyway, check it before dereferencing it in pr_warn().
Signed-off-by: qinyu <qinyu32@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8 |
|
#
c85c1916 |
| 21-Jan-2023 |
Andreas Kemnade <andreas@kemnade.info> |
power: supply: remove faulty cooling logic
The rn5t618 power driver fails to register a cooling device because POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX is missing but availability is not checked b
power: supply: remove faulty cooling logic
The rn5t618 power driver fails to register a cooling device because POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX is missing but availability is not checked before registering cooling device. After improved error checking in the thermal code, the registration of the power supply fails entirely.
Checking for availability of _MAX before registering cooling device fixes the rn5t618 problem. But the whole logic feels questionable.
First, the logic is inverted here: the code tells: max_current = max_cooling but 0 = max_cooling, so there needs to be some inversion in the code which cannot be found. Comparing with other cooling devices, it can be found that value for fan speed is not inverted, value for cpufreq cooling is inverted (similar situation as here lowest frequency = max cooling)
Second, analyzing usage of _MAX: it is seems that maximum capabilities of charging controller are specified and not of the battery. Probably there is not too much mismatch in the drivers actually implementing that. So nothing has exploded yet. So there is no easy and safe way to specifify a max cooling value now.
Conclusion for now (as a regression fix) just remove the cooling device registration and do it properly later on.
Fixes: e49a1e1ee078 ("thermal/core: fix error code in __thermal_cooling_device_register()") Fixes: 952aeeb3ee28 ("power_supply: Register power supply for thermal cooling device") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: 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 |
|
#
104bb8a6 |
| 05-Dec-2022 |
ruanjinjie <ruanjinjie@huawei.com> |
power: supply: fix null pointer dereferencing in power_supply_get_battery_info
when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will
power: supply: fix null pointer dereferencing in power_supply_get_battery_info
when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference.
So return ENOMEM if kasprintf() return NULL pointer.
Fixes: 3afb50d7125b ("power: supply: core: Add some helpers to use the battery OCV capacity table") Signed-off-by: ruanjinjie <ruanjinjie@huawei.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.0.11, v6.0.10, v5.15.80 |
|
#
5b79480c |
| 17-Nov-2022 |
Zeng Heng <zengheng4@huawei.com> |
power: supply: fix residue sysfs file in error handle route of __power_supply_register()
If device_add() succeeds, we should call device_del() when want to get rid of it, so move it into proper jump
power: supply: fix residue sysfs file in error handle route of __power_supply_register()
If device_add() succeeds, we should call device_del() when want to get rid of it, so move it into proper jump symbol.
Otherwise, when __power_supply_register() returns fail and goto wakeup_init_failed to exit, there is still residue device file in sysfs. When attempt to probe device again, sysfs would complain as below:
sysfs: cannot create duplicate filename '/devices/platform/i2c/i2c-0/0-001c/power_supply/adp5061' Call Trace: dump_stack_lvl+0x68/0x85 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x1b1/0x1d0 kobject_add_internal+0x143/0x390 kobject_add+0x108/0x170
Fixes: 80c6463e2fa3 ("power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77 |
|
#
98c148cd |
| 31-Oct-2022 |
Lukas Bulwahn <lukas.bulwahn@gmail.com> |
power: supply: core: repair kernel-doc for power_supply_vbat2ri()
The function power_supply_vbat2ri() does not have a parameter called table, despite it being mentioned in the kernel-doc comment. Th
power: supply: core: repair kernel-doc for power_supply_vbat2ri()
The function power_supply_vbat2ri() does not have a parameter called table, despite it being mentioned in the kernel-doc comment. The table is actually obtained from the info parameter, the battery information container. Hence, ./scripts/kernel-doc -none drivers/power/supply/power_supply_core.c warns about this excess function parameter.
Adjust the kernel-doc comment for power_supply_vbat2ri() for make W=1 happiness.
Fixes: e9e7d165b4b0 ("power: supply: Support VBAT-to-Ri lookup tables") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: 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 |
|
#
966f6551 |
| 04-Jul-2022 |
Schspa Shi <schspa@gmail.com> |
power: supply: Fix typo in power_supply_check_supplies
It seems to be a typo, there is no actual BUG, but it's better to fix it to avoid any possible BUG after we change the type of supplied_from.
power: supply: Fix typo in power_supply_check_supplies
It seems to be a typo, there is no actual BUG, but it's better to fix it to avoid any possible BUG after we change the type of supplied_from.
Signed-off-by: Schspa Shi <schspa@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: 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 |
|
#
093d27bb |
| 14-May-2022 |
Dorian Rudolph <mail@dorianrudolph.com> |
power: supply: core: Fix boundary conditions in interpolation
The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple handle boundary conditions incorrectly. The change was int
power: supply: core: Fix boundary conditions in interpolation
The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple handle boundary conditions incorrectly. The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283 ("power: supply: core: Use library interpolation"). There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap have the wrong order compared to temp2resist. As a consequence, ocv2cap sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read. Second, the logic of temp2resist is also not correct. Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}. For temp=5, we expect a resistance of 70% by interpolation. However, temp2resist sets high=low=2 and returns 60.
Cc: stable@vger.kernel.org Signed-off-by: Dorian Rudolph <mail@dorianrudolph.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: a4585ba2050f ("power: supply: core: Use library interpolation") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
e56a4be2 |
| 24-Apr-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: core: Initialize struct to zero
As we rely on pointers in the battery info to be zero-initialized such as in the helper function power_supply_supports_vbat2ri() we certainly need to a
power: supply: core: Initialize struct to zero
As we rely on pointers in the battery info to be zero-initialized such as in the helper function power_supply_supports_vbat2ri() we certainly need to allocate the struct power_supply_battery_info with kzalloc() as well. Else this happens:
Unable to handle kernel paging request at virtual address 00280000 (...) PC is at power_supply_vbat2ri+0x50/0x12c LR is at ab8500_fg_battery_resistance+0x34/0x108
Fixes: e9e7d165b4b0 ("power: supply: Support VBAT-to-Ri lookup tables") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33 |
|
#
581045ed |
| 28-Mar-2022 |
Yassine Oudjana <y.oudjana@protonmail.com> |
power: supply: Reset err after not finding static battery
Otherwise power_supply_get_battery_info always returns -ENODEV on devices that do not have a static battery, even when a simple battery is f
power: supply: Reset err after not finding static battery
Otherwise power_supply_get_battery_info always returns -ENODEV on devices that do not have a static battery, even when a simple battery is found.
Fixes: c8aee3f41cb8 ("power: supply: Static data for Samsung batteries") Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26 |
|
#
c8aee3f4 |
| 25-Feb-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: Static data for Samsung batteries
If we detect a Samsung SDI battery, we return a static struct power_supply_battery_info and avoid looking further.
Signed-off-by: Linus Walleij <lin
power: supply: Static data for Samsung batteries
If we detect a Samsung SDI battery, we return a static struct power_supply_battery_info and avoid looking further.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
e9e7d165 |
| 25-Feb-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: Support VBAT-to-Ri lookup tables
In Samsung devices, the method used to compensate for temperature, age, load etc is by way of VBAT to Ri tables, which correlates the battery voltage
power: supply: Support VBAT-to-Ri lookup tables
In Samsung devices, the method used to compensate for temperature, age, load etc is by way of VBAT to Ri tables, which correlates the battery voltage under load (VBAT) to an internal resistance (Ri).
Using this Ri and a measurement of the current out of the battery (IBAT) the open circuit voltage (OCV) can be calculated as:
OCV = VBAT - (Ri * IBAT)
The details are described in comments to struct power_supply_battery_info in the commit.
Since not all batteries supply this VBAT-to-Ri data, the fallback method to use the temperature-to-Ri lookup table can also be used as a fallback.
Add two helper functions to check if we have the tables needed for using power_supply_vbat2ri() or power_supply_temp2resist_simple() respectively, so capacity estimation code can choose which one to employ.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
1f918e0f |
| 25-Feb-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: ab8500: Standardize BTI resistance
The Battery Type Indicator (BTI) resistor is a resistor mounted between a special terminal on the battery and ground. By sending a fixed current (su
power: supply: ab8500: Standardize BTI resistance
The Battery Type Indicator (BTI) resistor is a resistor mounted between a special terminal on the battery and ground. By sending a fixed current (such as 7mA) through this resistor and measuring the voltage over it, the resistance can be determined, and this verifies the battery type.
Typical side view of the battery:
o o o GND BTI +3.8V
Typical example of the electrical layout:
+3.8 V BTI | | | + | _______ [ ] 7kOhm ___ | | | | | GND GND
By verifying this resistance before attempting to charge the battery we add an additional level of security.
In some systems this is used for plug-and-play of batteries with different capacity. In other cases, this is merely used to verify that the right type of battery is connected, if several batteries have the same physical shape and can be plugged into the same slot. Sometimes this is just a surplus security mechanism.
Nokia and Samsung among many other vendors are known to use these BTI resistors.
Add the BTI properties to struct power_supply_battery_info and switch the AB8500 charger code over to using it.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
0e8b903b |
| 25-Feb-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: ab8500: Standardize alert mode charging
The AB8500 code is using a special current and voltage setting when the battery is in "alert mode", i.e. when it is starting to go outside norm
power: supply: ab8500: Standardize alert mode charging
The AB8500 code is using a special current and voltage setting when the battery is in "alert mode", i.e. when it is starting to go outside normal operating conditions so it is too cold or too hot. This makes sense as a way for the charging algorithm to deal with hostile environments.
Add the needed members to the struct power_supply_battery_info, and switch the AB8500 charging code over to using this.
Reviewed-by: Matti Vaittineen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
d72ce7d3 |
| 25-Feb-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: ab8500: Standardize maintenance charging
Maintenance charging is the phase of keeping up the charge after the battery has charged fully using CC/CV charging.
This can be done in many
power: supply: ab8500: Standardize maintenance charging
Maintenance charging is the phase of keeping up the charge after the battery has charged fully using CC/CV charging.
This can be done in many successive phases and is usually done with a slightly lower constant voltage than CV, and a slightly lower allowed current.
Add an array of maintenance charging points each with a current, voltage and safety timer, and add helper functions to use these. Migrate the AB8500 code over.
This is used in several Samsung products using the AB8500 and these batteries and their complete parameters will be added later as full examples, but the default battery in the AB8500 code serves as a reasonable example so far.
Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
Revision tags: v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20 |
|
#
1c97db17 |
| 02-Feb-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
power: supply: core: Use device_property_string_array_count()
Use device_property_string_array_count() to get number of strings in a string array property.
Signed-off-by: Andy Shevchenko <andriy.sh
power: supply: core: Use device_property_string_array_count()
Use device_property_string_array_count() to get number of strings in a string array property.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|
#
c76787b0 |
| 06-Feb-2022 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: core: Add support for generic fwnodes to power_supply_get_battery_info()
Add support to power_supply_get_battery_info() to read the properties from other fwnode types such as swnodes
power: supply: core: Add support for generic fwnodes to power_supply_get_battery_info()
Add support to power_supply_get_battery_info() to read the properties from other fwnode types such as swnodes added by platform code on x86 devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
show more ...
|