#
4e61f1e9 |
|
03-Mar-2024 |
Thomas Weißschuh <linux@weissschuh.net> |
power: supply: core: fix charge_behaviour formatting This property is documented to have a special format which exposes all available behaviours and the currently active one at the same time. For this special format some helpers are provided. When the charge_behaviour property was added in 1b0b6cc8030d ("power: supply: add charge_behaviour attributes"), it did not update the default logic in in power_supply_sysfs.c to use the format helpers. Thus by default only the currently active behaviour is printed. This fixes the default logic to follow the documented format. There is currently only one in-tree drivers exposing charge behaviours - thinkpad_acpi, which is not affected by the change, as it directly uses the helpers and does not use the power_supply_sysfs.c logic. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240303-power_supply-charge_behaviour_prop-v2-3-8ebb0a7c2409@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
68ade097 |
|
01-Mar-2024 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
power: supply: core: add power_supply_for_each_device() Introduce power_supply_for_each_device(), which is a wrapper for class_for_each_device() using the power_supply_class and going through all devices. This allows making the power_supply_class itself a local variable, so that drivers cannot mess with it and simplifies the code slightly. Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240301-psy-class-cleanup-v1-1-aebe8c4b6b08@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
71c2cc5c |
|
01-Mar-2024 |
Ricardo B. Marliere <ricardo@marliere.net> |
power: supply: core: make power_supply_class constant Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the power_supply_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240301-class_cleanup-power-v1-1-97e0b7bf9c94@marliere.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
12e94aee |
|
13-Sep-2023 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
power: supply: core: Don't export power_supply_notifier power_supply_notifier can be internal, since all users are going through power_supply_reg_notifier()/power_supply_unreg_notifier(). Link: https://lore.kernel.org/r/20230913133900.591637-1-sebastian.reichel@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
bbaa6ffa |
|
12-Sep-2023 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaint 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>
|
#
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.org> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
a1c7c1a4 |
|
19-Jul-2022 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: Explain maintenance charging In order for everyone to understand clearly why we want to use maintenance charging for batteries, expand the description with two diagrams and some text. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
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 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>
|
#
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 (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>
|
#
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 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>
|
#
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 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>
|
#
05f2281b |
|
14-Feb-2022 |
Ricardo Rivera-Matos <rriveram@opensource.cirrus.com> |
power: supply: Introduces bypass charging property Adds a POWER_SUPPLY_CHARGE_TYPE_BYPASS option to the POWER_SUPPLY_PROP_CHARGE_TYPE property to facilitate bypass charging operation. In bypass charging operation, the charger bypasses the charging path around the integrated converter allowing for a "smart" wall adaptor to perform the power conversion externally. This operational mode is critical for the USB PPS standard of power adaptors and is becoming a common feature in modern charging ICs such as: - BQ25980 - BQ25975 - BQ25960 - LN8000 - LN8410 Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
2220af8c |
|
01-Feb-2022 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: core: Refactor power_supply_set_input_current_limit_from_supplier() Some (USB) charger ICs have variants with USB D+ and D- pins to do their own builtin charger-type detection, like e.g. the bq24190 and bq25890 and also variants which lack this functionality, e.g. the bq24192 and bq25892. In case the charger-type; and thus the input-current-limit detection is done outside the charger IC then we need some way to communicate this to the charger IC. In the past extcon was used for this, but if the external detection does e.g. full USB PD negotiation then the extcon cable-types do not convey enough information. For these setups it was decided to model the external charging "brick" and the parameters negotiated with it as a power_supply class-device itself; and power_supply_set_input_current_limit_from_supplier() was introduced to allow drivers to get the input-current-limit this way. But in some cases psy drivers may want to know other properties, e.g. the bq25892 can do "quick-charge" negotiation by pulsing its current draw, but this should only be done if the usb_type psy-property of its supplier is set to DCP (and device-properties indicate the board allows higher voltages). Instead of adding extra helper functions for each property which a psy-driver wants to query from its supplier, refactor power_supply_set_input_current_limit_from_supplier() into a more generic power_supply_get_property_from_supplier() function. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
3367d1bd |
|
08-Jan-2022 |
Thomas Weißschuh <linux@weissschuh.net> |
power: supply: Provide stubs for charge_behaviour helpers When CONFIG_SYSFS is not enabled provide stubs for the helper functions to not break their callers. Fixes: 539b9c94ac83 ("power: supply: add helpers for charge_behaviour sysfs") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20220108153158.189489-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
25fd3303 |
|
14-Dec-2021 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply_core: Pass pointer to battery info The function to retrieve battery info (from the device tree) assumes we have a static info struct that gets populated by calling into power_supply_get_battery_info(). This is awkward since I want to support tables of static battery info by just assigning a pointer to all info based on e.g. a compatible value in the device tree. We also have a mixture of static and dynamically allocated variables here. Bite the bullet and let power_supply_get_battery_info() allocate also the memory used for the very top level struct power_supply_battery_info container. Pass pointers around and lifecycle this with the psy device just like the stuff we allocate inside it. Change all current users over. As part of the change, initializers need to be added to some previously uninitialized fields in struct power_supply_battery_info. 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>
|
#
539b9c94 |
|
23-Nov-2021 |
Thomas Weißschuh <linux@weissschuh.net> |
power: supply: add helpers for charge_behaviour sysfs These helper functions can be used by drivers to implement their own sysfs-attributes. This is useful for ACPI-drivers extending the default ACPI-battery with their own charge_behaviour attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20211123232704.25394-3-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
1b0b6cc8 |
|
23-Nov-2021 |
Thomas Weißschuh <linux@weissschuh.net> |
power: supply: add charge_behaviour attributes This a revised version of "[RFC] add standardized attributes for force_discharge and inhibit_charge" [0], incorporating discussion results. The biggest change is the switch from two boolean attributes to a single enum attribute. [0] https://lore.kernel.org/platform-driver-x86/21569a89-8303-8573-05fb-c2fec29983d1@gmail.com/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20211123232704.25394-2-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
e0dbd7b0 |
|
16-Nov-2021 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: core: Add kerneldoc to battery struct This complements the struct power_supply_battery_info with extensive kerneldoc explaining the different semantics of the fields, including an overview of the CC/CV charging concepts implicit in some of the struct members. This is done to first establish semantics before I can add more charging methods by breaking out the CC/CV parameters to its own struct. Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> 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>
|
#
77d641ba |
|
08-Nov-2021 |
Luca Ceresoli <luca@lucaceresoli.net> |
power: supply: core: add POWER_SUPPLY_HEALTH_NO_BATTERY Some chargers can keep the system powered from the mains even when no battery is present. It this case none of the currently defined health statuses applies. Add a new status to report that no battery is present. Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
4eef766b |
|
05-Aug-2021 |
Linus Walleij <linus.walleij@linaro.org> |
power: supply: core: Parse battery chemistry/technology This extends the struct power_supply_battery_info with a "technology" field makes the core DT parser optionally obtain this from the device tree. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
25faa935 |
|
09-Feb-2021 |
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> |
power: supply: core: Use true and false for bool variable Fix the following coccicheck warning: ./include/linux/power_supply.h:507:9-10: WARNING: return of 0/1 in function 'power_supply_is_watt_property' with return type bool. ./include/linux/power_supply.h:479:9-10: WARNING: return of 0/1 in function 'power_supply_is_amp_property' with return type bool. Reported-by: Abaci Robot<abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
f38a1644 |
|
08-Mar-2021 |
Ray Chi <raychi@google.com> |
power: supply: core: provide function stubs if CONFIG_POWER_SUPPLY=n Fix build error when CONFIG_POWER_SUPPLY is not enabled. The build error occurs in mips (cavium_octeon_defconfig). mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_remove': drivers/usb/dwc3/core.c:1657: undefined reference to `power_supply_put' mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_properties': drivers/usb/dwc3/core.c:1270: undefined reference to `power_supply_get_by_name' mips-linux-gnu-ld: drivers/usb/dwc3/core.o: in function `dwc3_probe': drivers/usb/dwc3/core.c:1632: undefined reference to `power_supply_put' Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current control") Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Ray Chi <raychi@google.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
c21161e4 |
|
27-Mar-2021 |
Ray Chi <raychi@google.com> |
power: supply: Fix build error when CONFIG_POWER_SUPPLY is not enabled. The build error happens when CONFIG_POWER_SUPPLY is not enabled. h8300-linux-ld: drivers/usb/dwc3/gadget.o: in function `.L59': >> gadget.c:(.text+0x655): undefined reference to `power_supply_set_property' Fixes: 99288de36020 ("usb: dwc3: add an alternate path in vbus_draw callback") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ray Chi <raychi@google.com> Link: https://lore.kernel.org/r/20210327182809.1814480-3-raychi@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5ca937fb |
|
13-Aug-2020 |
Subbaraman Narayanamurthy <subbaram@codeaurora.org> |
power: supply: add wireless type Currently, power_supply framework supports only Battery, UPS, Mains and USB power_supply_type. Add wireless power_supply_type so that the drivers which supports wireless can register a power supply class device with POWER_SUPPLY_TYPE_WIRELESS. Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
00cda13e |
|
13-Aug-2020 |
Dmitry Osipenko <digetx@gmail.com> |
power: supply: Support battery temperature device-tree properties The generic battery temperature properties are already supported by the power-supply core. Let's support parsing of the common battery temperature properties from a device-tree. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
46cbd0b0 |
|
29-Jul-2020 |
Crag Wang <crag0715@gmail.com> |
power: supply: wilco_ec: Add long life charging mode This is a long life mode set in the factory for extended warranty battery, the power charging rate is customized so that battery at work last longer. Presently switching to a different battery charging mode is through EC PID 0x0710 to configure the battery firmware, this operation will be blocked by EC with failure code 0x01 when PLL mode is already in use. Signed-off-by: Crag Wang <crag.wang@dell.com> Reviewed-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
98cc1b93 |
|
20-Jul-2020 |
Dan Murphy <dmurphy@ti.com> |
power_supply: Add additional health properties to the header Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum. HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken from JEITA specification JISC8712:2015 Acked-by: Andrew F. Davis <afd@ti.com> Tested-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
601c2a54 |
|
13-May-2020 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
power: supply: core: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED Some battery fuel gauges know when the battery needs to be recalibrated before providing usable values. This should be reported via the health property. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
feabe49e |
|
13-May-2020 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
power: supply: core: add manufacture date properties Some smart batteries store their manufacture date, which is useful to identify the battery and/or to know about the cell quality. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
bac705ab |
|
13-May-2020 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
power: supply: core: add capacity error margin property Add a property for reporting the error margin expected by fuel gauge chips. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
5a63b7ba |
|
08-May-2020 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
power: supply: add battery parameters Add parsing of new device-tree battery bindings. - trickle-charge-current-microamp - precharge-upper-limit-microvolt - re-charge-voltage-microvolt - over-voltage-threshold-microvolt Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
9ba2353b |
|
03-Apr-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
power: supply: core: allow to constify property lists Since tables pointed to by power_supply_desc->properties and ->usb_types are not expected to change after registration, mark the pointers accordingly Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
65dbad71 |
|
08-Dec-2019 |
Baolin Wang <baolin.wang@linaro.org> |
power: supply: core: Add battery internal resistance temperature table support Since the battery internal resistance can be changed with the temperature changes, thus add a resistance temperature table support to look up the accurate battery internal resistance in a certain temperature. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Baolin Wang <baolin.wang7@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
a4496d52 |
|
07-May-2019 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
power: supply: add input power and voltage limit properties For thermal management strategy you might be interested on limit the input power for a power supply. We already have current limit but basically what we probably want is to limit power. So, introduce the input_power_limit property. Although the common use case is limit the input power, in some specific cases it is the voltage that is problematic (i.e some regulators have different efficiencies at higher voltage resulting in more heat). So introduce also the input_voltage_limit property. This happens in one Chromebook and is used on the Pixel C's thermal management strategy to effectively limit the input power to 5V 3A when the screen is on. When the screen is on, the display, the CPU, and the GPU all contribute more heat to the system than while the screen is off, and we made a tradeoff to throttle the charger in order to give more of the thermal budget to those other components. So there's nothing fundamentally broken about the hardware that would cause the Pixel C to malfunction if we were charging at 9V or 12V instead of 5V when the screen is on, i.e. if userspace doesn't change this. What would happen is that you wouldn't meet Google's skin temperature targets on the system if the charger was allowed to run at 9V or 12V with the screen on. For folks hacking on Pixel Cs (which is now outside of Google's official support window for Android) and customizing their own kernel and userspace this would be acceptable, but we wanted to expose this feature in the power supply properties because the feature does exist in the Emedded Controller firmware of the Pixel C and all of Google's Chromebooks with USB-C made since 2015 in case someone running an up to date kernel wanted to limit the charging power for thermal or other reasons. This patch exposes a new property, similar to input current limit, to re-configure the maximum voltage from the external supply at runtime based on system-level knowledge or user input. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
e67d4dfc |
|
12-Jun-2019 |
Andrey Smirnov <andrew.smirnov@gmail.com> |
power: supply: Add HWMON compatibility layer Add code implementing HWMON adapter/compatibility layer to allow expositing various sensors present on power supply devices via HWMON subsystem. This is done in order to allow userspace to use single ABI/library(libsensors) to access/manipulate all of the sensors of the system. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Chris Healy <cphealy@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Sebastian Reichel <sre@kernel.org> Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
a63a5fa9 |
|
28-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 218 Based on 1 normalized pattern(s): you may use this code as per gpl version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 5 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Steve Winslow <swinslow@gmail.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528171439.762454146@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
e3e83cc6 |
|
03-May-2019 |
Andrey Smirnov <andrew.smirnov@gmail.com> |
power: supply: core: Add POWER_SUPPLY_HEALTH_OVERCURRENT constant Add POWER_SUPPLY_HEALTH_OVERCURRENT constant in order to allow singalling overcurrent condition via power supply health information. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Cc: Enric Balletbo Serra <enric.balletbo@collabora.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
813cab8f |
|
18-Apr-2019 |
Nick Crews <ncrews@chromium.org> |
power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} properties Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand the existing CHARGE_CONTROL_* properties. I am adding them in order to support a new Chrome OS device, but these properties should be general enough that they can be used on other devices. When the charge_type is "Custom", the charge controller uses the POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some other algorithm. For example, in the use case that I am supporting, this means the battery begins charging when the percentage level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and charging ceases when the percentage level goes above POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD. v5 changes: - Add the other missing CHARGE_CONTROL_* properties documentation in a separate commit - Split up adding the charge types and adding the POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into two different commits. v4 changes: - Add documentation for the new properties, and add documentation for the the previously missing charge_control_limit and charge_control_limit_max properties. Signed-off-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
ba6cc850 |
|
18-Apr-2019 |
Nick Crews <ncrews@chromium.org> |
power: supply: core: Add Standard, Adaptive, and Custom charge types Add "Standard", "Adaptive", and "Custom" modes to the charge_type property, to expand the existing "Trickle" and "Fast" modes. I am adding them in order to support a new Chrome OS device, but these properties should be general enough that they can be used on other devices. The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are more tricky: "Adaptive" means that the charge controller uses some custom algorithm to change the charge type automatically, with no configuration needed. "Custom" means that the charge controller uses the POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some other algorithm. v5 changes: - Split up adding the charge types and adding the POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into two different commits. v4 changes: - Add documentation for the new properties, and add documentation for the the previously missing charge_control_limit and charge_control_limit_max properties. Signed-off-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
04fb5310 |
|
17-Feb-2019 |
Artur Rojek <contact@artur-rojek.eu> |
power: supply: core: Add a field to support battery max voltage Add a field for "voltage_max_design_uv" to present fully charged battery voltage. Signed-off-by: Artur Rojek <contact@artur-rojek.eu> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
cef8fe6a |
|
27-Sep-2018 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
power: supply: core: add support for custom sysfs attributes Add functionality to setup device specific sysfs attributes in a race condition free manner Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
3afb50d7 |
|
05-Nov-2018 |
Baolin Wang <baolin.wang@linaro.org> |
power: supply: core: Add some helpers to use the battery OCV capacity table We have introduced some battery properties to present the OCV table temperatures and OCV capacity table values. Thus this patch add OCV temperature and OCV table for battery information, as well as providing some helper functions to use the OCV capacity table for users. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
86131d93 |
|
05-Nov-2018 |
Baolin Wang <baolin.wang@linaro.org> |
power: supply: core: Add one field to present the battery internal resistance Add one field for 'struct power_supply_battery_info' to present the battery factory internal resistance. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
3ffa6583 |
|
25-Jun-2018 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
power: remove possible deadlock when unregistering power_supply If a device gets removed right after having registered a power_supply node, we might enter in a deadlock between the remove call (that has a lock on the parent device) and the deferred register work. Allow the deferred register work to exit without taking the lock when we are in the remove state. Stack trace on a Ubuntu 16.04: [16072.109121] INFO: task kworker/u16:2:1180 blocked for more than 120 seconds. [16072.109127] Not tainted 4.13.0-41-generic #46~16.04.1-Ubuntu [16072.109129] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16072.109132] kworker/u16:2 D 0 1180 2 0x80000000 [16072.109142] Workqueue: events_power_efficient power_supply_deferred_register_work [16072.109144] Call Trace: [16072.109152] __schedule+0x3d6/0x8b0 [16072.109155] schedule+0x36/0x80 [16072.109158] schedule_preempt_disabled+0xe/0x10 [16072.109161] __mutex_lock.isra.2+0x2ab/0x4e0 [16072.109166] __mutex_lock_slowpath+0x13/0x20 [16072.109168] ? __mutex_lock_slowpath+0x13/0x20 [16072.109171] mutex_lock+0x2f/0x40 [16072.109174] power_supply_deferred_register_work+0x2b/0x50 [16072.109179] process_one_work+0x15b/0x410 [16072.109182] worker_thread+0x4b/0x460 [16072.109186] kthread+0x10c/0x140 [16072.109189] ? process_one_work+0x410/0x410 [16072.109191] ? kthread_create_on_node+0x70/0x70 [16072.109194] ret_from_fork+0x35/0x40 [16072.109199] INFO: task test:2257 blocked for more than 120 seconds. [16072.109202] Not tainted 4.13.0-41-generic #46~16.04.1-Ubuntu [16072.109204] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16072.109206] test D 0 2257 2256 0x00000004 [16072.109208] Call Trace: [16072.109211] __schedule+0x3d6/0x8b0 [16072.109215] schedule+0x36/0x80 [16072.109218] schedule_timeout+0x1f3/0x360 [16072.109221] ? check_preempt_curr+0x5a/0xa0 [16072.109224] ? ttwu_do_wakeup+0x1e/0x150 [16072.109227] wait_for_completion+0xb4/0x140 [16072.109230] ? wait_for_completion+0xb4/0x140 [16072.109233] ? wake_up_q+0x70/0x70 [16072.109236] flush_work+0x129/0x1e0 [16072.109240] ? worker_detach_from_pool+0xb0/0xb0 [16072.109243] __cancel_work_timer+0x10f/0x190 [16072.109247] ? device_del+0x264/0x310 [16072.109250] ? __wake_up+0x44/0x50 [16072.109253] cancel_delayed_work_sync+0x13/0x20 [16072.109257] power_supply_unregister+0x37/0xb0 [16072.109260] devm_power_supply_release+0x11/0x20 [16072.109263] release_nodes+0x110/0x200 [16072.109266] devres_release_group+0x7c/0xb0 [16072.109274] wacom_remove+0xc2/0x110 [wacom] [16072.109279] hid_device_remove+0x6e/0xd0 [hid] [16072.109284] device_release_driver_internal+0x158/0x210 [16072.109288] device_release_driver+0x12/0x20 [16072.109291] bus_remove_device+0xec/0x160 [16072.109293] device_del+0x1de/0x310 [16072.109298] hid_destroy_device+0x27/0x60 [hid] [16072.109303] usbhid_disconnect+0x51/0x70 [usbhid] [16072.109308] usb_unbind_interface+0x77/0x270 [16072.109311] device_release_driver_internal+0x158/0x210 [16072.109315] device_release_driver+0x12/0x20 [16072.109318] usb_driver_release_interface+0x77/0x80 [16072.109321] proc_ioctl+0x20f/0x250 [16072.109325] usbdev_do_ioctl+0x57f/0x1140 [16072.109327] ? __wake_up+0x44/0x50 [16072.109331] usbdev_ioctl+0xe/0x20 [16072.109336] do_vfs_ioctl+0xa4/0x600 [16072.109339] ? vfs_write+0x15a/0x1b0 [16072.109343] SyS_ioctl+0x79/0x90 [16072.109347] entry_SYSCALL_64_fastpath+0x24/0xab [16072.109349] RIP: 0033:0x7f20da807f47 [16072.109351] RSP: 002b:00007ffc422ae398 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [16072.109353] RAX: ffffffffffffffda RBX: 00000000010b8560 RCX: 00007f20da807f47 [16072.109355] RDX: 00007ffc422ae3a0 RSI: 00000000c0105512 RDI: 0000000000000009 [16072.109356] RBP: 0000000000000000 R08: 00007ffc422ae3e0 R09: 0000000000000010 [16072.109357] R10: 00000000000000a6 R11: 0000000000000246 R12: 0000000000000000 [16072.109359] R13: 00000000010b8560 R14: 00007ffc422ae2e0 R15: 0000000000000000 Reported-and-tested-by: Richard Hughes <rhughes@redhat.com> Tested-by: Aaron Skomra <Aaron.Skomra@wacom.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Fixes: 7f1a57fdd6cb ("power_supply: Fix possible NULL pointer dereference on early uevent") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
|
#
ece711b5 |
|
22-May-2018 |
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> |
power: supply: Add fwnode pointer to power_supply_config struct To allow users of the power supply framework to be hw description agnostic, this commit adds the ability to pass a fwnode pointer, via the power_supply_config structure, to the initialisation code of the core, instead of explicitly specifying of_ndoe. If that fwnode pointer is provided then it will automatically resolve down to of_node on platforms which support it, otherwise it will be NULL. In the future, when ACPI support is added, this can be modified to accommodate ACPI without the need to change calling code which already provides the fwnode handle in this manner. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
cf450041 |
|
23-Apr-2018 |
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> |
power: supply: Add 'usb_type' property and supporting code This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event, to represent what was connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations however don't show all supported connectable types, so this knowledge has to be exlicitly known for each driver that supports this. The 'usb_type' property is intended to fill this void and show users all possible USB types supported by a driver. The property, when read, shows all available types for the driver, and the one currently chosen is highlighted/bracketed. It is expected that the 'type' property would then just show the top-level type 'USB', and this would be static. Currently the 'usb_type' enum contains all of the USB variant types that exist for the 'type' enum at this time, and in addition has SDP and PPS types. The mirroring is intentional so as to not impact existing usage of the 'type' property. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
285995d1 |
|
07-Feb-2018 |
Ognjen Galic <smclt30p@gmail.com> |
power: add to_power_supply macro to the API This patch adds the to_power_supply macro to upcast a device to a power_supply struct. This is needed because the same piece of code using container_of is used in various other places, so we abstract away such low-level operations via a macro. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Ognjen Galic <smclt30p@gmail.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c3142dd8 |
|
15-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: Add power_supply_set_input_current_limit_from_supplier helper On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another (charger) IC. It has been decided to model this by modelling the external Type-C power brick (adapter/charger) as a power-supply class device which supplies the charger-IC, with its voltage-now and current-max representing the negotiated voltage and max current draw. This commit adds a power_supply_set_input_current_limit_from_supplier helper function which charger power-supply drivers can call to get the max-current from their supplier and have this applied through their set_property call-back to their input-current-limit. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
|
#
413de34a |
|
07-Jun-2017 |
Liam Breck <kernel@networkimprov.net> |
power: supply: core: Add power_supply_prop_precharge Battery chargers use POWER_SUPPLY_PROP_PRECHARGE_CURRENT Clarify related item POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT Signed-off-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
|
#
c08b1f45 |
|
07-Jun-2017 |
Liam Breck <kernel@networkimprov.net> |
power: supply: core: Add power_supply_battery_info and API power_supply_get_battery_info() reads battery data from devicetree. struct power_supply_battery_info provides battery data to drivers. Its fields correspond to elements in enum power_supply_property. Drivers may surface battery data in sysfs via corresponding POWER_SUPPLY_PROP_* fields. Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Signed-off-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
|
#
71399aa5 |
|
08-May-2017 |
Benson Leung <bleung@chromium.org> |
power: supply: Add Apple Brick ID power supply type Apple currently supports three very common USB chargers: https://www.apple.com/power-adapters/ These chargers implement a proprietary Apple method for advertising 1A, 2.1A, and 2.4A at 5V called "Brick ID". In addition, 3rd parties implement the same charging method in many charging accessories that work with iOS devices. Devices that have charger detection chips such as the Pericom PI3USB9281, eg. Google Chromebook Pixel 2015, are capable of detecting these chargers, so let's add a type to facilicate passing that info up to userspace. This adds a separate power supply type for Apple's proprietary "Brick ID" charging method. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
|
#
e3805385 |
|
22-Jun-2016 |
Rhyland Klein <rklein@nvidia.com> |
power_supply: fix return value of get_property power_supply_get_property() should ideally return -EAGAIN if it is called while the power_supply is being registered. There was no way previously to determine if use_cnt == 0 meant that the power_supply wasn't fully registered yet, or if it had already been unregistered. Add a new boolean to the power_supply struct to simply show if registration is completed. Lastly, modify the check in power_supply_show_property() to also ignore -EAGAIN when so it doesn't complain about not returning the property. Signed-off-by: Rhyland Klein <rklein@nvidia.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
6659b55d |
|
12-Feb-2016 |
Benson Leung <bleung@chromium.org> |
power_supply: Add types for USB Type C and PD chargers This adds power supply types for USB chargers defined in the USB Type-C Specification 1.1 and in the USB Power Delivery Specification Revision 2.0 V1.1. The following are added : POWER_SUPPLY_TYPE_USB_TYPE_C, /* Type C Port */ POWER_SUPPLY_TYPE_USB_PD, /* Power Delivery Port */ POWER_SUPPLY_TYPE_USB_PD_DRP, /* PD Dual Role Port */ Signed-off-by: Benson Leung <bleung@chromium.org> [tomeu: remove the mention to Type C from the comments] Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
fe27e1df |
|
09-Jun-2015 |
Hans de Goede <hdegoede@redhat.com> |
power: Add devm_power_supply_get_by_phandle() helper function This commit adds a resource-managed version of the power_supply_get_by_phandle() function. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
5c6e3a97 |
|
07-Jun-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: sysfs: Bring back write to writeable properties The fix for NULL pointer exception related to calling uevent for not finished probe caused to set all writeable properties as non-writeable. This was caused by checking if property is writeable before the initial increase of power supply usage counter and in the same time using wrapper over property_is_writeable(). The wrapper returns ENODEV if the usage counter is still 0. The call trace looked like: device probe: power_supply_register() use_cnt = 0; device_add() create sysfs entries power_supply_attr_is_visible() power_supply_property_is_writeable() if (use_cnt == 0) return -ENODEV; use_cnt++; Replace the usage of wrapper with direct call to property_is_writeable() from driver. This should be safe call during device probe because implementations of this callback just return 0/1 for different properties and they do not access any of the driver's internal data. Fixes: 8e59c7f23410 ("power_supply: Fix NULL pointer dereference during bq27x00_battery probe") Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
7f1a57fd |
|
19-May-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Fix possible NULL pointer dereference on early uevent Don't call the power_supply_changed() from power_supply_register() when parent is still probing because it may lead to accessing parent too early. In bq27x00_battery this caused NULL pointer exception because uevent of power_supply_changed called back the the get_property() method provided by the driver. The get_property() method accessed pointer which should be returned by power_supply_register(). Starting from bq27x00_battery_probe(): di->bat = power_supply_register() power_supply_changed() kobject_uevent() power_supply_uevent() power_supply_show_property() power_supply_get_property() bq27x00_battery_get_property() dereference of di->bat which is NULL here The dereference of di->bat (value returned by power_supply_register()) is the currently visible problem. However calling back the methods provided by driver before ending the probe may lead to accessing other driver-related data which is not yet initialized. The call to power_supply_changed() is postponed till probing ends - mutex of parent device is released. Reported-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core") Tested-By: Dr. H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
1a352462 |
|
12-Mar-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Add power_supply_put for decrementing device reference counter The power_supply_get_by_phandle() and power_supply_get_by_name() use function class_find_device() for obtaining the reference to power supply. Each use of class_find_device() increases the power supply's device reference counter. However the reference counter was not decreased by users of this API. Thus final device_unregister() call from power_supply_unregister() could not release the device and clean up its resources. This lead to memory leak if at least once power_supply_get_by_*() was called between registering and unregistering the power supply. Add and document new API power_supply_put() for decrementing the reference counter. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
297d716f |
|
12-Mar-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Change ownership from driver to core Change the ownership of power_supply structure from each driver implementing the class to the power supply core. The patch changes power_supply_register() function thus all drivers implementing power supply class are adjusted. Each driver provides the implementation of power supply. However it should not be the owner of power supply class instance because it is exposed by core to other subsystems with power_supply_get_by_name(). These other subsystems have no knowledge when the driver will unregister the power supply. This leads to several issues when driver is unbound - mostly because user of power supply accesses freed memory. Instead let the core own the instance of struct 'power_supply'. Other users of this power supply will still access valid memory because it will be freed when device reference count reaches 0. Currently this means "it will leak" but power_supply_put() call in next patches will solve it. This solves invalid memory references in following race condition scenario: Thread 1: charger manager Thread 2: power supply driver, used by charger manager THREAD 1 (charger manager) THREAD 2 (power supply driver) ========================== ============================== psy = power_supply_get_by_name() Driver unbind, .remove power_supply_unregister() Device fully removed psy->get_property() The 'get_property' call is executed in invalid context because the driver was unbound and struct 'power_supply' memory was freed. This could be observed easily with charger manager driver (here compiled with max17040 fuel gauge): $ cat /sys/devices/virtual/power_supply/cm-battery/capacity & $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind [ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 55.732584] pgd = d98d4000 [ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000 [ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM [ 55.746210] Modules linked in: [ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496 [ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000 [ 55.771647] PC is at 0x0 [ 55.774182] LR is at charger_get_property+0x2f4/0x36c [ 55.779201] pc : [<00000000>] lr : [<c034b0b4>] psr: 60000013 [ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000 [ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68 [ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000 [ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68 [ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015 [ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210) [ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000) [ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8 [ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4 [ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80 [ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001 [ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000 [ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000 [ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124 [ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550 [ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364 [ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c [ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000 [ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000 [ 55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c) [ 55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48) [ 55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104) [ 55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28) [ 55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484) [ 55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c) [ 55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100) [ 55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c) [ 55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48) [ 56.000626] Code: bad PC value [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]--- Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for compal-laptop.c] Acked-by: Darren Hart <dvhart@linux.intel.com> [for the mfd part] Acked-by: Lee Jones <lee.jones@linaro.org> [for the hid part] Acked-by: Jiri Kosina <jkosina@suse.cz> [for the acpi part] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
bc154056 |
|
12-Mar-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Add API for safe access of power supply function attrs Add simple wrappers for accessing power supply's function attributes: - get_property -> power_supply_get_property - set_property -> power_supply_set_property - property_is_writeable -> power_supply_property_is_writeable - external_power_changed -> power_supply_external_power_changed This API along with atomic usage counter adds a safe way of accessing a power supply from another driver. If power supply is unregistered after obtaining reference to it by some driver, then the API wrappers won't be executed in invalid (freed) context. Next patch changing the ownership of power supply class is still needed to fully fix race conditions in accessing freed power supply. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
2dc9215d |
|
12-Mar-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Move run-time configuration to separate structure Add new structure 'power_supply_config' for holding run-time initialization data like of_node, supplies and private driver data. The power_supply_register() function is changed so all power supply drivers need updating. When registering the power supply this new 'power_supply_config' should be used instead of directly initializing 'struct power_supply'. This allows changing the ownership of power_supply structure from driver to the power supply core in next patches. When a driver does not use of_node or supplies then it should use NULL as config. If driver uses of_node or supplies then it should allocate config on stack and initialize it with proper values. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for drivers/platform/x86/compal-laptop.c] Reviewed-by: Darren Hart <dvhart@linux.intel.com> [for drivers/hid/*] Reviewed-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
e44ea364 |
|
12-Mar-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Add driver private data Allow drivers to store private data inside power_supply structure for later usage in power supply operations. Usage of driver private data is necessary to access driver's state container object from power supply calls (like get_property()) if struct 'power_supply' is a stored there as a pointer, for example: struct some_driver_info { struct i2c_client *client; struct power_supply *power_supply; ... } In such case one cannot use container_of() and must store pointer to state container as private data. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
5d8a4219 |
|
23-Feb-2015 |
NeilBrown <neilb@suse.de> |
power_supply core: support use of devres to register/unregister a power supply. Using devm_power_supply_register allows the unregister to happen automatically on error or final put. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
a69d82b9 |
|
07-Oct-2014 |
Krzysztof Kozlowski <krzk@kernel.org> |
power_supply: Add no_thermal property to prevent recursive get_temp calls Add a 'no_thermal' property to the power supply class. If true then thermal zone won't be created for this power supply in power_supply_register(). Power supply drivers may want to set it if they support POWER_SUPPLY_PROP_TEMP and they are forwarding this get property call to other thermal zone. If they won't set it lockdep may report false positive deadlock for thermal zone's mutex because of nested calls to thermal_zone_get_temp(). First is the call to thermal_zone_get_temp() of the driver's thermal zone. Thermal core gets POWER_SUPPLY_PROP_TEMP property from this driver. The driver then calls other thermal zone thermal_zone_get_temp() and returns result. Example of such driver is charger manager. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
3c5f8853 |
|
04-Sep-2014 |
Viresh Kumar <viresh.kumar@linaro.org> |
power-supply: Forward declare structs together power_supply.h requires to forward declare few structures. One of them is done at the top of the file and other one just before it is used. Declare them together for better readability. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
a8adcc90 |
|
27-Aug-2014 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add boot and calibration attributes Usually PMIC's come with coulomb counting mechanism which can be used to implement a Fuel Gauginig solution in Software itself. One of key input to these SW Fuel Gauge solutioons is the boot up parameters like boot voltage and boot current. This patch adds the VOLTAGE_BOOT and CURRENT_BOOT power supply attributes to report bootup voltage and current. This patch also adds CALIBRATE power supply attribute which useful is for calibrating the battery/coulomb counter. Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
6bb1d272 |
|
08-Jul-2014 |
Jenny TC <jenny.tc@intel.com> |
power_supply: Add inlmt,iterm, min/max temp props Add new power supply properties for input current, charge termination current, min and max temperature POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates the input current for a charging source. POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT - Charge termination current used to detect the end of charge condition Signed-off-by: Jenny TC <jenny.tc@intel.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
#
9113e260 |
|
28-May-2014 |
Zhang Rui <rui.zhang@intel.com> |
power_supply: allow power supply devices registered w/o wakeup source Currently, all the power supply devices are registered with wakeup source, this results in that every power_supply_changed() invocation brings the system out of suspend-to-freeze state. This is overkill as some device drivers, e.g. ACPI battery driver, have the ability to check the device status and wake up the system from sleeping only when necessary. Thus introduce a new API which allows device to be registered w/o wakeup source. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
abce9770 |
|
24-Nov-2013 |
Sebastian Reichel <sre@kernel.org> |
power_supply: Add power_supply_get_by_phandle Add method to get power supply by device tree phandle. Signed-off-by: Sebastian Reichel <sre@debian.org> Reviewed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
d36240d2 |
|
19-Nov-2013 |
Pali Rohár <pali@kernel.org> |
power_supply: Add power_supply notifier This patch adds a notifier chain to the power_supply, this helps drivers in other subsystem to listen to changes in power supply subsystem. This would help to take some actions in those drivers on changing the power supply properties. One such scenario is to increase/decrease system performance based on the battery capacity/voltage. Another scenario is to adjust the h/w peak current detection voltage/current thresholds based on battery voltage/capacity. The notifier helps drivers to listen to changes in power_suppy susbystem without polling the power_supply properties Signed-off-by: Jenny TC <jenny.tc@intel.com> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Jenny TC <jenny.tc@intel.com> Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
948dcf96 |
|
02-Aug-2013 |
Zoran Markovic <zoran.markovic@linaro.org> |
power_supply: Prevent suspend until power supply events are processed This patch, originally authored by Arve Hjonnevag and Todd Poynor, prevents the system from entering suspend mode until the power supply plug, unplug, or any other change of state event is fully processed. This guarantees that the screen lights up and displays the battery charging state. The implementation uses the power supply wakeup_source object. Cc: David Woodhouse <dwmw2@infradead.org> Cc: Arve Hjonnevag <arve@android.com> Cc: Todd Poynor <toddpoynor@google.com> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
b50df95c |
|
28-Jun-2013 |
Anton Vorontsov <anton@enomsg.org> |
power_supply: Move of_node out of the #ifdef CONFIG_OF Similar to linux/device.h, move of_node struct member out of the #ifdef CONFIG_OF so that the drivers won't have to mess with #ifdefs in .c files. Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
f6e0b081 |
|
01-Apr-2013 |
Rhyland Klein <rklein@nvidia.com> |
power_supply: Populate supplied_from hierarchy from the device tree With this patch the power_supply_core will try to populate supplied_from hierarchy from the device tree. Signed-off-by: Rhyland Klein <rklein@nvidia.com> Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
5e0848c6 |
|
01-Apr-2013 |
Rhyland Klein <rklein@nvidia.com> |
power_supply: Add core support for supplied_from This patch adds support for supplies to register a list of char *'s which represent the list of supplies which supply them. This is the opposite as the supplied_to list. This change maintains support for supplied_to until all drivers which make use of it already are converted. Signed-off-by: Rhyland Klein <rklein@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
9f3b795a |
|
01-Feb-2013 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
driver-core: constify data for class_find_device() All in-kernel users of class_find_device() don't really need mutable data for match callback. In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c) this patch changes match callbacks to use const search data. The const is propagated to rtc_class_open() and power_supply_get_by_name() parameters. Note that there's a dev reference leak in suspend_test.c that's not touched in this patch. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a05be991 |
|
30-Nov-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add watchdog and safety timer expiries under PROP_HEALTH_* As most of the charger chips come with two kinds of safety features related to timing: 1. Watchdog Timer (interms of seconds/mins) 2. Safety Timer (interms of hours) This patch adds these to fault causes in POWER_SUPPLY_PROP_HEALTH_* enums so that whenever there is either watchdog timeout or safety timer timeout driver could notify the user space accurately about the fault and will also be helpful for debug. Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton@enomsg.org>
|
#
952aeeb3 |
|
09-Oct-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Register power supply for thermal cooling device This patch registers the power supply as a cooling device if the power supply has support for charge throttling. Now with this change low level drivers need not register with thermal framework as it is automatically done by power supply framework. Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
|
#
ea2ce92e |
|
09-Oct-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add support for CHARGE_CONTROL_* attributes Add support for power supply attributes CHARGE_CONTROL_LIMIT and CHARGE_CONTROL_LIMIT_MAX. These new attributes will enable the user space to implement custom charging algorithms based on platform state. Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
|
#
2815b786 |
|
29-Jul-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add new power supply properties CHARGE_CURRENT/VOLTAGE_MAX There are different types of chargers avalibale like AC, Solar, USB, etc.. Even in USB we have different types SDP/DCP/CDP/ACA and all these chargers have different o/p ratings. For example SDP supports only 500mA of charge current whereas AC charger can support upto 8A or more. Similarly batteries also come with charge current and voltage ratings and these ratings vary depending on its capacity and the technology used. This patch adds two new power supply properties CONSTANT_CHARGE_CURRENT_MAX and CONSTANT_CHARGE_CURRENT_MAX. Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
|
#
b1b56872 |
|
22-Aug-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add new power supply AUTHENTIC property It is possible that users can use non-standard chargers or use invalid batteries especially with mobile devices. This patch adds a new power supply property called 'AUTHENTIC' to indicate this to the user(user space). Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
|
#
e908c418 |
|
05-Jul-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add min/max alert properties for CAPACITY, TEMP, TEMP_AMBIENT Minimum and maximum alerts on power supply properties will help or allow the user space to "proactively" create policies like connect/disconnect charger or stop/start the user apps based on capacity or temperature parameters. These parameters can be used to avoid unnecessary polling from user space and even from kernel space if the underlying HW can support INT triggers (ex: max17042/47). This patch adds the following power supply alert type properties: CAPACITY_ALERT_MIN CAPACITY_ALERT_MAX TEMP_ALERT_MIN TEMP_ALERT_MAX TEMP_AMBIENT_ALERT_MIN TEMP_AMBIENT_ALERT_MAX Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
|
#
3824c477 |
|
06-May-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add constant charge_current and charge_voltage properties Constant Charge Current(CC) is charging parameter which limit the maximum current which can be pumped into the battery during charge cycle. Constant Charge Voltage(CV) is also charging parameter which limit the maximum voltage that battery can reach during charge cycle. It is very common practice that at low or high temperatures we do not charge the batteries upto it's fullest charge voltage to avoid battery and user safety issues. These sysfs properties will be useful for debug and to implement certain user space policies like "Charging limited due to OverTemp". Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
3be330bf |
|
09-May-2012 |
Jenny TC <jenny.tc@intel.com> |
power_supply: Register battery as a thermal zone Battery and charger contribute to Thermals in most of the embedded devices. So, it makes sense to identify them as Thermal zones in a particular platform. This patch registers a thermal zone if the power supply is reporting a temperature property. The thermal zone will be used by platform's thermal management solution. Signed-off-by: Jenny TC <jenny.tc@intel.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
0d4ed4e2 |
|
04-May-2012 |
Anton Vorontsov <cbouatmailru@gmail.com> |
power_supply: Make the core a boolean instead of a tristate On Mon, Apr 02, 2012 at 01:53:23PM +1000, Benjamin Herrenschmidt wrote: > > drivers/built-in.o: In function `.nouveau_pm_trigger': > > (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied' > > > > nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module > > build with the latter is =m > > Ok, not that trivial... > > The problem is more like POWER_SUPPLY should be a bool, not a tristate. > > If you think about it: you don't want things like nouveau to depend on a > random subsystem like that, people will never get it. In fact, > POWER_SUPPLY provides empty inline stubs when not enabled, so that's > really designed to not have depends... > > However that -cannot- work if POWER_SUPPLY is modular and the drivers > who use it are not. > > The only fixes here that make sense I can think of > that don't also involve Kconfig horrors are: > > - Ugly: in power_supply.h, use the extern variant if > > defined(CONFIG_POWER_SUPPLY) || > (defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE)) > > IE. use the stub if power supply is a module and what is being built is > built-in. Of course that's not only ugly, it somewhat sucks from a user > perspective as the subsystem now exists but can't be used by some > drivers... > > - Better: Just make the bloody thing a bool :-) The power supply > framework itself is small enough, just make it a boolean option and > avoid the problem entirely. The actual power supply sub drivers can > remain modular of course. Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
a2ebfe2f |
|
10-Apr-2012 |
Ramakrishna Pallala <ramakrishna.pallala@intel.com> |
power_supply: Add voltage_ocv property and use it for max17042 driver This adds a new sysfs file called 'voltage_ocv' which gives the Open Circuit Voltage of the battery. This property can be used for platform shutdown policies and can be useful for initial capacity estimations. Note: This patch is generated against linux-next branch. Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
|
#
313162d0 |
|
30-Jan-2012 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
device.h: audit and cleanup users in main include dir The <linux/device.h> header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
9b887227 |
|
01-Dec-2011 |
Kim, Milo <Milo.Kim@ti.com> |
power_supply: Add "unknown" in power supply type For the default value of power supply type, "unknown" is added. With default prop value, supply type property can be displayed as default - "Unknown". Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
83516651 |
|
07-Dec-2011 |
Jeremy Fitzhardinge <jeremy@goop.org> |
power_supply: allow a power supply to explicitly point to powered device If a power supply has a scope of "Device", then allow the power supply to indicate what device it actually powers. This is represented in the power supply's sysfs directory as a symlink named "powers", which points to the sysfs directory of the powered device. If the device has children, then the sub-devices are also powered by the same power supply. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Richard Hughes <richard@hughsie.com>
|
#
25a0bc2d |
|
07-Dec-2011 |
Jeremy Fitzhardinge <jeremy@goop.org> |
power_supply: add SCOPE attribute to power supplies This adds a "scope" attribute to a power_supply, which indicates how much of the system it powers. It appears in sysfs as "scope" or in the uevent file as POWER_SUPPLY_SCOPE=. There are presently three possible values: Unknown - unknown power topology System - the power supply powers the whole system Device - it powers a specific device, or tree of devices A power supply which doesn't have a "scope" attribute should be assumed to have "System" scope. In general, usermode should assume that loss of all System-scoped power supplies will power off the whole system, but any single one is sufficient to power the system. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Richard Hughes <richard@hughsie.com>
|
#
35c9d267 |
|
28-Feb-2011 |
Rhyland Klein <rklein@nvidia.com> |
power_supply: Update power_supply_is_watt_property Update the power_supply_is_watt_property function to include POWER_NOW. Signed-off-by: Rhyland Klein <rklein@nvidia.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
6501f728 |
|
07-Jan-2011 |
Vasily Khoruzhick <anarsoul@gmail.com> |
power_supply: Add new LED trigger charging-blink-solid-full Add new trigger to power_supply LEDs. It will blink when battery is charging, and stay solid when battery is charged. It's usefull to indicate battery state when there's only one LED available. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
51d07566 |
|
25-Jan-2011 |
Rhyland Klein <rklein@nvidia.com> |
bq20z75: Add support for charge properties Adding support for charge properties for gas gauge. Also ensuring that battery mode is correct now for energy as well as charge properties by setting it on the fly. I also added 2 functions to power_supply.h to help identify the units for specific properties more easily by power supplies. Signed-off-by: Rhyland Klein <rklein@nvidia.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
fe3f6d09 |
|
04-Oct-2010 |
Heikki Krogerus <ext-heikki.krogerus@nokia.com> |
power_supply: Introduce maximum current property USB only gives the maximum current allowed to draw. Signed-off-by: Heikki Krogerus <ext-heikki.krogerus@nokia.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
85efc8a1 |
|
04-Oct-2010 |
Heikki Krogerus <ext-heikki.krogerus@nokia.com> |
power_supply: Add types for USB chargers This adds power supply types for USB chargers defined in Battery Charging Specification 1.1. Signed-off-by: Heikki Krogerus <ext-heikki.krogerus@nokia.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
0011d2d4 |
|
18-May-2010 |
Daniel Mack <daniel@caiaq.de> |
power_supply: Add support for writeable properties This patch adds support for writeable power supply properties and exposes them as writeable to sysfs. A power supply implementation must implement two new function calls in order to use that feature: int set_property(struct power_supply *psy, enum power_supply_property psp, const union power_supply_propval *val); int property_is_writeable(struct power_supply *psy, enum power_supply_property psp); Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Alexey Starikovskiy <astarikovskiy@suse.de> Cc: Len Brown <len.brown@intel.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Matt Reimer <mreimer@vpop.net> Cc: Evgeniy Polyakov <zbr@ioremap.net> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
5f487cd3 |
|
18-May-2010 |
Anton Vorontsov <cbouatmailru@gmail.com> |
power_supply: Use attribute groups This fixes a race between power supply device and initial attributes creation, plus makes it possible to implement writable properties. [Daniel Mack - removed superflous return statement and dropped .mode attribute from POWER_SUPPLY_ATTR] Suggested-by: Greg KH <gregkh@suse.de> Suggested-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Tested-by: Daniel Mack <daniel@caiaq.de>
|
#
c955fe8e |
|
15-Oct-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
POWER: Add support for cycle_count Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e5f5ccb6 |
|
23-Jul-2009 |
Daniel Mack <daniel@caiaq.de> |
power_supply: get_by_name and set_charged functionality This adds a function that indicates that a battery is fully charged. It also includes functions to get a power_supply device from the class of registered devices by name reference. These can be used to find a specific battery to call power_supply_set_battery_charged() on. Some battery drivers might need this information to calibrate themselves. Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: Ian Molton <spyro@f2s.com> Cc: Anton Vorontsov <cbou@mail.ru> Cc: Matt Reimer <mreimer@vpop.net> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
ee8076ed |
|
02-Jul-2009 |
Andres Salomon <dilinger@collabora.co.uk> |
power_supply: Add a charge_type property, and use it for olpc driver This adds a new sysfs file called 'charge_type' which displays the type of charging (unknown, n/a, trickle charge, or fast charging). This allows things like battery diagnostics to determine what the battery/EC is doing without resorting to changing the 'status' sysfs output. Signed-off-by: Andres Salomon <dilinger@collabora.co.uk> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
b294a290 |
|
30-Jun-2009 |
Andres Salomon <dilinger@collabora.co.uk> |
Revert "power: remove POWER_SUPPLY_PROP_CAPACITY_LEVEL" This reverts commit 8efe444038a205e79b38b7ad03878824901849a8 and 4cbc76eadf56399cd11fb736b33c53aec9caab8c. Richard@laptop.org was apparently using CAPACITY_LEVEL for debugging battery/EC problems, and was upset that it was removed. This readds it. Conflicts: Documentation/power_supply_class.txt Signed-off-by: Andres Salomon <dilinger@collabora.co.uk> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
7faa144a |
|
27-Mar-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: battery: add power_{now,avg} properties to power_class ACPI has smart batteries, which work in units of energy and measure rate of (dis)charge as power, thus it is not appropriate to export it as a current_now. Current_now will still be exported to allow for userland applications to match. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7e386e6e |
|
30-Nov-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
power_supply: Add cold to the POWER_SUPPLY_HEALTH report values Some systems are able to report problems with batteries being under temperature. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
|
#
942ed161 |
|
26-Aug-2008 |
Matthew Garrett <mjg59@srcf.ucam.org> |
power_supply: Add function to return system-wide power state Certain drivers benefit from knowing whether the system is on ac or battery, for instance when determining which backlight registers to read. This adds a simple call to determine whether there's an online power supply other than any batteries. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
8e552c36 |
|
12-May-2008 |
Andres Salomon <dilinger@debian.org> |
power_supply: add CHARGE_COUNTER property and olpc_battery support for it This adds PROP_CHARGE_COUNTER to the power supply class (documenting it as well). The OLPC battery driver uses this for spitting out its ACR values (in uAh). We have some rounding errors (the data sheet claims 416.7, the math actually works out to 416.666667, so we're forced to choose between overflows or precision loss. I chose precision loss, and stuck w/ data sheet values), but I don't think anyone will care that much. Signed-off-by: Andres Salomon <dilinger@debian.org> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
7c2670bb |
|
22-Jan-2008 |
maximilian attems <max@stro.at> |
ACPI: battery: add sysfs serial number egrep serial /proc/acpi/battery/BAT0/info serial number: 32090 serial number can tell you from the imminent danger of beeing set on fire. Signed-off-by: maximilian attems <max@stro.at> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c7cc930f |
|
06-Jan-2008 |
Dmitry Baryshkov <dbaryshkov@gmail.com> |
power_supply: add few more values and props Add LiMn (one of the most common for small non-rechargable batteries) battery technology and voltage_min/_max properties support. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Signed-off-by: Anton Vorontsov <cbou@mail.ru>
|
#
8efe4440 |
|
12-Dec-2007 |
Andres Salomon <dilinger@queued.net> |
power: remove POWER_SUPPLY_PROP_CAPACITY_LEVEL The CAPACITY_LEVEL stuff defines various levels of charge; however, what is the difference between them? What differentiates between HIGH and NORMAL, LOW and CRITICAL, etc? As it appears that these are fairly arbitrary, we end up making such policy decisions in the kernel (or in hardware). This is the sort of decision that should be made in userspace, not in the kernel. If the hardware does not support _CAPACITY and it cannot be easily calculated, then perhaps the driver should register a custom CAPACITY_LEVEL attribute; however, userspace should not become accustomed to looking for such a thing, and we should certainly not encourage drivers to provide CAPACITY_LEVEL stubs. The following removes support for POWER_SUPPLY_PROP_CAPACITY_LEVEL. The OLPC battery driver is the only driver making use of this, so it's removed from there as well. Signed-off-by: Andres Salomon <dilinger@debian.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
|
#
4a11b59d |
|
03-May-2007 |
Anton Vorontsov <cbou@mail.ru> |
[BATTERY] Universal power supply class (was: battery class) This class is result of "external power" and "battery" classes merge, as suggested by David Woodhouse. He also implemented uevent support. Here how userspace seeing it now: # ls /sys/class/power\ supply/ ac main-battery usb # cat /sys/class/power\ supply/ac/type AC # cat /sys/class/power\ supply/usb/type USB # cat /sys/class/power\ supply/main-battery/type Battery # cat /sys/class/power\ supply/ac/online 1 # cat /sys/class/power\ supply/usb/online 0 # cat /sys/class/power\ supply/main-battery/status Charging # cat /sys/class/leds/h5400\:red-left/trigger none h5400-radio timer hwtimer ac-online usb-online main-battery-charging-or-full [main-battery-charging] main-battery-full Signed-off-by: Anton Vorontsov <cbou@mail.ru> Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|