1. 14 9月, 2017 1 次提交
  2. 16 7月, 2017 1 次提交
    • G
      hwmon: (applesmc) Avoid buffer overruns · 1009ccdc
      Guenter Roeck 提交于
      gcc 7.1 complains that the driver uses sprintf() and thus does not validate
      the length of output buffers.
      
      drivers/hwmon/applesmc.c: In function 'applesmc_show_fan_position':
      drivers/hwmon/applesmc.c:82:21: warning:
      	'%d' directive writing between 1 and 5 bytes into a region of size 4
      
      Fix the problem by using scnprintf() instead of sprintf() throughout the
      driver. Also explicitly limit the number of supported fans to avoid actual
      buffer overruns and thus invalid keys.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      1009ccdc
  3. 16 11月, 2015 1 次提交
    • S
      hwmon : (applesmc) Fix uninitialized variables warnings · 5e0a0ee4
      Shuah Khan 提交于
      Fix the following "maybe used uninitialized" warnings by
      initializing the variables to keep the compiler quiet.
      There is no "used uninitialized" in this case.
      
        CC [M]  drivers/hwmon/applesmc.o
      drivers/hwmon/applesmc.c: In function ‘applesmc_init_smcreg’:
      drivers/hwmon/applesmc.c:595:43: warning: ‘right_light_sensor’
      may be used uninitialized in this function [-Wmaybe-uninitialized]
        s->num_light_sensors = left_light_sensor + right_light_sensor;
                                                 ^
      drivers/hwmon/applesmc.c:540:26: note: ‘right_light_sensor’ was
      declared here
        bool left_light_sensor, right_light_sensor;
                                ^
      drivers/hwmon/applesmc.c:595:43: warning: ‘left_light_sensor’ may
      be used uninitialized in this function [-Wmaybe-uninitialized]
        s->num_light_sensors = left_light_sensor + right_light_sensor;
                                                 ^
      drivers/hwmon/applesmc.c:540:7: note: ‘left_light_sensor’ was
      declared here
        bool left_light_sensor, right_light_sensor;
             ^
      Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      5e0a0ee4
  4. 29 9月, 2015 1 次提交
  5. 20 10月, 2014 1 次提交
  6. 10 10月, 2013 1 次提交
    • H
      hwmon: (applesmc) Always read until end of data · 25f2bd7f
      Henrik Rydberg 提交于
      The crash reported and investigated in commit 5f4513 turned out to be
      caused by a change to the read interface on newer (2012) SMCs.
      
      Tests by Chris show that simply reading the data valid line is enough
      for the problem to go away. Additional tests show that the newer SMCs
      no longer wait for the number of requested bytes, but start sending
      data right away.  Apparently the number of bytes to read is no longer
      specified as before, but instead found out by reading until end of
      data. Failure to read until end of data confuses the state machine,
      which eventually causes the crash.
      
      As a remedy, assuming bit0 is the read valid line, make sure there is
      nothing more to read before leaving the read function.
      
      Tested to resolve the original problem, and runtested on MBA3,1,
      MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
      machines before 2012.
      Tested-by: NChris Murphy <chris@cmurf.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      25f2bd7f
  7. 26 9月, 2013 1 次提交
  8. 08 4月, 2013 1 次提交
  9. 10 10月, 2012 1 次提交
  10. 19 9月, 2012 1 次提交
  11. 28 7月, 2012 1 次提交
    • H
      hwmon: (applesmc) Decode and act on read/write status codes · 829917cd
      Henrik Rydberg 提交于
      The behavior of the SMC has changed several times over the years,
      causing read failures in the driver. It seems the problem can be
      explained by a shift in SMC speed combined with improper action on
      status codes.
      
      We should first wait for the SMC to settle, which was the most
      frequent response on the old slow machines. Then, if the SMC is busy,
      we need to try again later by resending the command. This was the most
      likely response until 2012. Now, with a shorter wait time, we are
      again most likely to poll while the SMC is settling, and as a result
      we see high failure rates on many old and new models.
      
      With the distinction between busy and failure, we can also wait longer
      before retrying, without sacrificing speed.  This seems to bring
      failures down to virtually zero on all models.
      
      Tested on: MBA1,1 MBA3,1 MBA5,1 MBA5,2 MBP9,2
      Tested-by: NAdam Somerville <adamsomerville@gmail.com>
      Tested-by: NHubert Eichner <hubert.georg.eichner@gmail.com>
      Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      829917cd
  12. 22 7月, 2012 4 次提交
  13. 25 6月, 2012 1 次提交
  14. 18 6月, 2012 1 次提交
  15. 19 3月, 2012 2 次提交
  16. 06 1月, 2012 1 次提交
  17. 24 1月, 2011 1 次提交
  18. 09 1月, 2011 12 次提交
  19. 28 5月, 2010 4 次提交
  20. 11 5月, 2010 1 次提交
  21. 14 4月, 2010 1 次提交
  22. 16 12月, 2009 1 次提交