1. 11 Jan, 2018 2 commits
  2. 10 Jan, 2018 2 commits
  3. 05 Jan, 2018 4 commits
    • Viresh Kumar's avatar
      cpufreq: stats: Change return type of cpufreq_stats_update() as void · d476ec4f
      Viresh Kumar authored
      It always returns 0 and none of its callers check its return value. Make
      it return void.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d476ec4f
    • Gautham R. Shenoy's avatar
      powernv-cpufreq: Treat pstates as opaque 8-bit values · 967b87fd
      Gautham R. Shenoy authored
      On POWER8 and POWER9, the PMSR and the PMCR registers define pstates
      to be 8-bit wide values. The device-tree exports pstates as 32-bit
      wide values of which the lower byte is the actual pstate.
      
      The current implementation in the kernel treats pstates as integer
      type, since it used to use the sign of the pstate for performing some
      boundary-checks. This is no longer required after the patch
      "powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous
      pstates".
      
      So, in this patch, we modify the powernv-cpufreq driver to uniformly
      treat pstates as opaque 8-bit values obtained from the device-tree or
      the PMCR. This simplifies the extract_pstate() helper function since
      we no longer no longer require to worry about the sign-extentions.
      Signed-off-by: default avatarGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      967b87fd
    • Gautham R. Shenoy's avatar
      powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates · 332f0a01
      Gautham R. Shenoy authored
      The code in powernv-cpufreq, makes the following two assumptions which
      are not guaranteed by the device-tree bindings:
      
          1) Pstate ids are continguous: This is used in pstate_to_idx() to
             obtain the reverse map from a pstate to it's corresponding
             entry into the cpufreq frequency table.
      
          2) Every Pstate should always lie between the max and the min
             pstates that are explicitly reported in the device tree: This
             is used to determine whether a pstate reported by the PMSR is
             out of bounds.
      
      Both these assumptions are unwarranted and can change on future
      platforms.
      
      In this patch, we maintain the reverse map from a pstate to it's index
      in the cpufreq frequency table and use this in pstate_to_idx(). This
      does away with the assumptions (1) mentioned above, and will work with
      non continguous pstate ids. If no entry exists for a particular
      pstate, then such a pstate is treated as being out of bounds. This
      gets rid of assumption (2).
      
      On all the existing platforms, where the pstates are 8-bit long
      values, the new implementation of pstate_to_idx() takes constant time.
      Signed-off-by: default avatarGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      332f0a01
    • Gautham R. Shenoy's avatar
      powernv-cpufreq: Add helper to extract pstate from PMSR · ee1f4a7d
      Gautham R. Shenoy authored
      On POWERNV platform, the fields for pstates in the Power Management
      Status Register (PMSR) and the Power Management Control Register
      (PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered
      while on POWER9 they are positively numbered.
      
      The device-tree exports pstates as 32-bit entries. The device-tree
      implementation sign-extends the 8-bit pstate values to obtain the
      corresponding 32-bit entry.
      
      Eg: On POWER8, a pstate value 0x82 [-126] is represented in the
      device-tree as 0xfffffff82 while on POWER9, the same value 0x82 [130]
      is represented in the device-tree as 0x00000082.
      
      The powernv-cpufreq driver implementation represents pstates using the
      integer type. In multiple places in the driver, the code interprets
      the pstates extracted from the PMSR as a signed byte and assigns it to
      a integer variable to get the sign-extention.
      
      On POWER9 platforms which have greater than 128 pstates, this results
      in the driver performing incorrect sign-extention, and thereby
      treating a legitimate pstate (say 130) as an invalid pstates (since it
      is interpreted as -126).
      
      This patch fixes the issue by implementing a helper function to
      extract Pstates from PMSR register, and correctly sign-extend it to be
      consistent with the values provided by the device-tree.
      Signed-off-by: default avatarGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ee1f4a7d
  4. 28 Dec, 2017 2 commits
  5. 21 Dec, 2017 1 commit
  6. 18 Dec, 2017 3 commits
  7. 17 Dec, 2017 24 commits
  8. 16 Dec, 2017 2 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · f3b5ad89
      Linus Torvalds authored
      Pull rdma fixes from Jason Gunthorpe:
       "More fixes from testing done on the rc kernel, including more SELinux
        testing. Looking forward, lockdep found regression today in ipoib
        which is still being fixed.
      
        Summary:
      
         - Fix for SELinux on the umad SMI path. Some old hardware does not
           fill the PKey properly exposing another bug in the newer SELinux
           code.
      
         - Check the input port as we can exceed array bounds from this user
           supplied value
      
         - Users are unable to use the hash field support as they want due to
           incorrect checks on the field restrictions, correct that so the
           feature works as intended
      
         - User triggerable oops in the NETLINK_RDMA handler
      
         - cxgb4 driver fix for a bad interaction with CQ flushing in iser
           caused by patches in this merge window, and bad CQ flushing during
           normal close.
      
         - Unbalanced memalloc_noio in ipoib in an error path"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
        IB/ipoib: Restore MM behavior in case of tx_ring allocation failure
        iw_cxgb4: only insert drain cqes if wq is flushed
        iw_cxgb4: only clear the ARMED bit if a notification is needed
        RDMA/netlink: Fix general protection fault
        IB/mlx4: Fix RSS hash fields restrictions
        IB/core: Don't enforce PKey security on SMI MADs
        IB/core: Bound check alternate path port number
      f3b5ad89
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · f25e2295
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "Two bugfixes for the AT24 I2C eeprom driver and some minor corrections
        for I2C bus drivers"
      
      * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: piix4: Fix port number check on release
        i2c: stm32: Fix copyrights
        i2c-cht-wc: constify platform_device_id
        eeprom: at24: change nvmem stride to 1
        eeprom: at24: fix I2C device selection for runtime PM
      f25e2295