* [PATCH v5 02/18] PCI/CXL: Probe the underlying bus reset in cxl_reset_bus_function()
From: Nicolin Chen @ 2026-07-03 4:06 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <cover.1783044582.git.nicolinc@nvidia.com>
cxl_reset_bus_function() reports "supported" to a probe after checking only
that the upstream bridge carries a CXL port DVSEC. The underlying bus reset
can still be unavailable, e.g. on a bus shared with other devices, so both
the reset_methods[] array and the reset_method sysfs node end up listing a
"cxl_bus" that is guaranteed to fail with -ENOTTY when it is attempted.
Probe the underlying pci_dev_reset_slot_function() and then, if it is not
applicable, pci_parent_bus_reset(). These are the same two checks that the
actual reset runs, so a shared-bus CXL device no longer advertises a method
that can never succeed.
Probing via pci_reset_bus_function() would not work: its cxl_sbr_masked()
check rejects every CXL port with a masked SBR, while the do-reset path in
this function unmasks the SBR before resetting. Such a port would wrongly
probe as unsupported.
Also pass an explicit PCI_RESET_DO_RESET at the do-reset call site, since
probe is always false at that point.
Fixes: 53c49b6e6dd2e ("PCI/CXL: Add 'cxl_bus' reset method for devices below CXL Ports")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/pci/pci.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 01cf310540561..8102989673333 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4979,8 +4979,16 @@ static int cxl_reset_bus_function(struct pci_dev *dev, bool probe)
if (!dvsec)
return -ENOTTY;
- if (probe)
- return 0;
+ /*
+ * Do not probe via pci_reset_bus_function(), which would reject a
+ * masked SBR that the do-reset path below unmasks before resetting.
+ */
+ if (probe) {
+ rc = pci_dev_reset_slot_function(dev, PCI_RESET_PROBE);
+ if (rc != -ENOTTY)
+ return rc;
+ return pci_parent_bus_reset(dev, PCI_RESET_PROBE);
+ }
rc = pci_read_config_word(bridge, dvsec + PCI_DVSEC_CXL_PORT_CTL, ®);
if (rc)
@@ -5000,7 +5008,7 @@ static int cxl_reset_bus_function(struct pci_dev *dev, bool probe)
val);
}
- rc = pci_reset_bus_function(dev, probe);
+ rc = pci_reset_bus_function(dev, PCI_RESET_DO_RESET);
if (reg != val)
pci_write_config_word(bridge, dvsec + PCI_DVSEC_CXL_PORT_CTL,
--
2.43.0
^ permalink raw reply related
* [PATCH v5 00/18] iommu/arm-smmu-v3: Quarantine device upon ATC invalidation timeout
From: Nicolin Chen @ 2026-07-03 4:06 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
Hi all,
This series addresses a critical vulnerability and stability issue where an
unresponsive PCIe device failing to process ATC (Address Translation Cache)
invalidation requests leads to silent data corruption and continuous SMMU
CMDQ error spam.
[ As Jason pointed out, because this series fundamentally introduces a new
RAS feature to quarantine and recover from hardware faults and relies on
a recently accepted SMMU driver rework, it is not treated as a standard
bug fix. Thus, most of the patches here don't carry a "Fixes" tag. ]
Currently, when an ATC invalidation times out, the SMMUv3 driver skips the
CMDQ_ERR_CERROR_ATC_INV_IDX error. This leaves the device's ATS cache state
desynchronized from the SMMU: the device cache may retain stale ATC entries
for memory pages that the OS has already reclaimed and reassigned, creating
a direct vector for data corruption. Furthermore, the driver might continue
issuing ATC_INV commands, resulting in constant CMDQ errors:
unexpected global error reported (0x00000001), this could be serious
CMDQ error (cons 0x0302bb84): ATC invalidate timeout
unexpected global error reported (0x00000001), this could be serious
CMDQ error (cons 0x0302bb88): ATC invalidate timeout
unexpected global error reported (0x00000001), this could be serious
CMDQ error (cons 0x0302bb8c): ATC invalidate timeout
...
To resolve this, introduce a mechanism to quarantine a broken device in the
SMMUv3 driver and the IOMMU core. To achieve this, add preparatory changes:
- Pass in PCI reset result to pci_dev_reset_iommu_done()
- Co-clear pending CMDQ_ERR from the cmdq issuer under a raw_spinlock_t,
so an ATC_INV timeout flagged in cmdq->atc_sync_timeouts is definitive
when the issuer reads its bit after CMD_SYNC poll
On the SMMUv3 driver side, retry the timedout ATC_INV batch to identify the
faulty device(s). Perform a surgical STE update, and flag the ATS as broken
to reject further ATS/ATC requests at HW level and suppress timeout spam.
This is on Github:
https://github.com/nicolinc/iommufd/commits/smmuv3_atc_timeout-v5
Changelog
v5:
* Rebase on v7.2-rc1
* [PCI] Probe the underlying bus reset in cxl_reset_bus_function()
* [PCI] Add quirk_flr_err() to stop the reset cascade on FLR timeout
* [iommu] Drop iommu_report_device_broken() and its preparatory patches
* [smmuv3] Drop master->ats_broken bool
* [smmuv3] Drop master->ats_broken_lock
* [smmuv3] Drop master->ats_invs scratch
* [smmuv3] Introduce INV_TYPE_ATS_BROKEN marker
* [smmuv3] Add arm_smmu_cmdq_batch_force_sync()
* [smmuv3] Don't rb_erase() a never-inserted stream node
* [smmuv3] Add streams_lock for atomic SID->master lookup
* [smmuv3] Drop "Serialize STE.EATS and ats_broken updates"
* [smmuv3] Drop "Move arm_smmu_invs_for_each_entry to header"
* [smmuv3] Recheck CMDQ_ERR in tegra241_vintf0_handle_error()
* [smmuv3] Thread arm_smmu_master_domain on a per-master list
* [smmuv3] Drop pci_disable_ats() from arm_smmu_quarantine_ats()
* [smmuv3] Limit the quarantine() to ARM_SMMU_FEAT_COHERENCY only
* [smmuv3] Rework arm_smmu_quarantine_ats() to walk master_domains
* [smmuv3] Rework arm_smmu_cmdq_batch_retry(): per-unique-SID retry
* [smmuv3] Rework arm_smmu_inv_cmp() to treat ATS variants as one class
* [smmuv3] Rework the issuer-side atc_sync_timeouts test with smp_rmb()
* [smmuv3] Drop "Co-clear pending CMDQ_ERR when queue_has_space() fails"
* [smmuv3] Drop "Keep smmu pointer in arm_smmu_inv but add master for ATS"
v4:
https://lore.kernel.org/all/cover.1779161849.git.nicolinc@nvidia.com/
* Rebase on Joerg's IOMMU "fixes" branch
* Rebase on Jason's SMMUv3 cmd_ent series
https://lore.kernel.org/all/0-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com/
* [PCI] Don't suspend IOMMU in probe mode
* [iommu] kfree_rcu() iommu_group
* [iommu] Convert gdev->blocked to enum gdev_blocked
* [iommu] Use disable_work_sync() to fix UAF and ref leak
* [iommu] Gate done() transitions to preserve BLOCKED_BROKEN
* [iommu] Decrement recovery_cnt when unplugging a blocked gdev
* [iommu] Drop racy dev_has_iommu() in iommu_report_device_broken()
* [iommu] Add gdev->broken_pending to skip worker after racing recovery
* [smmuv3] Add master->ats_invs scratch
* [smmuv3] Add arm_smmu_cmdq_batch_issue() wrapper
* [smmuv3] Force per-flush sync for has_ats batches
* [smmuv3] Serialize STE.EATS and ats_broken updates
* [smmuv3] Co-clear pending CMDQ_ERR from cmdq issuer
* [smmuv3] Add invs and has_ats to arm_smmu_cmdq_batch
* [smmuv3] Move arm_smmu_invs_for_each_entry to header
* [smmuv3] Set master->ats_broken after clearing STE.EATS
* [smmuv3] Issue CFGI_STE via arm_smmu_cmdq_issue_cmd_with_sync()
* [smmuv3] Keep "smmu" pointer in arm_smmu_inv but add "master" for ATS
v3:
https://lore.kernel.org/all/cover.1776381841.git.nicolinc@nvidia.com/
* Rebase on arm/smmu/updates branch + bug fix
* Update commit messages and inline comments
* [iommu] Drop unnecessary ops validation
* [iommu] Add missed function stub when !CONFIG_IOMMU_API
* [iommu] Change iommu_report_device_broken() to per gdev
* [iommu] Separate quarantine from pci_dev_reset_prepare()
* [iommu] Check reset failure in pci_dev_reset_iommu_done()
* [smmuv3] Fix STE update with try_cmpxchg64()
* [smmuv3] Fix "continue" bug when skipping ATC commands
* [smmuv3] Replace atomic_t prod_err with a lockless bitmap
* [smmuv3] Drop master->invs_domain; disable ATS per-master directly
* [smmuv3] Return -EIO for ATC timeout v.s. -ETIMEDOUT for poll timeout
* [smmuv3] Replace INV_TYPE_ATS_DISABLED with per-master ats_broken flag
v2:
https://lore.kernel.org/all/cover.1773774441.git.nicolinc@nvidia.com/
* Rebase on arm_smmu_invs-v13 series
* Bisect batched atc invalidation commands
* Drop the direct pci_reset_function() call
* Move the work queue from SMMUv3 to the core
* Proceed a surgical STE update to disable EATS
* Wait for pci_dev_reset_iommu_done() to signal a recovery
v1:
https://lore.kernel.org/all/cover.1772686998.git.nicolinc@nvidia.com/
Thanks
Nicolin
Nicolin Chen (18):
PCI: Don't suspend IOMMU when probing reset capability
PCI/CXL: Probe the underlying bus reset in cxl_reset_bus_function()
PCI: Propagate FLR return values to callers
iommu: Convert gdev->blocked from bool to enum gdev_blocked
iommu: Pass in reset result to pci_dev_reset_iommu_done()
iommu/arm-smmu-v3: Don't rb_erase() a never-inserted stream node
iommu/arm-smmu-v3: Mark ATC invalidate timeouts via lockless bitmap
iommu/arm-smmu-v3: Skip remaining GERROR causes on SFM
iommu/arm-smmu-v3: Introduce per-cmdq cmdq_err_handler callback
iommu/arm-smmu-v3: Recheck CMDQ_ERR in tegra241_vintf0_handle_error()
iommu/arm-smmu-v3: Co-clear pending CMDQ_ERR when CMD_SYNC times out
iommu/arm-smmu-v3: Introduce arm_smmu_cmdq_batch_issue() wrapper
iommu/arm-smmu-v3: Add streams_lock for atomic-context SID->master
lookup
iommu/arm-smmu-v3: Add has_ats to struct arm_smmu_cmdq_batch
iommu/arm-smmu-v3: Add INV_TYPE_ATS_BROKEN to skip quarantined ATS
masters
iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
iommu/arm-smmu-v3: Thread arm_smmu_master_domain on a per-master list
iommu/arm-smmu-v3: Block ATS for a master upon an ATC invalidation
timeout
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 33 +-
include/linux/iommu.h | 5 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 500 ++++++++++++++++--
.../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 42 +-
drivers/iommu/iommu.c | 76 ++-
drivers/pci/pci-acpi.c | 2 +-
drivers/pci/pci.c | 35 +-
drivers/pci/quirks.c | 56 +-
8 files changed, 646 insertions(+), 103 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v5 01/18] PCI: Don't suspend IOMMU when probing reset capability
From: Nicolin Chen @ 2026-07-03 4:06 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <cover.1783044582.git.nicolinc@nvidia.com>
reset_method_store() in drivers/pci/pci-sysfs.c discovers supported reset
methods by calling reset_fn(pdev, PCI_RESET_PROBE, ...) without holding a
device_lock, since the probe path is expected to query the device's reset
capability without changing device state.
However, pci_reset_bus_function() and __pci_dev_specific_reset() violate
that contract after pci_dev_reset_iommu_prepare/done() were added, which
moves the device into a blocking domain and abruptly aborts any in-flight
DMA. Doing this for a probe -- a state-query call that does not even hold
device_lock -- can cause driver timeouts and data loss on a DMAing device.
The peer reset helpers all handle this correctly: they short-circuit on a
probe input before touching the IOMMU.
Skip pci_dev_reset_iommu_prepare()/_done() entirely when probe is set. The
inner reset routines already implement their own probe semantics, and they
perform the capability checks and return without changing device state.
Fixes: f5b16b802174 ("PCI: Suspend iommu function prior to resetting a device")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/pci/pci.c | 13 ++++++++-----
drivers/pci/quirks.c | 13 ++++++++-----
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 77b17b13ee615..01cf310540561 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4946,10 +4946,12 @@ static int pci_reset_bus_function(struct pci_dev *dev, bool probe)
if (bridge && pcie_is_cxl(bridge) && cxl_sbr_masked(bridge))
return -ENOTTY;
- rc = pci_dev_reset_iommu_prepare(dev);
- if (rc) {
- pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", rc);
- return rc;
+ if (!probe) {
+ rc = pci_dev_reset_iommu_prepare(dev);
+ if (rc) {
+ pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", rc);
+ return rc;
+ }
}
rc = pci_dev_reset_slot_function(dev, probe);
@@ -4958,7 +4960,8 @@ static int pci_reset_bus_function(struct pci_dev *dev, bool probe)
rc = pci_parent_bus_reset(dev, probe);
done:
- pci_dev_reset_iommu_done(dev);
+ if (!probe)
+ pci_dev_reset_iommu_done(dev);
return rc;
}
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f7846fc..8ecd1bc561d28 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4250,14 +4250,17 @@ static int __pci_dev_specific_reset(struct pci_dev *dev, bool probe,
{
int ret;
- ret = pci_dev_reset_iommu_prepare(dev);
- if (ret) {
- pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
- return ret;
+ if (!probe) {
+ ret = pci_dev_reset_iommu_prepare(dev);
+ if (ret) {
+ pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
+ return ret;
+ }
}
ret = i->reset(dev, probe);
- pci_dev_reset_iommu_done(dev);
+ if (!probe)
+ pci_dev_reset_iommu_done(dev);
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: dts: aspeed: Add NVIDIA VR-NVL BMC
From: Jacky Huang @ 2026-07-03 3:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jacky Huang, Andrew Jeffery, Joel Stanley, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-aspeed,
linux-arm-kernel, linux-kernel
In-Reply-To: <c43899a8-3d6a-4c94-b0c2-33c00a830610@lunn.ch>
On Thu, Jul 02, 2026 at 07:16:29PM +0200, Andrew Lunn wrote:
> No change required, just a comment. The strapping should not
> matter. All Linux PHY drivers should configure the PHY based on
> phy-mode, replacing the strapping settings. There have been cases
> where the strapping is wrong...
Good to know, thanks for the explanation.
> For these nodes only:
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Thanks for the review and the Reviewed by, much appreciated.
Jacky
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-07-03 3:32 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Pranjal Shrivastava, Mostafa Saleh, will, robin.murphy, joro,
kees, baolu.lu, kevin.tian, miko.lenczewski, linux-arm-kernel,
iommu, linux-kernel, stable, jamien
In-Reply-To: <20260702235004.GN7481@nvidia.com>
On Thu, Jul 02, 2026 at 08:50:04PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 02, 2026 at 12:25:43PM -0700, Nicolin Chen wrote:
> > On Thu, Jul 02, 2026 at 11:41:57AM -0300, Jason Gunthorpe wrote:
> > > The VMIDs that are in-used by the adopted stream table have to be
> > > removed from the idr as well (and similarly for ASID if we don't have
> > > VMID HW support).
> > >
> > > Then the VMIDs that may be dirtied by the prior kernel remain isolated
> > > and are never re-used by the new kernel. When the new kernel wants to
> > > do DMA it will replace the STE with a new, clean VMID, and there is no
> > > problem.
> >
> > I see. I assume the reserved VMID for the kdump kernel will be a
> > clean VMID (!=0). That should guarantee different cache tags.
>
> You will also have to change things to allocate the kernel global vmid
> from the IDR, it will usually be 0 but not for kdump. Then you have to
> find all the places where the 0 is implicitly placed and put in the
> actual value.
Hmm, I just realized that all the EL2 commands do not take VMID.
Looks like we have no choice but to scan through all the CDs for
the ASID too..
Nicolin
^ permalink raw reply
* Re: [PATCH 0/5] Add BBML3 cpu feature
From: Linu Cherian @ 2026-07-03 3:16 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Kevin Brodsky,
Anshuman Khandual, Mark Rutland, linux-arm-kernel, linux-kernel
In-Reply-To: <830a4d39-c829-4e79-a0ec-5a3633b58aa6@arm.com>
Hi Suzuki,
On Wed, Jul 01, 2026 at 11:11:35AM +0100, Suzuki K Poulose wrote:
> On 01/07/2026 10:41, Linu Cherian wrote:
> > Patches 1 and 2 introduces BBML3 cpu feature
> > Patches 3, 4 and 5 adds more cpus to the BBML3 support list,
> > which dont advertise themselves through the standard
> > MMFR2_ID registers.
> >
> > Linu Cherian (5):
> > arm64: cpufeature: Add BBML3
> > arm64: cpufeature: Detect BBML3 based on MMFR2 ID
>
>
> > arm64: cputype: Add Cortex-A520AE definitions
> > arm64: cputype: Add C1-Nano definitions
> > arm64: cpufeature: Extend bbml3 support list
>
> If you could move the last 3 patches to the top, would be easier
> for people to back port the "enable" BBLM3 for those CPUs, without
> the renaming conflicts.
>
IMHO, if we change the order, "arm64: cpufeature: Extend bbml3 support list"
title need to be tweaked and might not go well with this BBML3 support series.
Also, backporting issue wouldnt be a problem if the whole series is
backported and not just 3 patches in isolation ?
Thanks,
Linu Cherian.
^ permalink raw reply
* Re: [PATCH 2/5] arm64: cpufeature: Detect BBML3 based on MMFR2 ID
From: Linu Cherian @ 2026-07-03 3:06 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Kevin Brodsky,
Anshuman Khandual, Suzuki K Poulose, linux-arm-kernel,
linux-kernel
In-Reply-To: <akZBOkMSH77C6MH5@J2N7QTR9R3>
Hi Mark,
On Thu, Jul 02, 2026 at 11:45:14AM +0100, Mark Rutland wrote:
> On Wed, Jul 01, 2026 at 03:11:28PM +0530, Linu Cherian wrote:
> > Add MMFR2 ID based BBML3 feature detection, so
> > that compliant cpus doesn't need to be added to the
> > midr list.
> >
> > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > ---
> > arch/arm64/kernel/cpufeature.c | 14 +++++++-------
> > arch/arm64/tools/sysreg | 1 +
> > 2 files changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 9986eb7b379c..d754b1b7da77 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2133,6 +2133,7 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
> >
> > bool cpu_supports_bbml3(void)
> > {
> > + u64 mmfr2;
> > /* CPUs that support BBML3 but dont advertise through MMFR2 ID */
> > static const struct midr_range supports_bbml3_list[] = {
> > MIDR_REV_RANGE(MIDR_CORTEX_X4, 0, 3, 0xf),
> > @@ -2144,15 +2145,14 @@ bool cpu_supports_bbml3(void)
> > {}
> > };
> >
> > - if (!is_midr_in_range_list(supports_bbml3_list))
> > - return false;
> > + if (is_midr_in_range_list(supports_bbml3_list))
> > + return true;
> >
> > - /*
> > - * We currently ignore the ID_AA64MMFR2_EL1 register, and only care
> > - * about whether the MIDR check passes.
> > - */
> > + mmfr2 = __read_sysreg_by_encoding(SYS_ID_AA64MMFR2_EL1);
> > + if (SYS_FIELD_GET(ID_AA64MMFR2_EL1, BBM, mmfr2) == ID_AA64MMFR2_EL1_BBM_3)
> > + return true;
>
> This needs to be '>=', so that if there's a future BBML4, we correctly
> detect that CPUs with BBML4 also have the BBML3 behaviour.
>
> It would also be better to check the ID field first, before falling back
> to the MIDR check. That way a reader can more clearly see that
> supports_bbml3_list catches older parts that don't advertised BBML3, and
> the comment above supports_bbml3_list would be clearer.
Okay, agree.
--
Thanks,
Linu Cherian.
^ permalink raw reply
* Re: [PATCH 5/5] arm64: cpufeature: Extend bbml3 support list
From: Linu Cherian @ 2026-07-03 3:03 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Kevin Brodsky,
Anshuman Khandual, Suzuki K Poulose, linux-arm-kernel,
linux-kernel
In-Reply-To: <akZBqNTTGXch6I9n@J2N7QTR9R3>
Hi Mark,
On Thu, Jul 02, 2026 at 11:47:04AM +0100, Mark Rutland wrote:
> On Wed, Jul 01, 2026 at 03:11:31PM +0530, Linu Cherian wrote:
> > Add below cpus to the midr list, which supports
> > BBML3 but don't advertise through MMFR2 ID.
> >
> > Cortex A520(AE)
> > Cortex A715
> > Cortex A720(AE)
> > Cortex A725
> > Neoverse N3
> > C1-Nano
> > C1-Pro
> > C1-Ultra
> > C1-Premium
> >
> > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > ---
> > arch/arm64/kernel/cpufeature.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index d754b1b7da77..9b806c1c60aa 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2142,6 +2142,15 @@ bool cpu_supports_bbml3(void)
> > MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
> > MIDR_ALL_VERSIONS(MIDR_AMPERE1),
> > MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
> > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A520AE),
> > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A715),
> > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A720AE),
> > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A725),
> > + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3),
> > + MIDR_ALL_VERSIONS(MIDR_C1_NANO),
> > + MIDR_ALL_VERSIONS(MIDR_C1_PRO),
> > + MIDR_REV_RANGE(MIDR_C1_ULTRA, 1, 1, 0xf),
> > + MIDR_REV_RANGE(MIDR_C1_PREMIUM, 1, 1, 0xf),
>
> Why do these two have a range? The commit message didn't mention this.
C1 ultra and C1 Premium has BBM related errata until r1p0.
Will mention that in commit message.
Thanks,
Linu Cherian.
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Fix rk3588s-roc-pc audio description
From: Fabio Estevam @ 2026-07-03 2:56 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
linux-rockchip, Fabio Estevam, stable
From: Fabio Estevam <festevam@nabladev.com>
The rk3588s-roc-pc ES8388 codec is connected to the i2s0_8ch audio
interface. Use the matching I2S0 MCLK output for the codec clock
instead of I2S1.
Using the I2S1 MCLK can leave the ALSA PCM running while the codec has
no usable master clock for the active audio path, resulting in silent
headphone output.
Also make the CPU DAI provide bitclock and frame clock. This matches
the active Rockchip I2S controller side and avoids relying on the codec
to drive the bus clocks.
Route the headphone output to LOUT2 and ROUT2, matching the old 5.10
BSP device tree. LOUT1 and ROUT1 are used for the speaker route there,
so using them for the headphone widget can leave the headphone jack
silent even while the ALSA path is active.
The old BSP also used hp-con-gpio on GPIO1_A4. Model that GPIO as a
simple audio amplifier so DAPM enables the headphone connection when the
headphone path is active.
Cc: stable@vger.kernel.org
Fixes: 7f9509791507 ("arm64: dts: rockchip: add DTs for Firefly ROC-RK3588S-PC")
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
---
.../boot/dts/rockchip/rk3588s-roc-pc.dts | 23 +++++++++++++------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
index d534d662c40f..99853880aaac 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
@@ -23,16 +23,19 @@ analog-sound {
compatible = "simple-audio-card";
pinctrl-names = "default";
pinctrl-0 = <&hp_detect>;
+ simple-audio-card,aux-devs = <&headphones_amp>;
simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,bitclock-master = <&cpudai>;
simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,frame-master = <&cpudai>;
simple-audio-card,hp-det-gpios = <&gpio1 RK_PA6 GPIO_ACTIVE_LOW>;
simple-audio-card,mclk-fs = <256>;
simple-audio-card,pin-switches = "Headphones";
simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
+ "Headphones", "Headphone Amp OUTL",
+ "Headphones", "Headphone Amp OUTR",
+ "Headphone Amp INL", "LOUT2",
+ "Headphone Amp INR", "ROUT2",
"LINPUT1", "Microphone Jack",
"RINPUT1", "Microphone Jack",
"LINPUT2", "Onboard Microphone",
@@ -47,11 +50,17 @@ masterdai: simple-audio-card,codec {
system-clock-frequency = <12288000>;
};
- simple-audio-card,cpu {
+ cpudai: simple-audio-card,cpu {
sound-dai = <&i2s0_8ch>;
};
};
+ headphones_amp: audio-amplifier-headphones {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = <&gpio1 RK_PA4 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Headphone Amp";
+ };
+
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -327,12 +336,12 @@ &i2c3 {
es8388: audio-codec@11 {
compatible = "everest,es8388", "everest,es8328";
reg = <0x11>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
+ clocks = <&cru I2S0_8CH_MCLKOUT>;
AVDD-supply = <&vcc_3v3_s0>;
DVDD-supply = <&vcc_1v8_s0>;
HPVDD-supply = <&vcc_3v3_s0>;
PVDD-supply = <&vcc_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
assigned-clock-rates = <12288000>;
#sound-dai-cells = <0>;
};
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
From: Cunhao Lu @ 2026-07-03 2:35 UTC (permalink / raw)
To: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Cunhao Lu
In-Reply-To: <20260703-master-v3-0-6d56de6fd2f3@qq.com>
RK3588 integrates a Rockchip CAN-FD controller variant that is not
fully compatible with RK3568v2. The RX FIFO count register field is
encoded in bits 7:5 on RK3588, while RK3568v2 uses bits 6:4.
Add a dedicated rockchip,rk3588-canfd compatible to describe this
variant. Do not use rockchip,rk3568v2-canfd as a fallback, because that
would describe a register layout that does not match the hardware.
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
---
v2 -> v3:
- Move the Changelog below ---
- Collect Heiko's Reviewed-by tag
v1 -> v2:
- Use enum for the single-compatible entries, as suggested by Krzysztof.
- Reword the commit message to explain the hardware difference instead
of referring to Linux driver match data.
---
.../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c0330013..81e2b6dfeb02 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
oneOf:
- - const: rockchip,rk3568v2-canfd
+ - enum:
+ - rockchip,rk3568v2-canfd
+ - rockchip,rk3588-canfd
- items:
- const: rockchip,rk3568v3-canfd
- const: rockchip,rk3568v2-canfd
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/4] arm64: dts: rockchip: add CAN-FD nodes for RK3588
From: Cunhao Lu @ 2026-07-03 2:35 UTC (permalink / raw)
To: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Cunhao Lu, Heiko Stuebner
In-Reply-To: <20260703-master-v3-0-6d56de6fd2f3@qq.com>
Describe the three CAN-FD controllers integrated in RK3588 in the base
SoC .dtsi.
Add CAN0, CAN1 and CAN2 nodes with their register ranges, interrupts,
clocks and resets, and keep them disabled by default so board DTS files
can enable them as needed.
Co-developed-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Cunhao Lu <1579567540@qq.com>
---
v2 -> v3:
- Use Co-developed-by for Heiko's RK3588 contributions and add his
Signed-off-by
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index fc1fdbfd3162..b340973775c5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -2648,6 +2648,45 @@ dmac1: dma-controller@fea30000 {
#dma-cells = <1>;
};
+ can0: can@fea50000 {
+ compatible = "rockchip,rk3588-canfd";
+ reg = <0x0 0xfea50000 0x0 0x1000>;
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can0m0_pins>;
+ status = "disabled";
+ };
+
+ can1: can@fea60000 {
+ compatible = "rockchip,rk3588-canfd";
+ reg = <0x0 0xfea60000 0x0 0x1000>;
+ interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN1>, <&cru PCLK_CAN1>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN1>, <&cru SRST_P_CAN1>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can1m0_pins>;
+ status = "disabled";
+ };
+
+ can2: can@fea70000 {
+ compatible = "rockchip,rk3588-canfd";
+ reg = <0x0 0xfea70000 0x0 0x1000>;
+ interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN2>, <&cru PCLK_CAN2>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN2>, <&cru SRST_P_CAN2>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can2m0_pins>;
+ status = "disabled";
+ };
+
i2c1: i2c@fea90000 {
compatible = "rockchip,rk3588-i2c", "rockchip,rk3399-i2c";
reg = <0x0 0xfea90000 0x0 0x1000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/4] arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou
From: Cunhao Lu @ 2026-07-03 2:35 UTC (permalink / raw)
To: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Cunhao Lu, Heiko Stuebner
In-Reply-To: <20260703-master-v3-0-6d56de6fd2f3@qq.com>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
CAN0 is piped through the Q7-connector to the CAN-Header on the Haikou
base-board, so enable support for it there.
At least on RK3588-Tiger, the CAN clocks default to 99MHz, limiting
usable CAN bitrates without skew. Errata documentation mentions
300MHz as the default frequency on RK3568, so replicate this here
to allow more bitrates.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Cunhao Lu <1579567540@qq.com>
---
arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
index 873fbeb8daa1..6273e695b039 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
@@ -155,6 +155,12 @@ vddd_audio_1v6: regulator-vddd-audio-1v6 {
};
};
+&can0 {
+ assigned-clocks = <&cru CLK_CAN0>;
+ assigned-clock-rates = <300000000>;
+ status = "okay";
+};
+
&combphy2_psu {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/4] can: rockchip: add RK3588 CAN support
From: Cunhao Lu @ 2026-07-03 2:35 UTC (permalink / raw)
To: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Cunhao Lu, Heiko Stuebner
In-Reply-To: <20260703-master-v3-0-6d56de6fd2f3@qq.com>
Add support for the RK3588 CAN controller by introducing a dedicated
model ID and OF match entry.
The block is closely related to the existing RK3568 variants, but it
cannot reuse their match data unchanged. In particular, RK3588
encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
SoC-specific handling.
The RX FIFO count bitfield difference was found by comparing Rockchip's
vendor kernel 6.1 CAN support for RK3568 and RK3588. Runtime testing on
RK3588 also confirms that bits 7:5 are needed.
Enable the existing erratum 5 empty-FIFO workaround for RK3588.
Heiko reproduced erratum 6 on RK3588, so enable that workaround as
well.
Keep RKCANFD_QUIRK_CANFD_BROKEN enabled for RK3588, so CAN-FD stays
disabled for now. Local testing did not reproduce the two known CAN-FD
trigger frames that cause Error Interrupts on RK3568 variants. Instead,
RK3588 shows a different CAN-FD failure mode: CAN-FD frames without BRS
work in this setup, but BRS with a data bitrate different from the
nominal bitrate immediately drives the controller bus-off.
Co-developed-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
---
v2 -> v3:
- Use Co-developed-by for Heiko's RK3588 contributions and add his
Signed-off-by
- Collect Heiko's Reviewed-by and Tested-by tags
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 12 ++++++++++++
drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++++-
drivers/net/can/rockchip/rockchip_canfd.h | 26 +++++++++++++++++++++++++-
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e4ed..178d69edf1bb 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,13 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
RKCANFD_QUIRK_CANFD_BROKEN,
};
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
+ .model = RKCANFD_MODEL_RK3588,
+ .quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5 |
+ RKCANFD_QUIRK_RK3568_ERRATUM_6 |
+ RKCANFD_QUIRK_CANFD_BROKEN,
+};
+
static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
{
switch (model) {
@@ -57,6 +64,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
return "rk3568v2";
case RKCANFD_MODEL_RK3568V3:
return "rk3568v3";
+ case RKCANFD_MODEL_RK3588:
+ return "rk3588";
}
return "<unknown>";
@@ -846,6 +855,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
}, {
.compatible = "rockchip,rk3568v3-canfd",
.data = &rkcanfd_devtype_data_rk3568v3,
+ }, {
+ .compatible = "rockchip,rk3588-canfd",
+ .data = &rkcanfd_devtype_data_rk3588,
}, {
/* sentinel */
},
diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
index 475c0409e215..24e87daa1df0 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
{
const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
- return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
+ if (priv->devtype_data.model == RKCANFD_MODEL_RK3588)
+ return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
+
+ return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
}
int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7f54..82a617e4ca66 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -214,7 +214,8 @@
#define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
#define RKCANFD_REG_RX_FIFO_CTRL 0x118
-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)
#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)
@@ -331,6 +332,11 @@
* rarely with the standard clock of 300 MHz, but almost immediately
* at 80 MHz.
*
+ * Tests on the rk3588 show the same empty FIFO condition.
+ * In that setup rx_fifo_empty_errors increments when the bus
+ * transitions from idle to high CAN-FD load and stops growing once
+ * the bus reaches a steady state.
+ *
* To workaround this problem, check for empty FIFO with
* rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit
* early.
@@ -344,6 +350,8 @@
/* Erratum 6: The CAN controller's transmission of extended frames may
* intermittently change into standard frames
*
+ * Tests on the rk3588 show the same problem.
+ *
* Work around this issue by activating self reception (RXSTX). If we
* have pending TX CAN frames, check all RX'ed CAN frames in
* rkcanfd_rxstx_filter().
@@ -408,6 +416,18 @@
* cansend can0 002##07217010000000000
* DUT:
* candump any,0:0,#FFFFFFFF -cexdHtA
+ *
+ * Tests on the rk3588 show a different CAN-FD failure mode: these two
+ * CAN-FD frames do not trigger Error Interrupt or Error-Warning. CAN-FD
+ * frames without bitrate switching work in this setup, but BRS with a
+ * data bitrate different from the nominal bitrate drives the controller
+ * bus-off immediately.
+ *
+ * To reproduce:
+ * host:
+ * cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32 -b
+ * DUT:
+ * cansequence -rv can1 -f
*/
#define RKCANFD_QUIRK_CANFD_BROKEN BIT(12)
@@ -424,6 +444,9 @@
* cansequence -rv -i 1
*
* - TX starvation after repeated Bus-Off
+ * Tests on the rk3588 show the same problem. In a
+ * 10-cycle Bus-Off recovery test, 9 cycles failed to send after the
+ * controller restarted.
* To reproduce:
* host:
* sleep 3 && cangen can0 -I2 -Li -Di -p10 -g 0.0
@@ -434,6 +457,7 @@
enum rkcanfd_model {
RKCANFD_MODEL_RK3568V2 = 0x35682,
RKCANFD_MODEL_RK3568V3 = 0x35683,
+ RKCANFD_MODEL_RK3588 = 0x3588,
};
struct rkcanfd_devtype_data {
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/4] can: rockchip: add RK3588 CAN support
From: Cunhao Lu @ 2026-07-03 2:35 UTC (permalink / raw)
To: Marc Kleine-Budde, kernel, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Cunhao Lu, Heiko Stuebner
Add support for the RK3588 CAN controller.
RK3588 integrates three CAN-FD controllers that are closely related to
the existing Rockchip CAN-FD IP already supported in the kernel. The
RK3588 variant is not fully compatible with RK3568v2 because the RX
FIFO count register field has a different layout.
This series therefore:
- extends the existing Rockchip CAN-FD binding with the
rockchip,rk3588-canfd compatible
- adds a dedicated RK3588 match entry and devtype in the driver
- describes the three CAN controller nodes in rk3588-base.dtsi
- enables CAN on the RK3588 Tiger Haikou board
RK3588 encodes RX_FIFO_CNT in bits 7:5 instead of 6:4. This
difference was found by comparing Rockchip's vendor kernel 6.1 CAN
support for RK3568 and RK3588, and was also confirmed by runtime
testing.
RK3588 uses the existing erratum 5 empty-FIFO workaround. Based on
Heiko's testing, v2 also enables the erratum 6 workaround for extended
frames being transmitted as standard frames.
RKCANFD_QUIRK_CANFD_BROKEN remains enabled for RK3588, so CAN-FD stays
disabled for now. Local testing did not reproduce the two known CAN-FD
trigger frames that cause Error Interrupts on RK3568 variants. Instead,
RK3588 shows a different CAN-FD failure mode: CAN-FD frames without BRS
work in this setup, but BRS with a data bitrate different from the
nominal bitrate immediately drives the controller bus-off.
Tested on an embedfire,rk3588-lubancat-5io board with can0/can1
directly connected. Runtime testing used a 200 MHz CAN clock, nominal
bitrate 500 kbit/s, data bitrate 500 kbit/s and 1 Mbit/s, and included
stress and error-path coverage for the existing Rockchip errata handling.
v2 -> v3:
- Move the Changelog below ---
- Collect Heiko's Reviewed-by and the driver patch Tested-by tag
- Use Co-developed-by for Heiko's RK3588 contributions and add his
Signed-off-by
v1 -> v2:
- use real author name
- fold the single-compatible entries into an enum, as suggested by Krzysztof
- enable the erratum 6 workaround for RK3588 based on Heiko's testing
- add Heiko's RK3588 Tiger Haikou CAN enablement patch
- keep RKCANFD_QUIRK_CANFD_BROKEN enabled for RK3588 so CAN-FD stays disabled
- document the RK3588 CAN-FD/BRS bus-off failure mode
Signed-off-by: Cunhao Lu <1579567540@qq.com>
---
Cunhao Lu (3):
dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
can: rockchip: add RK3588 CAN support
arm64: dts: rockchip: add CAN-FD nodes for RK3588
Heiko Stuebner (1):
arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou
.../bindings/net/can/rockchip,rk3568v2-canfd.yaml | 4 ++-
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 ++++++++++++++++++++++
.../boot/dts/rockchip/rk3588-tiger-haikou.dts | 6 ++++
drivers/net/can/rockchip/rockchip_canfd-core.c | 12 +++++++
drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++-
drivers/net/can/rockchip/rockchip_canfd.h | 26 ++++++++++++++-
6 files changed, 89 insertions(+), 3 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260702-master-8c52be892a3f
Best regards,
--
Cunhao Lu <1579567540@qq.com>
^ permalink raw reply
* [PATCH v2] KVM: arm64: vgic: Fix race between LPI release and re-registration
From: Carlos López @ 2026-07-03 2:15 UTC (permalink / raw)
To: kvmarm, linux-kernel
Cc: Carlos López, Marc Zyngier, Oliver Upton, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon,
moderated list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
Fix a potential race between decrementing an LPI's reference count and
evicting that structure from the LPI xarray.
LPI structures are maintained in the VGIC LPI xarray (dist->lpi_xa).
When the reference count of an LPI structure drops to zero,
vgic_release_lpi_locked() removes the structure from the xarray and
frees it under the xarray lock.
However, the release of an LPI can race with a concurrent LPI
re-registration with the same INTID via vgic_add_lpi() on another CPU,
since the reference count drop and the xarray eviction are not performed
in a single atomic step. This can happen e.g. if the guest issues a
DISCARD while the LPI is still referenced from a vCPU's active-pending
list (ap_list), and the same INTID is re-mapped via MAPTI.
Particularly, vgic_release_lpi_locked() is called from two distinct
paths: direct release via vgic_put_irq(), and deferred release via
vgic_release_deleted_lpis(). During direct release, the issue can result
in deleting a newly registered LPI from the xarray:
CPU0 (Releasing LPI) CPU1 (Adding new LPI)
==================== =====================
vgic_put_irq()
__vgic_put_irq()
refcount_dec_and_test()
vgic_add_lpi()
xa_lock_irqsave(..);
old_irq = xa_load(&dist->lpi_xa, intid);
vgic_try_get_irq_ref(old_irq) == false
new IRQ inserted --> __xa_store(&dist->lpi_xa, intid, ..)
xa_unlock_irqrestore(..);
xa_lock_irqsave(..);
vgic_release_lpi_locked()
__xa_erase(&dist->lpi_xa, irq->intid); <-- BUG: new IRQ is erased
kfree_rcu(old_irq)
During the deferred release path, the old IRQ can be leaked:
CPU0 (Releasing LPI) CPU1 (Adding new LPI)
==================== =====================
vgic_put_irq_norelease()
__vgic_put_irq()
refcount_dec_and_test()
irq->pending_release = true
vgic_add_lpi()
xa_lock_irqsave(..);
old_irq = xa_load(&dist->lpi_xa, intid);
vgic_try_get_irq_ref() == false
BUG: old IRQ overwritten --> __xa_store(&dist->lpi_xa, intid, ..)
xa_unlock_irqrestore(..);
vgic_release_deleted_lpis()
xa_lock_irqsave(..);
xa_for_each() { .. } <-- old IRQ with pending_release = true
is gone, so it cannot be released
To fix the direct release path, move the reference count drop inside
the xarray lock, making sure that vgic_add_lpi() never encounters the
to-be-released LPI.
To fix the deferred release path, since the refcount drop must happen
under a raw spinlock, the same solution does not work. Instead, update
vgic_add_lpi(), so that if it evicts a non-NULL refcount=0 LPI from the
xarray, it takes on the responsibility of releasing it. If this happens,
vgic_release_deleted_lpis() will iterate the xarray normally and will
simply not find the already released structure.
Reported-by: Claude:claude-opus-4-6
Fixes: 3a08a6ca7c37 ("KVM: arm64: vgic-v3: Use bare refcount for VGIC LPIs")
Fixes: d54594accf73 ("KVM: arm64: vgic-v3: Erase LPIs from xarray outside of raw spinlocks")
Signed-off-by: Carlos López <clopez@suse.de>
---
v2:
* Address Sashiko's review. Fix the direct release path by decrementing the
refcount under the xarray spinlock, preventing a UAF that would have been
introduced in v1.
---
arch/arm64/kvm/vgic/vgic-its.c | 10 +++++++++-
arch/arm64/kvm/vgic/vgic.c | 5 +++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 67d107e9a77d..577286069368 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -116,7 +116,15 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid,
kfree(irq);
irq = oldirq;
} else {
- ret = xa_err(__xa_store(&dist->lpi_xa, intid, irq, 0));
+ /*
+ * The entry is either empty or contains a dead LPI (refcount=0)
+ * from the deferred release path, pending cleanup by
+ * vgic_release_deleted_lpis(). Evict and free it if present.
+ */
+ oldirq = __xa_store(&dist->lpi_xa, intid, irq, 0);
+ ret = xa_err(oldirq);
+ if (!ret && oldirq)
+ kfree_rcu(oldirq, rcu);
}
xa_unlock_irqrestore(&dist->lpi_xa, flags);
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 5a4768d8cd4f..c32e6c9777e5 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -167,11 +167,12 @@ void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq)
guard(spinlock_irqsave)(&dist->lpi_xa.xa_lock);
}
- if (!__vgic_put_irq(kvm, irq))
+ if (!irq_is_lpi(kvm, irq->intid))
return;
xa_lock_irqsave(&dist->lpi_xa, flags);
- vgic_release_lpi_locked(dist, irq);
+ if (refcount_dec_and_test(&irq->refcount))
+ vgic_release_lpi_locked(dist, irq);
xa_unlock_irqrestore(&dist->lpi_xa, flags);
}
base-commit: 1ee27dacbe5dc4def481794d899d67b0d4570094
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Kemeng Shi @ 2026-07-03 1:45 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, lpieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <87h5mh6o1q.wl-maz@kernel.org>
在 2026/7/3 6:10:09, Marc Zyngier 写道:
> On Thu, 02 Jul 2026 04:30:48 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> Multiple ITS units may exist in a system. When an error occurs, it is
>> difficult to identify which ITS triggered it because most error logs
>> lack the ITS address. Some logs already include this information and
>> is useful for debugging. Add the ITS address to the remaining error
>> logs so that all ITS-related errors can be consistently attributed to
>> a specific ITS instance.
>
> I already said *no* to this.
>
> If you want to log errors, implement a PMU or RAS driver that reports
> errors on a per ITS basis, in a way that is collectable by existing
> tooling.
>
> The kernel log is not the place for your sorry debug hacks, which is
> in general not readable by normal users. And I'd rather remove the
> other instances as a matter of consistency.
>
Will drop this in next version...> M.
>
^ permalink raw reply
* Re: [PATCH v4 3/6] irqchip/gic-v3-its: Fix leak in its_vpe_irq_domain_alloc()
From: Kemeng Shi @ 2026-07-03 1:44 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, jason, lpieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <87fr216nx2.wl-maz@kernel.org>
在 2026/7/3 6:12:57, Marc Zyngier 写道:
>> When its_irq_gic_domain_alloc() fails, the following
>> its_vpe_irq_domain_free() skips calling its_vep_teardown() for the
>> corresponding irq. Call its_vpe_teardown() when its_irq_gic_domain_alloc()
>> is failedto avoid the leak issue.
>>
>> Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown")
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 3e4edcb64065..8968bedefdba 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -4666,8 +4666,10 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq
>> break;
>> err = its_irq_gic_domain_alloc(domain, virq + i,
>> vm->vpes[i]->vpe_db_lpi);
>> - if (err)
>> + if (err) {
>> + its_vpe_teardown(vm->vpes[i]);
>> break;
>> + }
> There is already a spot for error handling in this function, we don't
> need a second one.
When its_irq_gic_domain_alloc() fails at index i, its_vpe_init(vpes[i])
has already succeeded but the exisiting its_vpe_irq_domain_free(domain, virq, i)
only tears down VPEs with index [0, i - 1], so its_vpe_teardown(vpes[i]) is still
needed.
So I guess you mean we can increase index when its_irq_gic_domain_alloc() fails to
free the resource with existing error handling?
Please correct me if I'm miss anything.
Thanks.
^ permalink raw reply
* Re: [PATCH v3] Subject: [PATCH] net: gro: fix double aggregation of flush-marked skbs
From: Shiming Cheng (成诗明) @ 2026-07-03 1:26 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, dsahern@kernel.org,
imv4bel@gmail.com, linux-mediatek@lists.infradead.org,
alice@isovalent.com, daniel.zahka@gmail.com,
eilaimemedsnaimel@gmail.com, nbd@nbd.name, horms@kernel.org,
kuba@kernel.org, willemb@google.com, pabeni@redhat.com,
edumazet@google.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
davem@davemloft.net, AngeloGioacchino Del Regno,
sd@queasysnail.net
Cc: Lena Wang (王娜), stable@vger.kernel.org
In-Reply-To: <3f540a8a-4167-4727-9516-6fb91335333f@redhat.com>
On Thu, 2026-07-02 at 12:02 +0200, Paolo Abeni wrote:
> Note: the patch subject is quite uncorrected
>
> On 6/30/26 4:35 AM, Shiming Cheng wrote:
> > The new skb_gro_receive_list() function is missing a critical
> > safety check
> > present in the legacy skb_gro_receive() path. Specifically, it does
> > not
> > validate NAPI_GRO_CB(skb)->flush before allowing packet
> > aggregation.
>
> skb_gro_receive_list() is not very "new" and definitely
> skb_gro_receive() is not legacy.
>
The wording here may need to be adjusted. I'm referring to the
chronological order/which one came first.
Updated:
The skb_gro_receive_list() function is missing a critical safety check
that exists in the skb_gro_receive() implementation. Specifically, it
does not validate NAPI_GRO_CB(skb)->flush before allowing packet
aggregation
> > This allows already-GRO'd packets with existing frag_list to be
> > re-aggregated into a new GRO session, corrupting the frag_list
> > chain
> > structure. When skb_segment() attempts to unpack these malformed
> > packets,
> > it encounters invalid state and triggers a kernel panic.
> >
> > Scenario (Tethering/Device forwarding):
> > 1. Driver: Generated aggregated packet P1 via LRO with frag_list
> > 2. Dev A: Receives aggregated fraglist packet and flush flag set
> > 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called
> > 4. Missing flush check allows re-aggregation despite flush flag
> > 5. Frag_list chain becomes corrupted (loops or dangling refs)
> > 6. Dev B: TX path calls skb_segment(), crashes on corrupted
> > frag_list
>
> I can't parse the above. Is this something that can happen with in-
> tree
> drivers or do you need OoT module to trigger it? In any case please
> clarify the actual order and the involved driver. Possibly a stack
> strace leading to the critical aggregation could help.
>
We are hitting a GRO/LRO-related failure in a tethering scenario.
On the RX path, the driver performs an LRO-style aggregation before
handing packets to the stack. When `nfrags` exceeds 17, additional
packets are no longer appended to the frags array, but are attached
through `skb_shared_info(skb)->frag_list`. After that, the driver still
passes the skb into `napi_gro_receive()`, so the same traffic goes
through a second aggregation stage in GRO.
In our tethering case, `NAPI_GRO_CB(skb)->is_flist = !sk`, so
`is_flist` becomes `true`, and the skb follows the `SKB_GSO_FRAGLIST`
path, eventually reaching `skb_gro_receive_list()`. The issue is that
some later skbs may already carry their own `frag_list` as a result of
the first aggregation done by the driver. When GRO links those skbs
again into a new `frag_list` chain, the resulting skb layout becomes
more complex than expected and eventually triggers the kernel
exception.
Actual skb relationships when the issue occurs is as follows.
A->frag_list = B
B->next = C
C->frag_list = D
In the observed layout, A already links `B -> C` through `frag_list`,
while C itself still carries its own `frag_list -> D`. In other words,
when GRO continues chaining skbs in `skb_gro_receive_list()`, the later
skb is no longer a simple standalone packet, but an skb that already
carries `shared_info->frag_list` from the driver-side LRO stage. This
creates a nested `frag_list` layout and eventually triggers the kernel
exception in our case.
> > Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return
> > check in
> > skb_gro_receive_list(), matching the defensive programming pattern
> > of
> > skb_gro_receive().
> >
> > Fixes: 8928756d53d5 ("net: add fraglist GRO/GSO support")
>
> The fix tag is wrong, should be:
>
> Fixes: 3a1296a38d0c ('net: Support GRO/GSO fraglist chaining.')
>
I will update it in the next patch.
> /P
>
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: errata: Workaround NVIDIA Olympus device store/load ordering
From: Shanker Donthineni @ 2026-07-03 0:51 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Vladimir Murzin, Jason Gunthorpe,
linux-arm-kernel, Mark Rutland, linux-kernel, linux-doc,
Vikram Sethi, Jason Sequeira
In-Reply-To: <akPQ8F3OgER621UP@willie-the-truck>
Hi Will,
On 6/30/2026 9:21 AM, Will Deacon wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu, Jun 25, 2026 at 01:24:24PM -0500, Shanker Donthineni wrote:
>> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
>> observed by a peripheral before an older, non-overlapping Device-nGnR*
>> store to the same peripheral. This breaks the program-order guarantee
>> that software expects for Device-nGnR* accesses and can leave a
>> peripheral in an incorrect state, as a load is observed before an
>> earlier store takes effect.
>>
>> The erratum can occur only when all of the following apply:
>>
>> - A PE executes a Device-nGnR* store followed by a younger
>> Device-nGnR* load.
>> - The store is not a store-release.
>> - The accesses target the same peripheral and do not overlap in bytes.
>> - There is at most one intervening Device-nGnR* store in program
>> order, and there are no intervening Device-nGnR* loads.
>> - There is no DSB, and no DMB that orders loads, between the store and
>> the load.
> Does that mean that a DMB LD between the store and the load would
> solve the problem?
I appreciate your suggestion to leave __raw_writeX() unchanged and apply
the workaround on the read side. It results in a much better
approach, write-combining performance is preserved and avoids dgh()
promotion to dmb.
The hardware team has confirmed that DMB OSH between the store and load
prevents T410-OLY-1027. They are still validating whether DMB LD is
sufficient, so I do not want to rely on DMB LD until that confirmation is
available.
> It would be interesting to see how your benchmarks motivating patch 2
> look if you leave __raw_writeX as-is and instead add a barrier in
> __raw_readX before the load instruction.
I profiled memcpy_fromio() after implementing your suggested read-side
workaround using DMB OSH:
- Patch 1 leaves __raw_writeX() unchanged and inserts DMB OSH before
each load in __raw_readX().
- Patch 2 provides an arm64 memcpy_fromio() implementation that applies
one DMB OSH before the block copy and then uses direct Device loads.
With patch 2 applying the barrier once per block, the results show no
noticeable performance regression when the workaround is active. The
micro-benchmark uses a write-combined MMIO buffer and is pinned to one
PE. The loop count is adjusted so each row performs approximately 10,000
64-bit MMIO loads in total. The table reports the per-call latency of
memcpy_fromio() in nanoseconds, with CPU cycles measured using the PMU
cycle counter shown in parentheses.
+-------+--------------------+----------------------+------------------------+
| size | WAR off ns (cyc) | OSH/load P1 ns (cyc) | OSH/block P1+P2 ns(cyc)|
+-------+--------------------+----------------------+------------------------+
| 8B | 830.4 (2735) | 835.0 (2750) | 835.1 (2750) |
| 16B | 1660.1 (5468) | 1669.6 (5499) | 1664.8 (5484) |
| 32B | 3319.7 (10934) | 3339.1 (10998) | 3324.1 (10953) |
| 64B | 6638.6 (21866) | 6677.5 (21994) | 6642.3 (21880) |
| 128B | 13275.8 (43729) | 13355.3 (43989) | 13279.0 (43747) |
| 256B | 26549.7 (87480) | 26714.5 (87993) | 26552.5 (87475) |
+-------+--------------------+----------------------+------------------------+
Micro-bench test:
local_irq_save(flags);
off = 0U;
c0 = wc_pmu_read();
t0 = ktime_get();
for (i = 0UL; i < 10000; i++) {
memcpy_fromio(dst, map + off, n * sizeof(u64));
off ^= buf_size;
}
t1 = ktime_get();
c1 = wc_pmu_read();
local_irq_restore(flags);
Patch 2:
void memcpy_fromio(void *dst, const volatile void __iomem *src, size_t count)
{
...
asm volatile(ALTERNATIVE("nop", "dmb osh",
ARM64_WORKAROUND_NVIDIA_OLYMPUS_1027)
: : : "memory");
while (count &&
!IS_ALIGNED((__force unsigned long)src, sizeof(u64))) {
u8 val;
asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
"ldarb %w0, [%1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (src));
*(u8 *)dst = val;
src++;
dst++;
count--;
}
while (count >= sizeof(u64)) {
u64 val;
asm volatile(ALTERNATIVE("ldr %0, [%1]",
"ldar %0, [%1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (src));
*(u64 *)dst = val;
src += sizeof(u64);
dst += sizeof(u64);
count -= sizeof(u64);
}
while (count) {
u8 val;
asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
"ldarb %w0, [%1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (src));
*(u8 *)dst = val;
src++;
dst++;
count--;
}
}
I am also discussing with the hardware team to understand any broader
implications of using a read-side DMB instead of store-release writes,
and to evaluate the correctness and performance differences between
DMB OSH and DMB LD. If we proceed with the load-side workaround, I will
drop patch 2 and keep the implementation limited to the raw read
helpers. I will post v5 after receiving their feedback.
-Shanker
^ permalink raw reply
* Re: [PATCH v3 0/5] dmaengine: sun6i-dma: Add support for Allwinner A733 DMA controller
From: Enzo Adriano @ 2026-07-03 0:12 UTC (permalink / raw)
To: Yuanshen Cao
Cc: Vinod Koul, Frank Li, Chen-Yu Tsai, Maxime Ripard, dmaengine,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland
In-Reply-To: <20260622-sun60i-a733-dma-v3-0-f697ef296cbc@gmail.com>
Hi Yuanshen,
Following up on my earlier note on patch 1: I have Cubie A7S hardware
on hand and boot test kernels over serial routinely. If runtime
confirmation of the DMA controller would help the next revision, say
what you would like exercised and I will run it.
(AI-assisted, as before.)
Thanks,
Enzo
^ permalink raw reply
* Re: [RFC PATCH 0/9] pinctrl: sunxi: Allwinner A733 support
From: Enzo Adriano @ 2026-07-03 0:07 UTC (permalink / raw)
To: Andre Przywara
Cc: Linus Walleij, Chen-Yu Tsai, Yangtao Li, linux-gpio,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland
In-Reply-To: <20250821004232.8134-1-andre.przywara@arm.com>
Hi Andre,
In case it helps when you next spin this series: these patches have
been part of my local A733 boot stack on a Radxa Cubie A7S for a
while now. UART console, MMC, LEDs and USB all sit on top of them
here and I have seen no problems attributable to the pinctrl driver.
Happy to turn around tests on real hardware whenever a v2 shows up,
or to run anything specific in the meantime.
Testing here is AI-assisted (Claude Code).
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH v3 0/8] clk: sun6i-rtc: Add support for Allwinner A733 SoC
From: Enzo Adriano @ 2026-07-02 23:59 UTC (permalink / raw)
To: Jerome Brunet
Cc: Brian Masney, Michael Turquette, Stephen Boyd, Chen-Yu Tsai,
Maxime Ripard, Junhui Liu, Alexandre Belloni, linux-clk,
linux-rtc, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Hi Jerome,
I gave v3 a spin on a Radxa Cubie A7S here: it applied cleanly to my
local A733 stack, the RTC probes as rtc0, hwclock set and read-back
work, and the oscillator tree in clk_summary looks as expected. If
there are specific checks that would save you time for this or a
future revision, tell me what you would like exercised and I will
report back.
For transparency, the test harness is AI-assisted (Claude Code) and
results are verified against the captured serial logs.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH RFC 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM
From: Enzo Adriano @ 2026-07-02 23:51 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Richard Cochran, linux-clk,
linux-riscv, netdev, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland
In-Reply-To: <DJO79318OW0A.2RDQOAXRTHNCW@pigmoral.tech>
Hi Junhui,
Good to hear from you, and glad the series stays in your hands. I hope
the move went smoothly. No rush at all from my side, please take
whatever time you need to settle in.
For whenever you get to v2: I posted register-check notes on five of
the patches earlier today, so they are on the list to pick through at
your convenience. Take from them whatever is useful and ignore the
rest.
One offer, entirely take-it-or-leave-it: I have three Cubie A7S boards
here with serial consoles attached, and I am eager to put them to
use. I can boot v2 the day you post it and report back, if that would
save you time.
On my side I have Cubie A7S board DTS support staged to follow once
the clock and pinctrl pieces land, so whenever v2 arrives it will get
exercised on real hardware right away.
For transparency: I use AI assistance (Claude Code) for the register
comparisons and the test harness, and I check each finding against the
manual and vendor sources before posting.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-07-02 23:50 UTC (permalink / raw)
To: Nicolin Chen
Cc: Pranjal Shrivastava, Mostafa Saleh, will, robin.murphy, joro,
kees, baolu.lu, kevin.tian, miko.lenczewski, linux-arm-kernel,
iommu, linux-kernel, stable, jamien
In-Reply-To: <aka7N6oLVq3CoBqn@nvidia.com>
On Thu, Jul 02, 2026 at 12:25:43PM -0700, Nicolin Chen wrote:
> On Thu, Jul 02, 2026 at 11:41:57AM -0300, Jason Gunthorpe wrote:
> > On Wed, Jul 01, 2026 at 01:36:29PM +0000, Pranjal Shrivastava wrote:
> >
> > > However, I agree with the overall problem, i.e. IF an active device
> > > unmaps the DMA addr after the transaction in the previous kernel,
> > > (with the SMMU powered ON) but the TLBI was missed due to a crash/panic,
> > > Any new DMA in the new kernel may alias onto a memory in the previous
> > > (crashed) kernel, not the kdump kernel.
> >
> > It looks like there is an issue in this series, it isn't doing
> > anything with the VMIDs.
> >
> > The VMIDs that are in-used by the adopted stream table have to be
> > removed from the idr as well (and similarly for ASID if we don't have
> > VMID HW support).
> >
> > Then the VMIDs that may be dirtied by the prior kernel remain isolated
> > and are never re-used by the new kernel. When the new kernel wants to
> > do DMA it will replace the STE with a new, clean VMID, and there is no
> > problem.
>
> I see. I assume the reserved VMID for the kdump kernel will be a
> clean VMID (!=0). That should guarantee different cache tags.
You will also have to change things to allocate the kernel global vmid
from the IDR, it will usually be 0 but not for kdump. Then you have to
find all the places where the 0 is implicitly placed and put in the
actual value.
> But, do we have to scan CDs for ASID? I wonder if we could limit
> to ARM_SMMU_FEAT_TRANS_S2 only, as this series does not memremap
> CDs at all..
Yeah, I would limit to S2 for now
Jason
^ permalink raw reply
* Re: (subset) [PATCH v5 0/5] Devicetree support for Glymur GPU
From: Bjorn Andersson @ 2026-07-02 23:40 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rob Clark, Sean Paul, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Will Deacon,
Robin Murphy, Joerg Roedel, Akhil P Oommen
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Rajendra Nayak, Konrad Dybcio,
Dmitry Baryshkov, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com>
On Fri, 22 May 2026 15:41:56 +0530, Akhil P Oommen wrote:
> This series adds the necessary Device Tree bits to enable GPU support
> on the Glymur-based CRD devices. The Adreno X2-85 GPU present in Glymur
> chipsets is based on the new Adreno A8x family of GPUs. It features a new
> slice architecture with 4 slices, significantly higher bandwidth
> throughput compared to mobile counterparts, raytracing support, and the
> highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among other
> improvements.
>
> [...]
Applied, thanks!
[3/5] arm64: dts: qcom: glymur: Add GPU smmu node
commit: b90a899027ae9def17cff2c566f50e406bb95307
[4/5] arm64: dts: qcom: Add GPU support for Glymur
commit: b6ff8cec8aaac2128a4fe82ccfba263cf645cc68
[5/5] arm64: dts: qcom: glymur: Add GPU cooling
commit: 7d260e77d88fa026a1e181cecee545687fa80f92
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox