summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-07-09udp: Remove duplicate included header file trace/events/udp.hThorsten Blum
Remove duplicate included header file trace/events/udp.h and the following warning reported by make includecheck: trace/events/udp.h is included more than once Compile-tested only. Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240706071132.274352-2-thorsten.blum@toblux.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-07-09net: tn40xx: add per queue netdev-genl stats supportFUJITA Tomonori
Add support for the netdev-genl per queue stats API. ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \ --dump qstats-get --json '{"scope":"queue"}' [{'ifindex': 4, 'queue-id': 0, 'queue-type': 'rx', 'rx-alloc-fail': 0, 'rx-bytes': 266613, 'rx-packets': 3325}, {'ifindex': 4, 'queue-id': 0, 'queue-type': 'tx', 'tx-bytes': 142823367, 'tx-packets': 2387}] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20240706064324.137574-1-fujita.tomonori@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-07-09perf/x86/intel: Add a distinct name for Granite RapidsKan Liang
Currently, the Sapphire Rapids and Granite Rapids share the same PMU name, sapphire_rapids. Because from the kernel’s perspective, GNR is similar to SPR. The only key difference is that they support different extra MSRs. The code path and the PMU name are shared. However, from end users' perspective, they are quite different. Besides the extra MSRs, GNR has a newer PEBS format, supports Retire Latency, supports new CPUID enumeration architecture, doesn't required the load-latency AUX event, has additional TMA Level 1 Architectural Events, etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES MSR. They weren't reflected in the model-specific kernel setup. But it is worth to have a distinct PMU name for GNR. Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL") Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240708193336.1192217-3-kan.liang@linux.intel.com
2024-07-09perf/x86/intel/ds: Fix non 0 retire latency on RaptorlakeKan Liang
A non-0 retire latency can be observed on a Raptorlake which doesn't support the retire latency feature. By design, the retire latency shares the PERF_SAMPLE_WEIGHT_STRUCT sample type with other types of latency. That could avoid adding too many different sample types to support all kinds of latency. For the machine which doesn't support some kind of latency, 0 should be returned. Perf doesn’t clear/init all the fields of a sample data for the sake of performance. It expects the later perf_{prepare,output}_sample() to update the uninitialized field. However, the current implementation doesn't touch the field of the retire latency if the feature is not supported. The memory garbage is dumped into the perf data. Clear the retire latency if the feature is not supported. Fixes: c87a31093c70 ("perf/x86: Support Retire Latency") Reported-by: "Bayduraev, Alexey V" <alexey.v.bayduraev@intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: "Bayduraev, Alexey V" <alexey.v.bayduraev@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240708193336.1192217-4-kan.liang@linux.intel.com
2024-07-09perf/x86/intel: Hide Topdown metrics events if the feature is not enumeratedKan Liang
The below error is observed on Ice Lake VM. $ perf stat Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (slots). /bin/dmesg | grep -i perf may provide additional information. In a virtualization env, the Topdown metrics and the slots event haven't been supported yet. The guest CPUID doesn't enumerate them. However, the current kernel unconditionally exposes the slots event and the Topdown metrics events to sysfs, which misleads the perf tool and triggers the error. Hide the perf-metrics topdown events and the slots event if the perf-metrics feature is not enumerated. The big core of a hybrid platform can also supports the perf-metrics feature. Fix the hybrid platform as well. Closes: https://lore.kernel.org/lkml/CAM9d7cj8z+ryyzUHR+P1Dcpot2jjW+Qcc4CPQpfafTXN=LEU0Q@mail.gmail.com/ Reported-by: Dongli Zhang <dongli.zhang@oracle.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Dongli Zhang <dongli.zhang@oracle.com> Link: https://lkml.kernel.org/r/20240708193336.1192217-2-kan.liang@linux.intel.com
2024-07-09perf/x86/intel/uncore: Fix the bits of the CHA extended umask for SPRKan Liang
The perf stat errors out with UNC_CHA_TOR_INSERTS.IA_HIT_CXL_ACC_LOCAL event. $perf stat -e uncore_cha_55/event=0x35,umask=0x10c0008101/ -a -- ls event syntax error: '..0x35,umask=0x10c0008101/' \___ Bad event or PMU The definition of the CHA umask is config:8-15,32-55, which is 32bit. However, the umask of the event is bigger than 32bit. This is an error in the original uncore spec. Add a new umask_ext5 for the new CHA umask range. Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support") Closes: https://lore.kernel.org/linux-perf-users/alpine.LRH.2.20.2401300733310.11354@Diego/ Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ian Rogers <irogers@google.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240708185524.1185505-1-kan.liang@linux.intel.com
2024-07-09perf: Split __perf_pending_irq() out of perf_pending_irq()Sebastian Andrzej Siewior
perf_pending_irq() invokes perf_event_wakeup() and __perf_pending_irq(). The former is in charge of waking any tasks which waits to be woken up while the latter disables perf-events. The irq_work perf_pending_irq(), while this an irq_work, the callback is invoked in thread context on PREEMPT_RT. This is needed because all the waking functions (wake_up_all(), kill_fasync()) acquire sleep locks which must not be used with disabled interrupts. Disabling events, as done by __perf_pending_irq(), expects a hardirq context and disabled interrupts. This requirement is not fulfilled on PREEMPT_RT. Split functionality based on perf_event::pending_disable into irq_work named `pending_disable_irq' and invoke it in hardirq context on PREEMPT_RT. Rename the split out callback to perf_pending_disable(). Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marco Elver <elver@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Link: https://lore.kernel.org/r/20240704170424.1466941-8-bigeasy@linutronix.de
2024-07-09perf: Don't disable preemption in perf_pending_task().Sebastian Andrzej Siewior
perf_pending_task() is invoked in task context and disables preemption because perf_swevent_get_recursion_context() used to access per-CPU variables. The other reason is to create a RCU read section while accessing the perf_event. The recursion counter is no longer a per-CPU accounter so disabling preemption is no longer required. The RCU section is needed and must be created explicit. Replace the preemption-disable section with a explicit RCU-read section. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20240704170424.1466941-7-bigeasy@linutronix.de
2024-07-09perf: Move swevent_htable::recursion into task_struct.Sebastian Andrzej Siewior
The swevent_htable::recursion counter is used to avoid creating an swevent while an event is processed to avoid recursion. The counter is per-CPU and preemption must be disabled to have a stable counter. perf_pending_task() disables preemption to access the counter and then signal. This is problematic on PREEMPT_RT because sending a signal uses a spinlock_t which must not be acquired in atomic on PREEMPT_RT because it becomes a sleeping lock. The atomic context can be avoided by moving the counter into the task_struct. There is a 4 byte hole between futex_state (usually always on) and the following perf pointer (perf_event_ctxp). After the recursion lost some weight it fits perfectly. Move swevent_htable::recursion into task_struct. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20240704170424.1466941-6-bigeasy@linutronix.de
2024-07-09perf: Shrink the size of the recursion counter.Sebastian Andrzej Siewior
There are four recursion counter, one for each context. The type of the counter is `int' but the counter is used as `bool' since it is only incremented if zero. The main goal here is to shrink the whole struct into 32bit int which can later be added task_struct into an existing hole. Reduce the type of the recursion counter to an unsigned char, keep the increment/ decrement operation. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20240704170424.1466941-5-bigeasy@linutronix.de
2024-07-09perf: Enqueue SIGTRAP always via task_work.Sebastian Andrzej Siewior
A signal is delivered by raising irq_work() which works from any context including NMI. irq_work() can be delayed if the architecture does not provide an interrupt vector. In order not to lose a signal, the signal is injected via task_work during event_sched_out(). Instead going via irq_work, the signal could be added directly via task_work. The signal is sent to current and can be enqueued on its return path to userland. Queue signal via task_work and consider possible NMI context. Remove perf_event::pending_sigtrap and and use perf_event::pending_work instead. Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marco Elver <elver@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Link: https://lore.kernel.org/r/20240704170424.1466941-4-bigeasy@linutronix.de
2024-07-09task_work: Add TWA_NMI_CURRENT as an additional notify mode.Sebastian Andrzej Siewior
Adding task_work from NMI context requires the following: - The kasan_record_aux_stack() is not NMU safe and must be avoided. - Using TWA_RESUME is NMI safe. If the NMI occurs while the CPU is in userland then it will continue in userland and not invoke the `work' callback. Add TWA_NMI_CURRENT as an additional notify mode. In this mode skip kasan and use irq_work in hardirq-mode to for needed interrupt. Set TIF_NOTIFY_RESUME within the irq_work callback due to k[ac]san instrumentation in test_and_set_bit() which does not look NMI safe in case of a report. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240704170424.1466941-3-bigeasy@linutronix.de
2024-07-09perf: Move irq_work_queue() where the event is prepared.Sebastian Andrzej Siewior
Only if perf_event::pending_sigtrap is zero, the irq_work accounted by increminging perf_event::nr_pending. The member perf_event::pending_addr might be overwritten by a subsequent event if the signal was not yet delivered and is expected. The irq_work will not be enqeueued again because it has a check to be only enqueued once. Move irq_work_queue() to where the counter is incremented and perf_event::pending_sigtrap is set to make it more obvious that the irq_work is scheduled once. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marco Elver <elver@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Link: https://lore.kernel.org/r/20240704170424.1466941-2-bigeasy@linutronix.de
2024-07-09perf: Fix event leak upon exec and file releaseFrederic Weisbecker
The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> <NMI> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= </NMI> perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> <IRQ> perf_pending_irq() //do nothing, rely on pending task work <======= </IRQ> begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release(). Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed. Fixes: 517e6a301f34 ("perf: Fix perf_pending_task() UaF") Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-5-frederic@kernel.org
2024-07-09perf: Fix event leak upon exitFrederic Weisbecker
When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario: TASK A ----- do_exit() exit_task_work(tsk); <IRQ> perf_event_overflow() event->pending_sigtrap = pending_id; irq_work_queue(&event->pending_irq); </IRQ> =========> PREEMPTION: TASK A -> TASK B event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FAILS: task work has exited task_work_add(&event->pending_task) [...] <IRQ WORK> perf_pending_irq() // early return: event->oncpu = -1 </IRQ WORK> [...] =========> TASK B -> TASK A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2 As a result the event is never released while the task exits. Fix this with appropriate task_work_add()'s error handling. Fixes: 517e6a301f34 ("perf: Fix perf_pending_task() UaF") Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-4-frederic@kernel.org
2024-07-09task_work: Introduce task_work_cancel() againFrederic Weisbecker
Re-introduce task_work_cancel(), this time to cancel an actual callback and not *any* callback pointing to a given function. This is going to be needed for perf events event freeing. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-3-frederic@kernel.org
2024-07-09task_work: s/task_work_cancel()/task_work_cancel_func()/Frederic Weisbecker
A proper task_work_cancel() API that actually cancels a callback and not *any* callback pointing to a given function is going to be needed for perf events event freeing. Do the appropriate rename to prepare for that. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-2-frederic@kernel.org
2024-07-09locking/rwsem: Add __always_inline annotation to __down_write_common() and ↵John Stultz
inlined callers Apparently despite it being marked inline, the compiler may not inline __down_write_common() which makes it difficult to identify the cause of lock contention, as the wchan of the blocked function will always be listed as __down_write_common(). So add __always_inline annotation to the common function (as well as the inlined helper callers) to force it to be inlined so a more useful blocking function will be listed (via wchan). This mirrors commit 92cc5d00a431 ("locking/rwsem: Add __always_inline annotation to __down_read_common() and inlined callers") which did the same for __down_read_common. I sort of worry that I'm playing wack-a-mole here, and talking with compiler people, they tell me inline means nothing, which makes me want to cry a little. So I'm wondering if we need to replace all the inlines with __always_inline, or remove them because either we mean something by it, or not. Fixes: c995e638ccbb ("locking/rwsem: Fold __down_{read,write}*()") Reported-by: Tim Murray <timmurray@google.com> Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Waiman Long <longman@redhat.com> Link: https://lkml.kernel.org/r/20240709060831.495366-1-jstultz@google.com
2024-07-09dt-bindings: gpio: convert Atmel GPIO to json-schemaManikandan Muralidharan
Convert the Atmel GPIO controller binding document to DT schema format using json-schema. The at91 pinctrl driver uses "atmel,at91rm9200-gpio" compatible string to find the number of active GPIO banks and identify the pinmux nodes. "atmel,at91sam9x5-gpio" and "microchip,sam9x60-gpio" have additional registers to handle drive-strength, slew-rate, pull-down to drive the pinmux configs. The new compatible string "microchip,sam9x7-gpio" is added. Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240709092354.191643-5-manikandan.m@microchip.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-09mdomain: Merge branch fixes into nextUlf Hansson
Merge the pmdomain fixes for v6.10-rc[n] into the next branch, to allow them to get tested together with the new changes that are targeted for v6.11. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09pmdomain: amlogic: Constify struct meson_secure_pwrc_domain_descChristophe JAILLET
'struct meson_secure_pwrc_domain_desc' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 4909 4072 0 8981 2315 drivers/pmdomain/amlogic/meson-secure-pwrc.o After: ===== text data bss dec hex filename 8605 392 0 8997 2325 drivers/pmdomain/amlogic/meson-secure-pwrc.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/871d6b708de8bb42e1fabd8a601dc9a9a217cf00.1719863475.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09erofs: tidy up stream decompressorsGao Xiang
Just use a generic helper to prepare buffers for all supported stream decompressors, eliminating similar logic. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20240709094106.3018109-3-hsiangkao@linux.alibaba.com
2024-07-09erofs: refine z_erofs_{init,exit}_subsystem()Gao Xiang
Introduce z_erofs_{init,exit}_decompressor() to unexport z_erofs_{deflate,lzma,zstd}_{init,exit}(). Besides, call them in z_erofs_{init,exit}_subsystem() for simplicity. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20240709094106.3018109-2-hsiangkao@linux.alibaba.com
2024-07-09erofs: move each decompressor to its own source fileGao Xiang
Thus *_config() function declarations can be avoided. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20240709094106.3018109-1-hsiangkao@linux.alibaba.com
2024-07-09venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6Jagadeesh Kona
The Venus driver requires vcodec GDSC to be ON in SW mode for clock operations and move it back to HW mode to gain power benefits. Earlier, as there is no interface to switch the GDSC mode from GenPD framework, the GDSC is moved to HW control mode as part of GDSC enable callback and venus driver is writing to its POWER_CONTROL register to keep the GDSC ON from SW whereever required. But the POWER_CONTROL register addresses are not constant and can vary across the variants. Also as per the HW recommendation, the GDSC mode switching needs to be controlled from respective GDSC register and this is a uniform approach across all the targets. Hence use dev_pm_genpd_set_hwmode() API which controls GDSC mode switching using its respective GDSC register. In venus V6 variants, the vcodec gdsc gets enabled in SW mode by default with new HW_CTRL_TRIGGER flag and there is no need to switch it to SW mode again after enable, hence add check to avoid switching gdsc to SW mode again after gdsc enable. Similarly add check to avoid switching GDSC to HW mode before disabling the GDSC, so GDSC gets enabled in SW mode in the next enable. Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20240624044809.17751-6-quic_jkona@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09clk: qcom: videocc: Use HW_CTRL_TRIGGER for SM8250, SC7280 vcodec GDSC'sJagadeesh Kona
For Venus V6 variant SoCs(sm8250, sc7280), the venus driver uses the newly introduced dev_pm_genpd_set_hwmode() API to switch the vcodec GDSC to HW/SW control modes at runtime. Hence use HW_CTRL_TRIGGER flag for vcodec GDSC's on sm8250, sc7280 to register the set_hwmode_dev & get_hwmode_dev callbacks for vcodec GDSC and allow the GDSC mode to be changed using dev_pm_genpd_set_hwmode() API. Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Acked-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20240624044809.17751-5-quic_jkona@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC modeJagadeesh Kona
Some GDSC client drivers require the GDSC mode to be switched dynamically to HW mode at runtime to gain the power benefits. Typically such client drivers require the GDSC to be brought up in SW mode initially to enable the required dependent clocks and configure the hardware to proper state. Once initial hardware set up is done, they switch the GDSC to HW mode to save power. At the end of usecase, they switch the GDSC back to SW mode and disable the GDSC. Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and get_hwmode_dev callbacks for GDSC's whose respective client drivers require the GDSC mode to be switched dynamically at runtime using dev_pm_genpd_set_hwmode() API. Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20240624044809.17751-4-quic_jkona@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09PM: domains: Add the domain HW-managed mode to the summaryAbel Vesa
Now that genpd supports dynamically switching the control for an attached device between hardware- and software-mode, let's add this information to the genpd summary under managed by column in debugfs. Suggested-by: Taniya Das <quic_tdas@quicinc.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20240624044809.17751-3-quic_jkona@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09PM: domains: Allow devices attached to genpd to be managed by HWUlf Hansson
Some power-domains may be capable of relying on the HW to control the power for a device that's hooked up to it. Typically, for these kinds of configurations the consumer driver should be able to change the behavior of power domain at runtime, control the power domain in SW mode for certain configurations and handover the control to HW mode for other usecases. To allow a consumer driver to change the behaviour of the PM domain for its device, let's provide a new function, dev_pm_genpd_set_hwmode(). Moreover, let's add a corresponding optional genpd callback, ->set_hwmode_dev(), which the genpd provider should implement if it can support switching between HW controlled mode and SW controlled mode. Similarly, add the dev_pm_genpd_get_hwmode() to allow consumers to read the current mode and its corresponding optional genpd callback, ->get_hwmode_dev(), which the genpd provider can also implement to synchronize the initial HW mode state in genpd_add_device() by reading back the mode from the hardware. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20240624044809.17751-2-quic_jkona@quicinc.com
2024-07-09pmdomain: amlogic: Add support for A5 power domains controllerXianwei Zhao
Add support for the A5 power controller, whose registers are in the secure domain and should be accessed via SMC. Signed-off-by: Hongyu Chen <hongyu.chen1@amlogic.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240627-a5_secpower-v1-2-1f47dde1270c@amlogic.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09pmdomain: Merge branch dt into nextUlf Hansson
Merge the immutable branch dt into next, to allow the DT bindings to be tested together with changes that are targeted for v6.11. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09dt-bindings: power: add Amlogic A5 power domainsXianwei Zhao
Add devicetree binding document and related header file for Amlogic A5 secure power domains. Signed-off-by: Hongyu Chen <hongyu.chen1@amlogic.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240627-a5_secpower-v1-1-1f47dde1270c@amlogic.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09octeontx2-af: Fix incorrect value output on error path in ↵Aleksandr Mishin
rvu_check_rsrc_availability() In rvu_check_rsrc_availability() in case of invalid SSOW req, an incorrect data is printed to error log. 'req->sso' value is printed instead of 'req->ssow'. Looks like "copy-paste" mistake. Fix this mistake by replacing 'req->sso' with 'req->ssow'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 746ea74241fa ("octeontx2-af: Add RVU block LF provisioning support") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240705095317.12640-1-amishin@t-argos.ru Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-07-09pmdomain: qcom: rpmhpd: Skip retention level for Power DomainsTaniya Das
In the cases where the power domain connected to logics is allowed to transition from a level(L)-->power collapse(0)-->retention(1) or vice versa retention(1)-->power collapse(0)-->level(L) will cause the logic to lose the configurations. The ARC does not support retention to collapse transition on MxC rails. The targets from SM8450 onwards the PLL logics of clock controllers are connected to MxC rails and the recommended configurations are carried out during the clock controller probes. The MxC transition as mentioned above should be skipped to ensure the PLL settings are intact across clock controller power on & off. On older targets that do not split MX into MxA and MxC does not collapse the logic and it is parked always at RETENTION, thus this issue is never observed on those targets. Cc: stable@vger.kernel.org # v5.17 Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-07-09Merge tag 'rtw-next-2024-07-05' of https://github.com/pkshih/rtwKalle Valo
rtw-next patches for v6.11 Some cleanups of rtl8xxxu and rtlwifi, and some fixes of rtw88. The major change is to develop WoWLAN and preparation of RTL8852BE-VT listed below: rtw89: - preparation of RTL8852BE-VT * add RF calibration code * move shared code with RTL8852BE to common module - add WoWLAN for WiFi 6 chips - support 36-bit PCI DMA
2024-07-09wifi: ipw2x00: Use kzalloc() instead of kmalloc()/memset()Chen Ni
Replace kmalloc() + memset() to kzalloc() for better code readability and simplicity. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240704090622.2260102-1-nichen@iscas.ac.cn
2024-07-09wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()Sascha Hauer
mwifiex_get_priv_by_id() returns the priv pointer corresponding to the bss_num and bss_type, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bss_mode set to something else than NL80211_IFTYPE_UNSPECIFIED. Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config: network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" } When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | process_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | process_one_work+0x148/0x2a0 | worker_thread+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]--- Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240703072409.556618-1-s.hauer@pengutronix.de
2024-07-09ALSA: hda/realtek: Enable Mute LED on HP 250 G7Nazar Bilinskyi
HP 250 G7 has a mute LED that can be made to work using quirk ALC269_FIXUP_HP_LINE1_MIC1_LED. Enable already existing quirk. Signed-off-by: Nazar Bilinskyi <nbilinskyi@gmail.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20240709080546.18344-1-nbilinskyi@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-07-09wifi: mac80211_hwsim: add support for multi-radio wiphyFelix Fietkau
This registers one wiphy radio per supported band. Number of different channels is set per radio. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/3a16838bb7a7d1a072bd7c9d586d17f70fcd8a60.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: add wiphy radio assignment and validationFelix Fietkau
Validate number of channels and interface combinations per radio. Assign each channel context to a radio. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/1d3e9ba70a30ce18aaff337f0a76d7aeb311bafb.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: move code in ieee80211_link_reserve_chanctx to a helperFelix Fietkau
Reduces indentation in preparation for further changes Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/cce95007092336254d51570f4a27e05a6f150a53.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: extend ifcomb check functions for multi-radioFelix Fietkau
Add support for counting global and per-radio max/current number of channels, as well as checking radio-specific interface combinations. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/e76307f8ce562a91a74faab274ae01f6a5ba0a2e.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: add radio index to ieee80211_chanctx_confFelix Fietkau
Will be used to explicitly assign a channel context to a wiphy radio. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/59f76f57d935f155099276be22badfa671d5bfd9.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: add support for DFS with multiple radiosFelix Fietkau
DFS can be supported with multi-channel combinations, as long as each DFS capable radio only supports one channel. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/4d27a4adca99fa832af1f7cda4f2e71016bd9fda.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: cfg80211: add helper for checking if a chandef is valid on a radioFelix Fietkau
Check if the full channel width is in the radio's frequency range. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/7c8ea146feb6f37cee62e5ba6be5370403695797.1720514221.git-series.nbd@nbd.name [add missing Return: documentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09bnxt: fix crashes when reducing ring count with active RSS contextsJakub Kicinski
bnxt doesn't check if a ring is used by RSS contexts when reducing ring count. Core performs a similar check for the drivers for the main context, but core doesn't know about additional contexts, so it can't validate them. bnxt_fill_hw_rss_tbl_p5() uses ring id to index bp->rx_ring[], which without the check may end up being out of bounds. BUG: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40 Read of size 2 at addr ffff8881c5809618 by task ethtool/31525 Call Trace: __bnxt_hwrm_vnic_set_rss+0xb79/0xe40 bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460 __bnxt_setup_vnic_p5+0x12e/0x270 __bnxt_open_nic+0x2262/0x2f30 bnxt_open_nic+0x5d/0xf0 ethnl_set_channels+0x5d4/0xb30 ethnl_default_set_doit+0x2f1/0x620 Core does track the additional contexts in net-next, so we can move this validation out of the driver as a follow up there. Fixes: b3d0083caf9a ("bnxt_en: Support RSS contexts in ethtool .{get|set}_rxfh()") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20240705020005.681746-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-07-09sctp: Fix typos and improve commentsThorsten Blum
Fix typos s/steam/stream/ and spell out Schedule/Unschedule in the comments. Compile-tested only. Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240704202558.62704-2-thorsten.blum@toblux.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-07-09wifi: cfg80211: extend interface combination check for multi-radioFelix Fietkau
Add a field in struct iface_combination_params to check per-radio interface combinations instead of per-wiphy ones. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/32b28da89c2d759b0324deeefe2be4cee91de18e.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: cfg80211: add support for advertising multiple radios belonging to a wiphyFelix Fietkau
The prerequisite for MLO support in cfg80211/mac80211 is that all the links participating in MLO must be from the same wiphy/ieee80211_hw. To meet this expectation, some drivers may need to group multiple discrete hardware each acting as a link in MLO under single wiphy. With this change, supported frequencies and interface combinations of each individual radio are reported to user space. This allows user space to figure out the limitations of what combination of channels can be used concurrently. Even for non-MLO devices, this improves support for devices capable of running on multiple channels at the same time. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/18a88f9ce82b1c9f7c12f1672430eaf2bb0be295.1720514221.git-series.nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-09wifi: mac80211: chanctx emulation set CHANGE_CHANNEL when in_reconfigZong-Zhe Yang
Chanctx emulation didn't info IEEE80211_CONF_CHANGE_CHANNEL to drivers during ieee80211_restart_hw (ieee80211_emulate_add_chanctx). It caused non-chanctx drivers to not stand on the correct channel after recovery. RX then behaved abnormally. Finally, disconnection/reconnection occurred. So, set IEEE80211_CONF_CHANGE_CHANNEL when in_reconfig. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Link: https://patch.msgid.link/20240709073531.30565-1-kevin_yang@realtek.com Cc: stable@vger.kernel.org Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.34.1) at 2025-09-22 00:37:44 +0000