1. 23 Nov, 2022 6 commits
  2. 22 Nov, 2022 13 commits
  3. 18 Nov, 2022 2 commits
  4. 16 Nov, 2022 3 commits
  5. 15 Nov, 2022 1 commit
  6. 14 Nov, 2022 1 commit
  7. 10 Nov, 2022 1 commit
  8. 09 Nov, 2022 2 commits
  9. 03 Nov, 2022 4 commits
    • Mark Brown's avatar
      regulator: Add DT support for regulator-output connectors · 3078d0c3
      Mark Brown authored
      Merge series from Zev Weiss <zev@bewilderbeest.net>:
      
      This series adds support for userspace-controlled regulator-supplied
      power outputs [2].  This is an important feature for some kinds of BMC
      (baseboard management controller) systems where the BMC provides an
      operator with manual control of a set of DC power outputs.
      
      As in a broadly similar patchset that was recently almost merged [0],
      this takes the approach of providing support by extending the existing
      userspace-consumer regulator driver.  A couple questions about the
      userspace-consumer driver came up along the way, however.
      
      First, how (if at all) is it currently being used?  It appears the
      last in-tree use of it was removed a bit over two years ago in commit
      9d323914 ("ARM: pxa: remove Compulab pxa2xx boards").  Aside from
      just adding DT support I've made a couple small tweaks to the driver
      in patch 3 that I hope are compatible with any current usage, but
      without any extant examples to look at it's kind of hard to say.
      
      Second, how critical is its support for controlling multiple
      regulators?  (i.e. its use of regulator_bulk_data and friends instead
      of a single struct regulator.)  As far as I can see every in-tree use
      of it that's ever existed has used num_supplies = 1.  If it's not
      important to retain, patch 1 of this series could be supplanted by one
      that instead simplifies the driver slightly by removing that
      functionality.
      
      The DT binding added in patch 2 is essentially identical to one I
      posted in a previous patchset that had an R-B from Rob [1], but has
      had some minor rewording and been moved from the extcon subsystem to
      the regulator subsystem.
      3078d0c3
    • Zev Weiss's avatar
      regulator: userspace-consumer: Handle regulator-output DT nodes · 5c51d4af
      Zev Weiss authored
      In addition to adding some fairly simple OF support code, we make some
      slight adjustments to the userspace-consumer driver to properly
      support use with regulator-output hardware:
      
       - We now do an exclusive get of the supply regulators so as to
         prevent regulator_init_complete_work from automatically disabling
         them.
      
       - Instead of assuming that the supply is initially disabled, we now
         query its state to determine the initial value of drvdata->enabled.
      Signed-off-by: default avatarZev Weiss <zev@bewilderbeest.net>
      Link: https://lore.kernel.org/r/20221031233704.22575-4-zev@bewilderbeest.netSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5c51d4af
    • Zev Weiss's avatar
      regulator: Add regulator-output binding · 14b8ad4c
      Zev Weiss authored
      This describes a power output supplied by a regulator, such as a
      power outlet on a power distribution unit (PDU).
      Signed-off-by: default avatarZev Weiss <zev@bewilderbeest.net>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20221031233704.22575-3-zev@bewilderbeest.netSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      14b8ad4c
    • Zev Weiss's avatar
      regulator: devres: Add devm_regulator_bulk_get_exclusive() · fd184506
      Zev Weiss authored
      We had an exclusive variant of the devm_regulator_get() API, but no
      corresponding variant for the bulk API; let's add one now.  We add a
      generalized version of the existing regulator_bulk_get() function that
      additionally takes a get_type parameter and redefine
      regulator_bulk_get() in terms of it, then do similarly with
      devm_regulator_bulk_get(), and finally add the new
      devm_regulator_bulk_get_exclusive().
      Signed-off-by: default avatarZev Weiss <zev@bewilderbeest.net>
      Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.netSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      fd184506
  10. 02 Nov, 2022 4 commits
  11. 16 Oct, 2022 3 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
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-for-v6.1-2-2022-10-16' of... · 8636df94
      Linus Torvalds authored
      Merge tag 'perf-tools-for-v6.1-2-2022-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull more perf tools updates from Arnaldo Carvalho de Melo:
      
       - Use BPF CO-RE (Compile Once, Run Everywhere) to support old kernels
         when using bperf (perf BPF based counters) with cgroups.
      
       - Support HiSilicon PCIe Performance Monitoring Unit (PMU), that
         monitors bandwidth, latency, bus utilization and buffer occupancy.
      
         Documented in Documentation/admin-guide/perf/hisi-pcie-pmu.rst.
      
       - User space tasks can migrate between CPUs, so when tracing selected
         CPUs, system-wide sideband is still needed, fix it in the setup of
         Intel PT on hybrid systems.
      
       - Fix metricgroups title message in 'perf list', it should state that
         the metrics groups are to be used with the '-M' option, not '-e'.
      
       - Sync the msr-index.h copy with the kernel sources, adding support for
         using "AMD64_TSC_RATIO" in filter expressions in 'perf trace' as well
         as decoding it when printing the MSR tracepoint arguments.
      
       - Fix program header size and alignment when generating a JIT ELF in
         'perf inject'.
      
       - Add multiple new Intel PT 'perf test' entries, including a jitdump
         one.
      
       - Fix the 'perf test' entries for 'perf stat' CSV and JSON output when
         running on PowerPC due to an invalid topology number in that arch.
      
       - Fix the 'perf test' for arm_coresight failures on the ARM Juno
         system.
      
       - Fix the 'perf test' attr entry for PERF_FORMAT_LOST, adding this
         option to the or expression expected in the intercepted
         perf_event_open() syscall.
      
       - Add missing condition flags ('hs', 'lo', 'vc', 'vs') for arm64 in the
         'perf annotate' asm parser.
      
       - Fix 'perf mem record -C' option processing, it was being chopped up
         when preparing the underlying 'perf record -e mem-events' and thus
         being ignored, requiring using '-- -C CPUs' as a workaround.
      
       - Improvements and tidy ups for 'perf test' shell infra.
      
       - Fix Intel PT information printing segfault in uClibc, where a NULL
         format was being passed to fprintf.
      
      * tag 'perf-tools-for-v6.1-2-2022-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (23 commits)
        tools arch x86: Sync the msr-index.h copy with the kernel sources
        perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet
        perf auxtrace arm64: Add support for HiSilicon PCIe Tune and Trace device driver
        perf auxtrace arm: Refactor event list iteration in auxtrace_record__init()
        perf tests stat+json_output: Include sanity check for topology
        perf tests stat+csv_output: Include sanity check for topology
        perf intel-pt: Fix system_wide dummy event for hybrid
        perf intel-pt: Fix segfault in intel_pt_print_info() with uClibc
        perf test: Fix attr tests for PERF_FORMAT_LOST
        perf test: test_intel_pt.sh: Add 9 tests
        perf inject: Fix GEN_ELF_TEXT_OFFSET for jit
        perf test: test_intel_pt.sh: Add jitdump test
        perf test: test_intel_pt.sh: Tidy some alignment
        perf test: test_intel_pt.sh: Print a message when skipping kernel tracing
        perf test: test_intel_pt.sh: Tidy some perf record options
        perf test: test_intel_pt.sh: Fix return checking again
        perf: Skip and warn on unknown format 'configN' attrs
        perf list: Fix metricgroups title message
        perf mem: Fix -C option behavior for perf mem record
        perf annotate: Add missing condition flags for arm64
        ...
      8636df94