summaryrefslogtreecommitdiff
path: root/include/linux/power_supply.h
AgeCommit message (Collapse)AuthorFilesLines
2019-05-03power: supply: core: Add POWER_SUPPLY_HEALTH_OVERCURRENT constantAndrey Smirnov1-0/+1
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>
2019-05-02power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} ↵Nick Crews1-0/+2
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>
2019-05-02power: supply: core: Add Standard, Adaptive, and Custom charge typesNick Crews1-2/+6
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>
2019-02-20power: supply: core: Add a field to support battery max voltageArtur Rojek1-0/+1
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>
2018-12-13power: supply: core: add support for custom sysfs attributesSebastian Reichel1-0/+3
Add functionality to setup device specific sysfs attributes in a race condition free manner Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-11-09power: supply: core: Add some helpers to use the battery OCV capacity tableBaolin Wang1-0/+19
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>
2018-11-09power: supply: core: Add one field to present the battery internal resistanceBaolin Wang1-0/+1
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>
2018-07-06power: remove possible deadlock when unregistering power_supplyBenjamin Tissoires1-0/+1
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>
2018-05-24power: supply: Add fwnode pointer to power_supply_config structAdam Thomson1-0/+2
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>
2018-04-25power: supply: Add 'usb_type' property and supporting codeAdam Thomson1-0/+16
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>
2018-02-21power: add to_power_supply macro to the APIOgnjen Galic1-0/+2
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>
2017-08-29power: supply: Add power_supply_set_input_current_limit_from_supplier helperHans de Goede1-0/+2
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>
2017-06-08power: supply: core: Add power_supply_prop_prechargeLiam Breck1-0/+3
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>
2017-06-08power: supply: core: Add power_supply_battery_info and APILiam Breck1-0/+22
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>
2017-06-08power: supply: Add Apple Brick ID power supply typeBenson Leung1-7/+8
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>
2016-07-01power_supply: fix return value of get_propertyRhyland Klein1-0/+1
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>
2016-02-15power_supply: Add types for USB Type C and PD chargersBenson Leung1-0/+3
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>
2015-06-10power: Add devm_power_supply_get_by_phandle() helper functionHans de Goede1-0/+5
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>
2015-06-10power_supply: sysfs: Bring back write to writeable propertiesKrzysztof Kozlowski1-0/+5
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>
2015-05-21power_supply: Fix possible NULL pointer dereference on early ueventKrzysztof Kozlowski1-0/+1
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>
2015-03-13power_supply: Add power_supply_put for decrementing device reference counterKrzysztof Kozlowski1-0/+1
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>
2015-03-13power_supply: Change ownership from driver to coreKrzysztof Kozlowski1-19/+30
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>
2015-03-13power_supply: Add API for safe access of power supply function attrsKrzysztof Kozlowski1-0/+16
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>
2015-03-13power_supply: Move run-time configuration to separate structureKrzysztof Kozlowski1-4/+18
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>
2015-03-13power_supply: Add driver private dataKrzysztof Kozlowski1-0/+4
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>
2015-02-26power_supply core: support use of devres to register/unregister a power supply.NeilBrown1-0/+4
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>
2014-10-28power_supply: Add no_thermal property to prevent recursive get_temp callsKrzysztof Kozlowski1-0/+6
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>
2014-09-16power-supply: Forward declare structs togetherViresh Kumar1-2/+1
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>
2014-09-06power_supply: Add boot and calibration attributesRamakrishna Pallala1-0/+5
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>
2014-07-18power_supply: Add inlmt,iterm, min/max temp propsJenny TC1-0/+4
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>
2014-05-30power_supply: allow power supply devices registered w/o wakeup sourceZhang Rui1-0/+2
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>
2013-12-23power_supply: Add power_supply_get_by_phandleSebastian Reichel1-0/+8
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>
2013-12-01power_supply: Add power_supply notifierPali Rohár1-0/+8
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>
2013-08-27power_supply: Prevent suspend until power supply events are processedZoran Markovic1-0/+3
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>
2013-06-28power_supply: Move of_node out of the #ifdef CONFIG_OFAnton Vorontsov1-2/+2
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>
2013-04-16power_supply: Populate supplied_from hierarchy from the device treeRhyland Klein1-0/+3
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>
2013-04-16power_supply: Add core support for supplied_fromRhyland Klein1-0/+3
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>
2013-02-21Merge tag 'driver-core-3.9-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core patches from Greg Kroah-Hartman: "Here is the big driver core merge for 3.9-rc1 There are two major series here, both of which touch lots of drivers all over the kernel, and will cause you some merge conflicts: - add a new function called devm_ioremap_resource() to properly be able to check return values. - remove CONFIG_EXPERIMENTAL Other than those patches, there's not much here, some minor fixes and updates" Fix up trivial conflicts * tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits) base: memory: fix soft/hard_offline_page permissions drivercore: Fix ordering between deferred_probe and exiting initcalls backlight: fix class_find_device() arguments TTY: mark tty_get_device call with the proper const values driver-core: constify data for class_find_device() firmware: Ignore abort check when no user-helper is used firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER firmware: Make user-mode helper optional firmware: Refactoring for splitting user-mode helper code Driver core: treat unregistered bus_types as having no devices watchdog: Convert to devm_ioremap_resource() thermal: Convert to devm_ioremap_resource() spi: Convert to devm_ioremap_resource() power: Convert to devm_ioremap_resource() mtd: Convert to devm_ioremap_resource() mmc: Convert to devm_ioremap_resource() mfd: Convert to devm_ioremap_resource() media: Convert to devm_ioremap_resource() iommu: Convert to devm_ioremap_resource() drm: Convert to devm_ioremap_resource() ...
2013-02-06driver-core: constify data for class_find_device()Michał Mirosław1-1/+1
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>
2013-01-05power_supply: Add watchdog and safety timer expiries under PROP_HEALTH_*Ramakrishna Pallala1-0/+2
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>
2012-11-17power_supply: Register power supply for thermal cooling deviceRamakrishna Pallala1-0/+1
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>
2012-11-17power_supply: Add support for CHARGE_CONTROL_* attributesRamakrishna Pallala1-0/+2
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>
2012-08-22power_supply: Add new power supply properties CHARGE_CURRENT/VOLTAGE_MAXRamakrishna Pallala1-0/+4
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>
2012-08-22power_supply: Add new power supply AUTHENTIC propertyRamakrishna Pallala1-0/+1
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>
2012-07-13power_supply: Add min/max alert properties for CAPACITY, TEMP, TEMP_AMBIENTRamakrishna Pallala1-0/+6
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>
2012-06-19power_supply: Add constant charge_current and charge_voltage propertiesRamakrishna Pallala1-0/+4
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>
2012-06-17power_supply: Register battery as a thermal zoneJenny TC1-0/+3
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>
2012-05-04power_supply: Make the core a boolean instead of a tristateAnton Vorontsov1-1/+1
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>
2012-05-04power_supply: Add voltage_ocv property and use it for max17042 driverRamakrishna Pallala1-0/+2
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>
2012-03-16device.h: audit and cleanup users in main include dirPaul Gortmaker1-1/+2
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 23:31:26 +0000