* Re: (subset) [PATCH 0/8] arm64: Implement support for 2025 dpISA extensions
From: Catalin Marinas @ 2026-04-09 18:39 UTC (permalink / raw)
To: Will Deacon, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <177575970227.3883927.939712260390088306.b4-ty@arm.com>
On Thu, Apr 09, 2026 at 07:35:02PM +0100, Catalin Marinas wrote:
> On Mon, 02 Mar 2026 22:53:15 +0000, Mark Brown wrote:
> > The 2025 dpISA extensions introduce a number of architecture features
> > all of which are fairly straightforward from a kernel point of view
> > since they only introduce new instructions, not any architecture state.
> >
> > All the relevant newly added ID registers are already exported by KVM,
> > all non-RES0 bits in ID_AA64ZFR0_EL1 and ID_AA64FPFR0_EL1 are writable
> > and the updates to ID_AA64ISARx_EL1 are all additional values in already
> > exported bitfields.
> >
> > [...]
>
> Applied to arm64 (for-next/sysreg), thanks! That's only the sysreg
> definitions as these are stable. I also applied the KERNEL_HWCAP_*
> generation on a different branch.
>
> [2/8] arm64/sysreg: Update ID_AA64ISAR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/b964aa8d68f7
> [3/8] arm64/sysreg: Update ID_AA64ISAR2_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/bb5e1e540501
> [4/8] arm64/sysreg: Update ID_AA64FPFR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/d74576b51ba6
> [5/8] arm64/sysreg: Update ID_AA64ZFR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/bf56250f34a4
> [6/8] arm64/sysreg: Update ID_AA64SMFR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/306736fd5155
b4 ty got confused with two emails for the same series, so only one went
out. The first patch is on for-next/misc:
[1/8] arm64/hwcap: Generate the KERNEL_HWCAP_ definitions for the hwcaps
https://git.kernel.org/arm64/c/abed23c3c44f
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Bryan O'Donoghue @ 2026-04-09 18:40 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-8-bc0c6dd77bc5@oss.qualcomm.com>
On 09/04/2026 19:10, Taniya Das wrote:
> + videocc: clock-controller@aaf0000 {
> + compatible = "qcom,eliza-videocc";
> + reg = <0x0 0xaaf0000 0x0 0x10000>;
> +
> + clocks = <&bi_tcxo_div2>,
> + <&sleep_clk>,
> + <&gcc GCC_VIDEO_AHB_CLK>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + camcc: clock-controller@ade0000 {
> + compatible = "qcom,eliza-camcc";
> + reg = <0x0 0x0ade0000 0x0 0x20000>;
> +
> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> + <&bi_tcxo_div2>,
> + <&sleep_clk>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
This looks odd.
Why do these two controllers have no power-domains ?
---
bod
^ permalink raw reply
* [PATCH rc v1 3/4] iommu/arm-smmu-v3: Retain SMMUEN during kdump device reset
From: Nicolin Chen @ 2026-04-09 19:46 UTC (permalink / raw)
To: jgg, will, robin.murphy
Cc: jamien, joro, praan, baolu.lu, kevin.tian, smostafa,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable
In-Reply-To: <cover.1775763475.git.nicolinc@nvidia.com>
When ARM_SMMU_OPT_KDUMP is set, skip the GBPA/disable/CR1/CR2/STRTAB_BASE
update sequence in arm_smmu_device_reset(). Those register writes are all
CONSTRAINED UNPREDICTABLE while SMMUEN==1, so leaving them untouched lets
in-flight DMA continue to be translated by the adopted stream table.
Initialize 'enables' to 0 so it can carry CR0_SMMUEN in kdump case. Then,
preserve that when enabling the command queue.
Also add a comment explaining why EVTQ/PRIQ are disabled in kdump cases.
Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 35 +++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
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 ff3c1beb3739e..d0ef8fb876978 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4931,13 +4931,28 @@ static void arm_smmu_write_strtab(struct arm_smmu_device *smmu)
static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
{
int ret;
- u32 reg, enables;
+ u32 reg, enables = 0;
struct arm_smmu_cmdq_ent cmd;
/* Clear CR0 and sync (disables SMMU and queue processing) */
reg = readl_relaxed(smmu->base + ARM_SMMU_CR0);
if (reg & CR0_SMMUEN) {
dev_warn(smmu->dev, "SMMU currently enabled! Resetting...\n");
+
+ /*
+ * In a kdump case, retain SMMUEN to avoid transiently aborting
+ * in-flight DMA. According to spec, updating STRTAB_BASE, CR1,
+ * or CR2 while SMMUEN==1 is CONSTRAINED UNPREDICTABLE. So skip
+ * those register updates and rely on the adopted stream table
+ * from the crashed kernel.
+ */
+ if (smmu->options & ARM_SMMU_OPT_KDUMP) {
+ dev_info(smmu->dev,
+ "kdump: retaining SMMUEN for in-flight DMA\n");
+ enables = CR0_SMMUEN;
+ goto reset_queues;
+ }
+
arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
}
@@ -4965,12 +4980,23 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
/* Stream table */
arm_smmu_write_strtab(smmu);
+reset_queues:
+ if (smmu->options & ARM_SMMU_OPT_KDUMP) {
+ /* Disable queues since arm_smmu_device_disable() was skipped */
+ ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0,
+ ARM_SMMU_CR0ACK);
+ if (ret) {
+ dev_err(smmu->dev, "failed to disable queues\n");
+ return ret;
+ }
+ }
+
/* Command queue */
writeq_relaxed(smmu->cmdq.q.q_base, smmu->base + ARM_SMMU_CMDQ_BASE);
writel_relaxed(smmu->cmdq.q.llq.prod, smmu->base + ARM_SMMU_CMDQ_PROD);
writel_relaxed(smmu->cmdq.q.llq.cons, smmu->base + ARM_SMMU_CMDQ_CONS);
- enables = CR0_CMDQEN;
+ enables |= CR0_CMDQEN;
ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0,
ARM_SMMU_CR0ACK);
if (ret) {
@@ -5038,6 +5064,11 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
return ret;
}
+ /*
+ * Disable EVTQ and PRIQ in kdump kernel. The old kernel's CDs and page
+ * tables may be corrupted, which could trigger event spamming. PRIQ is
+ * also useless since we cannot service page requests during kdump.
+ */
if (is_kdump_kernel())
enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
--
2.43.0
^ permalink raw reply related
* [PATCH rc v1 4/4] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP in arm_smmu_device_hw_probe()
From: Nicolin Chen @ 2026-04-09 19:46 UTC (permalink / raw)
To: jgg, will, robin.murphy
Cc: jamien, joro, praan, baolu.lu, kevin.tian, smostafa,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable
In-Reply-To: <cover.1775763475.git.nicolinc@nvidia.com>
arm_smmu_device_hw_probe() runs before arm_smmu_init_structures(), so it's
natural to decide whether the kdump kernel must adopt the crashed kernel's
stream table.
Given that memremap is used to adopt the old stream table, set this option
only on a coherent SMMU.
Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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 d0ef8fb876978..d92b5fa4bac17 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -5376,6 +5376,20 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
dev_info(smmu->dev, "oas %lu-bit (features 0x%08x)\n",
smmu->oas, smmu->features);
+
+ /*
+ * If SMMU is already active in kdump case, there could be in-flight DMA
+ * from devices initiated by the crashed kernel. Mark ARM_SMMU_OPT_KDUMP
+ * to let the init functions adopt the crashed kernel's stream table.
+ *
+ * Note that arm_smmu_adopt_strtab() uses memremap that can only work on
+ * a coherent SMMU. A non-coherent SMMU has no choice but to continue to
+ * abort any in-flight DMA.
+ */
+ if (is_kdump_kernel() && coherent &&
+ (readl_relaxed(smmu->base + ARM_SMMU_CR0) & CR0_SMMUEN))
+ smmu->options |= ARM_SMMU_OPT_KDUMP;
+
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH rc v1 2/4] iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
From: Nicolin Chen @ 2026-04-09 19:46 UTC (permalink / raw)
To: jgg, will, robin.murphy
Cc: jamien, joro, praan, baolu.lu, kevin.tian, smostafa,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable
In-Reply-To: <cover.1775763475.git.nicolinc@nvidia.com>
Though the kdump kernel adopts the crashed kernel's stream table, the iommu
core will still try to attach each probed device to a default domain, which
overwrites the adopted STE and breaks in-flight DMA from that device.
Implement an is_attach_deferred() callback to prevent this. For each device
that has STE.V=1 in the adopted table, defer the default domain attachment,
until the device driver explicitly requests it.
Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 28 +++++++++++++++++++++
1 file changed, 28 insertions(+)
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 8a1de3a67f78c..ff3c1beb3739e 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4212,6 +4212,33 @@ static void arm_smmu_remove_master(struct arm_smmu_master *master)
kfree(master->build_invs);
}
+static bool arm_smmu_is_attach_deferred(struct device *dev)
+{
+ struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+ struct arm_smmu_device *smmu = master->smmu;
+ int i;
+
+ if (!(smmu->options & ARM_SMMU_OPT_KDUMP))
+ return false;
+
+ for (i = 0; i < master->num_streams; i++) {
+ u32 sid = master->streams[i].id;
+ struct arm_smmu_ste *step;
+
+ /* Guard against unpopulated L2 entries in the adopted table */
+ if ((smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) &&
+ !smmu->strtab_cfg.l2.l2ptrs[arm_smmu_strtab_l1_idx(sid)])
+ continue;
+
+ step = arm_smmu_get_step_for_sid(smmu, sid);
+ /* If the STE has the Valid bit set, defer the attach */
+ if (le64_to_cpu(step->data[0]) & STRTAB_STE_0_V)
+ return true;
+ }
+
+ return false;
+}
+
static struct iommu_device *arm_smmu_probe_device(struct device *dev)
{
int ret;
@@ -4374,6 +4401,7 @@ static const struct iommu_ops arm_smmu_ops = {
.hw_info = arm_smmu_hw_info,
.domain_alloc_sva = arm_smmu_sva_domain_alloc,
.domain_alloc_paging_flags = arm_smmu_domain_alloc_paging_flags,
+ .is_attach_deferred = arm_smmu_is_attach_deferred,
.probe_device = arm_smmu_probe_device,
.release_device = arm_smmu_release_device,
.device_group = arm_smmu_device_group,
--
2.43.0
^ permalink raw reply related
* [PATCH rc v1 0/4] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-04-09 19:46 UTC (permalink / raw)
To: jgg, will, robin.murphy
Cc: jamien, joro, praan, baolu.lu, kevin.tian, smostafa,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable
When transitioning to a kdump kernel, the primary kernel might have crashed
while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
and setting the Global Bypass Attribute (GBPA) to ABORT.
In a kdump scenario, this aggressive reset is highly destructive:
a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
PCIe AER or SErrors that may panic the kdump kernel
b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
To safely absorb in-flight DMA, the kdump kernel must leave SMMUEN=1 intact
and avoid modifying STRTAB_BASE. This allows HW to continue translating in-
flight DMA using the crashed kernel's page tables until the endpoint device
drivers probe and quiesce their respective hardware.
However, the ARM SMMUv3 architecture specification states that updating the
SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
This leaves a kdump kernel no choice but to adopt the stream table from the
crashed kernel.
In this series:
- Introduce an ARM_SMMU_OPT_KDUMP
- Skip SMMUEN and STRTAB_BASE resets in arm_smmu_device_reset()
- Map the crashed kernel's stream tables into the kdump kernel [*]
- Defer any default domain attachment to retain STEs until device drivers
explicitly request it.
[*] This is implemented via memremap, which only works on a coherent SMMU.
Note that the entire series requires Jason's work that was merged in v6.12:
85196f5 ("iommu/arm-smmu-v3: Reorganize struct arm_smmu_strtab_cfg").
I have a backported version that is verified with a v6.8 kernel. I can send
if we see a strong need after this version is accepted.
This is on Github:
https://github.com/nicolinc/iommufd/commits/smmuv3_kdump-v1
Nicolin Chen (4):
iommu/arm-smmu-v3: Add arm_smmu_adopt_strtab() for kdump
iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
iommu/arm-smmu-v3: Retain SMMUEN during kdump device reset
iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP in
arm_smmu_device_hw_probe()
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 176 +++++++++++++++++++-
2 files changed, 174 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH rc v1 1/4] iommu/arm-smmu-v3: Add arm_smmu_adopt_strtab() for kdump
From: Nicolin Chen @ 2026-04-09 19:46 UTC (permalink / raw)
To: jgg, will, robin.murphy
Cc: jamien, joro, praan, baolu.lu, kevin.tian, smostafa,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable
In-Reply-To: <cover.1775763475.git.nicolinc@nvidia.com>
When transitioning to a kdump kernel, the primary kernel might have crashed
while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
and setting the Global Bypass Attribute (GBPA) to ABORT.
In a kdump scenario, this aggressive reset is highly destructive:
a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
PCIe AER or SErrors that may panic the kdump kernel
b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
To safely absorb in-flight DMA, the kdump kernel must leave SMMUEN=1 intact
and avoid modifying STRTAB_BASE. This allows HW to continue translating in-
flight DMA using the crashed kernel's page tables until the endpoint device
drivers probe and quiesce their respective hardware.
However, the ARM SMMUv3 architecture specification states that updating the
SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
This leaves a kdump kernel no choice but to adopt the stream table from the
crashed kernel.
Introduce ARM_SMMU_OPT_KDUMP and arm_smmu_adopt_strtab() that does memremap
on all the stream tables extracted from STRTAB_BASE and STRTAB_BASE_CFG.
The option will be set in arm_smmu_device_hw_probe().
Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
Cc: stable@vger.kernel.org # v6.12+
Suggested-by: Jason Gunthorpe <jgg@nvidia.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 | 99 ++++++++++++++++++++-
2 files changed, 99 insertions(+), 1 deletion(-)
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..74950d98ba09f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -861,6 +861,7 @@ struct arm_smmu_device {
#define ARM_SMMU_OPT_MSIPOLL (1 << 2)
#define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
#define ARM_SMMU_OPT_TEGRA241_CMDQV (1 << 4)
+#define ARM_SMMU_OPT_KDUMP (1 << 5)
u32 options;
struct arm_smmu_cmdq cmdq;
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 f6901c5437edc..8a1de3a67f78c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4553,11 +4553,108 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
return 0;
}
+static int arm_smmu_adopt_strtab_2lvl(struct arm_smmu_device *smmu, u32 cfg_reg,
+ dma_addr_t dma)
+{
+ u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
+ u32 split = FIELD_GET(STRTAB_BASE_CFG_SPLIT, cfg_reg);
+ struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
+ u32 num_l1_ents;
+ int i;
+
+ if (log2size < split) {
+ dev_err(smmu->dev, "kdump: invalid log2size %u < split %u\n",
+ log2size, split);
+ return -EINVAL;
+ }
+
+ if (split != STRTAB_SPLIT) {
+ dev_err(smmu->dev,
+ "kdump: unsupported STRTAB_SPLIT %u (expected %u)\n",
+ split, STRTAB_SPLIT);
+ return -EINVAL;
+ }
+
+ num_l1_ents = 1 << (log2size - split);
+ cfg->l2.l1_dma = dma;
+ cfg->l2.num_l1_ents = num_l1_ents;
+ cfg->l2.l1tab = devm_memremap(
+ smmu->dev, dma, num_l1_ents * sizeof(struct arm_smmu_strtab_l1),
+ MEMREMAP_WB);
+ if (!cfg->l2.l1tab)
+ return -ENOMEM;
+
+ cfg->l2.l2ptrs = devm_kcalloc(smmu->dev, num_l1_ents,
+ sizeof(*cfg->l2.l2ptrs), GFP_KERNEL);
+ if (!cfg->l2.l2ptrs)
+ return -ENOMEM;
+
+ for (i = 0; i < num_l1_ents; i++) {
+ u64 l2ptr = le64_to_cpu(cfg->l2.l1tab[i].l2ptr);
+ u32 span = FIELD_GET(STRTAB_L1_DESC_SPAN, l2ptr);
+ dma_addr_t l2_dma = l2ptr & STRTAB_L1_DESC_L2PTR_MASK;
+
+ if (span && l2_dma) {
+ cfg->l2.l2ptrs[i] = devm_memremap(
+ smmu->dev, l2_dma,
+ sizeof(struct arm_smmu_strtab_l2), MEMREMAP_WB);
+ if (!cfg->l2.l2ptrs[i])
+ return -ENOMEM;
+ }
+ }
+
+ return 0;
+}
+
+static int arm_smmu_adopt_strtab_linear(struct arm_smmu_device *smmu,
+ u32 cfg_reg, dma_addr_t dma)
+{
+ u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
+ struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
+
+ cfg->linear.ste_dma = dma;
+ cfg->linear.num_ents = 1 << log2size;
+ cfg->linear.table = devm_memremap(smmu->dev, dma,
+ cfg->linear.num_ents *
+ sizeof(struct arm_smmu_ste),
+ MEMREMAP_WB);
+ if (!cfg->linear.table)
+ return -ENOMEM;
+ return 0;
+}
+
+static int arm_smmu_adopt_strtab(struct arm_smmu_device *smmu)
+{
+ u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
+ u64 base_reg = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
+ u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
+ dma_addr_t dma = base_reg & STRTAB_BASE_ADDR_MASK;
+ int ret;
+
+ dev_info(smmu->dev, "kdump: adopting crashed kernel's stream table\n");
+
+ if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
+ /* Enforce 2-level feature flag to match the adopted table */
+ smmu->features |= ARM_SMMU_FEAT_2_LVL_STRTAB;
+ ret = arm_smmu_adopt_strtab_2lvl(smmu, cfg_reg, dma);
+ } else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
+ /* Force linear feature flag to match the adopted table */
+ smmu->features &= ~ARM_SMMU_FEAT_2_LVL_STRTAB;
+ ret = arm_smmu_adopt_strtab_linear(smmu, cfg_reg, dma);
+ } else {
+ dev_err(smmu->dev, "kdump: invalid STRTAB format %u\n", fmt);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
{
int ret;
- if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
+ if (smmu->options & ARM_SMMU_OPT_KDUMP)
+ ret = arm_smmu_adopt_strtab(smmu);
+ else if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
ret = arm_smmu_init_strtab_2lvl(smmu);
else
ret = arm_smmu_init_strtab_linear(smmu);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC 00/12] Add support for DisplayPort link training information report
From: Ville Syrjälä @ 2026-04-09 20:36 UTC (permalink / raw)
To: Kory Maincent
Cc: Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
David Airlie, Simona Vetter, Dave Airlie, Jesse Barnes,
Eric Anholt, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, AngeloGioacchino Del Regno, Chris Wilson,
Thomas Petazzoni, Mark Yacoub, Sean Paul, Louis Chauvet,
intel-gfx, intel-xe, dri-devel, linux-kernel, linux-mediatek,
linux-arm-kernel, Simona Vetter
In-Reply-To: <20260409-feat_link_cap-v1-0-7069e8199ce2@bootlin.com>
On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:
> DisplayPort link training negotiates the physical-layer parameters needed
> for a reliable connection: lane count, link rate, voltage swing,
> pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
> each driver exposes this state in its own way, often through
> driver-specific debugfs entries, with no standard interface for userspace
> diagnostic and monitoring tools.
>
> This series introduces a generic, DRM-managed framework for exposing DP
> link training state as standard connector properties, modeled after the
> existing HDMI helper drmm_connector_hdmi_init().
>
> The new drmm_connector_dp_init() helper initializes a DP connector and
> registers the following connector properties to expose the negotiated link
> state to userspace:
>
> - num_lanes: negotiated lane count (1, 2 or 4)
> - link_rate: negotiated link rate
> - dsc_en: whether Display Stream Compression is active
> - voltage_swingN: per-lane voltage swing level (lanes 0-3)
> - pre_emphasisN: per-lane pre-emphasis level (lanes 0-3)
I don't see why any real userspace would be interested in those (apart
from maybe DSC). If this is just for diagnostics and whatnot then I
think sysfs/debugfs could be a better fit.
>
> Two runtime helpers update and clear these properties when link training
> completes or the link goes down:
> - drm_connector_dp_set_link_train_properties()
> - drm_connector_dp_reset_link_train_properties()
>
> Two drivers are updated as reference implementations: i915 (direct
> connector path) and MediaTek (via the bridge connector framework using a
> new DRM_BRIDGE_OP_DP flag). The i915 patches are preceded by a series of
> conversions to DRM managed resources, which are required before adopting
> drmm_connector_dp_init().
>
> The MST case in i915 driver is not supported yet.
>
> Patches 1-3: Fix two error-path cleanup bugs in i915 sdvo and lvds
> [Will probably be sent standalone]
> Patches 4-8: Convert i915 display resources to DRM managed lifetime
> Patch 9: Introduce the core drmm_connector_dp_init() framework
> Patch 10: Wire the i915 DP connector to use the new helpers
> Patch 11: Introduce DRM_BRIDGE_OP_DP and wire bridge connectors
> Patch 12: Wire the MediaTek DP bridge to the new helpers [untested]
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> Kory Maincent (12):
> drm/i915/display/intel_sdvo: Fix double connector destroy in error paths
> drm/i915/display/intel_lvds: Drop redundant manual cleanup on init failure
> drm/i915/display/intel_dp: Drop redundant intel_dp_aux_fini() on init failure
> drm/i915/display: Switch to drmm_mode_config_init() and drop manual cleanup
> drm/i915/display: Switch to managed for crtc
> drm/i915/display: Switch to managed for plane
> drm/i915/display: Switch to managed for encoder
> drm/i915/display: Switch to managed for connector
> drm: Introduce drmm_connector_dp_init() with link training state properties
> drm/i915/display/dp: Adopt dp_connector helpers to expose link training state
> drm/bridge: Wire drmm_connector_dp_init() via new DRM_BRIDGE_OP_DP flag
> drm/mediatek: Use dp_connector helpers to report link training state
>
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/display/drm_bridge_connector.c | 26 +-
> drivers/gpu/drm/drm_dp_connector.c | 344 +++++++++++++++++++++
> drivers/gpu/drm/i915/display/g4x_dp.c | 39 +--
> drivers/gpu/drm/i915/display/g4x_hdmi.c | 27 +-
> drivers/gpu/drm/i915/display/i9xx_plane.c | 97 +++---
> drivers/gpu/drm/i915/display/icl_dsi.c | 50 ++-
> drivers/gpu/drm/i915/display/intel_connector.c | 26 +-
> drivers/gpu/drm/i915/display/intel_connector.h | 5 +-
> drivers/gpu/drm/i915/display/intel_crt.c | 28 +-
> drivers/gpu/drm/i915/display/intel_crtc.c | 102 +++---
> drivers/gpu/drm/i915/display/intel_cursor.c | 41 ++-
> drivers/gpu/drm/i915/display/intel_ddi.c | 64 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 8 -
> drivers/gpu/drm/i915/display/intel_display.h | 1 -
> .../gpu/drm/i915/display/intel_display_driver.c | 37 ++-
> drivers/gpu/drm/i915/display/intel_dp.c | 43 ++-
> .../gpu/drm/i915/display/intel_dp_link_training.c | 25 ++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 33 +-
> drivers/gpu/drm/i915/display/intel_dvo.c | 43 +--
> drivers/gpu/drm/i915/display/intel_encoder.c | 6 +-
> drivers/gpu/drm/i915/display/intel_encoder.h | 3 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 15 +-
> drivers/gpu/drm/i915/display/intel_lvds.c | 45 ++-
> drivers/gpu/drm/i915/display/intel_plane.c | 45 +--
> drivers/gpu/drm/i915/display/intel_plane.h | 5 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 134 +++-----
> drivers/gpu/drm/i915/display/intel_sprite.c | 119 ++++---
> drivers/gpu/drm/i915/display/intel_tv.c | 26 +-
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 102 +++---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 42 +--
> drivers/gpu/drm/mediatek/mtk_dp.c | 34 +-
> include/drm/drm_bridge.h | 13 +
> include/drm/drm_connector.h | 38 +++
> include/drm/drm_dp_connector.h | 109 +++++++
> 35 files changed, 1125 insertions(+), 651 deletions(-)
> ---
> base-commit: db5a75cfd29766536be62aece9f19c6e7a858fa6
> change-id: 20260226-feat_link_cap-20cbb6f31d40
>
> Best regards,
> --
> Köry Maincent, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Daniel Golle @ 2026-04-09 20:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Frank Wunderlich, Chester A. Unal, Felix Fietkau,
Alexander Couzens, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Frank Wunderlich,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260409164942.wbmwtkpd5d5zibyy@skbuf>
On Thu, Apr 09, 2026 at 07:49:42PM +0300, Vladimir Oltean wrote:
> I notice Arınc, listed by ./scripts/get_maintainer.pl drivers/net/dsa/mt7530.c,
> and Felix, listed by ./scripts/get_maintainer.pl drivers/net/ethernet/mediatek/mtk_eth_soc.c,
> are not on CC. Maybe they have more info.
>
> Only the switch port has a chance of having a non-zero default polarity
> setting? (coming from the efuse, if I understood this discussion properly)
> https://lore.kernel.org/netdev/C59EED96-3973-4074-A4D8-C264949D447E@linux.dev/
> The GMAC doesn't?
Yes, vendor SDK uses DT mediatek,pnswap{,-rx,-tx} properties only for the
SoC GMACs. For MT7531 there are **no** strap pins deciding the SerDes
polarity, and also no software-way to override the defaults in the vendor
SDK.
However, the MT7531 datasheet quite clearly states:
Register 000050EC QPHY_WRAP_CTRL -- QPHY wrapper control
Reset value: 0x00000501
BIT 1 RX_BIT_POLARITY -- RX bit polarity control
1'b0: normal
1'b1: inverted
BIT 0 TX_BIT_POLARITY -- TX bit polarity control (TX default inversed in MT7531)
1'b0: normal
1'b1: inverted
Hence the best would be to just assume the documented default in the driver
as well.
A quick register dump using the BPi-R3 confirms that this applies to *both*
SerDes PCS on MT7531A (port 5 and port 6) equally, both read 0x00000501
after reset.
^ permalink raw reply
* Re: [GIT PULL] pmdomain fixes for v7.0-rc8
From: pr-tracker-bot @ 2026-04-09 20:57 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Linus, linux-pm, linux-kernel, Ulf Hansson, linux-arm-kernel
In-Reply-To: <20260409150950.28527-1-ulf.hansson@linaro.org>
The pull request you sent on Thu, 9 Apr 2026 17:09:50 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git tags/pmdomain-v7.0-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d58305b2dbe3434c9b21ede210329b97c44ee9e8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v13 10/17] drm/bridge: analogix_dp: Pass struct drm_atomic_state* for analogix_dp_bridge_mode_set()
From: Dmitry Baryshkov @ 2026-04-09 21:02 UTC (permalink / raw)
To: Damon Ding
Cc: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan, Laurent.pinchart, jonas,
jernej.skrabec, kernel, festevam, alim.akhtar, luca.ceresoli,
nicolas.frattaroli, dianders, m.szyprowski, linux-kernel,
dri-devel, imx, linux-arm-kernel, linux-samsung-soc,
linux-rockchip
In-Reply-To: <20260409065301.446670-11-damon.ding@rock-chips.com>
On Thu, Apr 09, 2026 at 02:52:54PM +0800, Damon Ding wrote:
> To avoid using &analogix_dp_device.connector for compatibility
> with the bridge connector framework, get &drm_connector from
> &drm_atomic_state instead.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v13 11/17] drm/bridge: analogix_dp: Apply drm_bridge_connector helper
From: Dmitry Baryshkov @ 2026-04-09 21:06 UTC (permalink / raw)
To: Damon Ding
Cc: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan, Laurent.pinchart, jonas,
jernej.skrabec, kernel, festevam, alim.akhtar, luca.ceresoli,
nicolas.frattaroli, dianders, m.szyprowski, linux-kernel,
dri-devel, imx, linux-arm-kernel, linux-samsung-soc,
linux-rockchip
In-Reply-To: <20260409065301.446670-12-damon.ding@rock-chips.com>
On Thu, Apr 09, 2026 at 02:52:55PM +0800, Damon Ding wrote:
> Initialize bridge_connector for both Rockchip and Exynos encoder sides.
> Then, make DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory for Analogix bridge
> side, as the private &drm_connector is no longer created.
>
> The previous &drm_connector_funcs and &drm_connector_helper_funcs APIs
> are replaced by the corresponding &drm_bridge_funcs APIs:
>
> analogix_dp_atomic_check() -> analogix_dp_bridge_atomic_check()
> analogix_dp_detect() -> analogix_dp_bridge_detect()
> analogix_dp_get_modes() -> analogix_dp_bridge_get_modes()
> analogix_dp_bridge_edid_read()
>
> Additionally, the compatibilities of Analogix DP bridge based on whether
> the next bridge is a 'panel'. If it is, OP_MODES and OP_DETECT are
> supported; If not (the next bridge is a 'monitor' or a bridge chip),
> OP_EDID and OP_DETECT are supported.
>
> The devm_drm_bridge_add() is placed in analogix_dp_bind() instead of
> analogix_dp_probe(), because the type of next bridge (the panel, monitor
> or bridge chip) can only be determined after the probe process has fully
> completed.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add KVM_CAP_ARM_NATIVE_CACHE_CONFIG vcpu capability
From: David Woodhouse @ 2026-04-09 21:10 UTC (permalink / raw)
To: Marc Zyngier
Cc: Gutierrez Cantu, Bernardo, alexandru.elisei, alyssa, asahi,
broonie, catalin.marinas, james.morse, kvmarm, linux-arm-kernel,
linux-kernel, marcan, mathieu.poirier, oliver.upton,
suzuki.poulose, sven, will
In-Reply-To: <86qzoo2eba.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
On Thu, 2026-04-09 at 19:12 +0100, Marc Zyngier wrote:
>
> That only means you are doing a pretty bad job at supporting
> guests. And yes, this is an issue for anything that expects to see
> something meaningful in CCSIDR[]. The fact that none of your guests
> hit that problem only means you're lacking coverage.
I think we just have a different idea of what it means to do a good job
of supporting guests. For me, the most important thing is never to
randomly change stuff underneath a running guest, even if it's a "bug
fix".
Even fixing an egregious and obvious bug, like fixing the reported
serial port type from the legacy 16550 to ACPI_DBG2_16550_WITH_GAS
turned out to break FreeBSD, to pick just one recent example.
Guest operating systems will often work with the environment they
actually *had* already, regardless of the actual specifications or
common sense. We don't have the luxury of just changing things
underneath them and then saying "haha, well that should never have
worked so screw you".
Moving to the fixed model is obviously the plan, but it has to be done
carefully and starting with new launches and new instance types and a
rollback plan, not just randomly inflicted as an unexpected side-effect
of a kernel upgrade.
> From what I can read, anything from Neoverse V1 is affected.
>
> >
> > This isn't about introducing *new* behaviour; it's about allowing the
> > existing established behaviour to be maintained so that we can have a
> > *managed* transition to the new model (for new launches) rather than an
> > unconditional uncontrolled change as the kernel gets upgraded.
>
> Then fully implement "show me the cache hierarchy", read it out, and
> write it back with whatever level of brokenness you intend to inflict
> on your guests.
Again, *compatibility* is the point here, not brokenness.
> But I'm not reintroducing this particular bug.
Fair enough. It's not like the x86 zoo; there are only a certain number
of existing CPUs that I care about, that I need to enumerate. I can
just hard-code the values for all of those in the VMM — the kernel does
let me override the errantly-changed defaults, as the commit message
said.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* [PATCH 0/4] samsung,coreprimevelte dt fixes
From: Duje Mihanović @ 2026-04-09 21:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Karel Balej,
David Wronek, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
A small assortment of DT fixes for samsung,coreprimevelte.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Duje Mihanović (4):
arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen voltage
arm64: dts: marvell: samsung,coreprimevelte: Use memory-region for framebuffer
arm64: dts: marvell: pxa1908: Add PSCI function IDs
arm64: dts: marvell: samsung-coreprimevelte: Add missing SDIO properties
.../boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts | 11 +++++++----
arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi | 5 ++++-
2 files changed, 11 insertions(+), 5 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20251214-cprime-dt-fixes-v6-20-c15947ca5fd9
Best regards,
--
Duje Mihanović <duje@dujemihanovic.xyz>
^ permalink raw reply
* [PATCH 2/4] arm64: dts: marvell: samsung,coreprimevelte: Use memory-region for framebuffer
From: Duje Mihanović @ 2026-04-09 21:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Karel Balej,
David Wronek, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260409-cprime-dt-fixes-v6-20-v1-0-8df6f88942c8@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Since the framebuffer resides in system RAM, use the memory-region
property preferred in that case over reg.
Also, testing showed that reusing most of the region (excluding where
the actual framebuffer resides) is perfectly safe, so do that and save
~22.5 MiB of RAM in the process.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
index bb0a99399624..f71bb856f1e7 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
@@ -23,7 +23,7 @@ chosen {
fb0: framebuffer@17177000 {
compatible = "simple-framebuffer";
- reg = <0 0x17177000 0 (480 * 800 * 4)>;
+ memory-region = <&fb_mem>;
power-domains = <&apmu PXA1908_POWER_DOMAIN_DSI>;
width = <480>;
height = <800>;
@@ -48,8 +48,9 @@ secure-region@0 {
reg = <0 0 0 0x1000000>;
};
- framebuffer@17000000 {
- reg = <0 0x17000000 0 0x1800000>;
+ /* The "active buffer" is at 0x17000000 + (size of one buffer). */
+ fb_mem: framebuffer@17177000 {
+ reg = <0 0x17177000 0 (480 * 800 * 4)>;
no-map;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen voltage
From: Duje Mihanović @ 2026-04-09 21:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Karel Balej,
David Wronek, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260409-cprime-dt-fixes-v6-20-v1-0-8df6f88942c8@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
The old 1.9V setting was found to be insufficient in certain
environments (in my case cold ones), causing the touchscreen to register
ghost touches and mostly ignore actual touches. Increase the voltage to
2.5V to correct the issue.
Fixes: ec958b5b18c8 ("arm64: dts: samsung,coreprimevelte: add touchscreen")
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
index b2ce5edd9c6a..bb0a99399624 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
@@ -460,7 +460,7 @@ pmic@30 {
regulators {
ldo2: ldo2 {
- regulator-min-microvolt = <1900000>;
+ regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3100000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: marvell: samsung-coreprimevelte: Add missing SDIO properties
From: Duje Mihanović @ 2026-04-09 21:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Karel Balej,
David Wronek, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260409-cprime-dt-fixes-v6-20-v1-0-8df6f88942c8@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
According to the vendor device tree, the WiFi+BT card must not be
powered off during suspend and is capable of waking up the board. Add
the respective properties to the SDIO node to reflect this.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
index f71bb856f1e7..6ec899c427e1 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
@@ -524,6 +524,8 @@ &sdh1 {
pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
bus-width = <4>;
non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
};
&pwm3 {
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: marvell: pxa1908: Add PSCI function IDs
From: Duje Mihanović @ 2026-04-09 21:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Karel Balej,
David Wronek, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260409-cprime-dt-fixes-v6-20-v1-0-8df6f88942c8@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Add function IDs for CPU_ON and CPU_OFF from vendor kernel source. This
is done for completeness and to allow PSCI to work on the occasion that
the DT is used with an ancient kernel.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi b/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
index 5778bfdb8567..91022b62a39b 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
@@ -55,8 +55,11 @@ pmu {
};
psci {
- compatible = "arm,psci-0.2";
+ compatible = "arm,psci-0.2", "arm,psci";
method = "smc";
+
+ cpu_off = <0x85000001>;
+ cpu_on = <0x85000002>;
};
reserved-memory {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC 00/12] Add support for DisplayPort link training information report
From: Dmitry Baryshkov @ 2026-04-09 21:36 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Kory Maincent, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, David Airlie, Simona Vetter, Dave Airlie,
Jesse Barnes, Eric Anholt, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Chun-Kuang Hu,
Philipp Zabel, Matthias Brugger, AngeloGioacchino Del Regno,
Chris Wilson, Thomas Petazzoni, Mark Yacoub, Sean Paul,
Louis Chauvet, intel-gfx, intel-xe, dri-devel, linux-kernel,
linux-mediatek, linux-arm-kernel, Simona Vetter
In-Reply-To: <adgNxaFhbQaxC5E_@intel.com>
On Thu, Apr 09, 2026 at 11:36:21PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:
> > DisplayPort link training negotiates the physical-layer parameters needed
> > for a reliable connection: lane count, link rate, voltage swing,
> > pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
> > each driver exposes this state in its own way, often through
> > driver-specific debugfs entries, with no standard interface for userspace
> > diagnostic and monitoring tools.
> >
> > This series introduces a generic, DRM-managed framework for exposing DP
> > link training state as standard connector properties, modeled after the
> > existing HDMI helper drmm_connector_hdmi_init().
> >
> > The new drmm_connector_dp_init() helper initializes a DP connector and
> > registers the following connector properties to expose the negotiated link
> > state to userspace:
> >
> > - num_lanes: negotiated lane count (1, 2 or 4)
> > - link_rate: negotiated link rate
> > - dsc_en: whether Display Stream Compression is active
> > - voltage_swingN: per-lane voltage swing level (lanes 0-3)
> > - pre_emphasisN: per-lane pre-emphasis level (lanes 0-3)
>
> I don't see why any real userspace would be interested in those (apart
> from maybe DSC). If this is just for diagnostics and whatnot then I
> think sysfs/debugfs could be a better fit.
I'd agree here. Please consider implementing it as a debugfs interface,
possibly reusing the Intel's format.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Vladimir Oltean @ 2026-04-09 21:52 UTC (permalink / raw)
To: Daniel Golle
Cc: Frank Wunderlich, Chester A. Unal, Felix Fietkau,
Alexander Couzens, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Frank Wunderlich,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <adgSXDUn-oL6V_TK@makrotopia.org>
On Thu, Apr 09, 2026 at 09:55:56PM +0100, Daniel Golle wrote:
> On Thu, Apr 09, 2026 at 07:49:42PM +0300, Vladimir Oltean wrote:
> > I notice Arınc, listed by ./scripts/get_maintainer.pl drivers/net/dsa/mt7530.c,
> > and Felix, listed by ./scripts/get_maintainer.pl drivers/net/ethernet/mediatek/mtk_eth_soc.c,
> > are not on CC. Maybe they have more info.
> >
> > Only the switch port has a chance of having a non-zero default polarity
> > setting? (coming from the efuse, if I understood this discussion properly)
> > https://lore.kernel.org/netdev/C59EED96-3973-4074-A4D8-C264949D447E@linux.dev/
> > The GMAC doesn't?
>
> Yes, vendor SDK uses DT mediatek,pnswap{,-rx,-tx} properties only for the
> SoC GMACs. For MT7531 there are **no** strap pins deciding the SerDes
> polarity, and also no software-way to override the defaults in the vendor
> SDK.
>
> However, the MT7531 datasheet quite clearly states:
> Register 000050EC QPHY_WRAP_CTRL -- QPHY wrapper control
> Reset value: 0x00000501
>
> BIT 1 RX_BIT_POLARITY -- RX bit polarity control
> 1'b0: normal
> 1'b1: inverted
>
> BIT 0 TX_BIT_POLARITY -- TX bit polarity control (TX default inversed in MT7531)
> 1'b0: normal
> 1'b1: inverted
>
> Hence the best would be to just assume the documented default in the driver
> as well.
>
> A quick register dump using the BPi-R3 confirms that this applies to *both*
> SerDes PCS on MT7531A (port 5 and port 6) equally, both read 0x00000501
> after reset.
OK. Excepting the DSA driver for MT7531 from polarity configuration
based on lack of a fwnode for the PCS should be fine (for now, to
address the regression).
^ permalink raw reply
* Re: [PATCH RFC 09/12] drm: Introduce drmm_connector_dp_init() with link training state properties
From: Dmitry Baryshkov @ 2026-04-09 21:53 UTC (permalink / raw)
To: Kory Maincent
Cc: Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
David Airlie, Simona Vetter, Dave Airlie, Jesse Barnes,
Eric Anholt, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, AngeloGioacchino Del Regno, Chris Wilson,
Thomas Petazzoni, Mark Yacoub, Sean Paul, Louis Chauvet,
intel-gfx, intel-xe, dri-devel, linux-kernel, linux-mediatek,
linux-arm-kernel, Simona Vetter
In-Reply-To: <20260409-feat_link_cap-v1-9-7069e8199ce2@bootlin.com>
On Thu, Apr 09, 2026 at 07:08:25PM +0200, Kory Maincent wrote:
> Add a managed DisplayPort connector initialization helper,
> drmm_connector_dp_init(), modeled after the existing HDMI counterpart
> drmm_connector_hdmi_init(). Cleanup is handled automatically via a
> DRM-managed action.
>
> The helper creates the following immutable connector properties to expose
> DP link training capabilities and state to userspace:
>
> - num_lanes: bitmask of supported lane counts (1, 2, 4)
> - link_rate: Array of supported link rates.
> - dsc_en: Display Stream Compression supported
> - voltage_swingN: per-lane voltage swing level bitmask
> - pre-emphasisN: per-lane pre-emphasis level bitmask
>
> Link rates are passed by the driver in deca-kbps, following the DRM
> convention, but exposed to userspace in kbps for clarity.
>
> Two additional helpers are provided to update and reset those properties
> at runtime:
> - drm_connector_dp_set_link_train_properties()
> - drm_connector_dp_reset_link_train_properties()
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_dp_connector.c | 344 +++++++++++++++++++++++++++++++++++++
> include/drm/drm_connector.h | 38 ++++
> include/drm/drm_dp_connector.h | 109 ++++++++++++
> 4 files changed, 492 insertions(+)
>
> diff --git a/include/drm/drm_dp_connector.h b/include/drm/drm_dp_connector.h
> new file mode 100644
> index 0000000000000..77d2f4bb6df68
> --- /dev/null
> +++ b/include/drm/drm_dp_connector.h
> @@ -0,0 +1,109 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef DRM_DP_CONNECTOR_H_
> +#define DRM_DP_CONNECTOR_H_
> +
> +#include <drm/drm_connector.h>
> +
> +#define DRM_DP_1LANE BIT(0)
> +#define DRM_DP_2LANE BIT(1)
> +#define DRM_DP_4LANE BIT(2)
> +#define DRM_NLANES_MASK (DRM_DP_1LANE | DRM_DP_2LANE | DRM_DP_4LANE)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_0 BIT(0)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_1 BIT(1)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_2 BIT(2)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_3 BIT(3)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_MASK (DRM_DP_VOLTAGE_SWING_LEVEL_0 | \
> + DRM_DP_VOLTAGE_SWING_LEVEL_1 | \
> + DRM_DP_VOLTAGE_SWING_LEVEL_2 | \
> + DRM_DP_VOLTAGE_SWING_LEVEL_3)
> +#define DRM_DP_PRE_EMPH_LEVEL_0 BIT(0)
> +#define DRM_DP_PRE_EMPH_LEVEL_1 BIT(1)
> +#define DRM_DP_PRE_EMPH_LEVEL_2 BIT(2)
> +#define DRM_DP_PRE_EMPH_LEVEL_3 BIT(3)
> +#define DRM_DP_PRE_EMPH_LEVEL_MASK (DRM_DP_PRE_EMPH_LEVEL_0 | \
> + DRM_DP_PRE_EMPH_LEVEL_1 | \
> + DRM_DP_PRE_EMPH_LEVEL_2 | \
> + DRM_DP_PRE_EMPH_LEVEL_3)
> +
> +/**
> + * struct drm_connector_dp_link_train_caps - DRM DisplayPort link training
> + * capabilities
Those are not just link training caps. It is more like DP link caps.
They make sense to be a part of the DP-related drm_connector part.
> + */
> +struct drm_connector_dp_link_train_caps {
> + /**
> + * @nlanes: Bitmask of lanes number supported
> + */
> + u8 nlanes;
> +
> + /**
> + * @nrates: Number of link rates supported
> + */
> + u32 nrates;
> +
> + /**
> + * @rates: Array listing the supported link rates in deca-kbps
> + */
> + const u32 *rates;
> +
> + /**
> + * @dsc: Display Stream Compression supported
> + */
> + bool dsc;
> +
> + /**
> + * @v_swings: Bitmask of voltage swing level supported
> + */
> + u8 v_swings;
> +
> + /**
> + * @pre_emphs: Bitmask of pre-emphasis level supported
> + */
> + u8 pre_emphs;
> +};
> +
> +/**
> + * struct drm_connector_dp_link_train - DRM DisplayPort link training
> + * information report
> + */
> +struct drm_connector_dp_link_train {
THese define the current DP state. As such, they definitely make sense
to be a part of the drm_connector.
> + /**
> + * @nlanes: The number of lanes used
> + */
> + u8 nlanes;
> +
> + /**
> + * @rates: Link rate value selected in deca-kbps
> + */
> + u32 rate;
> +
> + /**
> + * @dsc: Display Stream Compression enabled
> + */
> + bool dsc_en;
> +
> + /**
> + * @v_swings: Array listing the bitmask voltage swing level per lanes
> + */
> + u8 v_swing[4];
> +
> + /**
> + * @pre_emph: Array listing the bitmask pre-emphasis level per lanes
> + */
> + u8 pre_emph[4];
Please consider following struct phy_configure_opts_dp (or using it as
is). Overall, please refer the talk and (more important) the lightning
resumee at this XDC. I have some bits and pieces ready in spite of that
proposal, but I didn't have time to finish it.
> +};
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Vladimir Oltean @ 2026-04-09 21:55 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Alexander Couzens, Daniel Golle, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Wunderlich, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260409133344.129620-1-linux@fw-web.de>
On Thu, Apr 09, 2026 at 03:33:42PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
>
> Commit 8871389da151 introduces common pcs dts properties which writes
> rx=normal,tx=normal polarity to register SGMSYS_QPHY_WRAP_CTRL of switch.
> This is initialized with tx-bit set and so change inverts polarity
> compared to before.
>
> It looks like mt7531 has tx polarity inverted in hardware and set tx-bit
> by default to restore the normal polarity.
>
> Till this patch the register write was only called when mediatek,pnswap
> property was set which cannot be done for switch because the fw-node param
> was always NULL from switch driver in the mtk_pcs_lynxi_create call.
>
> Do not configure switch side like it's done before.
>
> Fixes: 8871389da151 ("net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"")
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
^ permalink raw reply
* Re: [PATCH v12 04/25] drm/bridge: Act on the DRM color format property
From: Dmitry Baryshkov @ 2026-04-09 22:08 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260409-color-format-v12-4-ce84e1817a27@collabora.com>
On Thu, Apr 09, 2026 at 05:44:54PM +0200, Nicolas Frattaroli wrote:
> The new DRM color format property allows userspace to request a specific
> color format on a connector. In turn, this fills the connector state's
> color_format member to switch color formats.
>
> Make drm_bridges consider the color_format set in the connector state
> during the atomic bridge check. For bridges that represent HDMI bridges,
> rely on whatever format the HDMI logic set. Reject any output bus
> formats that do not correspond to the requested color format.
>
> Non-HDMI last bridges with DRM_CONNECTOR_COLOR_FORMAT_AUTO set will end
> up choosing the first output format that functions to make a whole
> recursive bridge chain format selection succeed.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 89 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index ba80bebb5685..7c1516864d96 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1150,6 +1150,47 @@ static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
> return ret;
> }
>
> +static bool __pure bus_format_is_color_fmt(u32 bus_fmt, enum drm_connector_color_format fmt)
> +{
> + if (fmt == DRM_CONNECTOR_COLOR_FORMAT_AUTO)
> + return true;
> +
> + switch (bus_fmt) {
> + case MEDIA_BUS_FMT_FIXED:
> + return true;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_VYUY8_1X16:
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_YVYU8_1X16:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_YUYV10_1X20:
> + case MEDIA_BUS_FMT_VYUY10_1X20:
> + case MEDIA_BUS_FMT_YVYU10_1X20:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + case MEDIA_BUS_FMT_VYUY12_1X24:
> + case MEDIA_BUS_FMT_YUYV12_1X24:
> + case MEDIA_BUS_FMT_YVYU12_1X24:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> + case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
> + case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
> + case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
> + case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> + default:
> + return false;
> + }
> +}
> +
> /*
> * This function is called by &drm_atomic_bridge_chain_check() just before
> * calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
> @@ -1193,6 +1234,7 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> struct drm_encoder *encoder = bridge->encoder;
> struct drm_bridge_state *last_bridge_state;
> unsigned int i, num_out_bus_fmts = 0;
> + enum drm_connector_color_format fmt;
> u32 *out_bus_fmts;
> int ret = 0;
>
> @@ -1234,13 +1276,58 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
> }
>
> + /*
> + * On HDMI connectors, use the output format chosen by whatever does the
> + * HDMI logic. For everyone else, just trust that the bridge out_bus_fmts
> + * are sorted by preference for %DRM_CONNECTOR_COLOR_FORMAT_AUTO, as
> + * bus_format_is_color_fmt() always returns true for AUTO.
> + */
> + if (last_bridge->type == DRM_MODE_CONNECTOR_HDMIA) {
I still think this is misplaced (and misidentified). Consider HDMI
bridge being routed to the DVI-D connector. The last bridge would have
different type, but the HDMI-specific logic must still be applied. The
bridge must use RGB444, but it must be handled in a generic way.
Or other way around, a DVI bridge being routed through the HDMI
connector (thinking about PandaBoard here). The combo should not go
through the HDMI-specific color format selection although the last
bridge in the chanin is the HDMI-A bridge.
I think all these cases should be handled by the connector, which knows
if there is an OP_HDMI bridge in the chain or not.
> + drm_dbg_kms(last_bridge->dev,
> + "HDMI bridge requests format %s\n",
> + drm_hdmi_connector_get_output_format_name(
> + conn_state->hdmi.output_format));
> + switch (conn_state->hdmi.output_format) {
> + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> + break;
> + default:
> + ret = -EINVAL;
> + goto out_free_bus_fmts;
> + }
> + } else {
> + fmt = conn_state->color_format;
> + drm_dbg_kms(last_bridge->dev, "Non-HDMI bridge requests format %d\n", fmt);
> + }
> +
> for (i = 0; i < num_out_bus_fmts; i++) {
> + if (!bus_format_is_color_fmt(out_bus_fmts[i], fmt)) {
> + drm_dbg_kms(last_bridge->dev,
> + "Skipping bus format 0x%04x as it doesn't match format %d\n",
> + out_bus_fmts[i], fmt);
> + ret = -ENOTSUPP;
> + continue;
> + }
> ret = select_bus_fmt_recursive(bridge, last_bridge, crtc_state,
> conn_state, out_bus_fmts[i]);
> - if (ret != -ENOTSUPP)
> + if (ret != -ENOTSUPP) {
> + drm_dbg_kms(last_bridge->dev,
> + "Found bridge chain ending with bus format 0x%04x\n",
> + out_bus_fmts[i]);
> break;
> + }
> }
>
> +out_free_bus_fmts:
> kfree(out_bus_fmts);
>
> return ret;
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH net-next v9 0/4] net: stmmac: Add PCI driver support for BCM8958x
From: Jitendra Vegiraju @ 2026-04-09 22:08 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <adSxQpAE0nY0ulfU@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Hi Russell,
On Tue, Apr 7, 2026 at 12:25 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Apr 02, 2026 at 02:36:25PM -0700, Jitendra Vegiraju wrote:
> > From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> >
> > This patchset adds basic PCI ethernet device driver support for Broadcom
> > BCM8958x Automotive Ethernet switch SoC devices.
> >
> > The MAC block on BCM8958x is based on Synopsis XGMAC 4.00a core. This
> > MAC IP introduces new DMA architecture called Hyper-DMA for virtualization
> > scalability.
> >
> > Driver functionality specific to new MAC (DW25GMAC) is implemented in
> > new file dw25gmac.c.
>
> Sorry for suggesting this rather late, but I recently came across
> another stmmac driver in the kernel - drivers/net/ethernet/synopsys.
> This is for XLGMAC, but I wonder whether it may be a better bet for
> this core. Have you looked at it?
>
I wasn't aware of this driver earlier. We are looking into this driver now.
Thanks
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5435 bytes --]
^ permalink raw reply
* Re: [PATCH v12 05/25] drm/atomic-helper: Add HDMI bridge output bus formats helper
From: Dmitry Baryshkov @ 2026-04-09 22:09 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260409-color-format-v12-5-ce84e1817a27@collabora.com>
On Thu, Apr 09, 2026 at 05:44:55PM +0200, Nicolas Frattaroli wrote:
> The drm_bridge_funcs atomic_get_output_bus_fmts operation should be the
> same for likely every HDMI connector bridge, unless such an HDMI
> connector bridge has some special hardware restrictions that I cannot
> envision yet.
>
> To avoid code duplication and standardize on a set of media bus formats
> that the HDMI output color formats translate to, add a common helper
> function that implements this operation to the drm bridge helpers.
>
> The function returns a list of output bus formats based on the HDMI
> bridge's current output bits-per-component, and its bitmask of supported
> color formats.
>
> To guard against future expansion of DRM_OUTPUT_COLOR_FORMAT outgrowing
> the hweight8 call, add a BUILD_BUG_ON statement where it's used that
> checks for DRM_OUTPUT_COLOR_FORMAT_COUNT. The justification for not
> using hweight32 in all cases is that not all ISAs have a popcount
> instruction, and will benefit from a smaller/faster software
> implementation that doesn't have to operate across all bits.
>
> The justification for not defining an hweight_color depending on the
> value of DRM_OUTPUT_COLOR_FORMAT_COUNT is that this count enum value is
> only known at compile time, not at preprocessor time.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 81 +++++++++++++++++++++++++++++++++++++
> include/drm/drm_atomic_helper.h | 7 ++++
> 2 files changed, 88 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ 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