14 Aug, 2021
1 commit
-
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
Signed-off-by: Sebastian Reichel
29 Apr, 2021
1 commit
-
Pull power supply and reset updates from Sebastian Reichel:
"battery/charger driver changes:
- core:
- provide function stubs if CONFIG_POWER_SUPPLY=n
- reduce loglevel for probe defer info
- surface:
- new battery and charger drivers for Surface
- bq27xxx:
- add bq78z100 support
- fix current_now/power_avg for newer chips
- cw2015:
- add CHARGE_NOW support
- ab8500:
- drop pdata support
- convert most DT bindings to YAML
- lots of minor fixes and cleanupsreset drivers:
- ltc2952-poweroff:
- make trigger delay configurable from DT
- minor fixes and cleanups"* tag 'for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (97 commits)
power: supply: cpcap-battery: fix invalid usage of list cursor
power: supply: bq256xx: add kerneldoc for structure members
power: supply: act8945a: correct kerneldoc
power: supply: max17040: remove unneeded double cast
power: supply: max17040: handle device_property_read_u8_array() failure
power: supply: max14577: remove unneeded variable initialization
power: supply: surface-charger: Make symbol 'surface_ac_pm_ops' static
power: supply: surface-battery: Make some symbols static
power: reset: restart-poweroff: Add missing MODULE_DEVICE_TABLE
power: reset: hisi-reboot: add missing MODULE_DEVICE_TABLE
power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove()
power: supply: generic-adc-battery: fix possible use-after-free in gab_remove()
power: supply: Add AC driver for Surface Aggregator Module
power: supply: Add battery driver for Surface Aggregator Module
power: supply: bq25980: Move props from battery node
power: supply: core: Use true and false for bool variable
power: supply: goldfish: Remove the GOLDFISH dependency
power: reset: ltc2952: make trigger delay configurable
power: supply: cpcap-charger: Simplify bool conversion
power: supply: cpcap-charger: Add usleep to cpcap charger to avoid usb plug bounce
...
05 Apr, 2021
1 commit
-
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
Signed-off-by: Jiapeng Chong
Signed-off-by: Sebastian Reichel
28 Mar, 2021
1 commit
-
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
Signed-off-by: Ray Chi
Link: https://lore.kernel.org/r/20210327182809.1814480-3-raychi@google.com
Signed-off-by: Greg Kroah-Hartman
09 Mar, 2021
1 commit
-
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
Signed-off-by: Ray Chi
Signed-off-by: Sebastian Reichel
26 Aug, 2020
2 commits
-
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
Signed-off-by: Guru Das Srinagesh
Signed-off-by: Sebastian Reichel -
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
Signed-off-by: Sebastian Reichel
31 Jul, 2020
1 commit
-
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
Reviewed-by: Mario Limonciello
Signed-off-by: Sebastian Reichel
22 Jul, 2020
1 commit
-
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:2015Acked-by: Andrew F. Davis
Tested-by: Guru Das Srinagesh
Signed-off-by: Dan Murphy
Signed-off-by: Sebastian Reichel
29 May, 2020
3 commits
-
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
-
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
-
Add a property for reporting the error margin expected
by fuel gauge chips.Signed-off-by: Sebastian Reichel
10 May, 2020
1 commit
-
Add parsing of new device-tree battery bindings.
- trickle-charge-current-microamp
- precharge-upper-limit-microvolt
- re-charge-voltage-microvolt
- over-voltage-threshold-microvoltSigned-off-by: Matti Vaittinen
Signed-off-by: Sebastian Reichel
01 May, 2020
1 commit
-
Since tables pointed to by power_supply_desc->properties and
->usb_types are not expected to change after registration, mark
the pointers accordinglySigned-off-by: Michał Mirosław
Signed-off-by: Sebastian Reichel
19 Dec, 2019
1 commit
-
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
Signed-off-by: Baolin Wang
Signed-off-by: Sebastian Reichel
16 Jul, 2019
1 commit
-
Pull power supply and reset updates from Sebastian Reichel:
"Core:
- add HWMON compat layer
- new properties:
- input power limit
- input voltage limitDrivers:
- qcom-pon: add gen2 support
- new driver for storing reboot move in NVMEM
- new driver for Wilco EC charger configuration
- simplify getting the adapter of a client"* tag 'for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply:
power: reset: nvmem-reboot-mode: add CONFIG_OF dependency
power_supply: wilco_ec: Add charging config driver
power: supply: cros: allow to set input voltage and current limit
power: supply: add input power and voltage limit properties
power: supply: fix semicolon.cocci warnings
power: reset: nvmem-reboot-mode: use NVMEM as reboot mode write interface
dt-bindings: power: reset: add document for NVMEM based reboot-mode
reset: qcom-pon: Add support for gen2 pon
dt-bindings: power: reset: qcom: Add qcom,pm8998-pon compatibility line
power: supply: Add HWMON compatibility layer
power: supply: sbs-manager: simplify getting the adapter of a client
power: supply: rt9455_charger: simplify getting the adapter of a client
power: supply: rt5033_battery: simplify getting the adapter of a client
power: supply: max17042_battery: simplify getting the adapter of a client
power: supply: max17040_battery: simplify getting the adapter of a client
power: supply: max14656_charger_detector: simplify getting the adapter of a client
power: supply: bq25890_charger: simplify getting the adapter of a client
power: supply: bq24257_charger: simplify getting the adapter of a client
power: supply: bq24190_charger: simplify getting the adapter of a client
28 Jun, 2019
1 commit
-
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
Reviewed-by: Guenter Roeck
Acked-by: Adam Thomson
Reviewed-by: Benson Leung
Signed-off-by: Sebastian Reichel
24 Jun, 2019
1 commit
-
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
Reviewed-by: Guenter Roeck
Tested-by: Chris Healy
Cc: Chris Healy
Cc: Cory Tusar
Cc: Lucas Stach
Cc: Fabio Estevam
Cc: Guenter Roeck
Cc: Sebastian Reichel
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: Sebastian Reichel
31 May, 2019
1 commit
-
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
Reviewed-by: Steve Winslow
Reviewed-by: Alexios Zavras
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190528171439.762454146@linutronix.de
Signed-off-by: Greg Kroah-Hartman
04 May, 2019
1 commit
-
Add POWER_SUPPLY_HEALTH_OVERCURRENT constant in order to allow
singalling overcurrent condition via power supply health information.Signed-off-by: Andrey Smirnov
Reviewed-by: Guenter Roeck
Cc: Enric Balletbo Serra
Cc: Chris Healy
Cc: Lucas Stach
Cc: Fabio Estevam
Cc: Guenter Roeck
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: Sebastian Reichel
02 May, 2019
2 commits
-
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
Reviewed-by: Enric Balletbo i Serra
Signed-off-by: Sebastian Reichel -
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
Reviewed-by: Enric Balletbo i Serra
Signed-off-by: Sebastian Reichel
20 Feb, 2019
1 commit
-
Add a field for "voltage_max_design_uv" to present fully charged
battery voltage.Signed-off-by: Artur Rojek
Signed-off-by: Sebastian Reichel
13 Dec, 2018
1 commit
-
Add functionality to setup device specific sysfs attributes
in a race condition free mannerSigned-off-by: Sebastian Reichel
10 Nov, 2018
2 commits
-
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
Reviewed-by: Linus Walleij
Signed-off-by: Sebastian Reichel -
Add one field for 'struct power_supply_battery_info' to present the battery
factory internal resistance.Signed-off-by: Baolin Wang
Reviewed-by: Linus Walleij
Signed-off-by: Sebastian Reichel
06 Jul, 2018
1 commit
-
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: 0000000000000000Reported-and-tested-by: Richard Hughes
Tested-by: Aaron Skomra
Signed-off-by: Benjamin Tissoires
Fixes: 7f1a57fdd6cb ("power_supply: Fix possible NULL pointer dereference on early uevent")
Signed-off-by: Sebastian Reichel
25 May, 2018
1 commit
-
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
Suggested-by: Heikki Krogerus
Reviewed-by: Sebastian Reichel
Reviewed-by: Heikki Krogerus
Signed-off-by: Greg Kroah-Hartman
25 Apr, 2018
1 commit
-
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
Reviewed-by: Heikki Krogerus
Reviewed-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2018
1 commit
-
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
Reviewed-by: Andy Shevchenko
Signed-off-by: Ognjen Galic
Reviewed-by: Sebastian Reichel
Signed-off-by: Rafael J. Wysocki
29 Aug, 2017
1 commit
-
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
Signed-off-by: Sebastian Reichel
08 Jun, 2017
3 commits
-
Battery chargers use POWER_SUPPLY_PROP_PRECHARGE_CURRENT
Clarify related item POWER_SUPPLY_PROP_CHARGE_TERM_CURRENTSigned-off-by: Liam Breck
Signed-off-by: Sebastian Reichel -
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
Signed-off-by: Liam Breck
Signed-off-by: Sebastian Reichel -
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
Signed-off-by: Sebastian Reichel
02 Jul, 2016
1 commit
-
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
Signed-off-by: Sebastian Reichel
15 Feb, 2016
1 commit
-
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
[tomeu: remove the mention to Type C from the comments]
Signed-off-by: Tomeu Vizoso
Reviewed-by: Alec Berg
Reviewed-by: Vincent Palatin
Reviewed-by: Todd Broch
Signed-off-by: Sebastian Reichel
10 Jun, 2015
2 commits
-
This commit adds a resource-managed version of the
power_supply_get_by_phandle() function.Signed-off-by: Hans de Goede
Signed-off-by: Sebastian Reichel -
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
Signed-off-by: Sebastian Reichel
21 May, 2015
1 commit
-
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 hereThe 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
Signed-off-by: Krzysztof Kozlowski
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Tested-By: Dr. H. Nikolaus Schaller
Signed-off-by: Sebastian Reichel
14 Mar, 2015
1 commit
-
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
Acked-by: Pavel Machek
Reviewed-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Sebastian Reichel
Signed-off-by: Sebastian Reichel