A patch from a few days ago fixed the division issue on 32-bit machines,
but it introduced a coding style problem.
WARNING: Missing a blank line after declarations
+ u32 rem;
+ div_u64_rem(off >> PCACHE_CACHE_SUBTREE_SIZE_SHIFT,
cache->n_ksets, &rem);
total: 0 errors, 1 warnings, 634 lines checked
Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
The smatch checker reports a “scheduler in atomic context” problem in
the following call chain:
miss_read_end_req()
-> cache_seg_put()
-> cache_seg_invalidate()
-> cache_seg_gen_increase()
-> mutex_lock(&cache_seg->ctrl_lock);
In practice, this `mutex_lock` will not actually schedule, because it is
only called when `cache_seg_put()` drops the last reference, which is
single-threaded. That is also why the issue never shows up during real
testing.
However, the code is still buggy. The original purpose of `ctrl_lock`
was to prevent read/write conflicts on the cache segment control
information. Looking at the current usage, all control information
accesses are single-threaded: reads only occur during the init phase,
where no conflicts are possible, and writes happen once in the init
phase (also single-threaded) and once when `cache_seg_put()` drops the
last reference (again single-threaded).
Therefore, this patch removes `ctrl_lock` entirely and adds comments in
the appropriate places to document this logic.
Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Now that Secure AVIC support is complete, make it part of to the SNP present
features.
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828113225.209174-1-Neeraj.Upadhyay@amd.com
The SECURE_AVIC_CONTROL MSR holds the GPA of the guest APIC backing page and
bitfields to control enablement of Secure AVIC and whether the guest allows
NMIs to be injected by the hypervisor.
This MSR is populated by the guest and can be read by the guest to get the GPA
of the APIC backing page. The MSR can only be accessed in Secure AVIC mode.
Any attempt to access it when not in Secure AVIC mode results in #GP. So, the
hypervisor should not intercept it. A #VC exception will be generated
otherwise. If this occurs and Secure AVIC is enabled, terminate the guest
execution.
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828113119.209135-1-Neeraj.Upadhyay@amd.com
With all the pieces in place now, enable Secure AVIC in the Secure AVIC
Control MSR. Any access to x2APIC MSRs are emulated by the hypervisor
before Secure AVIC is enabled in the control MSR. Post Secure AVIC
enablement, all x2APIC MSR accesses (whether accelerated by AVIC
hardware or trapped as a #VC exception) operate on the vCPU's APIC
backing page.
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828112126.209028-1-Neeraj.Upadhyay@amd.com
Commit 05f254a636 ("ALSA: usb-audio:
Improve filtering of sample rates on Focusrite devices") changed the
check for max_rate in a way which was overly restrictive, forcing
devices to use very high samplerates if they support them, despite
support existing for lower rates as well.
This maintains the intended outcome (ensuring samplerates selected are
supported) while allowing devices with higher maximum samplerates to be
opened at all supported samplerates.
This patch was tested with a Clarett+ 8Pre USB
Fixes: 05f254a636 ("ALSA: usb-audio: Improve filtering of sample rates on Focusrite devices")
Signed-off-by: Tina Wuest <tina@wuest.me>
Link: https://patch.msgid.link/20250901092024.140993-1-tina@wuest.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Several RISC-V boards feature Imagination GPUs that are compatible with
the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi
4A board. This commit adjusts the driver's Kconfig dependencies to allow
the PowerVR driver to be compiled on the RISC-V architecture.
By enabling compilation on RISC-V, we expand support for these GPUs,
providing graphics acceleration capabilities and enhancing hardware
compatibility on RISC-V platforms.
The RISC-V support is restricted to 64-bit systems (RISCV && 64BIT) as
the driver currently has an implicit dependency on a 64-bit platform.
Add a dependency on MMU to fix a build warning on RISC-V configurations
without an MMU.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Matt Coster <matt.coster@imgtec.com>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-4-af656f7cc6c3@samsung.com
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Rework the PowerVR Rogue GPU binding to use an explicit, per variant
style for defining power domain properties and add support for the
T-HEAD TH1520 SoC's GPU.
To improve clarity and precision, the binding is refactored so that
power domain items are listed explicitly for each variant [1]. The
previous method relied on an implicit, positional mapping between the
`power-domains` and `power-domain-names` properties. This change
replaces the generic rules with self contained if/then blocks for each
GPU variant, making the relationship between power domains and their
names explicit and unambiguous.
The generic if block for img,img-rogue, which previously required
power-domains and power-domain-names for all variants, is removed.
Instead, each specific GPU variant now defines its own power domain
requirements within a self-contained if/then block, making the schema
more explicit.
This new structure is then used to add support for the
`thead,th1520-gpu`. While its BXM-4-64 IP has two conceptual power
domains, the TH1520 SoC integrates them behind a single power gate. The
new binding models this with a specific rule that enforces a single
`power-domains` entry and disallows the `power-domain-names` property.
Link: https://lore.kernel.org/all/4d79c8dd-c5fb-442c-ac65-37e7176b0cdd@linaro.org/ [1]
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-2-af656f7cc6c3@samsung.com
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Update the Imagination PVR DRM driver to leverage the pwrseq framework
for managing the complex power sequence of the GPU on the T-HEAD TH1520
SoC.
To cleanly separate platform-specific logic from the generic driver,
this patch introduces an `init` callback to the `pwr_power_sequence_ops`
struct. This allows for different power management strategies to be
selected at probe time based on the device's compatible string.
A `pvr_device_data` struct, associated with each compatible in the
of_device_id table, points to the appropriate ops table (manual or
pwrseq).
At probe time, the driver now calls the `->init()` op. For pwrseq-based
platforms, this callback calls `devm_pwrseq_get("gpu-power")`, deferring
probe if the sequencer is not yet available. For other platforms, it
falls back to the existing manual clock and reset handling. The runtime
PM callbacks continue to call the appropriate functions via the ops
table.
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Matt Coster <matt.coster@imgtec.com>
Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-1-af656f7cc6c3@samsung.com
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
vfs_ioctl() is no longer called by anything outside of fs/ioctl.c, so
remove the global symbol and export as it is not needed.
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/2025083038-carving-amuck-a4ae@gregkh
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Add a apic->teardown() callback to disable Secure AVIC before rebooting into
the new kernel. This ensures that the new kernel does not access the old APIC
backing page which was allocated by the previous kernel.
Such accesses can happen if there are any APIC accesses done during the guest
boot before Secure AVIC driver probe is done by the new kernel (as Secure AVIC
would have remained enabled in the Secure AVIC control MSR).
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250828112008.209013-1-Neeraj.Upadhyay@amd.com
Secure AVIC accelerates the guest's EOI MSR writes for edge-triggered
interrupts.
For level-triggered interrupts, EOI MSR writes trigger a #VC exception with
an SVM_EXIT_AVIC_UNACCELERATED_ACCESS error code. To complete EOI handling,
the #VC exception handler would need to trigger a GHCB protocol MSR write
event to notify the hypervisor about completion of the level-triggered
interrupt. Hypervisor notification is required for cases like emulated
IO-APIC, to complete and clear interrupt in the IO-APIC's interrupt state.
However, #VC exception handling adds extra performance overhead for APIC
register writes. In addition, for Secure AVIC, some unaccelerated APIC
register MSR writes are trapped, whereas others are faulted.
This results in additional complexity in #VC exception handling for
unaccelerated APIC MSR accesses. So, directly do a GHCB protocol based APIC
EOI MSR write from apic->eoi() callback for level-triggered interrupts.
Use WRMSR for edge-triggered interrupts, so that hardware re-evaluates any
pending interrupt which can be delivered to the guest vCPU. For
level-triggered interrupts, re-evaluation happens on return from VMGEXIT
corresponding to the GHCB event for APIC EOI MSR write.
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828111654.208987-1-Neeraj.Upadhyay@amd.com
The Hypervisor needs information about the current state of the LVT registers
for device emulation and NMIs. So, forward reads and write of these registers
to the hypervisor for Secure AVIC enabled guests.
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828111356.208972-1-Neeraj.Upadhyay@amd.com
Now that support to send NMI IPI and support to inject NMI from the hypervisor
has been added, set V_NMI_ENABLE in the VINTR_CTRL field of the VMSA to enable
NMI for Secure AVIC guests.
[ bp: Zap useless brackets. ]
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828111315.208959-1-Neeraj.Upadhyay@amd.com
Secure AVIC requires the "AllowedNmi" bit in the Secure AVIC Control MSR to be
set for an NMI to be injected from the hypervisor. So set it.
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828111243.208946-1-Neeraj.Upadhyay@amd.com
Secure AVIC introduces a new field in the APIC backing page "NmiReq" that has
to be set by the guest to request a NMI IPI through APIC_ICR write.
Add support to set NmiReq appropriately to send NMI IPI.
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828111213.208933-1-Neeraj.Upadhyay@amd.com
Virtual GIF (VGIF) provides masking capability for when virtual interrupts
(virtual maskable interrupts, virtual NMIs) can be taken by the guest vCPU.
The Secure AVIC hardware reads VGIF state from the vCPU's VMSA. So, set VGIF for
secondary CPUs (the configuration for the boot CPU is done by the hypervisor),
to unmask delivery of virtual interrupts to the vCPU.
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828111141.208920-1-Neeraj.Upadhyay@amd.com
Secure AVIC requires the LAPIC timer to be emulated by the hypervisor. KVM
already supports emulating the LAPIC timer using hrtimers. In order to emulate
it, APIC_LVTT, APIC_TMICT and APIC_TDCR register values need to be propagated
to the hypervisor for arming the timer. APIC_TMCCT register value has to be
read from the hypervisor, which is required for calibrating the APIC timer.
So, read/write all APIC timer registers from/to the hypervisor.
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828110926.208866-1-Neeraj.Upadhyay@amd.com
Secure AVIC hardware accelerates only Self-IPI, i.e. on WRMSR to APIC_SELF_IPI
and APIC_ICR (with destination shorthand equal to Self) registers, hardware
takes care of updating the APIC_IRR in the APIC backing page of the vCPU.
For other IPI types (cross-vCPU, broadcast IPIs), software needs to take care
of updating the APIC_IRR state of the target vCPUs and to ensure that the
target vCPUs notice the new pending interrupt.
Add new callbacks in the Secure AVIC driver for sending IPI requests. These
callbacks update the IRR in the target guest vCPU's APIC backing page. To
ensure that the remote vCPU notices the new pending interrupt, reuse the GHCB
MSR handling code in vc_handle_msr() to issue APIC_ICR MSR-write GHCB protocol
event to the hypervisor.
For Secure AVIC guests, on APIC_ICR write MSR exits, the hypervisor notifies
the target vCPU by either sending an AVIC doorbell (if target vCPU is running)
or by waking up the non-running target vCPU.
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828110824.208851-1-Neeraj.Upadhyay@amd.com
Add an update_vector() callback to set/clear the ALLOWED_IRR field in a vCPU's
APIC backing page for vectors which are emulated by the hypervisor.
The ALLOWED_IRR field indicates the interrupt vectors which the guest allows
the hypervisor to inject (typically for emulated devices). Interrupt vectors
used exclusively by the guest itself and the vectors which are not emulated by
the hypervisor, such as IPI vectors, should not be set by the guest in the
ALLOWED_IRR fields.
As clearing/setting state of a vector will also be used in subsequent commits
for other APIC registers (such as APIC_IRR update for sending IPI), add
a common update_vector() in the Secure AVIC driver.
[ bp: Massage commit message. ]
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828110255.208779-4-Neeraj.Upadhyay@amd.com
Currently, if we are the last iput, and we have the I_DIRTY_TIME bit
set, we will grab a reference on the inode again and then mark it dirty
and then redo the put. This is to make sure we delay the time update
for as long as possible.
We can rework this logic to simply dec i_count if it is not 1, and if it
is do the time update while still holding the i_count reference.
Then we can replace the atomic_dec_and_lock with locking the ->i_lock
and doing atomic_dec_and_test, since we did the atomic_add_unless above.
Co-developed-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/be208b89bdb650202e712ce2bcfc407ac7044c7a.1756222464.git.josef@toxicpanda.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()
to ensure that no new recovery work items can be queued after device
removal has started. Previously, recovery work could be scheduled even
after canceling existing work, potentially leading to use-after-free
bugs if recovery accessed freed resources.
Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better
reflect its new behavior.
Fixes: 58cde80f45 ("accel/ivpu: Use dedicated work for job timeout detection")
Cc: stable@vger.kernel.org # v6.8+
Signed-off-by: Karol Wachowski <karol.wachowski@intel.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://lore.kernel.org/r/20250808110939.328366-1-jacek.lawrynowicz@linux.intel.com
Add an update_vector() callback to allow APIC drivers to perform driver
specific operations on external vector allocation/teardown on a CPU. This
callback will be used by the Secure AVIC APIC driver to configure the vectors
which a guest vCPU allows the hypervisor to send to it.
As system vectors have fixed vector assignments and are not dynamically
allocated, add an apic_update_vector() public API to facilitate
update_vector() callback invocation for them. This will be used for Secure
AVIC enabled guests to allow the hypervisor to inject system vectors which are
emulated by the hypervisor such as APIC timer vector and
HYPERVISOR_CALLBACK_VECTOR.
While at it, cleanup line break in apic_update_irq_cfg().
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250828110255.208779-3-Neeraj.Upadhyay@amd.com
Initialize the APIC ID in the Secure AVIC APIC backing page with the APIC_ID
MSR value read from the hypervisor. CPU topology evaluation later during boot
would catch and report any duplicate APIC ID for two CPUs.
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828110255.208779-2-Neeraj.Upadhyay@amd.com
The pxa_defconfig file defines CONFIG_USB_GPIO_VBUS twice, first as
built-in ('y') and then as a module ('m'). The kconfig system correctly
uses the last definition, but the duplication is confusing.
Remove the obsolete configuration to resolve the ambiguity and clean
up the configuration.
Fixes: 2002f39687 ("ARM: refresh defconfig files")
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Commit a7352c8494 ("dt-bindings: npu: rockchip,rknn: Add bindings") adds
the device-tree binding rockchip,rk3588-rknn-core.yaml, whereas the commit
ed98261b41 ("accel/rocket: Add a new driver for Rockchip's NPU") adds the
section DRM ACCEL DRIVER FOR ROCKCHIP NPU in MAINTAINERS with a file entry
referring to rockchip,rknn-core.yaml. Note that the file entry is missing
the part rk3588, compared to the added file above, which it intends to
refer to.
Adjust the file entry to the intended file name.
Fixes: ed98261b41 ("accel/rocket: Add a new driver for Rockchip's NPU")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://lore.kernel.org/r/20250826063248.32153-1-lukas.bulwahn@redhat.com
- Enable support for the Renesas RZ/T2H serial driver and the
RZ/V2H(P) RSPI driver in the ARM64 defconfig.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCaLGQlQAKCRCKwlD9ZEnx
cB5SAP0SGMXzkc53TvvY6OtGBE7alJqloqN8qmwq8kPT+omfGwD/bWgbtDytscYP
2uHuIvKSuAAxiQOLjDXGf2mOuI3QMAQ=
=Wrka
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmi1cVAACgkQmmx57+YA
GNmH/w//RCYStV1s7T9PYvVgkjZoTvieRTIe8eVpRrBeYFDCmwf5OerDItwCfREq
xxNvk4RaehUk3pczzYszgFLi4BeRzXLLfpC8ZYo3EUBxijTc5flIGyW4yRnLa0DG
OqbxJpVIsAF6p11cjGD5781y6yaW+k4SpBfU5tCQREaVKiPlhYIRLYMLNkV7lTiK
gg8xQR2NQMy19n4NIfMVqusJk9YrA2HbAFkSwAxckVcaw7dYoFti8SQ+A+qZmRaZ
gRatIZXxITfHzqgZI7Z//bMJwxMi6r0dAiHi5uhJFFVhkpGFgSqXg+SfJCW57k+U
4RX+xa1DBkd4BEcVT8WcRfI/CGCazvCU+ntdWE6MDvEAE+Z/8xk+iSpi3KWzudDN
Y1czFBxRZ0NgJ9p9fvE8Pbl9LT8SLtMOdpQruv670DIlAVfg3czPdT/8/pyDg2ak
q0hoyIQ7VRyPxQQ7JI/mD5jivnXy8GsudNrO51DRLxonZqVs8mo+eZjc/q8iqL4P
yKpQYdb05MHK00RC6ix8CNZdY42vW9pXf7JMIenRkssxd2gmDBk3GDxY+QFs07Ry
1SACBCUniMODkn3JI/oYeXEbyaouri8V5SQeSChC7V3CJmnXAUN/8/c+8jF9+N9c
RNgcKJSQoYJPH/IkdJsDInNKKRI6oVBoRTjJkQvQNxoFprzzF28=
=vIpR
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v6.18-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/defconfig
Renesas ARM defconfig updates for v6.18
- Enable support for the Renesas RZ/T2H serial driver and the
RZ/V2H(P) RSPI driver in the ARM64 defconfig.
* tag 'renesas-arm-defconfig-for-v6.18-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: defconfig: Enable the RZ/V2H(P) RSPI driver
arm64: defconfig: Enable Renesas RZ/T2H serial SCI
Link: https://lore.kernel.org/r/cover.1756468043.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The problem is that pm_runtime_get_sync() can return 1 on success so
checking for zero doesn't work. Use the pm_runtime_resume_and_get()
function instead. The pm_runtime_resume_and_get() function does
additional cleanup as well so that's a bonus as well.
Fixes: 0810d5ad88 ("accel/rocket: Add job submission IOCTL")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://lore.kernel.org/r/aKcRW6fsRP_o5C_y@stanley.mountain
Right now, the code checks the DMA_READ_ERROR state 2 times, while
I guess it was supposed to warn about both read and write errors.
Change the 2nd check to look at the write-error flag.
Fixes: 0810d5ad88 ("accel/rocket: Add job submission IOCTL")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://lore.kernel.org/r/20250818185658.2585696-1-heiko@sntech.de
Replace usages of kfree() with kvfree() for pointers which were
allocated using kvmalloc(), as required by the kernel memory management
API.
Use sizeof() on the type that a pointer references instead of the
pointer itself. In this case, scheds and *scheds both happen to be
pointers, so sizeof() will expand to the same value in either case, but
using *scheds is more technically correct since scheds is an array of
drm_gpu_scheduler *.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/r/202508120730.PLbjlKbI-lkp@intel.com/
Signed-off-by: Brigham Campbell <me@brighamcampbell.com>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://lore.kernel.org/r/20250813-rocket-free-fix-v1-1-51f00a7a1271@brighamcampbell.com
Fixes: 0810d5ad88 ("accel/rocket: Add job submission IOCTL")
With the current dependency on only DRM, a config of
CONFIG_DRM_ACCEL_ROCKET=y
is possible, but of course wrong, because without DRM_ACCEL the build-
system will never even enter drivers/accel/* .
So depend on DRM_ACCEL instead of just DRM.
Fixes: ed98261b41 ("accel/rocket: Add a new driver for Rockchip's NPU")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://lore.kernel.org/r/20250814113519.1551855-3-heiko@sntech.de
The general indentation for the Kconfig lines is one tab, so adapt the
lines accordingly.
The description is correctly indented (1 tab + 2 spaces) so doesn't need
changes.
Fixes: ed98261b41 ("accel/rocket: Add a new driver for Rockchip's NPU")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://lore.kernel.org/r/20250814113519.1551855-2-heiko@sntech.de
Two small changes, the most interesting being the addition of the silicon IDs
for ASPEED's AST2700 SoC family.
-----BEGIN PGP SIGNATURE-----
iJIEABYIADoWIQSoUT1x3bOSX/nAa8ajM9GZTrjhpgUCaKu87RwcYW5kcmV3QGNv
ZGVjb25zdHJ1Y3QuY29tLmF1AAoJEKMz0ZlOuOGmxAoBAIWvFqHDVHh4qzcnmNeM
g1a5wEbNo/wS0DcEAX39tr9+AP45dJRQdIyj1lFbp0oyGvoyMK1zzr/cUQUGgdTQ
5OPgBQ==
=rg00
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmi1cLoACgkQmmx57+YA
GNkv+xAAm3l42yMRz7GbMNTRbBOh+On9XlvViXHbOjk4KFaBqEtiIYdbaoM8iIeI
Pp0wv4yX8Dn7qDd4THTKJ1xnnoe+wGwsYAi5lwR/miJv4U4ZyfWoDKhsNzvbCrL7
j25FyKMcXMmV1U+fufNUGOAwcjOawP26ud8Fb2xT2yEnaZl0em30hbMaYUu7Uj+0
/jBtTUf0nrHC7TRFgnM1oKRW41WjZgsD8Tdc/gTW2eWS68bG9XBBSPqWVxH4JcG9
JwP4yZ2RLRZb8YknVJhT3ue8FvtNklRcyo5O9iZCbDfIYJGsvZJZ3vuHvPlFkB+9
v/eQ4qDaWoJCJsAdzv1Jqp2Gcb4hTiwsTckwGGjVBe7vgjHYBkFlOPmlp2cqpi0D
vCLP+4SHlsz8koGRtPgC9sDJO+RvY32il2Kp6eMfWHEQ67h/8ncYQyW663uWJAek
hpdt6mFhj7k55YusKPH43KKdy12dtO7pnNja0Iio/GQ2cFrXzX1Tr3xdsaZS1L8K
Ipmjj0zGdJV21aEOCxtWDK4302702+nMKNh9zCgZYC7L8OtL23Pm3gIEqegcVrKV
IHvQRWnCg8Z0R4C00doDpVZyC38hAU/DigEIDVzbXK/UQZpTfMb8v817Il/5bUXZ
ONM/i60qW7aLchItfnuy9yNCZEgPtI4+CsJqztBCGDUHjVDnfHQ=
=mCh9
-----END PGP SIGNATURE-----
Merge tag 'aspeed-6.18-drivers-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/drivers
Early ASPEED driver updates for 6.18
Two small changes, the most interesting being the addition of the silicon IDs
for ASPEED's AST2700 SoC family.
* tag 'aspeed-6.18-drivers-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
soc: aspeed: socinfo: Add AST27xx silicon IDs
soc: aspeed: Use of_reserved_mem_region_to_resource() for "memory-region"
Link: https://lore.kernel.org/r/2d122b5c4a19261148993b66e4b98371a684ba74.camel@codeconstruct.com.au
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patches for the arm64 defconfig are supposed to be sent to the
SoC maintainers (e.g. a change in the generic arm64 defconfig
required for Rockchip devices should be send to Heiko Stübner
as he is listed as maintainer for "ARM/Rockchip SoC support")
and not the ARM64 PORT maintainers.
While we cannot easily describe this in MAINTAINERS, we can at
least stop it from giving false information and make it behave
the same way as for the MAINTAINERS file itself (which basically
has the same rules), so that it just outputs the LKML for the
ARM64 defconfig.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20250818-arm64-defconfig-v1-1-f589553c3d72@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Remove fixed PPI lane count setup. The R-Car DSI host is capable
of operating in 1..4 DSI lane mode. Remove the hard-coded 4-lane
configuration from PPI register settings and instead configure
the PPI lane count according to lane count information already
obtained by this driver instance.
Configure TXSETR register to match PPI lane count. The R-Car V4H
Reference Manual R19UH0186EJ0121 Rev.1.21 section 67.2.2.3 Tx Set
Register (TXSETR), field LANECNT description indicates that the
TXSETR register LANECNT bitfield lane count must be configured
such, that it matches lane count configuration in PPISETR register
DLEN bitfield. Make sure the LANECNT and DLEN bitfields are
configured to match.
Fixes: 155358310f ("drm: rcar-du: Add R-Car DSI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20250813210840.97621-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Correct 'leave' to 'leaf' in memory bitmaps description comment.
Signed-off-by: Li Jun <lijun01@kylinos.cn>
Link: https://patch.msgid.link/20250819104038.1596952-1-lijun01@kylinos.cn
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
