* [PATCH v6 2/3] PCI: Allow ATS to be always on for pre-CXL devices
From: Nicolin Chen @ 2026-05-21 20:34 UTC (permalink / raw)
To: jgg, will
Cc: robin.murphy, joro, bhelgaas, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <cover.1779392420.git.nicolinc@nvidia.com>
Some NVIDIA GPU/NIC devices, though they don't implement CXL config space,
have many CXL-like properties. Call this kind "pre-CXL".
Similar to CXL.cache capability, these pre-CXL devices also require the ATS
function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on"
v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases.
Introduce pci_dev_specific_ats_required() quirk function to scan a list of
IDs for these devices. Then, include it in pci_ats_required().
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/pci/pci.h | 9 +++++++++
drivers/pci/ats.c | 3 ++-
drivers/pci/quirks.c | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a2..e8ad27abb1cfe 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1155,6 +1155,15 @@ static inline int pci_dev_specific_reset(struct pci_dev *dev, bool probe)
}
#endif
+#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_PCI_ATS)
+bool pci_dev_specific_ats_required(struct pci_dev *dev);
+#else
+static inline bool pci_dev_specific_ats_required(struct pci_dev *dev)
+{
+ return false;
+}
+#endif
+
#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
int acpi_get_rc_resources(struct device *dev, const char *hid, u16 segment,
struct resource *res);
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 84cd06d74fc9c..96efa00d97433 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -247,7 +247,8 @@ bool pci_ats_required(struct pci_dev *pdev)
if (pdev->is_virtfn)
pdev = pci_physfn(pdev);
- return pci_cxl_ats_required(pdev);
+ return pci_cxl_ats_required(pdev) ||
+ pci_dev_specific_ats_required(pdev);
}
EXPORT_SYMBOL_GPL(pci_ats_required);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc02..c0242f3e9f063 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5715,6 +5715,48 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1457, quirk_intel_e2000_no_ats);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1459, quirk_intel_e2000_no_ats);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x145a, quirk_intel_e2000_no_ats);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x145c, quirk_intel_e2000_no_ats);
+
+static bool quirk_nvidia_gpu_ats_required(struct pci_dev *pdev)
+{
+ switch (pdev->device) {
+ case 0x2e00 ... 0x2e3f: /* GB20B */
+ return true;
+ }
+ return false;
+}
+
+static const struct pci_dev_ats_required {
+ u16 vendor;
+ u16 device;
+ bool (*ats_required)(struct pci_dev *dev);
+} pci_dev_ats_required[] = {
+ /* NVIDIA GPUs */
+ { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, quirk_nvidia_gpu_ats_required },
+ /* NVIDIA CX10 Family NVlink-C2C */
+ { PCI_VENDOR_ID_MELLANOX, 0x2101, NULL },
+ { 0 }
+};
+
+/*
+ * Some NVIDIA devices do not implement CXL config space, but present as PCIe
+ * devices that can issue CXL-like cache operations like CXL.cache. Thus, they
+ * require ATS to obtain host physical addresses, like pci_cxl_ats_required().
+ */
+bool pci_dev_specific_ats_required(struct pci_dev *pdev)
+{
+ const struct pci_dev_ats_required *i;
+
+ for (i = pci_dev_ats_required; i->vendor; i++) {
+ if (i->vendor != pdev->vendor)
+ continue;
+ if (i->ats_required && i->ats_required(pdev))
+ return true;
+ if (!i->ats_required && i->device == pdev->device)
+ return true;
+ }
+
+ return false;
+}
#endif /* CONFIG_PCI_ATS */
/* Freescale PCIe doesn't support MSI in RC mode */
--
2.43.0
^ permalink raw reply related
* [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
From: Nicolin Chen @ 2026-05-21 20:34 UTC (permalink / raw)
To: jgg, will
Cc: robin.murphy, joro, bhelgaas, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <cover.1779392420.git.nicolinc@nvidia.com>
Controlled by IOMMU drivers, ATS can be enabled "on demand", when a given
PASID on a device is attached to an I/O page table. This is working, even
when a device has no translation on its RID (i.e., RID is IOMMU bypassed).
However, certain PCIe devices require non-PASID ATS on their RID even when
the RID is IOMMU bypassed. Call this "ATS always on" in IOMMU term.
For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache:
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other words, the CXL.cache capability requires ATS; otherwise, it can't
access host physical memory.
Introduce a new pci_ats_required() helper for the IOMMU driver to scan a
PCI device and shift ATS policies between "on demand" and "always on".
Add the support for CXL.cache devices first. Pre-CXL devices will be added
in quirks.c file.
Note that pci_ats_required() validates against pci_ats_supported(), so we
ensure that untrusted devices (e.g. external ports) will not be always on.
This maintains the existing ATS security policy regarding potential side-
channel attacks via ATS.
Cc: linux-cxl@vger.kernel.org
Suggested-by: Vikram Sethi <vsethi@nvidia.com>
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
include/linux/pci-ats.h | 3 +++
include/uapi/linux/pci_regs.h | 1 +
drivers/pci/ats.c | 46 +++++++++++++++++++++++++++++++++++
3 files changed, 50 insertions(+)
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index 75c6c86cf09dc..f3723b6861294 100644
--- a/include/linux/pci-ats.h
+++ b/include/linux/pci-ats.h
@@ -12,6 +12,7 @@ int pci_prepare_ats(struct pci_dev *dev, int ps);
void pci_disable_ats(struct pci_dev *dev);
int pci_ats_queue_depth(struct pci_dev *dev);
int pci_ats_page_aligned(struct pci_dev *dev);
+bool pci_ats_required(struct pci_dev *dev);
#else /* CONFIG_PCI_ATS */
static inline bool pci_ats_supported(struct pci_dev *d)
{ return false; }
@@ -24,6 +25,8 @@ static inline int pci_ats_queue_depth(struct pci_dev *d)
{ return -ENODEV; }
static inline int pci_ats_page_aligned(struct pci_dev *dev)
{ return 0; }
+static inline bool pci_ats_required(struct pci_dev *dev)
+{ return false; }
#endif /* CONFIG_PCI_ATS */
#ifdef CONFIG_PCI_PRI
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 14f634ab9350d..6ac45be1008b8 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -1349,6 +1349,7 @@
/* CXL r4.0, 8.1.3: PCIe DVSEC for CXL Device */
#define PCI_DVSEC_CXL_DEVICE 0
#define PCI_DVSEC_CXL_CAP 0xA
+#define PCI_DVSEC_CXL_CACHE_CAPABLE _BITUL(0)
#define PCI_DVSEC_CXL_MEM_CAPABLE _BITUL(2)
#define PCI_DVSEC_CXL_HDM_COUNT __GENMASK(5, 4)
#define PCI_DVSEC_CXL_CTRL 0xC
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index ec6c8dbdc5e9c..84cd06d74fc9c 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -205,6 +205,52 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
return 0;
}
+/*
+ * CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source requests on
+ * CXL.cache, devices need to get the Host Physical Address (HPA) from the Host
+ * by means of an ATS request on CXL.io.
+ *
+ * In other words, CXL.cache devices cannot access host physical memory without
+ * ATS.
+ *
+ * Check Cache_Capable instead of Cache_Enable because CXL.cache may be enabled
+ * after the caller uses this to make its ATS decision.
+ */
+static bool pci_cxl_ats_required(struct pci_dev *pdev)
+{
+ int offset;
+ u16 cap;
+
+ offset = pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_CXL,
+ PCI_DVSEC_CXL_DEVICE);
+ if (!offset)
+ return false;
+
+ if (pci_read_config_word(pdev, offset + PCI_DVSEC_CXL_CAP, &cap))
+ return false;
+
+ return cap & PCI_DVSEC_CXL_CACHE_CAPABLE;
+}
+
+/**
+ * pci_ats_required - Whether the PCI device requires ATS
+ * @pdev: the PCI device
+ *
+ * Returns true, if the PCI device requires ATS for basic functional operation.
+ */
+bool pci_ats_required(struct pci_dev *pdev)
+{
+ if (!pci_ats_supported(pdev))
+ return false;
+
+ /* A VF inherits its PF's requirement for ATS function */
+ if (pdev->is_virtfn)
+ pdev = pci_physfn(pdev);
+
+ return pci_cxl_ats_required(pdev);
+}
+EXPORT_SYMBOL_GPL(pci_ats_required);
+
#ifdef CONFIG_PCI_PRI
void pci_pri_init(struct pci_dev *pdev)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v6 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
From: Nicolin Chen @ 2026-05-21 20:34 UTC (permalink / raw)
To: jgg, will
Cc: robin.murphy, joro, bhelgaas, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <cover.1779392420.git.nicolinc@nvidia.com>
When a device's default substream attaches to an identity domain, the SMMU
driver currently sets the device's STE between two modes:
Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1
Mode 2: Cfg=bypass (EATS is ignored by HW)
When there is an active PASID (non-default substream), mode 1 is used. And
when there is no PASID support or no active PASID, mode 2 is used.
The driver will also downgrade an STE from mode 1 to mode 2, when the last
active substream becomes inactive.
However, there are PCIe devices that demand ATS to be always on. For these
devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2.
Change the driver accordingly:
- always use the mode 1
- never downgrade to mode 2
- allocate and retain a CD table (see note below)
Note that these devices might not support PASID, i.e. doing non-PASID ATS.
In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to
a !0 value in order to keep the S1DSS field effective. Thus, when a master
requires ats_always_on, set its s1cdmax to at least 1, meaning that the CD
table will have a dummy entry (SSID=1) that will never be used.
Now for these devices, arm_smmu_cdtab_allocated() will always return true,
v.s. false prior to this change. When its default substream is attached to
an IDENTITY domain, its first CD is NULL in the table, which is a totally
valid case. Thus, add "!master->ats_always_on" to the condition.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 81 ++++++++++++++++++---
2 files changed, 73 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index ef42df4753ec4..8c3600f4364c5 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -943,6 +943,7 @@ struct arm_smmu_master {
bool ats_enabled : 1;
bool ste_ats_enabled : 1;
bool stall_enabled;
+ bool ats_always_on;
unsigned int ssid_bits;
unsigned int iopf_refcount;
};
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e8d7dbe495f03..4afdb775e0722 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1742,8 +1742,11 @@ void arm_smmu_clear_cd(struct arm_smmu_master *master, ioasid_t ssid)
if (!arm_smmu_cdtab_allocated(&master->cd_table))
return;
cdptr = arm_smmu_get_cd_ptr(master, ssid);
- if (WARN_ON(!cdptr))
+ if (!cdptr) {
+ /* Only ats_always_on allows a NULL CD on default substream */
+ WARN_ON(!master->ats_always_on || ssid);
return;
+ }
arm_smmu_write_cd_entry(master, ssid, cdptr, &target);
}
@@ -1756,6 +1759,22 @@ static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master)
struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
cd_table->s1cdmax = master->ssid_bits;
+
+ /*
+ * When a device doesn't support PASID (non default SSID), ssid_bits is
+ * set to 0. This also sets S1CDMAX to 0, which disables the substreams
+ * and ignores the S1DSS field.
+ *
+ * On the other hand, if a device demands ATS to be always on even when
+ * its default substream is IOMMU bypassed, it has to use EATS that is
+ * only effective with an STE (CFG=S1translate, S1DSS=Bypass). For such
+ * use cases, S1CDMAX has to be !0, in order to make use of S1DSS/EATS.
+ *
+ * Set S1CDMAX no lower than 1. This would add a dummy substream in the
+ * CD table but it should never be used by an actual CD.
+ */
+ if (master->ats_always_on)
+ cd_table->s1cdmax = max_t(u8, cd_table->s1cdmax, 1);
max_contexts = 1 << cd_table->s1cdmax;
if (!(smmu->features & ARM_SMMU_FEAT_2_LVL_CDTAB) ||
@@ -3854,9 +3873,12 @@ static int arm_smmu_blocking_set_dev_pasid(struct iommu_domain *new_domain,
if (!arm_smmu_ssids_in_use(&master->cd_table)) {
struct iommu_domain *sid_domain =
iommu_driver_get_domain_for_dev(master->dev);
+ bool ats_always_on = master->ats_always_on &&
+ sid_domain->type != IOMMU_DOMAIN_BLOCKED;
+ bool downgrade = sid_domain->type == IOMMU_DOMAIN_IDENTITY ||
+ sid_domain->type == IOMMU_DOMAIN_BLOCKED;
- if (sid_domain->type == IOMMU_DOMAIN_IDENTITY ||
- sid_domain->type == IOMMU_DOMAIN_BLOCKED)
+ if (!ats_always_on && downgrade)
sid_domain->ops->attach_dev(sid_domain, dev,
sid_domain);
}
@@ -3875,6 +3897,8 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain,
.old_domain = old_domain,
.ssid = IOMMU_NO_PASID,
};
+ bool ats_always_on = master->ats_always_on &&
+ s1dss != STRTAB_STE_1_S1DSS_TERMINATE;
/*
* Do not allow any ASID to be changed while are working on the STE,
@@ -3886,7 +3910,7 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain,
* If the CD table is not in use we can use the provided STE, otherwise
* we use a cdtable STE with the provided S1DSS.
*/
- if (arm_smmu_ssids_in_use(&master->cd_table)) {
+ if (ats_always_on || arm_smmu_ssids_in_use(&master->cd_table)) {
/*
* If a CD table has to be present then we need to run with ATS
* on because we have to assume a PASID is using ATS. For
@@ -4215,6 +4239,44 @@ static void arm_smmu_remove_master(struct arm_smmu_master *master)
kfree(master->build_invs);
}
+static int arm_smmu_master_prepare_ats(struct arm_smmu_master *master)
+{
+ bool s1p = master->smmu->features & ARM_SMMU_FEAT_TRANS_S1;
+ unsigned int stu = __ffs(master->smmu->pgsize_bitmap);
+ struct pci_dev *pdev;
+ int ret;
+
+ if (!dev_is_pci(master->dev))
+ return 0;
+ pdev = to_pci_dev(master->dev);
+
+ if (!arm_smmu_ats_supported(master)) {
+ if (pci_ats_required(pdev)) {
+ dev_err_once(master->dev, "SMMU doesn't support ATS\n");
+ return -EOPNOTSUPP;
+ }
+ return 0;
+ }
+
+ ret = pci_prepare_ats(pdev, stu);
+ if (ret || !pci_ats_required(pdev))
+ return ret;
+
+ /*
+ * S1DSS is required for ATS to be always on for identity domain cases.
+ * However, the S1DSS field is ignored if !IDR0_S1P or !IDR1_SSIDSIZE.
+ */
+ if (!s1p || !master->smmu->ssid_bits) {
+ dev_err_once(master->dev,
+ "SMMU doesn't support ATS to be always on\n");
+ return -EOPNOTSUPP;
+ }
+
+ master->ats_always_on = true;
+
+ return arm_smmu_alloc_cd_tables(master);
+}
+
static struct iommu_device *arm_smmu_probe_device(struct device *dev)
{
int ret;
@@ -4263,14 +4325,15 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
smmu->features & ARM_SMMU_FEAT_STALL_FORCE)
master->stall_enabled = true;
- if (dev_is_pci(dev)) {
- unsigned int stu = __ffs(smmu->pgsize_bitmap);
-
- pci_prepare_ats(to_pci_dev(dev), stu);
- }
+ ret = arm_smmu_master_prepare_ats(master);
+ if (ret)
+ goto err_disable_pasid;
return &smmu->iommu;
+err_disable_pasid:
+ arm_smmu_disable_pasid(master);
+ arm_smmu_remove_master(master);
err_free_master:
kfree(master);
return ERR_PTR(ret);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
From: Bjorn Helgaas @ 2026-05-21 20:57 UTC (permalink / raw)
To: Nicolin Chen
Cc: jgg, will, robin.murphy, joro, bhelgaas, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl, nirmoyd
In-Reply-To: <05044d2113e20d81f96677ba53605311662b6b10.1779392420.git.nicolinc@nvidia.com>
On Thu, May 21, 2026 at 01:34:20PM -0700, Nicolin Chen wrote:
> Controlled by IOMMU drivers, ATS can be enabled "on demand", when a given
> PASID on a device is attached to an I/O page table. This is working, even
> when a device has no translation on its RID (i.e., RID is IOMMU bypassed).
>
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "ATS always on" in IOMMU term.
>
> For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache:
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
>
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_required() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_required() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
>
> Cc: linux-cxl@vger.kernel.org
> Suggested-by: Vikram Sethi <vsethi@nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
> Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ...
> +bool pci_ats_required(struct pci_dev *pdev)
> +{
> + if (!pci_ats_supported(pdev))
> + return false;
> +
> + /* A VF inherits its PF's requirement for ATS function */
> + if (pdev->is_virtfn)
> + pdev = pci_physfn(pdev);
> +
> + return pci_cxl_ats_required(pdev);
I acked this before I saw this sashiko feedback, which looks like a
legit issue to me:
Will this VF inheritance logic ever be reached?
According to the PCIe SR-IOV specification (section 9.3.3.1), VFs do
not implement the ATS Extended Capability, which means pdev->ats_cap
is always 0 for VFs.
Because of this, pci_ats_supported(pdev) will unconditionally return
false for any VF. This causes the function to return false before it
can ever reach the pdev->is_virtfn check.
Could this prevent VFs from correctly enabling the ATS always on
feature and leave them unable to access host memory without
triggering IOMMU faults?
(From https://sashiko.dev/#/patchset/cover.1779304390.git.nicolinc%40nvidia.com)
I withdraw my ack for now until we figure out if it's a real issue.
> +}
> +EXPORT_SYMBOL_GPL(pci_ats_required);
> +
> #ifdef CONFIG_PCI_PRI
> void pci_pri_init(struct pci_dev *pdev)
> {
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
From: Nicolin Chen @ 2026-05-21 21:07 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jgg, will, robin.murphy, joro, bhelgaas, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl, nirmoyd
In-Reply-To: <20260521205723.GA184317@bhelgaas>
On Thu, May 21, 2026 at 03:57:23PM -0500, Bjorn Helgaas wrote:
> On Thu, May 21, 2026 at 01:34:20PM -0700, Nicolin Chen wrote:
> > +bool pci_ats_required(struct pci_dev *pdev)
> > +{
> > + if (!pci_ats_supported(pdev))
> > + return false;
> > +
> > + /* A VF inherits its PF's requirement for ATS function */
> > + if (pdev->is_virtfn)
> > + pdev = pci_physfn(pdev);
> > +
> > + return pci_cxl_ats_required(pdev);
>
> I acked this before I saw this sashiko feedback, which looks like a
> legit issue to me:
>
> Will this VF inheritance logic ever be reached?
>
> According to the PCIe SR-IOV specification (section 9.3.3.1), VFs do
> not implement the ATS Extended Capability, which means pdev->ats_cap
> is always 0 for VFs.
>
> Because of this, pci_ats_supported(pdev) will unconditionally return
> false for any VF. This causes the function to return false before it
> can ever reach the pdev->is_virtfn check.
>
> Could this prevent VFs from correctly enabling the ATS always on
> feature and leave them unable to access host memory without
> triggering IOMMU faults?
>
> (From https://sashiko.dev/#/patchset/cover.1779304390.git.nicolinc%40nvidia.com)
>
> I withdraw my ack for now until we figure out if it's a real issue.
I did a bit of research here.
The existing pci_enable_ats() checks:
if (!pci_ats_supported(dev))
return -EINVAL;
at the top, prior to:
if (dev->is_virtfn) {
pdev = pci_physfn(dev);
if (pdev->ats_stu != ps)
return -EINVAL;
So, VF must *support* ATS (its ats_cap must be !0) so as to turn
on ATS, instead of relying on the PF's ats_cap.
IOW, Sashiko's comment "which means pdev->ats_cap is always 0 for
VFs" is wrong.
So, I kept the same order in this new pci_ats_required().
FWIW, I also did an inverted version and asked Sashiko to review:
====================================================================
> @@ -205,6 +205,52 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
[ ... ]
> +bool pci_ats_required(struct pci_dev *pdev)
> +{
> + /* A VF inherits its PF's requirement for ATS function */
> + if (pdev->is_virtfn)
> + pdev = pci_physfn(pdev);
> +
> + if (!pci_ats_supported(pdev))
> + return false;
This isn't a bug, but it looks like these two lines are indented with spaces
instead of tabs.
Also, since pdev is reassigned to pci_physfn(pdev) before checking ATS
support, does this incorrectly check the ATS capability of the PF rather than
the VF?
If a VF has its ATS support explicitly disabled (for example, via PCIe quirks
that set vf->ats_cap = 0), this check might bypass the VF's specific
properties and incorrectly return true based on the PF's capabilities.
Consequently, if a caller attempts to enable ATS on the VF by calling
pci_enable_ats(), it will fail because pci_enable_ats() correctly checks
pci_ats_supported() against the VF.
Would it be better to evaluate pci_ats_supported() on the original pdev
before reassigning it to the PF?
====================================================================
What would you like me to do, Bjorn?
Nicolin
^ permalink raw reply
* [PATCH] ARM: rockchip: keep reset control around
From: Heiko Stuebner @ 2026-05-21 21:09 UTC (permalink / raw)
To: heiko; +Cc: linux-arm-kernel, linux-rockchip, Philipp Zabel, Steven Price
Do not put the reset control, retain exclusive control over it.
After turning on a CPU, the corresponding reset line must stay
deasserted.
This also avoids calling reset_control_put() before workqueues
are operational.
Fixes: 78ebbff6d1a0 ("reset: handle removing supplier before consumers")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Steven Price <steven.price@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm/mach-rockchip/platsmp.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index f432d22bfed8..f659d894bfae 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -34,6 +34,7 @@ static int ncores;
static struct regmap *pmu;
static int has_pmu = true;
+static struct reset_control *cpu_rstc[4];
static int pmu_power_domain_is_on(int pd)
{
@@ -64,9 +65,11 @@ static struct reset_control *rockchip_get_core_reset(int cpu)
static int pmu_set_power_domain(int pd, bool on)
{
u32 val = (on) ? 0 : BIT(pd);
- struct reset_control *rstc = rockchip_get_core_reset(pd);
+ struct reset_control *rstc;
int ret;
+ rstc = pd < ARRAY_SIZE(cpu_rstc) ? cpu_rstc[pd] : ERR_PTR(-EINVAL);
+
if (IS_ERR(rstc) && read_cpuid_part() != ARM_CPU_PART_CORTEX_A9) {
pr_err("%s: could not get reset control for core %d\n",
__func__, pd);
@@ -100,11 +103,8 @@ static int pmu_set_power_domain(int pd, bool on)
}
}
- if (!IS_ERR(rstc)) {
- if (on)
- reset_control_deassert(rstc);
- reset_control_put(rstc);
- }
+ if (!IS_ERR(rstc) && on)
+ reset_control_deassert(rstc);
return 0;
}
@@ -312,6 +312,10 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
ncores = ((l2ctlr >> 24) & 0x3) + 1;
}
+ /* Collect cpu core reset control for each core */
+ for (i = 0; i < ncores; i++)
+ cpu_rstc[i] = rockchip_get_core_reset(i);
+
/* Make sure that all cores except the first are really off */
for (i = 1; i < ncores; i++)
pmu_set_power_domain(0 + i, false);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] ARM: rockchip: keep reset control around
From: Heiko Stuebner @ 2026-05-21 21:13 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-arm-kernel, linux-rockchip, Philipp Zabel, Steven Price,
Bartosz Golaszewski
In-Reply-To: <20260521210915.2331176-1-heiko@sntech.de>
Am Donnerstag, 21. Mai 2026, 23:09:15 Mitteleuropäische Sommerzeit schrieb Heiko Stuebner:
> Do not put the reset control, retain exclusive control over it.
> After turning on a CPU, the corresponding reset line must stay
> deasserted.
>
> This also avoids calling reset_control_put() before workqueues
> are operational.
>
> Fixes: 78ebbff6d1a0 ("reset: handle removing supplier before consumers")
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Tested-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Forgot to add Bartosz to the Cc list, sorry
Heiko
> ---
> arch/arm/mach-rockchip/platsmp.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
> index f432d22bfed8..f659d894bfae 100644
> --- a/arch/arm/mach-rockchip/platsmp.c
> +++ b/arch/arm/mach-rockchip/platsmp.c
> @@ -34,6 +34,7 @@ static int ncores;
>
> static struct regmap *pmu;
> static int has_pmu = true;
> +static struct reset_control *cpu_rstc[4];
>
> static int pmu_power_domain_is_on(int pd)
> {
> @@ -64,9 +65,11 @@ static struct reset_control *rockchip_get_core_reset(int cpu)
> static int pmu_set_power_domain(int pd, bool on)
> {
> u32 val = (on) ? 0 : BIT(pd);
> - struct reset_control *rstc = rockchip_get_core_reset(pd);
> + struct reset_control *rstc;
> int ret;
>
> + rstc = pd < ARRAY_SIZE(cpu_rstc) ? cpu_rstc[pd] : ERR_PTR(-EINVAL);
> +
> if (IS_ERR(rstc) && read_cpuid_part() != ARM_CPU_PART_CORTEX_A9) {
> pr_err("%s: could not get reset control for core %d\n",
> __func__, pd);
> @@ -100,11 +103,8 @@ static int pmu_set_power_domain(int pd, bool on)
> }
> }
>
> - if (!IS_ERR(rstc)) {
> - if (on)
> - reset_control_deassert(rstc);
> - reset_control_put(rstc);
> - }
> + if (!IS_ERR(rstc) && on)
> + reset_control_deassert(rstc);
>
> return 0;
> }
> @@ -312,6 +312,10 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
> ncores = ((l2ctlr >> 24) & 0x3) + 1;
> }
>
> + /* Collect cpu core reset control for each core */
> + for (i = 0; i < ncores; i++)
> + cpu_rstc[i] = rockchip_get_core_reset(i);
> +
> /* Make sure that all cores except the first are really off */
> for (i = 1; i < ncores; i++)
> pmu_set_power_domain(0 + i, false);
>
^ permalink raw reply
* Re: [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
From: Bjorn Helgaas @ 2026-05-21 21:31 UTC (permalink / raw)
To: Nicolin Chen
Cc: jgg, will, robin.murphy, joro, bhelgaas, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl, nirmoyd
In-Reply-To: <ag90FlOaljwa0qqU@Asurada-Nvidia>
On Thu, May 21, 2026 at 02:07:34PM -0700, Nicolin Chen wrote:
> On Thu, May 21, 2026 at 03:57:23PM -0500, Bjorn Helgaas wrote:
> > On Thu, May 21, 2026 at 01:34:20PM -0700, Nicolin Chen wrote:
> > > +bool pci_ats_required(struct pci_dev *pdev)
> > > +{
> > > + if (!pci_ats_supported(pdev))
> > > + return false;
> > > +
> > > + /* A VF inherits its PF's requirement for ATS function */
> > > + if (pdev->is_virtfn)
> > > + pdev = pci_physfn(pdev);
> > > +
> > > + return pci_cxl_ats_required(pdev);
> >
> > I acked this before I saw this sashiko feedback, which looks like a
> > legit issue to me:
> >
> > Will this VF inheritance logic ever be reached?
> >
> > According to the PCIe SR-IOV specification (section 9.3.3.1), VFs do
> > not implement the ATS Extended Capability, which means pdev->ats_cap
> > is always 0 for VFs.
Huh. I wish sashiko would include the spec revision because that sure
looks wrong. In PCIe r7.0, there is no sec 9.3.3.1. In PCIe r6.0,
sec 9.3.3.1 is the SR-IOV Extended Capability, which doesn't mention
ATS. In both, sec 10.5.1 is the ATS Extended Capability and says both
PFs and VFs can implement it.
So I think this is OK as-is:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
^ permalink raw reply
* Re: [PATCH v11 1/2] kunit: add tests for smp_cond_load_*_timeout()
From: Andrew Morton @ 2026-05-21 21:46 UTC (permalink / raw)
To: Ankur Arora
Cc: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, linux-next,
bpf, arnd, catalin.marinas, will, peterz, mark.rutland, harisokn,
cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, joao.m.martins, boris.ostrovsky,
konrad.wilk, ashok.bhat, Boqun Feng, Boqun Feng,
Christoph Lameter, Ingo Molnar, Konrad Dybcio, Mark Brown
In-Reply-To: <20260521083038.134260-1-ankur.a.arora@oracle.com>
On Thu, 21 May 2026 01:30:37 -0700 Ankur Arora <ankur.a.arora@oracle.com> wrote:
> Add success and failure case tests for smp_cond_load_*_timeout().
>
> All of the test cases wait on some state in smp_cond_load_*_timeout().
> In the success case we spawn a kthread that pokes the bit.
>
> Success or failure cases depend on the expected bit being set (or not).
> Additionally in failure cases smp_cond_load_*_timeout() cannot return
> before timeout.
Your title "kunit: ..." implies that this is a kunit patchset. ie, and
to my mind, this implies that the patchset makes changes to kunit
infrastructure. This isn't the case, of course.
>
> ...
>
> +config BARRIER_TIMEOUT_TEST
> + tristate "KUnit tests for smp_cond_load_relaxed_timeout()"
The patchset which attempted to add smp_cond_load_relaxed_timeout() was
titled "barrier: ...", which is a more appropriate identifier for this
patchset.
Anyway, I removed the series "barrier: Add
smp_cond_load_{relaxed,acquire}_timeout()" from mm.git on May 19 for
forgotten reasons. So I suggest that the series be respun and resent,
with these two test patches included.
Again, I'm really not the guy to be handling these patches. But a 4-6%
performance improvement in real world workloads is not to be ignored.
Not by me, anyway.
^ permalink raw reply
* Re: [PATCH v11 1/2] kunit: add tests for smp_cond_load_*_timeout()
From: Mark Brown @ 2026-05-21 21:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Ankur Arora, linux-kernel, linux-arch, linux-arm-kernel, linux-pm,
linux-next, bpf, arnd, catalin.marinas, will, peterz,
mark.rutland, harisokn, cl, ast, rafael, daniel.lezcano, memxor,
zhenglifeng1, xueshuai, rdunlap, david.laight.linux,
joao.m.martins, boris.ostrovsky, konrad.wilk, ashok.bhat,
Boqun Feng, Boqun Feng, Christoph Lameter, Ingo Molnar,
Konrad Dybcio
In-Reply-To: <20260521144629.11ee1e2ff88c5387a589f54a@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Thu, May 21, 2026 at 02:46:29PM -0700, Andrew Morton wrote:
> Anyway, I removed the series "barrier: Add
> smp_cond_load_{relaxed,acquire}_timeout()" from mm.git on May 19 for
> forgotten reasons. So I suggest that the series be respun and resent,
> with these two test patches included.
The tests were failing on arm64 when run on hardware (rather than qemu).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
From: Nicolin Chen @ 2026-05-21 21:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jgg, will, robin.murphy, joro, bhelgaas, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl, nirmoyd
In-Reply-To: <20260521213123.GA186424@bhelgaas>
On Thu, May 21, 2026 at 04:31:23PM -0500, Bjorn Helgaas wrote:
> On Thu, May 21, 2026 at 02:07:34PM -0700, Nicolin Chen wrote:
> > On Thu, May 21, 2026 at 03:57:23PM -0500, Bjorn Helgaas wrote:
> > > On Thu, May 21, 2026 at 01:34:20PM -0700, Nicolin Chen wrote:
> > > > +bool pci_ats_required(struct pci_dev *pdev)
> > > > +{
> > > > + if (!pci_ats_supported(pdev))
> > > > + return false;
> > > > +
> > > > + /* A VF inherits its PF's requirement for ATS function */
> > > > + if (pdev->is_virtfn)
> > > > + pdev = pci_physfn(pdev);
> > > > +
> > > > + return pci_cxl_ats_required(pdev);
> > >
> > > I acked this before I saw this sashiko feedback, which looks like a
> > > legit issue to me:
> > >
> > > Will this VF inheritance logic ever be reached?
> > >
> > > According to the PCIe SR-IOV specification (section 9.3.3.1), VFs do
> > > not implement the ATS Extended Capability, which means pdev->ats_cap
> > > is always 0 for VFs.
>
> Huh. I wish sashiko would include the spec revision because that sure
> looks wrong. In PCIe r7.0, there is no sec 9.3.3.1. In PCIe r6.0,
> sec 9.3.3.1 is the SR-IOV Extended Capability, which doesn't mention
> ATS. In both, sec 10.5.1 is the ATS Extended Capability and says both
> PFs and VFs can implement it.
I am glad you checked the spec. I should have done the same.
> So I think this is OK as-is:
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Thanks!
Nicolin
^ permalink raw reply
* Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
From: Andrew Morton @ 2026-05-21 22:31 UTC (permalink / raw)
To: Alistair Popple
Cc: linux-arm-kernel, linux-kernel, linux-mm, catalin.marinas, will,
david
In-Reply-To: <20260521032730.2104017-1-apopple@nvidia.com>
On Thu, 21 May 2026 13:27:30 +1000 Alistair Popple <apopple@nvidia.com> wrote:
> Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in
> __create_pgd_mapping()") page-table allocation on ARM64 always
> calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type
> to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL.
> However the matching pagetable_dtor() calls were never added.
>
> With DEBUG_VM enabled on kernel versions prior to v6.17 without
> 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page
> type") this leads to the following warning when freeing these pages due
> to page->page_type sharing page->_mapcount:
>
> BUG: Bad page state in process ... pfn:284fbb
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb
> flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)
> page_type: f2(table)
> page dumped because: nonzero mapcount
> Call trace:
> bad_page+0x13c/0x160
> __free_frozen_pages+0x6cc/0x860
> ___free_pages+0xf4/0x180
> free_pages+0x54/0x80
> free_hotplug_page_range.part.0+0x58/0x90
> free_empty_tables+0x438/0x500
> __remove_pgd_mapping.constprop.0+0x60/0xa8
> arch_remove_memory+0x48/0x80
> try_remove_memory+0x158/0x1d8
> offline_and_remove_memory+0x138/0x180
>
> It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS
> is defined and incorrect NR_PAGETABLE stats. Fix this by calling
> pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the
> page to undo the effects of calling pagetable_*_ctor().
>
> Fixes: 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()")
6.16+, so I assume we want cc:stable here.
> arch/arm64/mm/mmu.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 8e1d80a7033e..0c24fe650e95 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1422,6 +1422,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
>
> static void free_hotplug_pgtable_page(struct page *page)
> {
> + pagetable_dtor(page_ptdesc(page));
> free_hotplug_page_range(page, PAGE_SIZE, NULL);
> }
I'd of course prefer that arm maintainers handle this. But
5e8eb9aeeda3 came via myself so convention kinda-dictates that I get to
fix it.
^ permalink raw reply
* Re: [PATCH v14 07/44] arm64: RMI: Configure the RMM with the host's page size
From: Suzuki K Poulose @ 2026-05-21 22:36 UTC (permalink / raw)
To: Gavin Shan, Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Shanker Donthineni, Alper Gun,
Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve, WeiLin.Chang,
Lorenzo.Pieralisi2
In-Reply-To: <45a953a8-6edc-45c3-b5bd-17f14397ab89@redhat.com>
On 21/05/2026 01:51, Gavin Shan wrote:
> Hi Steven,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> RMM v2.0 brings the ability to set the RMM's granule size. Check the
>> feature registers and configure the RMM so that it matches the host's
>> page size. This means that operations can be done with a granulatity
>> equal to PAGE_SIZE.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * Moved out of KVM.
>> ---
>> arch/arm64/kernel/rmi.c | 42 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/rmi.c b/arch/arm64/kernel/rmi.c
>> index 99c1ccc35c11..a14ead5dedda 100644
>> --- a/arch/arm64/kernel/rmi.c
>> +++ b/arch/arm64/kernel/rmi.c
>> @@ -49,6 +49,45 @@ static int rmi_check_version(void)
>> return 0;
>> }
>> +static int rmi_configure(void)
>> +{
>> + struct rmm_config *config __free(free_page) = NULL;
>> + unsigned long ret;
>> +
>> + config = (struct rmm_config *)get_zeroed_page(GFP_KERNEL);
>> + if (!config)
>> + return -ENOMEM;
>> +
>> + switch (PAGE_SIZE) {
>> + case SZ_4K:
>> + config->rmi_granule_size = RMI_GRANULE_SIZE_4KB;
>> + break;
>> + case SZ_16K:
>> + config->rmi_granule_size = RMI_GRANULE_SIZE_16KB;
>> + break;
>> + case SZ_64K:
>> + config->rmi_granule_size = RMI_GRANULE_SIZE_64KB;
>> + break;
>> + default:
>> + pr_err("Unsupported PAGE_SIZE for RMM\n");
>> + return -EINVAL;
>> + }
>> +
>> + ret = rmi_rmm_config_set(virt_to_phys(config));
>> + if (ret) {
>> + pr_err("RMM config set failed\n");
>> + return -EINVAL;
>> + }
>> +
>
> Looking at branch 'topics/rmm-v2.0-poc_2' of RMM implementation, the
> granule size
> is fixed to be 4KB at present. I'm not sure if I have looked into
> correct RMM
> implementation, but 'topics/rmm-v2.0-poc_2' is recommended one in the cover
> letter.
>
You are right. The tf-RMM only supports 4KB. The policy at the KVM host
is to set the Linux PAGE_SIZE for the GRANULE_SIZE (at least for now).
If the RMM doesn't support the PAGE_SIZE, we don't support the RMM.
> Besides, there has checks in the handler of the RMI command to make sure
> that
> struct rmm_config::tracking_region_size to be 1GB, indicated by zero. It
> maybe
> worthy to set it before call to rmi_rmm_config_set().
>
> config.tracking_region_size = 0; /* 1GB */
Thanks, this explicit initialisation is missing, though in effect the
value is 0'd. Also, we can't really say 1GB here, because the driver
should work for an RMM capable of 64K. So, instead, may be we could :
/* See the definition of RMM_GRANULE_TRACKING_SIZE */
config.tracking_region_size = 0;
Suzuki
> ret = rmi_rmm_config_set(virt_to_phys(config));
>
>
>> + ret = rmi_rmm_activate();
>> + if (ret) {
>> + pr_err("RMM activate failed\n");
>> + return -ENXIO;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int __init arm64_init_rmi(void)
>> {
>> /* Continue without realm support if we can't agree on a version */
>> @@ -60,6 +99,9 @@ static int __init arm64_init_rmi(void)
>> if (WARN_ON(rmi_features(1, &rmm_feat_reg1)))
>> return 0;
>> + if (rmi_configure())
>> + return 0;
>> +
>> return 0;
>> }
>> subsys_initcall(arm64_init_rmi);
>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH RESEND v3 2/6] drm/bridge: pass down IRQ_HPD to the drivers
From: Bjorn Andersson @ 2026-05-21 23:12 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Konrad Dybcio, Pengyu Luo, Nikita Travkin, Yongxing Mou,
dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260513-hpd-irq-events-v3-2-086857017f16@oss.qualcomm.com>
On Wed, May 13, 2026 at 09:23:22PM +0300, Dmitry Baryshkov wrote:
> Pass down the notifications about the IRQ_HPD events down to the
> individual drivers, letting them handle those as required.
>
I think patch 2 through 6 relies on patch 1's commit message to
establish the motivation for each change, but they are scattered across
a variety of drivers/files.
It would be preferable to have the commit message of each patch stand on
its own.
Regards,
Bjorn
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 3 ++-
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 3 ++-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 ++-
> drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
> drivers/gpu/drm/display/drm_bridge_connector.c | 22 +++++++++++++---------
> drivers/gpu/drm/drm_bridge.c | 5 +++--
> drivers/gpu/drm/drm_connector.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
> drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 ++-
> drivers/gpu/drm/msm/dp/dp_display.c | 3 ++-
> drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 ++-
> include/drm/drm_bridge.h | 9 ++++++---
> include/drm/drm_connector.h | 3 ++-
> 14 files changed, 43 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> index 54d49d4882c8..04e6b4c00a28 100644
> --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -259,7 +259,8 @@ static const struct drm_connector_helper_funcs ch7033_connector_helper_funcs = {
> .best_encoder = ch7033_connector_best_encoder,
> };
>
> -static void ch7033_hpd_event(void *arg, enum drm_connector_status status)
> +static void ch7033_hpd_event(void *arg, enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct ch7033_priv *priv = arg;
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 8a0b48efca58..b404f0cbf60d 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -504,7 +504,8 @@ static int lt8912_attach_dsi(struct lt8912 *lt)
> return 0;
> }
>
> -static void lt8912_bridge_hpd_cb(void *data, enum drm_connector_status status)
> +static void lt8912_bridge_hpd_cb(void *data, enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct lt8912 *lt = data;
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index 11aab07d88df..ca41ebe9f26f 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -430,7 +430,8 @@ static const struct drm_edid *lt9611uxc_bridge_edid_read(struct drm_bridge *brid
>
> static void lt9611uxc_bridge_hpd_notify(struct drm_bridge *bridge,
> struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> const struct drm_edid *drm_edid;
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 3b6b0e92cf89..199916662895 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -39,7 +39,6 @@ drm_bridge_to_tfp410(struct drm_bridge *bridge)
> {
> return container_of(bridge, struct tfp410, bridge);
> }
> -
> static inline struct tfp410 *
> drm_connector_to_tfp410(struct drm_connector *connector)
> {
> @@ -110,7 +109,8 @@ static void tfp410_hpd_work_func(struct work_struct *work)
> drm_helper_hpd_irq_event(dvi->bridge.dev);
> }
>
> -static void tfp410_hpd_callback(void *arg, enum drm_connector_status status)
> +static void tfp410_hpd_callback(void *arg, enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct tfp410 *dvi = arg;
>
> diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
> index 39cc18f78eda..5fdb1a231cec 100644
> --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
> @@ -141,7 +141,8 @@ struct drm_bridge_connector {
> */
>
> static void drm_bridge_connector_hpd_notify(struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
> @@ -149,12 +150,13 @@ static void drm_bridge_connector_hpd_notify(struct drm_connector *connector,
> /* Notify all bridges in the pipeline of hotplug events. */
> drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
> if (bridge->funcs->hpd_notify)
> - bridge->funcs->hpd_notify(bridge, connector, status);
> + bridge->funcs->hpd_notify(bridge, connector, status, extra_status);
> }
> }
>
> static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bridge_connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_connector *connector = &drm_bridge_connector->base;
> struct drm_device *dev = connector->dev;
> @@ -163,24 +165,26 @@ static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bri
> connector->status = status;
> mutex_unlock(&dev->mode_config.mutex);
>
> - drm_bridge_connector_hpd_notify(connector, status);
> + drm_bridge_connector_hpd_notify(connector, status, extra_status);
>
> drm_kms_helper_connector_hotplug_event(connector);
> }
>
> static void drm_bridge_connector_hpd_cb(void *cb_data,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> - drm_bridge_connector_handle_hpd(cb_data, status);
> + drm_bridge_connector_handle_hpd(cb_data, status, extra_status);
> }
>
> static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> - drm_bridge_connector_handle_hpd(bridge_connector, status);
> + drm_bridge_connector_handle_hpd(bridge_connector, status, extra_status);
> }
>
> static void drm_bridge_connector_enable_hpd(struct drm_connector *connector)
> @@ -223,7 +227,7 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force)
> if (hdmi)
> drm_atomic_helper_connector_hdmi_hotplug(connector, status);
>
> - drm_bridge_connector_hpd_notify(connector, status);
> + drm_bridge_connector_hpd_notify(connector, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
> } else {
> switch (connector->connector_type) {
> case DRM_MODE_CONNECTOR_DPI:
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index d6f512b73389..c8c3301cd936 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1444,7 +1444,8 @@ EXPORT_SYMBOL_GPL(drm_bridge_edid_read);
> */
> void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> void (*cb)(void *data,
> - enum drm_connector_status status),
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status),
> void *data)
> {
> if (!(bridge->ops & DRM_BRIDGE_OP_HPD))
> @@ -1509,7 +1510,7 @@ void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> {
> mutex_lock(&bridge->hpd_mutex);
> if (bridge->hpd_cb)
> - bridge->hpd_cb(bridge->hpd_data, status);
> + bridge->hpd_cb(bridge->hpd_data, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
> mutex_unlock(&bridge->hpd_mutex);
> }
> EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index edee9daccd51..415eb834808c 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -3532,7 +3532,7 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> return;
>
> if (connector->funcs->oob_hotplug_event)
> - connector->funcs->oob_hotplug_event(connector, status);
> + connector->funcs->oob_hotplug_event(connector, status, extra_status);
>
> drm_connector_put(connector);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4955bd8b11d7..98bbcab2067b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6779,7 +6779,8 @@ static int intel_dp_connector_atomic_check(struct drm_connector *_connector,
> }
>
> static void intel_dp_oob_hotplug_event(struct drm_connector *_connector,
> - enum drm_connector_status hpd_state)
> + enum drm_connector_status hpd_state,
> + enum drm_connector_status_extra extra_status)
> {
> struct intel_connector *connector = to_intel_connector(_connector);
> struct intel_display *display = to_intel_display(connector);
> diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
> index 1abb0572bb5f..691b9996c8a4 100644
> --- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
> @@ -323,7 +323,8 @@ static int meson_encoder_hdmi_atomic_check(struct drm_bridge *bridge,
>
> static void meson_encoder_hdmi_hpd_notify(struct drm_bridge *bridge,
> struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct meson_encoder_hdmi *encoder_hdmi = bridge_to_meson_encoder_hdmi(bridge);
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index d2124d625485..7a0623fdbd8e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1785,7 +1785,8 @@ void msm_dp_bridge_hpd_disable(struct drm_bridge *bridge)
>
> void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
> struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct msm_dp_bridge *msm_dp_bridge = to_dp_bridge(bridge);
> struct msm_dp *msm_dp_display = msm_dp_bridge->msm_dp_display;
> diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
> index 9eb3431dd93a..74da3ef6b625 100644
> --- a/drivers/gpu/drm/msm/dp/dp_drm.h
> +++ b/drivers/gpu/drm/msm/dp/dp_drm.h
> @@ -41,6 +41,7 @@ void msm_dp_bridge_hpd_enable(struct drm_bridge *bridge);
> void msm_dp_bridge_hpd_disable(struct drm_bridge *bridge);
> void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
> struct drm_connector *connector,
> - enum drm_connector_status status);
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status);
>
> #endif /* _DP_DRM_H_ */
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 29b2dfb90b5f..a7288791b2a5 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -429,7 +429,8 @@ static void hdmi4_bridge_disable(struct drm_bridge *bridge,
>
> static void hdmi4_bridge_hpd_notify(struct drm_bridge *bridge,
> struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index a8d67bd9ee50..3e4672fbd7a8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -615,7 +615,8 @@ struct drm_bridge_funcs {
> */
> void (*hpd_notify)(struct drm_bridge *bridge,
> struct drm_connector *connector,
> - enum drm_connector_status status);
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status);
>
> /**
> * @hpd_enable:
> @@ -1260,7 +1261,8 @@ struct drm_bridge {
> * @hpd_cb: Hot plug detection callback, registered with
> * drm_bridge_hpd_enable().
> */
> - void (*hpd_cb)(void *data, enum drm_connector_status status);
> + void (*hpd_cb)(void *data, enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status);
> /**
> * @hpd_data: Private data passed to the Hot plug detection callback
> * @hpd_cb.
> @@ -1550,7 +1552,8 @@ const struct drm_edid *drm_bridge_edid_read(struct drm_bridge *bridge,
> struct drm_connector *connector);
> void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> void (*cb)(void *data,
> - enum drm_connector_status status),
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status),
> void *data);
> void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index e05197e970d3..5ac5a64f83d9 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1720,7 +1720,8 @@ struct drm_connector_funcs {
> * has been received from a source outside the display driver / device.
> */
> void (*oob_hotplug_event)(struct drm_connector *connector,
> - enum drm_connector_status status);
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status);
>
> /**
> * @debugfs_init:
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH 4/4] ASoC: meson: aiu: use aiu-formatter-i2s to format I2S output data
From: Mark Brown @ 2026-05-21 23:15 UTC (permalink / raw)
To: Valerio Setti
Cc: Jerome Brunet, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, linux-kernel,
linux-sound, linux-arm-kernel, linux-amlogic
In-Reply-To: <20260515-reshape-aiu-as-axg-v1-4-53b457784ff3@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]
On Fri, May 15, 2026 at 05:10:40PM +0200, Valerio Setti wrote:
> Create a new DAPM widget for "I2S formatter" and place it on the path
> between FIFO and output DAI interface. Remove I2S output formatting code
> from aiu-encoder-i2s since it's now implemented from aiu-formatter-i2s.
This series, it looks like this specific patch, is breaking pcm-test on
my libretech Le Potato board, the clocking looks to be seriously messed
up. I'm getting:
# selftests: alsa: pcm-test
# TAP version 13
# # Card 0/LIBRETECHCC - LIBRETECH-CC (LIBRETECH-CC)
# # LIBRETECHCC.0 - fe.dai-link-0 (*)
# 1..7
# # default.time1.LIBRETECHCC.0.0.PLAYBACK - 8kHz mono large periods
# ok 1 # SKIP default.time1.LIBRETECHCC.0.0.PLAYBACK
# # snd_pcm_hw_params_set_channels 1: Invalid argument
# # default.time2.LIBRETECHCC.0.0.PLAYBACK - 8kHz stereo large periods
# # default.time2.LIBRETECHCC.0.0.PLAYBACK hw_params.RW_INTERLEAVED.S16_LE.8000.2.8000.32000 sw_params.32000
# not ok 2 default.time2.LIBRETECHCC.0.0.PLAYBACK
# # time mismatch: expected 2000ms got 4425
# # default.time3.LIBRETECHCC.0.0.PLAYBACK - 44.1kHz stereo large periods
# # default.time3.LIBRETECHCC.0.0.PLAYBACK hw_params.RW_INTERLEAVED.S16_LE.44100.2.22528.192000 sw_params.180224
# not ok 3 default.time3.LIBRETECHCC.0.0.PLAYBACK
# # time mismatch: expected 2000ms got 4852
# # default.time4.LIBRETECHCC.0.0.PLAYBACK - 48kHz stereo small periods
# # default.time4.LIBRETECHCC.0.0.PLAYBACK hw_params.RW_INTERLEAVED.S16_LE.48000.2.512.4096 sw_params.4096
# not ok 4 default.time4.LIBRETECHCC.0.0.PLAYBACK
# # expected 48000, wrote 4096
# # default.time5.LIBRETECHCC.0.0.PLAYBACK - 48kHz stereo large periods
# # default.time5.LIBRETECHCC.0.0.PLAYBACK hw_params.RW_INTERLEAVED.S16_LE.48000.2.24000.192000 sw_params.192000
# not ok 5 default.time5.LIBRETECHCC.0.0.PLAYBACK
# # time mismatch: expected 2000ms got 4489
# # default.time6.LIBRETECHCC.0.0.PLAYBACK - 48kHz 6 channel large periods
# # default.time6.LIBRETECHCC.0.0.PLAYBACK hw_params.RW_INTERLEAVED.S16_LE.48000.2.48000.262144 sw_params.240000
# not ok 6 default.time6.LIBRETECHCC.0.0.PLAYBACK
# # time mismatch: expected 2000ms got 6135
# # default.time7.LIBRETECHCC.0.0.PLAYBACK - 96kHz stereo large periods
# # default.time7.LIBRETECHCC.0.0.PLAYBACK hw_params.RW_INTERLEAVED.S16_LE.96000.2.48000.192000 sw_params.192000
# not ok 7 default.time7.LIBRETECHCC.0.0.PLAYBACK
# # time mismatch: expected 2000ms got 2287
# # 1 skipped test(s) detected. Consider enabling relevant config options to improve coverage.
# # Totals: pass:0 fail:6 xfail:0 xpass:0 skip:1 error:0
Full log:
https://lava.sirena.org.uk/scheduler/job/2786342#L1934
The prior patches seem to test fine, it's this one that seems to
introduce the issue.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3 5/6] soc: qcom: pmic-glink-altmode: pass down HPD_IRQ events
From: Bjorn Andersson @ 2026-05-21 23:17 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Konrad Dybcio, Pengyu Luo, Nikita Travkin, Yongxing Mou,
dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260513-hpd-irq-events-v3-5-086857017f16@oss.qualcomm.com>
On Wed, May 13, 2026 at 09:23:25PM +0300, Dmitry Baryshkov wrote:
> Pass IRQ_HPD events to the HPD bridge, letting those to be delivered to
> the DisplayPort driver.
>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Regards,
Bjorn
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/soc/qcom/pmic_glink_altmode.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c
> index 619bad2c27ee..946eb20b8f83 100644
> --- a/drivers/soc/qcom/pmic_glink_altmode.c
> +++ b/drivers/soc/qcom/pmic_glink_altmode.c
> @@ -373,7 +373,11 @@ static void pmic_glink_altmode_worker(struct work_struct *work)
> else
> conn_status = connector_status_disconnected;
>
> - drm_aux_hpd_bridge_notify(&alt_port->bridge->dev, conn_status);
> + drm_aux_hpd_bridge_notify_extra(&alt_port->bridge->dev,
> + conn_status,
> + alt_port->hpd_irq ?
> + DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> } else if (alt_port->mux_ctrl == MUX_CTRL_STATE_TUNNELING) {
> if (alt_port->svid == USB_TYPEC_TBT_SID)
> pmic_glink_altmode_enable_tbt(altmode, alt_port);
>
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH ath-next] wifi: ath9k: owl: remove misleading error message
From: Rosen Penev @ 2026-05-21 23:21 UTC (permalink / raw)
To: linux-wireless
Cc: Toke Høiland-Jørgensen, Andreas Färber,
Manivannan Sadhasivam,
moderated list:ARM/ACTIONS SEMI ARCHITECTURE,
moderated list:ARM/ACTIONS SEMI ARCHITECTURE, open list
The error is about the firmware failing to be requested, not calibration
data. Just return directly anyways.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
index b9ef34709202..4460ee7f44e1 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -204,12 +204,8 @@ static int owl_probe(struct pci_dev *pdev,
scnprintf(eeprom_name, sizeof(eeprom_name), "ath9k-eeprom-pci-%s.bin",
dev_name(dev));
- err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ return request_firmware_nowait(THIS_MODULE, true, eeprom_name,
&pdev->dev, GFP_KERNEL, ctx, owl_fw_cb);
- if (err)
- dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
-
- return err;
}
static void owl_remove(struct pci_dev *pdev)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Bagas Sanjaya @ 2026-05-21 23:26 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Stefan Dösinger, Linus Walleij, Krzysztof Kozlowski,
linux-arm-kernel, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260521191458.177046-1-rdunlap@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
On Thu, May 21, 2026 at 12:14:57PM -0700, Randy Dunlap wrote:
> Fix multiple documentation build warnings.
> Improve punctuation and formatting of the rendered output.
Much better, thanks!
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Alistair Popple @ 2026-05-21 23:48 UTC (permalink / raw)
To: Ryan Roberts
Cc: Balbir Singh, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <60542cd7-d01c-4247-8957-8423b54ae99d@arm.com>
On 2026-05-21 at 21:24 +1000, Ryan Roberts <ryan.roberts@arm.com> wrote...
> On 21/05/2026 11:46, Balbir Singh wrote:
> > On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
> >> On 21/05/2026 05:24, Alistair Popple wrote:
> >>> Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
> >>> the page to be hot unplugged from the direct map. Currently that happens
> >>> one page at a time, meaning range based invalidates cannot be used. The
> >>> result of this is that removing large amounts of memory takes a long
> >>> time and in some cases can trigger an RCU stall warning.
> >>>
> >>> For example on one system hot unplugging 480GB of memory takes ~1
> >>> minute. With this change the same operation took ~1 second, a 60x
> >>> improvement.
> >>>
> >>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
> >>>
> >>> ---
> >>>
> >>> This is an RFC, because I'm not sure the change is correct as it frees
> >>> the PTE page before flushing the TLB. I'm not familiar enough with ARM64
> >>> architecture to be sure this is safe, for example I don't know if HW
> >>> can update PTE bits such as access/dirty in the page through a stale
> >>> TLB entry.
> >>>
> >>> If so this would open a window during which the page is free but could
> >>> still be written to. Likely the safe option would be to collect all the
> >>> pages to be free on a list and free them after doing the range based TLB
> >>> flush, but wanted to get feedback on the approach before implementing it
> >>> which is the goal of this RFC.
> >>
> >> Hi Alistair,
> >>
> >> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
> >>
> >> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
> >>
> >> which has a very similar performance improvement, so hopefully it solves your
> >> problem?
Yes it does. This issue has been niggling me for a while, so how coincidental
that I finally try and do something about it just after someone has fixed it :-)
> >> There are two paths which use this logic; unmapping the linear map and unmapping
> >> the corresponding vmemmap. In the latter case, the memory is also freed, so we
> >> can't safely do the range optimizaiton there since the TLB needs to be flushed
> >> before freeing the memory. But the linear map is the big, slow bit so hopefully
> >> it's sufficent for you?
> >>
> >
> > I assume vmemmap path is for tearing down the struct pages corresponding
> > to the physical memory and vmemmap teardowns taking a flush should be
> > OK. It is worth checking if the issue is already fixed.
>
> Yes, exactly. Assuming you're using 64K pages, I think vmemmap is mapped using
> base pages. So you'd get 1024 struct pages on a page, so 1 TLBI per 64M of
> memory that is being unplugged on the vmemmap path.
>
> On the linear map path, it's a single range tlbi operation to over the entire range.
>
> Alistair's patch is doing it per 512M in both cases, but is unsafe for vmemmap
> as currently written.
Right - hence the RFC. This was somewhat sent in the spirit of it being wrong
in the hope that somebody could help me figure out how to do it properly. As
it turns out though it's already been fixed which is an even better outcome so
thanks for pointing that out.
So this patch can be ignored, I see a similar offlining performance improvement
on my system (~1m -> ~1s) with 48478b9f79137 applied.
Thanks.
- Alistair
> >
> > Balbir
> > <snip>
>
^ permalink raw reply
* Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
From: Alistair Popple @ 2026-05-21 23:50 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arm-kernel, linux-kernel, linux-mm, catalin.marinas, will,
david
In-Reply-To: <20260521153130.d7d5cd060f7522f894252333@linux-foundation.org>
On 2026-05-22 at 08:31 +1000, Andrew Morton <akpm@linux-foundation.org> wrote...
> On Thu, 21 May 2026 13:27:30 +1000 Alistair Popple <apopple@nvidia.com> wrote:
>
> > Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in
> > __create_pgd_mapping()") page-table allocation on ARM64 always
> > calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type
> > to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL.
> > However the matching pagetable_dtor() calls were never added.
> >
> > With DEBUG_VM enabled on kernel versions prior to v6.17 without
> > 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page
> > type") this leads to the following warning when freeing these pages due
> > to page->page_type sharing page->_mapcount:
> >
> > BUG: Bad page state in process ... pfn:284fbb
> > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb
> > flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)
> > page_type: f2(table)
> > page dumped because: nonzero mapcount
> > Call trace:
> > bad_page+0x13c/0x160
> > __free_frozen_pages+0x6cc/0x860
> > ___free_pages+0xf4/0x180
> > free_pages+0x54/0x80
> > free_hotplug_page_range.part.0+0x58/0x90
> > free_empty_tables+0x438/0x500
> > __remove_pgd_mapping.constprop.0+0x60/0xa8
> > arch_remove_memory+0x48/0x80
> > try_remove_memory+0x158/0x1d8
> > offline_and_remove_memory+0x138/0x180
> >
> > It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS
> > is defined and incorrect NR_PAGETABLE stats. Fix this by calling
> > pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the
> > page to undo the effects of calling pagetable_*_ctor().
> >
> > Fixes: 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()")
>
> 6.16+, so I assume we want cc:stable here.
Yes indeed. Sorry I forgot to do that but I can see you added it so thanks for
that.
- Alistair
> > arch/arm64/mm/mmu.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 8e1d80a7033e..0c24fe650e95 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1422,6 +1422,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
> >
> > static void free_hotplug_pgtable_page(struct page *page)
> > {
> > + pagetable_dtor(page_ptdesc(page));
> > free_hotplug_page_range(page, PAGE_SIZE, NULL);
> > }
>
> I'd of course prefer that arm maintainers handle this. But
> 5e8eb9aeeda3 came via myself so convention kinda-dictates that I get to
> fix it.
>
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Andrew Morton @ 2026-05-22 0:17 UTC (permalink / raw)
To: Qu Wenruo
Cc: Christoph Hellwig, H. Peter Anvin, kreijack, David Sterba,
Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <f46636c8-80ba-4802-a6a0-74cbc35e7bee@gmx.com>
On Wed, 20 May 2026 18:11:09 +0930 Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
> 在 2026/5/18 14:42, Christoph Hellwig 写道:
> > On Fri, May 15, 2026 at 12:59:34PM -0700, H. Peter Anvin wrote:
> >> I don't think this is a good idea. Error out; it is the btrfs maintainers' job to ensure user data isn't lost.
> >>
> >> The RAID-6 code has *never* supported only 3 units, and if it ever worked for *any* of the implementations it was purely by accident. Speaking as the original author I should know; this was deliberate as in some cases the degenerate case (3) would have required extra trays in the code to no user benefit.
> >>
> >> I would not be surprised if the kernel crashed or corrupted the page cache in that case.
> >
> > It does, that's why I wanted to exclude it. Anyway, for the about to be
> > resent version I'll drop this btrfs patch over the stated objection and
> > will otherwise not change anything. This means the (IMHO hypothetical)
> > users of this configuration will get a WARN_ON_ONCE triggered, but
> > otherwise keep working (or rather not working) as before.
> >
>
> For the btrfs part, I believe I can get the current 2-disk-raid5 and
> 3-disk-raid6 to fallback to raid1 inside btrfs.
>
> I hope the btrfs part can be finished and reach the next merge window,
> but I'm not 100% sure.
>
> What is the planned cycle to merge this raid5/6 cleanup?
At present it's on track for the 7.2-rc1 merge window. Does that suit?
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Qu Wenruo @ 2026-05-22 0:27 UTC (permalink / raw)
To: Andrew Morton, Qu Wenruo
Cc: Christoph Hellwig, H. Peter Anvin, kreijack, David Sterba,
Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260521171730.7872482df453975cf60ce7dc@linux-foundation.org>
在 2026/5/22 09:47, Andrew Morton 写道:
> On Wed, 20 May 2026 18:11:09 +0930 Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>>
>>
>> 在 2026/5/18 14:42, Christoph Hellwig 写道:
>>> On Fri, May 15, 2026 at 12:59:34PM -0700, H. Peter Anvin wrote:
>>>> I don't think this is a good idea. Error out; it is the btrfs maintainers' job to ensure user data isn't lost.
>>>>
>>>> The RAID-6 code has *never* supported only 3 units, and if it ever worked for *any* of the implementations it was purely by accident. Speaking as the original author I should know; this was deliberate as in some cases the degenerate case (3) would have required extra trays in the code to no user benefit.
>>>>
>>>> I would not be surprised if the kernel crashed or corrupted the page cache in that case.
>>>
>>> It does, that's why I wanted to exclude it. Anyway, for the about to be
>>> resent version I'll drop this btrfs patch over the stated objection and
>>> will otherwise not change anything. This means the (IMHO hypothetical)
>>> users of this configuration will get a WARN_ON_ONCE triggered, but
>>> otherwise keep working (or rather not working) as before.
>>>
>>
>> For the btrfs part, I believe I can get the current 2-disk-raid5 and
>> 3-disk-raid6 to fallback to raid1 inside btrfs.
>>
>> I hope the btrfs part can be finished and reach the next merge window,
>> but I'm not 100% sure.
>>
>> What is the planned cycle to merge this raid5/6 cleanup?
>
> At present it's on track for the 7.2-rc1 merge window. Does that suit?
The current btrfs fix (*) is pretty small, I believe we can get it into
the next merge window, as long as we got enough review on it.
*:
https://lore.kernel.org/linux-btrfs/a1d63733465229936351804f3760803d5894a962.1779274630.git.wqu@suse.com/T/#u
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: rockchip: analogix-dp: Add data-lanes example
From: Damon Ding @ 2026-05-22 1:25 UTC (permalink / raw)
To: Conor Dooley
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521-powdery-tux-22a7cf4fadc3@spud>
On 5/22/2026 3:47 AM, Conor Dooley wrote:
> On Thu, May 21, 2026 at 07:44:58PM +0800, Damon Ding wrote:
>> Add data-lanes setting in endpoint example to show actual lane mapping
>> usage.
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> Squash this with patch 1.
> pw-bot: changes-requested
>
Yes, will fix in v3
Best regards,
Damon
>
>> ---
>> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> index bb75d898a5c5..cf75c926318b 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> @@ -151,6 +151,7 @@ examples:
>> reg = <1>;
>>
>> edp_out_panel: endpoint {
>> + data-lanes = <0 1>;
>> remote-endpoint = <&panel_in_edp>;
>> };
>> };
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO
From: Dylan Hatch @ 2026-05-22 1:31 UTC (permalink / raw)
To: Jens Remus
Cc: Catalin Marinas, Will Deacon, Steven Rostedt, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Weinan Liu, linux-arm-kernel,
linux-kernel, Heiko Carstens, Ilya Leoshkevich
In-Reply-To: <20260417150827.1183376-4-jremus@linux.ibm.com>
Hi Jens,
Sorry for the slow reply on this.
On Fri, Apr 17, 2026 at 8:08 AM Jens Remus <jremus@linux.ibm.com> wrote:
>
> This replicates Josh's x86 patch "x86/vdso: Enable sframe generation
> in VDSO" [1] for arm64.
>
> Enable .sframe generation in the vDSO library so kernel and user space
> can unwind through it. Keep all function symbols in the vDSO .symtab
> for stack trace purposes. This enables perf to lookup these function
> symbols in addition to those already exported in vDSO .dynsym.
>
> Starting with binutils 2.46 both GNU assembler and GNU linker
> exclusively support generating and merging .sframe in SFrame V3 format.
> For vDSO, only if supported by the assembler, generate .sframe, collect
> it, mark it as KEEP, and generate a GNU_SFRAME program table entry.
> Otherwise explicitly discard any .sframe.
>
> [1]: x86/vdso: Enable sframe generation in VDSO,
> https://lore.kernel.org/all/20260211141357.271402-7-jremus@linux.ibm.com/
>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
>
> Notes (jremus):
> @Dylan: Adding -Wa,--gsframe-3 to the VDSO CC_FLAGS_ADD_VDSO (and
> AS_FLAGS_ADD_VDSO) may clash with your patch [1] that adds likewise
> to the CC_FLAGS_REMOVE_VDSO. Any idea how to resolve?
>
> [1]: [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info,
> https://lore.kernel.org/all/20260406185000.1378082-3-dylanbhatch@google.com/
In a kernel tree with both your patch and my [1] patch merged, I
believe we'd want to hold two invariants true:
1. If HAVE_UNWIND_KERNEL_SFRAME=n, we must not build the kernel with .sframe.
2. If AS_SFRAME3=y, we must build vDSO with .sframe.
Since HAVE_UNWIND_KERNEL_SFRAME=y implies AS_SFRAME3=y, I wonder if we
should be able to drop CC_FLAGS_SFRAME from CC_FLAGS_REMOVE_VDSO and
move some definitions:
diff --git a/Makefile b/Makefile
index 227fda16deb1..ef059bccb8c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1147,12 +1147,15 @@ endif
# Ensure compilers do not transform certain loops into calls to wcslen()
KBUILD_CFLAGS += -fno-builtin-wcslen
+ifeq ($(CONFIG_AS_SFRAME3),y)
+CC_FLAGS_SFRAME := -Wa,--gsframe-3
+export CC_FLAGS_SFRAME
+endif
+
# build with sframe table
ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
-CC_FLAGS_SFRAME := -Wa,--gsframe-3
KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
-export CC_FLAGS_SFRAME
endif
# change __FILE__ to the relative path to the source directory
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index e90427a8d0f6..f03cac27857c 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -15,10 +15,6 @@ obj-vdso := vgettimeofday.o note.o sigreturn.o
vgetrandom.o vgetrandom-chacha.o
targets := $(obj-vdso) vdso.so vdso.so.dbg
obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
-ifeq ($(CONFIG_AS_SFRAME3),y)
- SFRAME_CFLAGS := -Wa,--gsframe-3
-endif
-
btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
# -Bsymbolic has been added for consistency with arm, the compat vDSO and
@@ -42,12 +38,12 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) \
$(RANDSTRUCT_CFLAGS) $(KSTACK_ERASE_CFLAGS) \
$(GCC_PLUGINS_CFLAGS) \
- $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
+ $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
-Wmissing-prototypes -Wmissing-declarations
-CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
$(SFRAME_CFLAGS)
+CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
$(CC_FLAGS_SFRAME)
-AS_FLAGS_ADD_VDSO := $(SFRAME_CFLAGS)
+AS_FLAGS_ADD_VDSO := $(CC_FLAGS_SFRAME)
CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
If done this way I think we will add the -Wa,--gsframe-3 twice when
HAVE_UNWIND_KERNEL_SFRAME=y, but maybe that's not a problem? This
could probably be folded into either this patch or mine [1], depending
which is applied first. I'm happy to rebase my unwind-for-kernel
patches onto this series, or we can do the other way around if that
works better.
What do you think?
Thanks,
Dylan
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Damon Ding @ 2026-05-22 1:32 UTC (permalink / raw)
To: Conor Dooley
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521-modify-quadrant-8d6a2e36727c@spud>
On 5/22/2026 3:50 AM, Conor Dooley wrote:
> On Thu, May 21, 2026 at 07:44:57PM +0800, Damon Ding wrote:
>> Add data-lanes property support to the port@1 endpoint for physical
>> lane mapping configuration.
>>
>> Lane mapping is mainly used for below scenarios:
>> 1. Correct PCB lane swap and differential line routing crossover
>> without hardware changes;
>> 2. Adapt mismatched lane pin definitions between SoC and eDP panel;
>> 3. Support multiple panel hardware variants on the same board
>> by configuring data-lanes in device tree only.
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> Sashiko complaint here looks valid.
> pw-bot: changes-requested
>
Yes, unevaluatedProperties: false should be added to both the port@1
and endpoint nodes.
Will fix in v3.
Best regards,
Damon
>
>>
>> ---
>>
>> Changes in v2:
>> - Add lane mapping application scenarios in commit message.
>> - Remove redundant deprecated property 'data-lanes' for eDP node.
>> - Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
>> ---
>> .../bindings/display/bridge/analogix,dp.yaml | 17 ++++++++++++-----
>> 1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
>> index 62f0521b0924..e34fdb21adb4 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
>> @@ -42,13 +42,20 @@ properties:
>> properties:
>> port@0:
>> $ref: /schemas/graph.yaml#/properties/port
>> - description:
>> - Input node to receive pixel data.
>> + description: Input node to receive pixel data.
>>
>> port@1:
>> - $ref: /schemas/graph.yaml#/properties/port
>> - description:
>> - Port node with one endpoint connected to a dp-connector node.
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description: Port node with one endpoint connected to sink device node.
>> + properties:
>> + endpoint:
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + properties:
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> + items:
>> + enum: [ 0, 1, 2, 3 ]
>>
>> required:
>> - port@0
>> --
>> 2.34.1
>>
^ 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