We have all this fine kernel-doc written, and it's not published
anywhere. Expose it to public view.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250604195753.823742-1-willy@infradead.org
Add missing GPIOLIB dependency reported by the LKP test robot.
This fixes the following report:
"
kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for GPIO_REGMAP when selected by REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2
WARNING: unmet direct dependencies detected for GPIO_REGMAP
Depends on [n]: GPIOLIB [=n]
Selected by [y]:
- REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2 [=y] && REGULATOR [=y] && I2C [=y]
"
Fixes: d49305862f ("regulator: rpi-panel-v2: Add regulator for 7" Raspberry Pi 720x1280")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506092341.enbNKMOR-lkp@intel.com/
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20250609200242.31271-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
It is reported that on Acer Nitro V15 suspend only works properly if the
keyboard backlight is turned off. In looking through the issue Acer Nitro
V15 has a GPIO (#8) specified in _AEI but it has no matching notify device
in _EVT. The values for GPIO #8 change as keyboard backlight is turned on
and off.
This makes it seem that GPIO #8 is actually supposed to be solely for
keyboard backlight. Turning off the interrupt for this GPIO fixes the issue.
Add a quirk that does just that.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4169
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We are going to want to re-use this before the component is bound, when
we don't yet have the device pointer (but we do have the of node).
v2: use %pOF
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657705/
To better match add_gpu_components().
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/657700/
The files generated by gen_header.py capture the source path to the
input files and the date. While that can be informative, it varies
based on where and when the kernel was built as the full path is
captured.
Since all of the files that this tool is run on is under the drivers
directory, this modifies the application to strip all of the path before
drivers. Additionally it prints <stripped> instead of the date.
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/655599/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Calling this packet is necessary when we switch contexts because there
are various pieces of state used by userspace to synchronize between BR
and BV that are persistent across submits and we need to make sure that
they are in a "safe" state when switching contexts. Otherwise a
userspace submission in one context could cause another context to
function incorrectly and hang, effectively a denial of service (although
without leaking data). This was missed during initial a7xx bringup.
Fixes: af66706acc ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654924/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Based on kgsl.
Fixes: af66706acc ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654922/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Improve the usability of the unit_add sysfs attribute by ensuring that
the associated FCP LUN scan processing is completed synchronously. This
enables configuration tooling to consistently determine the end of the
scan process to allow for serialization of follow-on actions.
While the scan process associated with unit_add typically completes
synchronously, it is deferred to an asynchronous background process if
unit_add is used before initial remote port scanning has completed. This
occurs when unit_add is used immediately after setting the associated FCP
device online.
To ensure synchronous unit_add processing, wait for remote port scanning
to complete before initiating the FCP LUN scan.
Cc: stable@vger.kernel.org
Reviewed-by: M Nikhil <nikh1092@linux.ibm.com>
Reviewed-by: Nihar Panda <niharp@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Nihar Panda <niharp@linux.ibm.com>
Link: https://lore.kernel.org/r/20250603182252.2287285-2-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Correct the error handling goto labels used when host lookup fails in
various flashnode-related event handlers:
- iscsi_new_flashnode()
- iscsi_del_flashnode()
- iscsi_login_flashnode()
- iscsi_logout_flashnode()
- iscsi_logout_flashnode_sid()
scsi_host_put() is not required when shost is NULL, so jumping to the
correct label avoids unnecessary operations. These functions previously
jumped to the wrong goto label (put_host), which did not match the
intended cleanup logic.
Use the correct exit labels (exit_new_fnode, exit_del_fnode, etc.) to
ensure proper error handling. Also remove the unused put_host label
under iscsi_new_flashnode() as it is no longer needed.
No functional changes beyond accurate error path correction.
Fixes: c6a4bb2ef5 ("[SCSI] scsi_transport_iscsi: Add flash node mgmt support")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Link: https://lore.kernel.org/r/20250530193012.3312911-1-alok.a.tiwari@oracle.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Spelling fixes:
Deocder --> Decoder
Memroy --> Memory
This is a non-functional change aimed at improving code clarity.
Signed-off-by: Ankit Chauhan <ankitchauhan2065@gmail.com>
Link: https://lore.kernel.org/r/20250528110604.59528-1-ankitchauhan2065@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When things go wrong, the GPU is capable of quickly generating millions
of faulting translation requests per second. When that happens, in the
stall-on-fault model each access will stall until it wins the race to
signal the fault and then the RESUME register is written. This slows
processing page faults to a crawl as the GPU can generate faults much
faster than the CPU can acknowledge them. It also means that all
available resources in the SMMU are saturated waiting for the stalled
transactions, so that other transactions such as transactions generated
by the GMU, which shares translation resources with the GPU, cannot
proceed. This causes a GMU watchdog timeout, which leads to a failed
reset because GX cannot collapse when there is a transaction pending and
a permanently hung GPU.
On older platforms with qcom,smmu-v2, it seems that when one transaction
is stalled subsequent faulting transactions are terminated, which avoids
this problem, but the MMU-500 follows the spec here.
To work around these problems, disable stall-on-fault as soon as we get a
page fault until a cooldown period after pagefaults stop. This allows
the GMU some guaranteed time to continue working. We only use
stall-on-fault to halt the GPU while we collect a devcoredump and we
always terminate the transaction afterward, so it's fine to miss some
subsequent page faults. We also keep it disabled so long as the current
devcoredump hasn't been deleted, because in that case we likely won't
capture another one if there's a fault.
After this commit HFI messages still occasionally time out, because the
crashdump handler doesn't run fast enough to let the GMU resume, but the
driver seems to recover from it. This will probably go away after the
HFI timeout is increased.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654891/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Unused since the previous commit.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654890/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The support for dropping "_noprof" missed dropping the suffix from
exported symbols. That meant that using the :export: feature would
look for kernel-doc for (eg) krealloc_noprof() and not find the
kernel-doc for krealloc().
Fixes: 51a7bf0238 (scripts/kernel-doc: drop "_noprof" on function prototypes)
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250606141543.1285671-1-willy@infradead.org
Now that we use a threaded IRQ, it should be safe to do this in the
fault handler.
We can also remove fault_info from struct msm_gpu and just pass it
directly.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654889/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
put_unused_fd() doesn't free the installed file, if we've already done
fd_install(). So we need to also free the sync_file.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/653583/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called. Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this case.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/653584/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The dedicated helper is more verbose and effective comparing to
cpumask_first() followed by cpumask_next().
Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Ian mentioned a reliably occurred failure in the trace_btf_general test
where he obtained trace output of:
sleep/279619 clock_nanosleep(0, 0, {1,1,}, 0x7ffcd47b6450) = 0
But the regex pattern used for verification is
"^sleep/[0-9]+ clock_nanosleep\(0, 0, \{1,\}, ..."
This lead to a mismatch.
The reason is, different sleep commands use different timespec data to
call clock_nanosleep, on my machine, the value of tv_nsec is 0.
~~~
$ sudo /tmp/perf/perf trace -e clock_nanosleep -- sleep 1
0.000 (1000.196 ms): sleep/54261 clock_nanosleep(rqtp: { .tv_sec:
1, .tv_nsec: 0 }, rmtp: 0x7ffe13529550) = 0
~~~
While Ian had this trace log:
~~~
$ sudo /tmp/perf/perf trace -e clock_nanosleep -- sleep 1
0.000 (1000.208 ms): sleep/1710732 clock_nanosleep(rqtp: {
.tv_sec: 1, .tv_nsec: 1 }, rmtp: 0x7ffc091f4090) = 0
~~~
Because sleep's behavior of setting 'tv_nsec' is not certain, and tv_sec
is most definitely 1, this patch relaxes the key regex pattern to
'\{1,.*\}' for a better chance of matching.
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-7-howardchu95@gmail.com
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The event 'timer:hrtimer_setup' is relatively new, for older kernels,
perf trace enum tests won't run as the event 'timer:hrtimer_setup'
cannot be found.
It was originally called 'timer:hrtimer_init', before being renamed in:
commit 244132c4e5 ("tracing/timers: Rename the hrtimer_init event to hrtimer_setup")
Using timer:hrtimer_start should be enough for current testing, and
hopefully 'start' won't be renamed in the future.
Before:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 786187
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint timer:hrtimer_setup,timer:hrtimer_start
[tracepoint failure] Failed to trace timer:hrtimer_setup,timer:hrtimer_start tracepoint, output:
event syntax error: 'timer:hrtimer_setup,timer:hrtimer_start'
\___ unknown tracepoint
Error: File /sys/kernel/tracing//events/timer/hrtimer_setup not found.
Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
Run 'perf list' for a list of valid events
Usage: perf trace [<options>] [<command>]
or: perf trace [<options>] -- <command> [<options>]
or: perf trace record [<options>] [<command>]
or: perf trace record [<options>] -- <command> [<options>]
-e, --event <event> event/syscall selector. use 'perf list' to list available events
---- end(-1) ----
107: perf trace enum augmentation tests : FAILED!
After:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 808547
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint timer:hrtimer_start
---- end(0) ----
107: perf trace enum augmentation tests : Ok
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-4-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Currently perf test utilizes the set -e option in shell that exit
immediately if a command exits with a non-zero status, this prevents
further error handling and introduces ambiguity. This patch removes set
-e and prints the error message after invoking perf trace during perf
tests.
In my case, the command that exits with a non-zero status is perf
trace instead of grep, because it can't find the 'timer:hrtimer_setup'
tracepoint, see below.
Before:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 783533
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint syscall
---- end(-1) ----
107: perf trace enum augmentation tests : FAILED!
After:
$ sudo /tmp/perf test enum -vv
107: perf trace enum augmentation tests:
107: perf trace enum augmentation tests : Running
--- start ---
test child forked, pid 851658
Checking if vmlinux exists
Tracing syscall landlock_add_rule
Tracing non-syscall tracepoint timer:hrtimer_setup,timer:hrtimer_start
[tracepoint failure] Failed to trace tracepoint timer:hrtimer_setup,timer:hrtimer_start, output:
event syntax error: 'timer:hrtimer_setup,timer:hrtimer_start'
\___ unknown tracepoint
Error: File /sys/kernel/tracing//events/timer/hrtimer_setup not found.
Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
Run 'perf list' for a list of valid events
Usage: perf trace [<options>] [<command>]
or: perf trace [<options>] -- <command> [<options>]
or: perf trace record [<options>] [<command>]
or: perf trace record [<options>] -- <command> [<options>]
-e, --event <event> event/syscall selector. use 'perf list' to list available events---- end(-1) ----
107: perf trace enum augmentation tests : FAILED!
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-3-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
To match the style of the existing codebase, no functional changes
were applied.
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Tested-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20250528191148.89118-2-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The --map-dump option was removed in 5e6da6be30 ("perf trace: Migrate
BPF augmentation to use a skeleton"), this patch removes its remaining
documentation.
Fixes: 5e6da6be30 ("perf trace: Migrate BPF augmentation to use a skeleton")
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Link: https://lore.kernel.org/r/20250601173252.717780-1-howardchu95@gmail.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Commit 76a97cf2e1 ("perf build: Remove libbpf pre-1.0 feature
tests") removed the libbpf feature test logic used by perf in favor of
using LIBBPF_MAJOR_VERSION. Remove some build targets that should have
been removed as part of that clean up.
Fixes: 76a97cf2e1 ("perf build: Remove libbpf pre-1.0 feature tests")
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250603221358.2562167-1-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Now the target doesn't have a uid, it is handled through BPF filters,
remove the uid options to thread_map creation. Tidy up the functions
used in tests to avoid passing unused arguments.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-11-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Gathering threads with a uid by scanning /proc is inherently racy
leading to perf_event_open failures that quit perf. All users of the
functionality now use BPF filters, so remove uid and uid_str from
target.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-10-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-9-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match. Ensure adding the BPF filter forces
system-wide.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-8-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-7-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Based on the system-wide test with changes around how failure is
handled as BPF permissions are a bigger issue than perf event
paranoia.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-6-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Finding user processes by scanning /proc is inherently racy and
results in perf_event_open failures. Use a BPF filter to drop samples
where the uid doesn't match. Ensure adding the BPF filter forces
system-wide.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-5-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Add parse_uid_filter filter as a helper to parse_filter, that
constructs a uid filter string. As uid filters don't work with
tracepoint filters, add a is_possible_tp_filter function so the
tracepoint filter isn't attempted for tracepoint evsels.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-4-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Allow parse_uid to be called without a struct target. Rather than have
two errors, remove TARGET_ERRNO__USER_NOT_FOUND and use
TARGET_ERRNO__INVALID_UID as the handling is identical.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174545.2853620-3-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The BPF filter needs libbpf/BPF-skeleton support and root privilege.
Add error messages to help users understand the problem easily.
When it's not build with BPF support (make BUILD_BPF_SKEL=0).
$ sudo perf record -e cycles --filter "pid != 0" true
Error: BPF filter is requested but perf is not built with BPF.
Please make sure to build with libbpf and BPF skeleton.
Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
--filter <filter>
event filter
When it supports BPF but runs without root or CAP_BPF. Note that it
also checks pinned BPF filters.
$ perf record -e cycles --filter "pid != 0" -o /dev/null true
Error: BPF filter only works for users with the CAP_BPF capability!
Please run 'perf record --setup-filter pin' as root first.
Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
--filter <filter>
event filter
Reviewed-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250604174835.1852481-1-namhyung@kernel.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the `DEFINE_RAW_FLEX()` helper for on-stack definitions of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with these changes, fix the following warnings:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:124:52: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2067:51: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2162:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2225:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/Z_FxXjiMvG5u73fi@kspp
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add "Availability" section to Control Group v2 docs. It describes the
meaning of a controller being available in a cgroup, complementing the
existing "Enabling and Disabling" section.
This update improves the clarity of cgroup controller management by
explicitly distinguishing between:
1. Availability – when a controller is supported by the kernel and
listed in "cgroup.controllers", making its interface files accessible
in the cgroup's directory.
2. Enabling – when a controller is enabled via explicitly writing the
name of the controller to "cgroup.subtree_control" to control
distribution of resource across the cgroup's immediate children.
As an example, consider
/sys/fs/cgroup # cat cgroup.controllers
cpuset cpu io memory hugetlb pids misc
/sys/fs/cgroup # cat cgroup.subtree_control # No controllers enabled by default
/sys/fs/cgroup # echo +cpu +memory > cgroup.subtree_control # enabling "cpu" and "memory"
/sys/fs/cgroup # cat cgroup.subtree_control
cpu memory # cpu and memory enabled in /sys/fs/cgroup
/sys/fs/cgroup # mkdir foo_cgrp
/sys/fs/cgroup # cd foo_cgrp/
/sys/fs/cgroup/foo_cgrp # cat cgroup.controllers
cpu memory # cpu and memory available in 'foo_cgrp'
/sys/fs/cgroup/foo_cgrp # cat cgroup.subtree_control # empty by default
/sys/fs/cgroup/foo_cgrp # ls
cgroup.controllers cpu.max.burst memory.numa_stat
cgroup.events cpu.pressure memory.oom.group
cgroup.freeze cpu.stat memory.peak
cgroup.kill cpu.stat.local memory.pressure
cgroup.max.depth cpu.weight memory.reclaim
cgroup.max.descendants cpu.weight.nice memory.stat
cgroup.pressure io.pressure memory.swap.current
cgroup.procs memory.current memory.swap.events
cgroup.stat memory.events memory.swap.high
cgroup.subtree_control memory.events.local memory.swap.max
cgroup.threads memory.high memory.swap.peak
cgroup.type memory.low memory.zswap.current
cpu.idle memory.max memory.zswap.max
cpu.max memory.min memory.zswap.writeback
In this example, "cpu" and "memory" are enabled in the root cgroup,
making them available in "foo_cgrp". This exposes the corresponding
interface files in "foo_cgrp/", allowing resource control of processes
in that cgroup. However, these controllers are not yet enabled in
"foo_cgrp" itself.
Once a controller is available in a cgroup it can be used to resource
control processes of the cgroup.
Acked-by: Michal Koutný <mkoutny@suse.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Merge series from Félix Piédallu <felix.piedallu@non.se.com>:
These patches fix the behaviour of the SPI Chip Select of the OMAP2 MCSPI
driver used on TI SoCs.
The omap2-mcspi driver supports the use of multi mode (multichannel in TI
documentation). In this mode, the CS is asserted and deasserted by the
hardware.
The multi mode is disabled for messages when cs_change=0 for all transfers
(e.g when CS is kept asserted between transfers of a same message).
The multi mode also needs to be disabled for messages when cs_change=1 on the
last transfer (e.g when CS is kept asserted after the WHOLE message), and the
message right after.
Currently, that is not the case and it CS is deasserted by hardware when it
shouldn't.
This breaks peripheral drivers that send multiple messages with the CS asserted
in between.
Patch 1 ensures that multi mode is disabled when cs_change=1 on the last
transfer of the message.
Patch 2 ensures that multi mode is disable on a message following one with
cs_change=1 on the last transfer.
This is the case for the TPM TIS SPI driver that uses this logic for flow
control purposes.
Tested on an AM6442 platform with a TPM ST33HTPH2X32AHE4.
Merge series from James Clark <james.clark@linaro.org>:
DT and driver changes for DSPI on S32G platforms. First 3 commits are
fixes for various edge cases which also apply to other platforms.
Remaining commits add new S32G registers and device settings, some S32G
specific fixes and then finally add the DT compatibles and binding docs.
Tested in both host and target mode on S32G-VNP-RDB3 by transferring to
an external device over spi1 using spidev_test.c
Raspberry Pi RP1 is a southbridge PCIe device which embeds several
peripherals.
Add a new section to cover the main RP1 driver, DTS and specific
subperipherals (such as clock and pinconf/pinmux/gpio controller).
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Link: https://lore.kernel.org/r/20250529135052.28398-13-andrea.porta@suse.com
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
bcm-nsp.dtsi has #pwm-cells = <3> as is specified in the binding. So to
also use that correct value for bcm958625-meraki-mx6x the property
overriding that value just has to be dropped. This fixes a few warnings
like:
arch/arm/boot/dts/broadcom/bcm958625-meraki-mx65.dtb: pwm@31000: #pwm-cells: 3 was expected
from schema $id: http://devicetree.org/schemas/pwm/brcm,iproc-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250527181320.373572-2-u.kleine-koenig@baylibre.com
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.
Add the watchdog, GPIO, RNG, LED and DMA blocks for the
BCM63178 based on the vendor files 63178_map_part.h and
63178_intr.h from the "bcmopen-consumer" code drop.
This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-8-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.
Add the GPIO, RNG and LED and DMA blocks for the
BCM63148 based on the vendor files 63148_map_part.h and
63148_intr.h from the "bcmopen-consumer" code drop.
This SoC has up to 160 possible GPIOs due to having 5
registers with 32 GPIOs in each available.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-7-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.
Extend the peripheral interrupt window to 0x10000 as it need
to fit the DMA block.
Add the GPIO, RNG and LED and DMA blocks for the
BCM63138 based on the vendor files 63138_map_part.h and
63138_intr.h from the "bcmopen-consumer" code drop.
This SoC has up to 160 possible GPIOs due to having 5
registers with 32 GPIOs in each available.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-6-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.
Add the first and second watchdog, GPIO, RNG, LED and
DMA blocks for the BCM6878 based on the vendor files
6878_map_part.h and 6878_intr.h from the "bcmopen-consumer"
code drop.
This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-5-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.
Add the first and second watchdog, GPIO, RNG, LED, DMA and
second PL011 UART blocks for the BCM6855 based on the vendor
files 6855_map_part.h and 6855_intr.h from the
"bcmopen-consumer" code drop.
This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-4-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
