10 Apr, 2016

1 commit

  • POWER_SUPPLY_STATUS_NOT_CHARGING is used for AC connected, but
    battery not charging (e.g. because battery temperature is out
    of acceptable range).

    When battery is charging near dry and BATTERY_FULL_DISCHARGED is set,
    it is wrong to set as POWER_SUPPLY_STATUS_NOT_CHARGING.
    Just use BATTERY_DISCHARGING to decide the power supply status is
    discharging or charging.

    Signed-off-by: YH Huang
    Reviewed-by: Daniel Kurtz
    Signed-off-by: Sebastian Reichel

    YH Huang
     

10 Jun, 2015

1 commit

  • Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
    device") introduced a step in probing the SBS battery, that tries to
    talk to the device before actually registering it, saying:

    this driver doesn't actually try talking to the device at probe
    time, so if it's incorrectly configured in the device tree or
    platform data (or if the battery has been removed from the system),
    then probe will succeed and every access will sit there and time
    out. The end result is a possibly laggy system that thinks it has a
    battery but can never read status, which isn't very useful.

    Which is of course reasonable. However, it is also very well possible
    for a device to boot up on wall-power and be connected to a battery
    later on. This is a scenario that the driver supported before said patch
    was applied, and even easily achieved by booting up with the battery
    attached and removing it later on. sbs-battery's 'present' sysfs file
    can be used to determine if the device is available or not.

    So with automated device detection lacking for now, in some cases it is
    possible that one wants to register a battery, even if none are attached
    at the moment. To facilitate this, add a module parameter that can be
    used to configure forced loading module loading time. If set, the battery
    will always be registered without checking the sanity of the connection.

    Signed-off-by: Frans Klaver
    Signed-off-by: Sebastian Reichel

    Frans Klaver
     

14 Mar, 2015

2 commits

  • 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 : [] lr : [] 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] [] (charger_get_property) from [] (power_supply_show_property+0x48/0x20c)
    [ 55.939286] [] (power_supply_show_property) from [] (dev_attr_show+0x1c/0x48)
    [ 55.948130] [] (dev_attr_show) from [] (sysfs_kf_seq_show+0x84/0x104)
    [ 55.956298] [] (sysfs_kf_seq_show) from [] (kernfs_seq_show+0x24/0x28)
    [ 55.964536] [] (kernfs_seq_show) from [] (seq_read+0x1b0/0x484)
    [ 55.972172] [] (seq_read) from [] (__vfs_read+0x18/0x4c)
    [ 55.979188] [] (__vfs_read) from [] (vfs_read+0x7c/0x100)
    [ 55.986304] [] (vfs_read) from [] (SyS_read+0x40/0x8c)
    [ 55.993164] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x48)
    [ 56.000626] Code: bad PC value
    [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]---

    Signed-off-by: Krzysztof Kozlowski
    Reviewed-by: Bartlomiej Zolnierkiewicz

    [for the nvec part]
    Reviewed-by: Marc Dietrich

    [for compal-laptop.c]
    Acked-by: Darren Hart

    [for the mfd part]
    Acked-by: Lee Jones

    [for the hid part]
    Acked-by: Jiri Kosina

    [for the acpi part]
    Acked-by: Rafael J. Wysocki

    Signed-off-by: Sebastian Reichel

    Krzysztof Kozlowski
     
  • 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
    Reviewed-by: Bartlomiej Zolnierkiewicz
    Acked-by: Pavel Machek

    [for the nvec part]
    Reviewed-by: Marc Dietrich

    [for drivers/platform/x86/compal-laptop.c]
    Reviewed-by: Darren Hart

    [for drivers/hid/*]
    Reviewed-by: Jiri Kosina

    Signed-off-by: Sebastian Reichel

    Krzysztof Kozlowski
     

07 Sep, 2014

2 commits

  • sbs-battery has a max design voltage but not a min design voltage field.
    The SBS spec only has one design voltage:
    http://www.sbs-forum.org/specs/sbdat110.pdf

    Currently this is being used for max design voltage. This patch uses it
    for min design voltage as well.

    Signed-off-by: Simon Que
    Reviewed-by: Simon Glass
    Reviewed-by: Todd Broch
    Signed-off-by: Javier Martinez Canillas
    Signed-off-by: Sebastian Reichel

    Simon Que
     
  • This CL supports two power_supply_property items for smart battery:
    POWER_SUPPLY_PROP_MANUFACTURER and POWER_SUPPLY_PROP_MODEL_NAME such
    that battery information 'manufacturer' and 'model_name' can be exported
    to sysfs.

    Signed-off-by: Cheng-Yi Chiang
    Reviewed-by: Olof Johansson
    Signed-off-by: Javier Martinez Canillas
    Signed-off-by: Sebastian Reichel

    Cheng-Yi Chiang
     

29 Jun, 2013

1 commit

  • By passing in the dt node of this device, we enable the logic for linking
    power_supplies together from dt. This is specified by adding a
    "power-supplies" property with a phandle to the charger for a given
    supply.

    Enable this logic now for the sbs-battery driver.

    Signed-off-by: Rhyland Klein
    Signed-off-by: Anton Vorontsov

    Rhyland Klein
     

01 Apr, 2013

2 commits


29 Nov, 2012

3 commits


21 Sep, 2012

1 commit

  • Turns out this driver doesn't actually try talking to the device at
    probe time, so if it's incorrectly configured in the device tree or
    platform data (or if the battery has been removed from the system),
    then probe will succeed and every access will sit there and time out.
    The end result is a possibly laggy system that thinks it has a battery
    but can never read status, which isn't very useful.

    Instead, just read any register (I chose status) at probe, and if that
    fails, don't register the device.

    Signed-off-by: Olof Johansson
    Acked-by: Rhyland Klein
    Signed-off-by: Anton Vorontsov

    Olof Johansson
     

20 Jun, 2012

1 commit

  • power_supply_changed() events are triggerd based on the return value
    of a get_property() call. However the property TECHNOLOGY is
    hard-coded to LION in this driver, thus always succeeds.

    So, with the battery removed, this triggers a false battery present
    uevent. This uevent triggers a new query via power_supply_uevent()
    which again starts to query all known properties and thus leads to
    an infinite loop of battery present/not-present uevents.

    This patch skips the battery presence detection for the hard-coded
    property TECHNOLOGY.

    Signed-off-by: Nikolaus Voss
    Acked-by Rhyland Klein
    Signed-off-by: Anton Vorontsov

    Nikolaus Voss
     

06 May, 2012

1 commit

  • Currently, the capacity exported by this driver refers to reg 0x0e,
    which is the absolute state of charge which according to SBS
    refers to the design capacity/ energy of the battery. It can be
    > 100 % and drops below 100 % for a fully charged battery with
    the battery aging.

    This is not what the user exspects of a remaining capacity
    indication between 0 and 100 % with 100 % referring to
    a fully charged battery. This is provided by SBS reg 0x0d,
    which is the relative state of charge referring to the
    full charge capacity.

    Signed-off-by: Nikolaus Voss
    Acked-by: Rhyland Klein
    Signed-off-by: Anton Vorontsov

    Nikolaus Voss
     

27 Mar, 2012

1 commit


06 Jan, 2012

4 commits