Driver makes use of drmm_encoder_init() to initialize the encoder and
automatically handle the cleanup by registering drm_encoder_cleanup()
with drmm_add_action().
However, the internal structure containing the encoder part gets
allocated with devm_kzalloc(), which happens while component_bind_all()
is being called from Rockchip DRM driver. The component framework
further ensures it is deallocated as part of releasing all the resources
claimed during bind, which is triggered from component_unbind_all().
When the reference to the DRM device gets eventually dropped via
drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release()
attempts to access the now released encoder structure, leading to
use-after-free.
Ensure driver's internal structure is still reachable on encoder cleanup
by switching from a device-managed allocation to a drm-managed one.
Ilpo Järvinen [Thu, 19 Feb 2026 15:39:51 +0000 (17:39 +0200)]
PCI: Prevent shrinking bridge window from its required size
Steve reported an eGPU (either Radeon Instinct MI50 32GB or NVIDIA 3080
10GB) connected via Thunderbolt was not assigned sufficient BAR space in
v6.11, so the amdgpu and nvidia drivers were unable to initialize the
device.
pci_bridge_distribute_available_resources() -> ... ->
adjust_bridge_window() is called between __pci_bus_size_bridges()
and assigning the resources. Since the commit 948675736a77 ("PCI: Allow
adjust_bridge_window() to shrink resource if necessary")
adjust_bridge_window() can also shrink the bridge window. The shrunken
size, however, conflicts with what __pci_bus_size_bridges() ->
pbus_size_mem() calculated as the required bridge window size. By shrinking
the size, adjust_bridge_window() prevents the rest of the resource fitting
algorithm from working as intended. Resource fitting logic is expecting
assignment failures when bridge windows need resizing, but there are cases
where failures are no longer happening after the commit 948675736a77 ("PCI:
Allow adjust_bridge_window() to shrink resource if necessary").
The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink
resource if necessary") justifies the change by the extra reservation
made due to hpmemsize parameter, however, the kernel code contradicts
that statement. (For simplicity, finer-grained hpmmiosize and hpmmiopref
parameters that can be used to the same effect as hpmemsize are ignored in
this description.)
pbus_size_mem() calls calculate_memsize() twice. First with add_size=0
to find out the minimal required resource size. The second call occurs
with add_size=hpmemsize (effectively) but the result does not directly
affect the resource size only resulting in an entry on the realloc_head
list (a.k.a. add_list). Yet, adjust_bridge_window() directly changes
the resource size which does not include what is reserved due to
hpmemsize. Also, if the required size for the bridge window exceeds
hpmemsize, the parameter does not have any effect even on the second
size calculation made by pbus_size_mem(); from calculate_memsize():
size = max(size, add_size) + children_add_size;
The commit ae4611f1d7e9 ("PCI: Set resource size directly in
adjust_bridge_window()") that precedes the commit 948675736a77 ("PCI:
Allow adjust_bridge_window() to shrink resource if necessary") is also
related to causing this problem. Its changelog explicitly states
adjust_bridge_window() wants to "guarantee" allocation success.
Guaranteed allocations, however, are incompatible with how the other
parts of the resource fitting algorithm work. The given justification
fails to explain why guaranteed allocations at this stage are required
nor why forcing window to a smaller value than what was calculated by
pbus_size_mem() is correct. While the change might have worked by chance
in some test scenario, too small bridge window does not "guarantee"
success from the point of view of the endpoint device resource
assignments. No issue is mentioned within the changelog so it's unclear
if the change was made to fix some observed issue nor and what that
issue was.
The unwanted shrinking of a bridge window occurs, e.g., when a device with
large BARs such as eGPU is attached using Thunderbolt and the Root Port
holds less than enough resource space for the eGPU. The GPU resources are
in order of GBs and the default hotplug allocation is a mere 2MB
(DEFAULT_HOTPLUG_MMIO_PREF_SIZE). The problem is illustrated by this log
(filtered to the relevant content only):
The initial size of the Root Port's window is 448MB (0x601bffffff -
0x6000000000). __pci_bus_size_bridges() -> pbus_size_mem() calculates the
required size to be 32772 MB (0x10003fffff - 0x800000000) which would fit
the eGPU resources. adjust_bridge_window() then shrinks the bridge window
down to what is guaranteed to fit into the Root Port's bridge window. The
bridge window for 03:00.0 is also eliminated from the add_list (a.k.a.
realloc_head) list by adjust_bridge_window().
After adjustment, the resources are assigned and as the bridge window for
03:00.0 is assigned successfully, no failure is recorded. Without a
failure, no attempt to resize the window of the Root Port is required. The
end result is eGPU not having large enough resources to work.
The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink
resource if necessary") also claims nested bridge windows are sized the
same, which is false. pbus_size_mem() calculates the size for the parent
bridge window by summing all the downstream resources so the resource
fitting calculates larger bridge window for the parent to accommodate the
childen. That is, hpmemsize does not result the same size for the case
where there are nested bridge windows.
In order to fix the most immediate problem, don't shrink the resource size
in adjust_bridge_window() as hpmemsize had nothing to do with it. When
considering add_size, only reduce it up to what is added due to hpmemsize
(if required size is larger than hpmemsize, the parameter has no impact,
see calculate_memsize()). Unfortunately, if the tail of the bridge window
was aligned in calculate_memsize() from below hpmemsize to above it, the
size check will falsely match but the check at least errs to the side of
caution. There's not enough information available in adjust_bridge_window()
to know the calculated size precisely.
This is not exactly a revert of the commits e4611f1d7e9 ("PCI: Set resource
size directly in adjust_bridge_window()") and 948675736a77 ("PCI: Allow
adjust_bridge_window() to shrink resource if necessary") as shrinking still
remains in place but is implemented differently, and the end result behaves
very differently.
It is possible that those two commits fixed some other issue that is not
described with enough detail in the changelog and undoing parts of them
results in another regression due to behavioral change. Nonetheless, as
described above, the solution by those two commits was flawed and the
issue, if one exists, should be solved in a way that is compatible with the
rest of the resource fitting algorithm instead of working against it.
Besides shrinking, the case where adjust_bridge_window() expands the bridge
window is likely somewhat wrong as well because it removes the entry from
add_list (a.k.a. realloc_head), but it is less damaging as that only
impacts optional resources and may have no impact if expanding by hpmemsize
is larger than what add_size was. Fixing it is left as further work.
Fixes: 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") Fixes: ae4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") Reported-by: Steve Oswald <stevepeter.oswald@gmail.com> Closes: https://lore.kernel.org/linux-pci/CAN95MYEaO8QYYL=5cN19nv_qDGuuP5QOD17pD_ed6a7UqFVZ-g@mail.gmail.com/ Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260219153951.68869-1-ilpo.jarvinen@linux.intel.com
Ahmed Naseef [Thu, 12 Mar 2026 16:53:32 +0000 (16:53 +0000)]
PCI: Prevent assignment to unsupported bridge windows
Previously, pci_read_bridge_io() and pci_read_bridge_mmio_pref()
unconditionally set resource type flags (IORESOURCE_IO or IORESOURCE_MEM |
IORESOURCE_PREFETCH) when reading bridge window registers. For windows that
are not implemented in hardware, this may cause the allocator to assign
space for a window that doesn't exist.
For example, the EcoNET EN7528 SoC Root Port doesn't support the
prefetchable window, but since a downstream device had a prefetchable BAR,
the allocator mistakenly assigned a prefetchable window:
pci 0001:00:01.0: [14c3:0811] type 01 class 0x060400 PCIe Root Port
pci 0001:00:01.0: PCI bridge to [bus 01-ff]
pci 0001:00:01.0: bridge window [mem 0x28000000-0x280fffff]: assigned
pci 0001:00:01.0: bridge window [mem 0x28100000-0x282fffff pref]: assigned
pci 0001:01:00.0: BAR 0 [mem 0x28100000-0x281fffff 64bit pref]: assigned
pci_read_bridge_windows() already detects unsupported windows by testing
register writability and sets dev->io_window/pref_window accordingly.
Check dev->io_window/pref_window so we don't set the resource flags for
unsupported windows, which prevents the allocator from assigning space to
them.
After this commit, the prefetchable BAR is correctly allocated from the
non-prefetchable window:
Linus Torvalds [Thu, 26 Mar 2026 19:27:17 +0000 (12:27 -0700)]
Merge tag 'thermal-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"This prevents the int340x thermal driver from taking the power slider
offset parameter into account incorrectly in some cases (Srinivas
Pandruvada)"
* tag 'thermal-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: intel: int340x: soc_slider: Set offset only for balanced mode
Abel Vesa [Fri, 13 Mar 2026 12:22:38 +0000 (14:22 +0200)]
dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Document Eliza compatible
The SPMI multi-master Arbiter found on Eliza is version 7.2.0, yet
driver-wise, still compatible with the one featured on Hamoa (X1E80100),
which is 7.0.1.
So document the Eliza compatible and allow Hamoa one as fallback.
Move the content of fdt_reserved_mem_save_node() to
fdt_init_reserved_mem_node() function. Initialization is no longer
performed in two steps as it was initially, so
fdt_reserved_mem_save_node() name is a bit misleading and that function
now performs full initialization of the reserved memory region.
This also fixes the problem of keeping pointers to the regions, which
failed to initialize, what might cause issues when such region is
assigned to the device.
Rename fdt_scan_reserved_mem_reg_nodes() to fdt_scan_reserved_mem_late()
to clearly show how it differs from fdt_scan_reserved_mem() and update
description of both functions.
Marek Szyprowski [Wed, 25 Mar 2026 09:00:21 +0000 (10:00 +0100)]
of: reserved_mem: rearrange code a bit
Move __rmem_check_for_overlap() and __rmem_cmp() functions before
fdt_scan_reserved_mem_reg_nodes() to avoid forward declaration and keep
related code close together.
Marek Szyprowski [Wed, 25 Mar 2026 09:00:19 +0000 (10:00 +0100)]
of: reserved_mem: switch to ops based OF_DECLARE()
Move init function from OF_DECLARE() argument to the given reserved
memory region ops structure and then pass that structure to the
OF_DECLARE() initializer. This node_init callback is mandatory for the
reserved mem driver. Such change makes it possible in the future to add
more functions called by the generic code before given memory region is
initialized and rmem object is created.
Marek Szyprowski [Wed, 25 Mar 2026 09:00:18 +0000 (10:00 +0100)]
of: reserved_mem: use -ENODEV instead of -ENOENT
When given reserved memory region doesn't really support given node,
return -ENODEV instead of -ENOENT. Then fix __reserved_mem_init_node()
function to properly propagate error code different from -ENODEV instead
of silently ignoring it.
Linus Torvalds [Thu, 26 Mar 2026 19:06:40 +0000 (12:06 -0700)]
Merge tag 'acpi-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support fix from Rafael Wysocki:
"Prevent use-after-free from occurring on reduced-hardware ACPI
platforms when -EPROBE_DEFER is returned by ec_install_handlers()
during ACPI EC driver initialization (Weiming Shi)"
* tag 'acpi-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
Biju Das [Thu, 26 Mar 2026 16:24:51 +0000 (16:24 +0000)]
pinctrl: renesas: rzg2l: Fix save/restore of {IOLH,IEN,PUPD,SMT} registers
The rzg2l_pinctrl_pm_setup_regs() handles save/restore of
{IOLH,IEN,PUPD,SMT} registers during s2ram, but only for ports where all
pins share the same pincfg. Extend the code to also support ports with
variable pincfg per pin, so that {IOLH,IEN,PUPD,SMT} registers are
correctly saved and restored for all pins.
Lad Prabhakar [Thu, 19 Mar 2026 14:15:15 +0000 (14:15 +0000)]
pinctrl: renesas: rzt2h: Add pin configuration support
Add pin configuration support for the Renesas RZ/T2H SoC. The RZ/T2H SoC
allows configuring several electrical characteristics through the DRCTLm
(I/O Buffer Function Switching) registers. These registers control bias
configuration, Schmitt trigger input, output slew rate, and drive
strength.
Implement pinconf_ops to allow reading and updating these properties
through the generic pin configuration framework. The implementation
supports bias-disable, bias-pull-up, bias-pull-down,
input-schmitt-enable, slew-rate, and drive-strength-microamp.
Linus Torvalds [Thu, 26 Mar 2026 19:03:37 +0000 (12:03 -0700)]
Merge tag 'landlock-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux
Pull Landlock fixes from Mickaël Salaün:
"This mainly fixes Landlock TSYNC issues related to interrupts and
unexpected task exit.
Other fixes touch documentation and sample, and a new test extends
coverage"
* tag 'landlock-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
landlock: Expand restrict flags example for ABI version 8
selftests/landlock: Test tsync interruption and cancellation paths
landlock: Clean up interrupted thread logic in TSYNC
landlock: Serialize TSYNC thread restriction
samples/landlock: Bump ABI version to 8
landlock: Improve TSYNC types
landlock: Fully release unused TSYNC work entries
landlock: Fix formatting
Document the pin configuration properties supported by the RZ/T2H
pinctrl driver.
The RZ/T2H SoC allows configuring several electrical characteristics
through the DRCTLm (I/O Buffer Function Switching) registers. These
registers control drive strength, bias configuration, Schmitt trigger
input, and output slew rate.
Matthew Brost [Thu, 26 Mar 2026 01:12:07 +0000 (18:12 -0700)]
drm/xe: Issue GGTT invalidation under lock in ggtt_node_remove
Async work (e.g., GuC queue teardowns) can call ggtt_node_remove, so the
operation must be performed under the GGTT lock to ensure the GGTT
online check remains stable. GGTT insertion and removal are heavyweight
operations (e.g., queue create/destroy), so the additional serialization
cost is negligible compared to ensuring correctness.
Marek Vasut [Thu, 26 Mar 2026 04:54:59 +0000 (05:54 +0100)]
ARM: dts: renesas: Drop KSZ8041 PHY C22 compatible strings
The Microchip KSZ8041 PHY schema indicates that the compatible string
"ethernet-phy-id0022.1537" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Marek Vasut [Thu, 26 Mar 2026 04:54:01 +0000 (05:54 +0100)]
ARM: dts: renesas: rza2mevb: Drop RTL8201F PHY C22 compatible string
The Realtek RTL8201F PHY schema indicates that the compatible string
"ethernet-phy-id001c.c816" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Marek Vasut [Thu, 26 Mar 2026 04:53:38 +0000 (05:53 +0100)]
ARM: dts: renesas: r8a7742-iwg21d-q7-dbcm-ca: Drop KSZ8081 PHY C22 compatible string
The Microchip KSZ8081 PHY schema indicates that the compatible string
"ethernet-phy-id0022.1560" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Biju Das [Tue, 24 Mar 2026 11:43:13 +0000 (11:43 +0000)]
arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
Add the initial DTSI for the RZ/G3L SoC.
The files in this commit have the following meaning:
- r9a08g046.dtsi: RZ/G3L family SoC common parts
- r9a08g046l48.dtsi: RZ/G3L R9A08G046L48 SoC-specific parts
Add placeholders to reuse the code for the Renesas SMARC II carrier
board.
Document the device tree bindings for the Renesas RZ/G3L SoC Clock Pulse
Generator (CPG). RZ/G3L CPG is similar to RZ/G2L CPG but has 5 clocks
compared to 1 clock on other SoCs.
Also define RZ/G3L (R9A08G046) Clock Pulse Generator Core Clocks, as
listed in section 4.4.4.1 ("Block Diagram of the Clock System"), module
clock outputs, as listed in section 4.4.2 ("Clock List r1.00") and add
Reset definitions referring to registers CPG_RST_* in Section 4.4.3
("Register") of the RZ/G3L Hardware User's Manual (Rev.1.00 Oct, 2025).
Biju Das [Tue, 24 Mar 2026 11:43:11 +0000 (11:43 +0000)]
clk: renesas: rzg2l: Re-enable critical module clocks during resume
After a suspend/resume cycle, critical module clocks (CLK_IS_CRITICAL)
may be left disabled as there is no owning driver to restore them,
unlike regular clocks.
Add rzg2l_mod_enable_crit_clock_init_mstop() which walks all module
clocks on resume, re-enables any critical clock found disabled, and then
restores the MSTOP state for clocks that have one via the existing
helper. This replaces the direct call to rzg2l_mod_clock_init_mstop()
in rzg2l_cpg_resume(), preserving the correct clock-before-MSTOP restore
ordering.
Refactor the mstop initialisation logic in rzg2l_mod_clock_init_mstop()
into a dedicated helper function rzg2l_mod_clock_init_mstop_helper().
This decouples the logic for setting module stop state on disabled
clocks from the iteration loop, allowing it to be reused during resume
to re-enable critical clocks.
Biju Das [Tue, 24 Mar 2026 11:43:09 +0000 (11:43 +0000)]
clk: renesas: rzg2l: Add helper for mod clock enable/disable
Refactor rzg2l_mod_clock_endisable() by extracting its logic into a new
helper function rzg2l_mod_clock_endisable_helper(), which accepts an
additional set_mstop_state boolean parameter. This allows callers to
control whether the module stop state is updated alongside the clock
enable/disable operation. No functional change for existing callers.
The RZ/G2L SoC family requires DMA resets to be deasserted for routing
some peripheral interrupts to the CPU. Asserting these resets after boot
would silently break interrupt delivery with no driver to restore them.
Mark the DMA resets as critical by adding them to the crit_resets table
in the SoC-specific rzg2l_cpg_info for r9a07g043, r9a07g044, and
r9a08g045, preventing __rzg2l_cpg_assert() from asserting them and
ensuring they are deasserted during probe and resume.
Biju Das [Tue, 24 Mar 2026 11:43:07 +0000 (11:43 +0000)]
clk: renesas: rzg2l: Add support for critical resets
Some reset lines must remain deasserted at all times after boot, as
asserting them would disable critical system functionality with no
owning driver to restore them. This mirrors the existing crit_mod_clks
mechanism which protects critical module clocks from being disabled.
On RZ/G2L family SoCs, the DMA reset must be remain deasserted for
routing some peripheral interrupts to CPU.
Add crit_resets and num_crit_resets fields to struct rzg2l_cpg_info to
allow SoC-specific data tables to declare reset IDs that must never be
asserted.
Introduce rzg2l_cpg_deassert_crit_resets() to iterate over all critical
resets and deassert them. Call it both at probe time and during resume
to ensure critical peripherals are held out of reset after power-on and
suspend/resume cycles.
The of_pci_get_max_link_speed() function currently validates the
"max-link-speed" DT property to be in the range 1..4 (Gen1..Gen4).
This imposes a maintenance burden because each new PCIe generation
would require updating this validation.
Remove the range check so the function returns the raw property value
(or a negative error code if the property is missing or malformed).
Since the callers are now validating the returned speed against the
range they support, this check can now be safely removed.
Removing the validation from this common function also allows future PCIe
generations to be supported without modifying drivers/pci/of.c.
Hans Zhang [Fri, 13 Mar 2026 16:55:21 +0000 (00:55 +0800)]
PCI: controller: Validate max-link-speed
Add validation for the "max-link-speed" DT property in three more
drivers, using the pcie_get_link_speed() helper.
- brcmstb: If the value is missing or invalid, fall back to no
limitation (pcie->gen = 0). Fix the previous incorrect logic.
- mediatek-gen3: If the value is missing or invalid, use the maximum
speed supported by the controller.
- rzg3s-host: If the value is missing or invalid, fall back to Gen2.
This ensures that all users of of_pci_get_max_link_speed() are ready
for the removal of the central range check.
Hans Zhang [Fri, 13 Mar 2026 16:55:20 +0000 (00:55 +0800)]
PCI: j721e: Validate max-link-speed from DT
Use the new pcie_get_link_speed() helper to validate the value read from
the "max-link-speed" DT property. If the value is missing or invalid,
fall back to Gen2 (speed = 2). This prepares for the removal of the
range check in of_pci_get_max_link_speed().
Hans Zhang [Fri, 13 Mar 2026 16:55:19 +0000 (00:55 +0800)]
PCI: dwc: Use pcie_get_link_speed() helper for safe array access
Replace direct indexing of pcie_link_speed[] with the new helper
pcie_get_link_speed() in all DesignWare core and glue drivers. This
ensures that out-of-range generation numbers do not cause out-of-bounds
accesses when the helper returns PCI_SPEED_UNKNOWN, and prepares for
the removal of the range check in of_pci_get_max_link_speed().
The actual validation of the "max-link-speed" DT property (e.g., fallback
to a safe default and warning) is added in subsequent patches for each
driver that reads the property.
Hans Zhang [Fri, 13 Mar 2026 16:55:18 +0000 (00:55 +0800)]
PCI: Add pcie_get_link_speed() helper for safe array access
The pcie_link_speed[] array is indexed by PCIe generation numbers
(1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
which can lead to out-of-bounds accesses if an invalid generation
number is used.
Introduce a helper function pcie_get_link_speed() that returns the
pci_bus_speed value for a given generation number, or PCI_SPEED_UNKNOWN if
the generation is out of range. This will allow us to safely handle
invalid values after the range check is removed from
of_pci_get_max_link_speed().
Yeoreum Yun [Sat, 14 Mar 2026 17:51:26 +0000 (17:51 +0000)]
arm64: cpufeature: Add FEAT_LSUI
Since Armv9.6, FEAT_LSUI introduces atomic instructions that allow
privileged code to access user memory without clearing the PSTATE.PAN
bit. Add CPU feature detection for FEAT_LSUI.
The rest of Qualcomm Interconnect drivers have stopped using
DEFINE_QNODE long ago for the sake of readability. Stop using it inside
the msm8974 interconnect driver too.
Dmitry Baryshkov [Tue, 24 Mar 2026 00:10:43 +0000 (02:10 +0200)]
interconnect: qcom: msm8974: switch to the main icc-rpm driver
In preparation to restoring the ability of MSM8974 driver to work with
the modern kernels, switch the driver to the main icc-rpm set of helper
code.
As platform-specific workarounds, set the get_bw callback (returning 0)
to prevent initial setup from programming INT_MAX into the RPM (which
otherwise might hang the platform) and tell RPM programming code to
ignore -ENXIO errors from the firmware (until the QoS programming is
sorted out).
Dmitry Baryshkov [Tue, 24 Mar 2026 00:10:42 +0000 (02:10 +0200)]
interconnect: qcom: let platforms declare their bugginess
On MSM8974 programming some of the RPM resources results in the
"resource does not exist" messages from the firmware. This occurs even
with the downstream bus driver, which happily ignores the errors. My
assumption is that these resources existed in the earlier firmware
revisions but were later switched to be programmed differently (for the
later platforms corresponding nodes use qos.ap_owned, which prevents
those resources from being programmed.
In preparation for conversion of the MSM8974 driver (which doesn't have
QoS code yet) to the main icc-rpm set of helpers, let the driver declare
that those -ENXIO errors must be ignored (for now). Later, when the QoS
programming is sorted out (and more interconnects are added to the DT),
this quirk might be removed.
Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://msgid.link/20260324-msm8974-icc-v2-6-527280043ad8@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
MSM8974 requires a separate get_bw callback, since on that platform
increasing the clock rate for some of the NoCs during boot may lead to
hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
msm8974: Don't boost the NoC rate during boot").
Dmitry Baryshkov [Tue, 24 Mar 2026 00:10:39 +0000 (02:10 +0200)]
interconnect: qcom: drop unused is_on flag
The commit 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface
clocks") has added the is_on flag to the qcom_icc_provider, but failed
to actually utilize it. Drop the flag.
Dmitry Baryshkov [Tue, 24 Mar 2026 00:10:38 +0000 (02:10 +0200)]
dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common
Use qcom,rpm-common schema to declare interconnects property instead
describing it again. In future this will allow the platform to switch to
the two-cell interconnects, adding the tag to the specification.
Hans Zhang [Sun, 15 Mar 2026 15:53:51 +0000 (23:53 +0800)]
PCI: sky1: Use boolean true for is_rc field
The is_rc field in struct cdns_pcie is of type bool. Replace the
integer assignment (1) with the boolean literal true to improve
code clarity and maintain consistency with the type definition.
Dmitry Baryshkov [Tue, 24 Mar 2026 00:10:37 +0000 (02:10 +0200)]
dt-bindings: interconnect: qcom,msm8974: drop bus clocks
Remove the wrong internal RPM bus clock representation that we've been
carrying for years. They are an internal part of the interconnect
fabric. They are not exported by any device and are not supposed to be
used.
PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion support
Qcom PCIe Root Ports advertise hotplug capability in hardware, but do not
support hotplug command completion. As a result, the hotplug commands
issued by the pciehp driver never gets completion notification, leading to
repeated timeout warnings and multi-second delays during boot and
suspend/resume.
Commit a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for
IPs v2.7.0 and v1.9.0") mistakenly assumed that the Root Ports doesn't
support Hotplug due to timeouts and disabled the Hotplug functionality
altogether. But the Root Ports does support reporting Hotplug events like
DL_Up/Down events.
So to fix the command completion timeout issues, just set the No Command
Completed Support (NCCS) bit and enable Hotplug in Slot Capability field
back.
Fixes: a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0") Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: renamed function, commit log and added comment] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # Hamoa CRD, tunneled link Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260314-hotplug-v1-1-96ac87d93867@oss.qualcomm.com
- Prevent pm_restore_gfp_mask() from triggering a WARN_ON() in some
code paths in which it is legitimately called without invoking
pm_restrict_gfp_mask() previously (Youngjun Park)
- Update snapshot_write_finalize() to take trailing zero pages into
account properly which prevents user space restore from failing
subsequently in some cases (Alberto Garcia)
* pm-sleep:
PM: sleep: Drop spurious WARN_ON() from pm_restore_gfp_mask()
PM: hibernate: Drain trailing zero pages on userspace restore
Hans Zhang [Sat, 7 Mar 2026 02:01:52 +0000 (10:01 +0800)]
PCI: dwc: Expose PCIe event counters for groups 5 to 7 over debugfs
Extend the DesignWare PCIe controller's debugfs statistical counter
interface with event definitions from groups 5 through 7 as documented
in the DWC PCIe Databook (version 6.30a, section 3.8.2.3, Tables 3-59,
3-60, 3-61). These counters provide visibility into Layer1 non-error
events (link state transitions,ASPM, L1 substates), Layer2 DLLP
exchanges, and Layer3 TLP transactions.
The counters are exposed under the debugfs statistical counter directory,
allowing users to monitor link behavior and diagnose PCIe protocol issues
more effectively.
Bruce Johnston [Tue, 24 Mar 2026 18:06:52 +0000 (14:06 -0400)]
dm vdo: save the formatted metadata to disk
Add vdo_save_super_block() and vdo_save_geometry_block() to perform
asynchronous writes of the super block and geometry block respectively.
Add vdo_clear_layout() to zero the UDS index's first block, the block
map partition, and the recovery journal partition.
These operations are driven by new phases in the pre-load state machine
(PRE_LOAD_PHASE_FORMAT_*), ensuring that disk writes happen during
pre-resume rather than during dmsetup create.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Bruce Johnston [Tue, 24 Mar 2026 18:06:51 +0000 (14:06 -0400)]
dm vdo: add formatting logic and initialization
Add the core formatting logic. The initialization path is updated to
read the geometry block (block 0 on the storage device). If the block
is entirely zeroed, the device is treated as unformatted and
vdo_format() is called. Otherwise, the existing geometry is parsed
and the VDO is loaded as before.
The vdo_format() function initializes the volume geometry and super
block, and marks the VDO as needing it's layout saved to disk.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Add vdo_submit_metadata_vio_wait(), a synchronous I/O submission
helper that blocks until completion. This is needed for I/O during
early initialization before work queues are available.
Refactor read_geometry_block() to use it.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Bruce Johnston [Tue, 24 Mar 2026 18:06:49 +0000 (14:06 -0400)]
dm vdo: add geometry block structure
Introduce a vdo_geometry_block structure, containing a vio and buffer,
mirroring the existing vdo_super_block structure. Both are now
initialized at VDO startup and freed at shutdown, establishing the
infrastructure needed to read and write the geometry block using the
same mechanisms as the super block.
Refactor read_geometry_block() to use the new structure.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Bruce Johnston [Tue, 24 Mar 2026 18:06:48 +0000 (14:06 -0400)]
dm vdo: add geometry block encoding
Add vdo_encode_volume_geometry() to write the geometry block into a
buffer so that it can be written to disk. The corresponding decode
path already exists.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Bruce Johnston [Tue, 24 Mar 2026 18:06:46 +0000 (14:06 -0400)]
dm vdo: add formatting parameters to table line
Extend the dm table line with three new optional parameters:
indexMemory (UDS index memory size), indexSparse (dense vs sparse
index), and slabSize (blocks per allocation slab). These values are
parsed, validated, and stored in the device configuration for use
during formatting.
Rework the slab size constants from the single MAX_VDO_SLAB_BITS into
explicit MIN_VDO_SLAB_BLOCKS, MAX_VDO_SLAB_BLOCKS, and
DEFAULT_VDO_SLAB_BLOCKS values.
Bump the target version from 9.1.0 to 9.2.0 to reflect this table
line change.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Bruce Johnston [Tue, 24 Mar 2026 18:06:45 +0000 (14:06 -0400)]
dm vdo: add super block initialization to encodings.c
Add vdo_initialize_component_states() to populate the super block,
computing the space required for the main VDO components on disk.
Those include the slab depot, block map, and recovery journal.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Sherry Sun [Fri, 6 Mar 2026 03:04:56 +0000 (11:04 +0800)]
PCI: imx6: Separate PERST# assertion from core reset functions
The imx_pcie_assert_core_reset() and imx_pcie_deassert_core_reset()
functions are primarily intended to reset the RC controller itself, not
the remote PCIe endpoint devices. However, the PERST# GPIO control was
previously embedded within these functions, which conflates two distinct
reset operations.
Move the PERST# GPIO handling into a dedicated function
imx_pcie_assert_perst(). This makes the code more maintainable and
prepares for parsing the reset-gpios property according to the new
Root Port DT binding in subsequent patches.
- eth: iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
Previous releases - always broken:
- bluetooth: fix null-ptr-deref on l2cap_sock_ready_cb
- udp: fix wildcard bind conflict check when using hash2
- netfilter: fix use of uninitialized rtp_addr in process_sdp
- tls: Purge async_hold in tls_decrypt_async_wait()
- xfrm:
- prevent policy_hthresh.work from racing with netns teardown
- fix skb leak with espintcp and async crypto
- smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer
- can:
- add missing error handling to call can_ctrlmode_changelink()
- fix OOB heap access in cgw_csum_crc8_rel()
- eth:
- mana: fix use-after-free in add_adev() error path
- virtio-net: fix for VIRTIO_NET_F_GUEST_HDRLEN
- bcmasp: fix double free of WoL irq"
* tag 'net-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (90 commits)
net: macb: use the current queue number for stats
netfilter: ctnetlink: use netlink policy range checks
netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp
netfilter: nf_conntrack_expect: skip expectations in other netns via proc
netfilter: nf_conntrack_expect: store netns and zone in expectation
netfilter: ctnetlink: ensure safe access to master conntrack
netfilter: nf_conntrack_expect: use expect->helper
netfilter: nf_conntrack_expect: honor expectation helper field
netfilter: nft_set_rbtree: revisit array resize logic
netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()
netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD
tls: Purge async_hold in tls_decrypt_async_wait()
selftests: netfilter: nft_concat_range.sh: add check for flush+reload bug
netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry
Bluetooth: btusb: clamp SCO altsetting table indices
Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop
Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()
Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lock
Bluetooth: L2CAP: Fix send LE flow credits in ACL link
net: mana: fix use-after-free in add_adev() error path
...
Richard Zhu [Sat, 28 Feb 2026 08:09:25 +0000 (16:09 +0800)]
PCI: imx6: Skip waiting for L2/L3 Ready on i.MX6SX
On i.MX6SX, the LTSSM registers become inaccessible after the
PME_Turn_Off message is sent to the link. So there is no way to verify
whether the link has entered L2/L3 Ready state or not.
Hence, set IMX_PCIE_FLAG_SKIP_L23_READY flag for i.MX6SX SoC to skip the
L2/L3 Ready state polling and let the DWC core wait for 10ms after sending
the PME_Turn_Off message as per the PCIe spec r6.0, sec 5.3.3.2.1.
Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260228080925.1558395-1-hongxing.zhu@nxp.com
Marco Crivellari [Mon, 10 Nov 2025 17:03:32 +0000 (18:03 +0100)]
smp: Use system_percpu_wq instead of system_wq
When a caller enqueues a work item using schedule_delayed_work() the used
wq is "system_wq" (per-cpu wq) while queue_delayed_work() uses
WORK_CPU_UNBOUND (used when no target CPU is specified). The same applies
to schedule_work() that is using system_wq and queue_work(), which again
makes use of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
Continue the effort to refactor workqueue APIs, which began with the
introduction of new workqueues and a new alloc_workqueue() flag in:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
and switch smp_call_on_cpu() to use system_percpu_wq because system_wq is
going away once the ongoing workqueue restructuring is done.
irqchip/gic-v3: Print a warning for out-of-range interrupt numbers
gic_irq_domain_translate() does not check if an interrupt number lies
within the valid range of the specified interrupt type. Add these checks,
and print a warning if the interrupt number is out of range.
This can help flagging incorrectly described Extended SPI and PPI
interrupts in DT.
Mark Brown [Thu, 26 Mar 2026 16:22:45 +0000 (16:22 +0000)]
ASoC: add rt1320/rt1321 dmic dai and fix the wrong name prefix
Bard Liao <yung-chuan.liao@linux.intel.com> says:
The new rt722 + rt1320 configuration uses the DMIC on the rt1320.
This series adds support for such configurations, where the DMIC is
provided by the rt1320 instead of the rt722.
Derek Fang [Thu, 26 Mar 2026 07:53:01 +0000 (15:53 +0800)]
ASoC: SOF: Intel: Add a is_amp flag to fix the wrong name prefix
According to the Intel sof design, it will create the name prefix
appended with amp index for the amp codec only, such as:
rt1318-1, rt1318-2, etc...
But the rt1320 is a codec with amp and mic codec functions, it doesn't
have the amp index in its name prefix as above.
And then it will be hard to identify the codec if in multi-rt1320 case.
So we add a flag to force the amp index to be appended.
Add DT compatible strings for the Verdin i.MX95 SoM and its supported
carrier boards: the Verdin Development Board, and the Dahlia, Ivy,
Mallow and Yavia carrier boards.
Martin Schmiedel [Thu, 19 Mar 2026 12:50:08 +0000 (13:50 +0100)]
dt-bindings: arm: fsl: add MBa93xxLA-MINI
Adds support for the MBa93xxLA-MINI SBC.
https://www.tq-group.com/en/products/tq-embedded/arm-architecture/mba93xxla-mini/
Signed-off-by: Martin Schmiedel <Martin.Schmiedel@tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Frank Li [Wed, 15 Oct 2025 18:48:45 +0000 (14:48 -0400)]
dt-bindings: arm: lpc: add missed lpc43xx board
Add missed legancy lpc43xx board compatible string to fix below CHECK_DTB
warnings:
arch/arm/boot/dts/nxp/lpc/lpc4337-ciaa.dtb: /: failed to match any schema with compatible: ['ciaa,lpc4337', 'nxp,lpc4337', 'nxp,lpc4350']
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Frank Li <Frank.Li@nxp.com>
dt-bindings: arm: fsl: Add NXP S32N79 SoC and RDB board
Add device tree binding documentation for the NXP S32N79 automotive SoC
and the S32N79 Reference Design Board (S32N79-RDB).
The S32N79 is an automotive-grade SoC featuring eight ARM Cortex-A78AE
cores organized for high-performance networking and gateway applications
in vehicles.
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
dt-bindings: interrupt-controller: fsl,irqsteer: add S32N79 support
Add compatible string for the interrupt steering controller used in NXP
S32N79 SoC.
The S32N79 SoC differs from the i.MX version by not implementing the
CHANCTRL register, but otherwise maintains the same programming model and
register layout.
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Introduce a new DT compatible string for the NXP i.MX8MP audio board
(version 2).
i.MX Audio Board is a configurable and functional audio processing
platform. Integrating a variety of audio input and output interfaces into
the system, the i.MX Audio Board supports HDMI input, HDMI eARC,
S/PDIF I/O, 2-ch ADC line-in, 24-ch DAC line-out and more. Based on these
features, rich audio application cases can be realized.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Josua Mayer [Thu, 26 Feb 2026 16:36:30 +0000 (18:36 +0200)]
dt-bindings: arm: fsl: Add various solidrun i.MX8M boards
Add bindings for various SolidRun boards:
- i.MX8MP HummingBoard IIoT - based on the SolidRun i.MX8M Plus SoM
- SolidSense N8 - single-board design with i.MX8M Nano
- i.MX8M Mini System on Module
- i.MX8M Mini HummingBoard Ripple
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Max Zhen [Thu, 26 Mar 2026 01:06:42 +0000 (18:06 -0700)]
accel/amdxdna: Fix leak when pinning ubuf pages
When pin_user_pages_fast() returns fewer pages than requested, the pages
that were successfully pinned are not released, leading to a leak.
Fix this by unpinning any partially pinned pages before returning failure.
Fixes: bd72d4acda10 ("accel/amdxdna: Support user space allocated buffer") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260326010642.2596525-1-lizhi.hou@amd.com
Biju Das [Wed, 25 Mar 2026 19:24:31 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Add shared interrupt support
The RZ/G3L SoC has 16 external interrupts, of which 8 are shared with TINT
(GPIO interrupts), whereas RZ/G2L has only 8 external interrupts with no
sharing. The shared interrupt line selection between external interrupt and
GPIO interrupt is based on the INTTSEL register. Add shared_irq_cnt
variable to struct rzg2l_hw_info handle these differences.
Add used_irqs bitmap to struct rzg2l_irqc_priv to track allocation state.
In the alloc callback, use test_and_set_bit() to enforce mutual exclusion
and configure the INTTSEL register to route to either the external
interrupt or TINT. In the free callback, use test_and_clear_bit() to
release the shared interrupt line and reset the INTTSEL. Also add INTTSEL
register save/restore support to the suspend/resume path.
Biju Das [Wed, 25 Mar 2026 19:24:30 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Add RZ/G3L support
The IRQC block on the RZ/G3L SoC is almost identical to the one found on
the RZ/G2L SoC, with the following differences:
- The number of GPIO interrupts for TINT selection is 113 instead of 123.
- The pin index and TINT selection index are not in the 1:1 map.
- The number of external interrupts are 16 instead of 8, out of these
8 external interrupts are shared with TINT.
Add support for the RZ/G3L driver by filling the rzg2l_hw_info table and
adding LUT for mapping between pin index and TINT selection index.
Biju Das [Wed, 25 Mar 2026 19:24:29 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Drop IRQC_IRQ_COUNT macro
The total number of external interrupts in RZ/G2L and RZ/G3L SoC are
different. The RZ/G3L has 16 external interrupts whereas RZ/G2L has only 8
external interrupts. Add irq_count variable in struct rzg2l_hw_info to
handle these differences and drop the macro IRQC_IRQ_COUNT.
Biju Das [Wed, 25 Mar 2026 19:24:28 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Drop IRQC_TINT_START macro
The IRQC_TINT_START value is different for RZ/G3L and RZ/G2L SoC. Add
tint_start variable in struct rzg2l_hw_info to handle this difference and
drop the macro IRQC_TINT_START.
While at it, update the variable type of titseln, tssr_offset, tssr_index,
index, and sense to unsigned int, in rzg2l_tint_set_edge() as these
variables are used only for calculation.
Biju Das [Wed, 25 Mar 2026 19:24:27 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Drop IRQC_NUM_IRQ macro
The total number of interrupts in RZ/G2L and RZ/G3L SoC are different.
Introduce struct rzg2l_hw_info to handle the hardware differences and
replace the macro IRQC_NUM_IRQ with num_irq variable in struct
rzg2l_hw_info.
The total number of interrupts in RZ/G2L and RZ/G3L SoC are different. The
RZ/G3L has 16 external interrupts whereas RZ/G2L has only 8 external
interrupts. Dynamically allocate fwspec memory instead of static allocation
to support both SoCs.
Biju Das [Wed, 25 Mar 2026 19:24:25 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Split rzfive_irqc_{mask,unmask} into separate IRQ and TINT handlers
rzfive_irqc_mask() and rzfive_irqc_unmask() use hw_irq range checks to
dispatch between IRQ and TINT masking operations. Split each into two
dedicated handlers — rzfive_irqc_irq_mask(), rzfive_irqc_tint_mask(),
rzfive_irqc_irq_unmask(), and rzfive_irqc_tint_unmask() — each operating
unconditionally on its respective interrupt type, removing the runtime
conditionals.
Assign the IRQ-specific handlers to rzfive_irqc_irq_chip and the
TINT-specific handlers to rzfive_irqc_tint_chip, consistent with the
separation applied to the EOI, set_type, and enable/disable callbacks in
previous patches.
While at it, simplify rzfive_irqc_{irq,tint}_{mask,unmask}() by replacing
raw_spin_lock locking/unlocking with scoped_guard().
Biju Das [Wed, 25 Mar 2026 19:24:24 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Split rzfive_tint_irq_endisable() into separate IRQ and TINT helpers
rzfive_tint_irq_endisable() handles both IRQ and TINT enable/disable paths
via a hw_irq range check.
Split this into two dedicated helpers, rzfive_irq_endisable() for IRQ
interrupts and rzfive_tint_endisable() for TINT interrupts, each operating
unconditionally on their respective interrupt type.
While at it, simplify rzfive_{irq,tint}_endisable by replacing
raw_spin_lock locking/unlocking with guard() and update the variable types
of offset, tssr_offset, and tssr_index to unsigned int, as these variables
are used only for calculation.
Biju Das [Wed, 25 Mar 2026 19:24:23 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Replace rzg2l_irqc_irq_{enable,disable} with TINT-specific handlers
rzg2l_irqc_irq_disable() and rzg2l_irqc_irq_enable() are used by both the
IRQ and TINT chips, but only perform TINT-specific work via
rzg2l_tint_irq_endisable(), guarded by a hw_irq range check.
Since the IRQ chip does not require this extra enable/disable handling,
replace its callbacks with the generic irq_chip_disable_parent() and
irq_chip_enable_parent() directly.
While at it, simplify rzfive_irqc_irq_enable() by replacing raw_spin_lock
locking/unlocking with guard() and update the variable types of offset,
tssr_offset, and tssr_index to unsigned int, as these variables are used
only for calculation.
Biju Das [Wed, 25 Mar 2026 19:24:22 +0000 (19:24 +0000)]
irqchip/renesas-rzg2l: Split set_type handler into separate IRQ and TINT functions
The common rzg2l_irqc_set_type() handler uses hw_irq range checks to
dispatch to either rzg2l_irq_set_type() or rzg2l_tint_set_edge().
Split this into two dedicated handlers, rzg2l_irqc_irq_set_type() and
rzg2l_irqc_tint_set_type(), each calling only their respective type
configuration function without runtime conditionals.
projects / thirdparty / kernel / linux.git / log
