1. 03 Oct, 2020 2 commits
    • Iskren Chernev's avatar
      power: supply: max17040: Use devm_ to automate remove · e55a5061
      Iskren Chernev authored
      Two actions were performed during remove - power supply dereg and
      delayed work cleanup. Power supply dereg can be handled by using the
      devm_ version of the registration function. Work cleanup can be added as
      a devm_action.
      
      If probe fails after psy registration it will now be cleaned up
      properly.
      Signed-off-by: default avatarIskren Chernev <iskren.chernev@gmail.com>
      Tested-by: default avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      e55a5061
    • Sebastian Reichel's avatar
      power: supply: document current direction · 05f94eb9
      Sebastian Reichel authored
      Currently the sign for CURRENT_NOW and CURRENT_AVG is a bit
      of a mess. There are basically 3 different ways battery fuel
      gauges report the current:
      
      1. uses negative values for discharging and positive values
         for charging
      2. uses positive values for discharging and negative values
         for discharging (opposit of 1)
      3. only uses positive values
      
      As a result userspace currently cannot use the sign at all in
      a generic way. Let's solve the issue by documenting a canonical
      way for reporting the data and ensure new drivers follow this
      way. Then existing drivers can be fixed on a case-by-case basis.
      
      The 'negative value = battery discharging' has been choosen,
      since there are only very few drivers doing it the other way
      around.
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      05f94eb9
  2. 01 Oct, 2020 6 commits
  3. 30 Sep, 2020 1 commit
    • Lucas Stach's avatar
      power: supply: ucs1002: fix some health status issues · 81196e2e
      Lucas Stach authored
      Some fault events like the over-current condition will get resolved
      by the hardware, by e.g. disabling the port. As the status in the
      interrupt status register is cleared on read when the fault is resolved,
      the sysfs health property will only contain the correct health status
      for the first time it is read after such an event, even if the actual
      fault condition (like a VBUS short) still persists. To reflect this
      properly in the property we cache the last health status and only update
      the cache when a actual change happens, i.e. the ERR bit in the status
      register flips, as this one properly reflects a continued fault condition.
      
      The ALERT pin however, is not driven by the ERR status, but by the actual
      fault status, so the pin will change back to it's default state when the
      hardware has automatically resolved the fault by cutting the power. Thus
      we never get an IRQ when the actual fault condition has been resolved and
      the ERR status bit has been cleared in auto-recovery mode. To get this
      information we need to poll the interrupt status register after some time
      to see if the fault is gone and update our cache in that case.
      
      To avoid any additional locking, we handle both paths (IRQ firing and
      delayed polling) through the same single-threaded delayed work.
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      81196e2e
  4. 29 Sep, 2020 7 commits
  5. 28 Aug, 2020 14 commits
  6. 27 Aug, 2020 7 commits
  7. 26 Aug, 2020 3 commits