1. 09 Jan, 2017 10 commits
    • Ian Abbott's avatar
      staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask · 5283a7be
      Ian Abbott authored
      commit 655c4d44 upstream.
      
      For NI M Series cards, the Comedi `insn_read` handler for the AI
      subdevice is broken due to ANDing the value read from the AI FIFO data
      register with an incorrect mask.  The incorrect mask clears all but the
      most significant bit of the sample data.  It should preserve all the
      sample data bits.  Correct it.
      
      Fixes: 817144ae ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5283a7be
    • Krzysztof Kozlowski's avatar
      thermal: hwmon: Properly report critical temperature in sysfs · e692edec
      Krzysztof Kozlowski authored
      commit f37fabb8 upstream.
      
      In the critical sysfs entry the thermal hwmon was returning wrong
      temperature to the user-space.  It was reporting the temperature of the
      first trip point instead of the temperature of critical trip point.
      
      For example:
      	/sys/class/hwmon/hwmon0/temp1_crit:50000
      	/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
      	/sys/class/thermal/thermal_zone0/trip_point_0_type:active
      	/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
      	/sys/class/thermal/thermal_zone0/trip_point_3_type:critical
      
      Since commit e68b16ab ("thermal: add hwmon sysfs I/F") the driver
      have been registering a sysfs entry if get_crit_temp() callback was
      provided.  However when accessed, it was calling get_trip_temp() instead
      of the get_crit_temp().
      
      Fixes: e68b16ab ("thermal: add hwmon sysfs I/F")
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e692edec
    • Boris Brezillon's avatar
      clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk · 9d9541d4
      Boris Brezillon authored
      commit 68af4fa8 upstream.
      
      bcm2835_pll_divider_off() is resetting the divider field in the A2W reg
      to zero when disabling the clock.
      
      Make sure we preserve this value by reading the previous a2w_reg value
      first and ORing the result with A2W_PLL_CHANNEL_DISABLE.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Fixes: 41691b88 ("clk: bcm2835: Add support for programming the audio domain clocks")
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d9541d4
    • Thomas Gleixner's avatar
      timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion · e01b04be
      Thomas Gleixner authored
      commit 9c164572 upstream.
      
      The clocksource delta to nanoseconds conversion is using signed math, but
      the delta is unsigned. This makes the conversion space smaller than
      necessary and in case of a multiplication overflow the conversion can
      become negative. The conversion is done with scaled math:
      
          s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift;
      
      Shifting a signed integer right obvioulsy preserves the sign, which has
      interesting consequences:
      
       - Time jumps backwards
      
       - __iter_div_u64_rem() which is used in one of the calling code pathes
         will take forever to piecewise calculate the seconds/nanoseconds part.
      
      This has been reported by several people with different scenarios:
      
      David observed that when stopping a VM with a debugger:
      
       "It was essentially the stopped by debugger case.  I forget exactly why,
        but the guest was being explicitly stopped from outside, it wasn't just
        scheduling lag.  I think it was something in the vicinity of 10 minutes
        stopped."
      
       When lifting the stop the machine went dead.
      
      The stopped by debugger case is not really interesting, but nevertheless it
      would be a good thing not to die completely.
      
      But this was also observed on a live system by Liav:
      
       "When the OS is too overloaded, delta will get a high enough value for the
        msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so
        after the shift the nsec variable will gain a value similar to
        0xffffffffff000000."
      
      Unfortunately this has been reintroduced recently with commit 6bd58f09
      ("time: Add cycles to nanoseconds translation"). It had been fixed a year
      ago already in commit 35a4933a ("time: Avoid signed overflow in
      timekeeping_get_ns()").
      
      Though it's not surprising that the issue has been reintroduced because the
      function itself and the whole call chain uses s64 for the result and the
      propagation of it. The change in this recent commit is subtle:
      
         s64 nsec;
      
      -  nsec = (d * m + n) >> s:
      +  nsec = d * m + n;
      +  nsec >>= s;
      
      d being type of cycle_t adds another level of obfuscation.
      
      This wouldn't have happened if the previous change to unsigned computation
      would have made the 'nsec' variable u64 right away and a follow up patch
      had cleaned up the whole call chain.
      
      There have been patches submitted which basically did a revert of the above
      patch leaving everything else unchanged as signed. Back to square one. This
      spawned a admittedly pointless discussion about potential users which rely
      on the unsigned behaviour until someone pointed out that it had been fixed
      before. The changelogs of said patches added further confusion as they made
      finally false claims about the consequences for eventual users which expect
      signed results.
      
      Despite delta being cycle_t, aka. u64, it's very well possible to hand in
      a signed negative value and the signed computation will happily return the
      correct result. But nobody actually sat down and analyzed the code which
      was added as user after the propably unintended signed conversion.
      
      Though in sensitive code like this it's better to analyze it proper and
      make sure that nothing relies on this than hunting the subtle wreckage half
      a year later. After analyzing all call chains it stands that no caller can
      hand in a negative value (which actually would work due to the s64 cast)
      and rely on the signed math to do the right thing.
      
      Change the conversion function to unsigned math. The conversion of all call
      chains is done in a follow up patch.
      
      This solves the starvation issue, which was caused by the negative result,
      but it does not solve the underlying problem. It merily procrastinates
      it. When the timekeeper update is deferred long enough that the unsigned
      multiplication overflows, then time going backwards is observable again.
      
      It does neither solve the issue of clocksources with a small counter width
      which will wrap around possibly several times and cause random time stamps
      to be generated. But those are usually not found on systems used for
      virtualization, so this is likely a non issue.
      
      I took the liberty to claim authorship for this simply because
      analyzing all callsites and writing the changelog took substantially
      more time than just making the simple s/s64/u64/ change and ignore the
      rest.
      
      Fixes: 6bd58f09 ("time: Add cycles to nanoseconds translation")
      Reported-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reported-by: default avatarLiav Rehana <liavr@mellanox.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Parit Bhargava <prarit@redhat.com>
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: "Christopher S. Hall" <christopher.s.hall@intel.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Link: http://lkml.kernel.org/r/20161208204228.688545601@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e01b04be
    • Linus Walleij's avatar
      regulator: stw481x-vmmc: fix ages old enable error · 96ea1b9e
      Linus Walleij authored
      commit 295070e9 upstream.
      
      The regulator has never been properly enabled, it has been
      dormant all the time. It's strange that MMC was working
      at all, but it likely worked by the signals going through
      the levelshifter and reaching the card anyways.
      
      Fixes: 3615a34e ("regulator: add STw481x VMMC driver")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96ea1b9e
    • Adrian Hunter's avatar
      mmc: sdhci: Fix recovery from tuning timeout · 842ec27c
      Adrian Hunter authored
      commit 61e53bd0 upstream.
      
      Clearing the tuning bits should reset the tuning circuit. However there is
      more to do. Reset the command and data lines for good measure, and then
      for eMMC ensure the card is not still trying to process a tuning command by
      sending a stop command.
      
      Note the JEDEC eMMC specification says the stop command (CMD12) can be used
      to stop a tuning command (CMD21) whereas the SD specification is silent on
      the subject with respect to the SD tuning command (CMD19). Considering that
      CMD12 is not a valid SDIO command, the stop command is sent only when the
      tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
      which have been on eMMC.
      
      Note that this replaces the commit fe5fb2e3 ("mmc: sdhci: Reset cmd and
      data circuits after tuning failure") which is being reverted for v4.9+.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarDan O'Donovan <dan@emutex.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      842ec27c
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards. · dae7cb41
      Vittorio Gambaletta (VittGam) authored
      commit 79e57dd1 upstream.
      
      The active_high LED of my Wistron DNMA-92 is still being recognized as
      active_low on 4.7.6 mainline. When I was preparing my former commit
      0f9edcdd ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
      cards.") to fix that I must have somehow messed up with testing, because
      I tested the final version of that patch before sending it, and it was
      apparently working; but now it is not working on 4.7.6 mainline.
      
      I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
      PCI_VDEVICE section for 0x0029; but then I moved the former below the
      latter after seeing how 0x002A sections were sorted in the file.
      
      This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
      both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
      specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
      match first and will be used.
      
      With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
      
      While I'm at it, let's fix 0x002A too by also moving its generic definition
      below its specific ones.
      
      Fixes: 0f9edcdd ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.")
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      [kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dae7cb41
    • Johannes Berg's avatar
      cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts · b63929e8
      Johannes Berg authored
      commit e6f462df upstream.
      
      When mac80211 abandons an association attempt, it may free
      all the data structures, but inform cfg80211 and userspace
      about it only by sending the deauth frame it received, in
      which case cfg80211 has no link to the BSS struct that was
      used and will not cfg80211_unhold_bss() it.
      
      Fix this by providing a way to inform cfg80211 of this with
      the BSS entry passed, so that it can clean up properly, and
      use this ability in the appropriate places in mac80211.
      
      This isn't ideal: some code is more or less duplicated and
      tracing is missing. However, it's a fairly small change and
      it's thus easier to backport - cleanups can come later.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b63929e8
    • Larry Finger's avatar
      rtlwifi: Fix enter/exit power_save · 05f4183a
      Larry Finger authored
      commit ba9f93f8 upstream.
      
      In commit a5ffbe0a ("rtlwifi: Fix scheduling while atomic bug") and
      commit a269913c ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
      to use work queue"), an error was introduced in the power-save routines
      due to the fact that leaving PS was delayed by the use of a work queue.
      
      This problem is fixed by detecting if the enter or leave routines are
      in interrupt mode. If so, the workqueue is used to place the request.
      If in normal mode, the enter or leave routines are called directly.
      
      Fixes: a269913c ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
      Reported-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05f4183a
    • Larry Finger's avatar
      ssb: Fix error routine when fallback SPROM fails · f5d90f43
      Larry Finger authored
      commit 8052d724 upstream.
      
      When there is a CRC error in the SPROM read from the device, the code
      attempts to handle a fallback SPROM. When this also fails, the driver
      returns zero rather than an error code.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5d90f43
  2. 06 Jan, 2017 30 commits