1. 08 Jul, 2016 2 commits
  2. 27 May, 2016 1 commit
    • Arnd Bergmann's avatar
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann authored
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      I was using this definition for testing:
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 19 May, 2016 1 commit
  4. 17 May, 2016 1 commit
  5. 13 May, 2016 1 commit
  6. 12 May, 2016 3 commits
  7. 09 May, 2016 3 commits
    • Heiko Stuebner's avatar
      clk: rockchip: drop old_rate calculation on pll rate changes · 7e5385dc
      Heiko Stuebner authored
      Previously when everything happened in the set_rate callbacks itself we
      needed the old_rate value for the possible rate rollback, so that made
      it easy to also use it in the debug output.
      Now with the param-handling being done in separate functions, reading and
      recalculating the current pll rate only to use it in a debug message that
      won't get displayed in regular cases anyway is quite a waste.
      Therefore drop that value from the debug output. In the worst case that
      previous rate will have been displayed on the rate change before.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
    • Heiko Stuebner's avatar
      clk: rockchip: simplify GRF handling in pll clocks · c9c3c6ee
      Heiko Stuebner authored
      With the previous commit, the clock drivers now know at init time if the
      GRF regmap is available. That means if it isn't available then, it also
      won't become available later and we can therefore switch PLLs, that need
      the GRF for the lock-status, to read-only mode - similar behaviour as the
      aborting of rate changes we did before.
      This saves some conditionals on every rate change and we can also drop
      the rockchip_clk_get_grf function completely.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
    • Heiko Stuebner's avatar
      clk: rockchip: lookup General Register Files in rockchip_clk_init · 6f339dc2
      Heiko Stuebner authored
      In the distant past syscons were initialized pretty late and weren't
      available at the time the clock init ran. As the GRF is mainly needed
      for PLL lock-status checking, we had this lazy init that tried to grab
      the syscon on PLL rate changes and denied these changes if it was not
      These days syscons are available very early and recent addition to
      rockchip clocks, like the PLL clk_init actually also rely on them
      being available at that time, so there is no need to keep that lazy
      init around, as it will also result in some more simplifications in
      other parts of the clock-code.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
  8. 08 May, 2016 1 commit
  9. 06 May, 2016 12 commits
  10. 03 May, 2016 1 commit
    • Stefan Agner's avatar
      clk: imx7d: fix ahb clock mux 1 · 92a847e3
      Stefan Agner authored
      The clock parent of the AHB root clock when using mux option 1
      is the SYS PLL 270MHz clock. This is specified in  Table 5-11
      Clock Root Table of the i.MX 7Dual Applications Processor
      Reference Manual.
      While it could be a documentation error, the 270MHz parent is
      also mentioned in the boot ROM configuration in Table 6-28: The
      clock is by default at 135MHz due to a POST_PODF value of 1
      (=> divider of 2).
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
  11. 02 May, 2016 1 commit
  12. 28 Apr, 2016 13 commits