1. 19 6月, 2015 1 次提交
  2. 15 6月, 2015 1 次提交
  3. 13 6月, 2015 3 次提交
  4. 10 6月, 2015 4 次提交
    • F
      sbs-battery: add option to always register battery · f4ed950a
      Frans Klaver 提交于
      Commit a22b41a3 ("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: NFrans Klaver <frans.klaver@xsens.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      f4ed950a
    • H
      power: Add devm_power_supply_get_by_phandle() helper function · fe27e1df
      Hans de Goede 提交于
      This commit adds a resource-managed version of the
      power_supply_get_by_phandle() function.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      fe27e1df
    • K
      power_supply: max17042: Add OF support for setting thresholds · a6e6b63e
      Krzysztof Kozlowski 提交于
      The commit edd4ab05 ("power: max17042_battery: add HEALTH and TEMP_*
      properties support") added support for setting voltage and temperature
      thresholds with platform data. For DeviceTree default of 0 was always
      used.
      
      This caused reporting battery health always as over voltage or
      over heated.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: edd4ab05 ("power: max17042_battery: add HEALTH and TEMP_* properties support")
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      a6e6b63e
    • K
      power_supply: sysfs: Bring back write to writeable properties · 5c6e3a97
      Krzysztof Kozlowski 提交于
      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: 8e59c7f2 ("power_supply: Fix NULL pointer dereference during bq27x00_battery probe")
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      5c6e3a97
  5. 03 6月, 2015 3 次提交
    • A
      power_supply: rt9455_charger: Check if CONFIG_USB_PHY is enabled · fb323ecc
      Anda-Maria Nicolae 提交于
      If CONFIG_USB_PHY is not enabled, struct notifier_block is not defined and
      compilation fails. Therefore, the functions that process USB event
      notifications are defined only if CONFIG_USB_PHY is enabled.
      There is no need to define these functions if CONFIG_USB_PHY is not
      enabled, since no USB notifications are received in this case.
      Also, since rt9455_set_boost_voltage_before_boost_mode() function is
      called only if USB_EVENT_ID notification is received, this function should
      also be defined only if CONFIG_USB_PHY is enabled.
      Signed-off-by: NAnda-Maria Nicolae <anda-maria.nicolae@intel.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      fb323ecc
    • H
      power: reset: gpio-restart: increase priority slightly · bcd56fe1
      Heiko Stübner 提交于
      gpio-restart uses a priority of 128 and currently most soc-level restart
      mechanisms use the same - with some exceptions even using 192.
      But while the soc-level restarts are provided by the soc itself,
      gpio-restarts will most of the time be board-specfic and be used
      when some special board condition makes the soc-level restart
      only a second choice.
      
      The problem at hand manifested itself on the rk3288-veyron devices.
      While the soc-level restart can sucessfully restart all other rockchip
      boards I have, the veyron devices use an external restart mechanism that
      seems to not only reset the soc but also some external needed components.
      
      With both restart handlers having priority 128 in my tests the soc-specific
      variant took precedent in all cases. While it could restart the soc
      sucessfully in all cases, firmware then got an issue when talking to an
      external component, resulting in the device being put into recovery mode.
      
      So, give the board-specific restart handler a slight push and move it
      to priority 129 to make it more important than the generic soc-specific
      restart-handler.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      bcd56fe1
    • L
      power_supply: bq25890: make chip_id int · 23fa43a2
      Laurentiu Palcu 提交于
      Smatch static checker correctly detected an impossible condition because
      chip_id was declared as u8, instead of int:
      
      drivers/power/bq25890_charger.c:843 bq25890_probe()
      warn: impossible condition '(bq->chip_id < 0) => (0-255 < 0)'
      
      Also, while at it, fix the return value too.
      Signed-off-by: NLaurentiu Palcu <laurentiu.palcu@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      23fa43a2
  6. 30 5月, 2015 1 次提交
  7. 29 5月, 2015 2 次提交
  8. 24 5月, 2015 12 次提交
  9. 21 5月, 2015 2 次提交
    • K
      power_supply: Fix possible NULL pointer dereference on early uevent · 7f1a57fd
      Krzysztof Kozlowski 提交于
      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: NH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 297d716f ("power_supply: Change ownership from driver to core")
      Tested-By: NDr. H. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      7f1a57fd
    • K
      power_supply: Fix NULL pointer dereference during bq27x00_battery probe · 8e59c7f2
      Krzysztof Kozlowski 提交于
      Power supply is often registered during probe of a driver. The
      power_supply_register() returns pointer to newly allocated structure as
      return value. However before returning the power_supply_register()
      calls back the get_property() method provided by the driver through
      uevent.
      
      In that time the driver probe is still in progress and driver did not
      assigned pointer to power supply to its local variables. This leads to
      NULL pointer dereference from get_property() function.
      Starting from bq27x00_battery_probe():
        di->bat = power_supply_register()
          device_add()
            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 first uevent of power supply (the one coming from device creation)
      should not call back to the driver. To prevent that from happening,
      increment the atomic use counter at the end of power_supply_register().
      This means that power_supply_get_property() will return -ENODEV.
      
      IMPORTANT:
      The patch has impact on this first uevent sent from power supply because
      it will not contain properties from power supply.
      
      The uevent with properties will be sent later after indicating that
      power supply has changed. This also has a race now, but will be fixed in
      other patches.
      Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 297d716f ("power_supply: Change ownership from driver to core")
      Tested-By: NDr. H. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      8e59c7f2
  10. 16 5月, 2015 1 次提交
  11. 15 5月, 2015 2 次提交
  12. 14 5月, 2015 3 次提交
    • D
      drm/radeon: don't do mst probing if MST isn't enabled. · bed447e7
      Dave Airlie 提交于
      This causes an oops as we haven't initialised the mst
      layer.
      Reported-by: NDave Jones <&lt;davej@codemonkey.org.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      bed447e7
    • J
      firmware: dmi_scan: Fix ordering of product_uuid · 5c1ac56b
      Jean Delvare 提交于
      In function dmi_present(), dmi_walk_early() calls dmi_table(), which
      calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
      function makes a decision based on the value of global variable
      dmi_ver. The problem is that this variable is set right _after_
      dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0
      regardless of the actual version implemented.
      
      This causes /sys/class/dmi/id/product_uuid to always use the old
      ordering even on systems implementing DMI/SMBIOS 2.6 or later, which
      should use the new ordering.
      
      This is broken since kernel v3.8 for legacy DMI implementations and
      since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3
      implementations with the 64-bit entry point are not affected.
      
      The first breakage does not matter much as in practice legacy DMI
      implementations are always for versions older than 2.6, which is when
      the UUID ordering changed. The second breakage is more problematic as
      it affects the vast majority of x86 systems manufactured since 2009.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Fixes: 9f9c9cbb ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
      Fixes: 79bae42d ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
      Acked-by: NZhenzhong Duan <zhenzhong.duan@oracle.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Artem Savkov <artem.savkov@gmail.com>
      Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: stable@vger.kernel.org [v3.10+]
      5c1ac56b
    • J
      firmware: dmi_scan: Simplified displayed version · c2493045
      Jean Delvare 提交于
      The trailing .x adds no information for the reader, and if anyone
      tries to parse that line, this is more work as they have 3 different
      formats to handle instead of 2. Plus, this makes backporting fixes
      harder.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Fixes: 95be58df ("firmware: dmi_scan: Use full dmi version for SMBIOS3")
      Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      c2493045
  13. 13 5月, 2015 5 次提交
反馈
建议
客服 返回
顶部