1. 15 Jul, 2017 1 commit
    • Guenter Roeck's avatar
      hwmon: (applesmc) Avoid buffer overruns · 1009ccdc
      Guenter Roeck authored
      
      
      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: default avatarGuenter Roeck <linux@roeck-us.net>
      1009ccdc
  2. 16 Nov, 2015 1 commit
    • Shuah Khan's avatar
      hwmon : (applesmc) Fix uninitialized variables warnings · 5e0a0ee4
      Shuah Khan authored
      
      
      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: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      5e0a0ee4
  3. 29 Sep, 2015 1 commit
  4. 20 Oct, 2014 1 commit
  5. 09 Oct, 2013 1 commit
    • Henrik Rydberg's avatar
      hwmon: (applesmc) Always read until end of data · 25f2bd7f
      Henrik Rydberg authored
      
      
      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: default avatarChris Murphy <chris@cmurf.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      25f2bd7f
  6. 26 Sep, 2013 1 commit
  7. 08 Apr, 2013 1 commit
  8. 10 Oct, 2012 1 commit
  9. 18 Sep, 2012 1 commit
  10. 27 Jul, 2012 1 commit
    • Henrik Rydberg's avatar
      hwmon: (applesmc) Decode and act on read/write status codes · 829917cd
      Henrik Rydberg authored
      
      
      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: default avatarAdam Somerville <adamsomerville@gmail.com>
      Tested-by: default avatarHubert Eichner <hubert.georg.eichner@gmail.com>
      Signed-off-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      829917cd
  11. 22 Jul, 2012 4 commits
  12. 25 Jun, 2012 1 commit
  13. 18 Jun, 2012 1 commit
  14. 19 Mar, 2012 2 commits
  15. 05 Jan, 2012 1 commit
  16. 23 Jan, 2011 1 commit
  17. 08 Jan, 2011 12 commits
  18. 27 May, 2010 4 commits
  19. 11 May, 2010 1 commit
  20. 14 Apr, 2010 1 commit
  21. 15 Dec, 2009 1 commit
  22. 22 Sep, 2009 1 commit