1. 06 Dec, 2022 30 commits
  2. 29 Nov, 2022 3 commits
  3. 23 Nov, 2022 2 commits
  4. 11 Nov, 2022 1 commit
    • Steven Price's avatar
      pwm: tegra: Fix 32 bit build · dd1f1da4
      Steven Price authored
      The value of NSEC_PER_SEC << PWM_DUTY_WIDTH doesn't fix within a 32 bit
      integer causing a build warning/error (and the value truncated):
      
        drivers/pwm/pwm-tegra.c: In function ‘tegra_pwm_config’:
        drivers/pwm/pwm-tegra.c:148:53: error: result of ‘1000000000 << 8’ requires 39 bits to represent, but ‘long int’ only has 32 bits [-Werror=shift-overflow=]
          148 |   required_clk_rate = DIV_ROUND_UP_ULL(NSEC_PER_SEC << PWM_DUTY_WIDTH,
              |                                                     ^~
      
      Explicitly cast to a u64 to ensure the correct result.
      
      Fixes: cfcb68817fb3 ("pwm: tegra: Improve required rate calculation")
      Signed-off-by: default avatarSteven Price <steven.price@arm.com>
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      dd1f1da4
  5. 09 Nov, 2022 2 commits
    • Jon Hunter's avatar
      pwm: tegra: Ensure the clock rate is not less than needed · 5eccd0d9
      Jon Hunter authored
      When dynamically scaling the PWM clock, the function
      dev_pm_opp_set_rate() may set the PWM clock to a rate that is lower than
      what is required. The clock rate requested when calling
      dev_pm_opp_set_rate() is the minimum clock rate that is needed to drive
      the PWM to achieve the required period. Hence, if the actual clock
      rate is less than the requested clock rate, then the required period
      cannot be achieved and configuring the PWM fails. Fix this by
      calling clk_round_rate() to check if the clock rate that will be provided
      is sufficient and if not, double the required clock rate to ensure the
      required period can be attained.
      
      Fixes: 8c193f47 ("pwm: tegra: Optimize period calculation")
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      5eccd0d9
    • Jon Hunter's avatar
      pwm: tegra: Improve required rate calculation · f2719461
      Jon Hunter authored
      For the case where dev_pm_opp_set_rate() is called to set the PWM clock
      rate, the requested rate is calculated as ...
      
       required_clk_rate = (NSEC_PER_SEC / period_ns) << PWM_DUTY_WIDTH;
      
      The above calculation may lead to rounding errors because the
      NSEC_PER_SEC is divided by 'period_ns' before applying the
      PWM_DUTY_WIDTH multiplication factor. For example, if the period is
      45334ns, the above calculation yields a rate of 5646848Hz instead of
      5646976Hz. Fix this by applying the multiplication factor before
      dividing and using the DIV_ROUND_UP macro which yields the expected
      result of 5646976Hz.
      
      Fixes: 1d7796bd ("pwm: tegra: Support dynamic clock frequency configuration")
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      f2719461
  6. 16 Oct, 2022 2 commits
    • Linus Torvalds's avatar
      Linux 6.1-rc1 · 9abf2313
      Linus Torvalds authored
      9abf2313
    • Linus Torvalds's avatar
      Merge tag 'random-6.1-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random · f1947d7c
      Linus Torvalds authored
      Pull more random number generator updates from Jason Donenfeld:
       "This time with some large scale treewide cleanups.
      
        The intent of this pull is to clean up the way callers fetch random
        integers. The current rules for doing this right are:
      
         - If you want a secure or an insecure random u64, use get_random_u64()
      
         - If you want a secure or an insecure random u32, use get_random_u32()
      
           The old function prandom_u32() has been deprecated for a while
           now and is just a wrapper around get_random_u32(). Same for
           get_random_int().
      
         - If you want a secure or an insecure random u16, use get_random_u16()
      
         - If you want a secure or an insecure random u8, use get_random_u8()
      
         - If you want secure or insecure random bytes, use get_random_bytes().
      
           The old function prandom_bytes() has been deprecated for a while
           now and has long been a wrapper around get_random_bytes()
      
         - If you want a non-uniform random u32, u16, or u8 bounded by a
           certain open interval maximum, use prandom_u32_max()
      
           I say "non-uniform", because it doesn't do any rejection sampling
           or divisions. Hence, it stays within the prandom_*() namespace, not
           the get_random_*() namespace.
      
           I'm currently investigating a "uniform" function for 6.2. We'll see
           what comes of that.
      
        By applying these rules uniformly, we get several benefits:
      
         - By using prandom_u32_max() with an upper-bound that the compiler
           can prove at compile-time is ≤65536 or ≤256, internally
           get_random_u16() or get_random_u8() is used, which wastes fewer
           batched random bytes, and hence has higher throughput.
      
         - By using prandom_u32_max() instead of %, when the upper-bound is
           not a constant, division is still avoided, because
           prandom_u32_max() uses a faster multiplication-based trick instead.
      
         - By using get_random_u16() or get_random_u8() in cases where the
           return value is intended to indeed be a u16 or a u8, we waste fewer
           batched random bytes, and hence have higher throughput.
      
        This series was originally done by hand while I was on an airplane
        without Internet. Later, Kees and I worked on retroactively figuring
        out what could be done with Coccinelle and what had to be done
        manually, and then we split things up based on that.
      
        So while this touches a lot of files, the actual amount of code that's
        hand fiddled is comfortably small"
      
      * tag 'random-6.1-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random:
        prandom: remove unused functions
        treewide: use get_random_bytes() when possible
        treewide: use get_random_u32() when possible
        treewide: use get_random_{u8,u16}() when possible, part 2
        treewide: use get_random_{u8,u16}() when possible, part 1
        treewide: use prandom_u32_max() when possible, part 2
        treewide: use prandom_u32_max() when possible, part 1
      f1947d7c