* Re: [PATCH v5 00/12] scsi: ufs: Add TX Equalization support for UFS 5.0
From: Martin K. Petersen @ 2026-04-03 2:05 UTC (permalink / raw)
To: avri.altman, bvanassche, beanhuo, peter.wang, mani, Can Guo
Cc: Martin K . Petersen, linux-scsi, Matthias Brugger,
AngeloGioacchino Del Regno, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260325152154.1604082-1-can.guo@oss.qualcomm.com>
On Wed, 25 Mar 2026 08:21:42 -0700, Can Guo wrote:
> The UFS v5.0 and UFSHCI v5.0 standards have published, introducing support
> for HS-G6 (46.6 Gbps per lane) through the new UniPro V3.0 interconnect
> layer and M-PHY V6.0 physical layer specifications. To achieve reliable
> operation at these higher speeds, UniPro V3.0 introduces TX Equalization
> and Pre-Coding mechanisms that are essential for signal integrity.
>
> This patch series implements TX Equalization support in the UFS core
> driver as specified in UFSHCI v5.0, along with the necessary vendor
> operations and a reference implementation for Qualcomm UFS host
> controllers.
>
> [...]
Applied to 7.1/scsi-queue, thanks!
[01/12] scsi: ufs: core: Introduce a new ufshcd vops negotiate_pwr_mode()
https://git.kernel.org/mkp/scsi/c/d3eba21c7170
[02/12] scsi: ufs: core: Pass force_pmc to ufshcd_config_pwr_mode() as a parameter
https://git.kernel.org/mkp/scsi/c/c91c83671642
[03/12] scsi: ufs: core: Add UFS_HS_G6 and UFS_HS_GEAR_MAX to enum ufs_hs_gear_tag
https://git.kernel.org/mkp/scsi/c/6669ab18c223
[04/12] scsi: ufs: core: Add support for TX Equalization
https://git.kernel.org/mkp/scsi/c/03e5d38e2f98
[05/12] scsi: ufs: core: Add debugfs entries for TX Equalization params
https://git.kernel.org/mkp/scsi/c/10c40143f369
[06/12] scsi: ufs: core: Add helpers to pause and resume command processing
https://git.kernel.org/mkp/scsi/c/dc5dcac53278
[07/12] scsi: ufs: core: Add support to retrain TX Equalization via debugfs
https://git.kernel.org/mkp/scsi/c/adbabdcf0db0
[08/12] scsi: ufs: ufs-qcom: Fixup PAM-4 TX L0_L1_L2_L3 adaptation pattern length
https://git.kernel.org/mkp/scsi/c/53c94067efa2
[09/12] scsi: ufs: ufs-qcom: Implement vops tx_eqtr_notify()
https://git.kernel.org/mkp/scsi/c/385b95893e79
[10/12] scsi: ufs: ufs-qcom: Implement vops get_rx_fom()
https://git.kernel.org/mkp/scsi/c/26605db7604d
[11/12] scsi: ufs: ufs-qcom: Implement vops apply_tx_eqtr_settings()
https://git.kernel.org/mkp/scsi/c/16cbdc830877
[12/12] scsi: ufs: ufs-qcom: Enable TX Equalization
https://git.kernel.org/mkp/scsi/c/57b7943fd87f
--
Martin K. Petersen
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu: Use pm_runtime in fault handlers
From: Pranjal Shrivastava @ 2026-04-03 2:20 UTC (permalink / raw)
To: Prakash Gupta
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Clark, Connor Abbott,
linux-arm-msm, linux-arm-kernel, iommu, linux-kernel,
Akhil P Oommen, Pratyush Brahma
In-Reply-To: <20260313-smmu-rpm-v2-1-8c2236b402b0@oss.qualcomm.com>
On Fri, Mar 13, 2026 at 03:53:53PM +0530, Prakash Gupta wrote:
> Commit d4a44f0750bb ("iommu/arm-smmu: Invoke pm_runtime across the driver")
> enabled pm_runtime for the arm-smmu device. On systems where the SMMU
> sits in a power domain, all register accesses must be done while the
> device is runtime active to avoid unclocked register reads and
> potential NoC errors.
>
> So far, this has not been an issue for most SMMU clients because
> stall-on-fault is enabled by default. While a translation fault is
> being handled, the SMMU stalls further translations for that context
> bank, so the fault handler would not race with a powered-down
> SMMU.
>
> Adreno SMMU now disables stall-on-fault in the presence of fault
> storms to avoid saturating SMMU resources and hanging the GMU. With
> stall-on-fault disabled, the SMMU can generate faults while its power
> domain may no longer be enabled, which makes unclocked accesses to
> fault-status registers in the SMMU fault handlers possible.
>
> Guard the context and global fault handlers with pm_runtime_get_if_active()
> and pm_runtime_put_autosuspend() so that all SMMU fault register accesses
> are done with the SMMU powered. In case pm_runtime is not active we can
> safely ignore the fault as for pm runtime resume the smmu device is
> reset and fault registers are cleared.
>
> Fixes: b13044092c1e ("drm/msm: Temporarily disable stall-on-fault after a page fault")
> Co-developed-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
> Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
> Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
> ---
> Changes in v2:
> - Switched from arm_smmu_rpm_get()/arm_smmu_rpm_put() wrappers to
> pm_runtime_get_if_active()/pm_runtime_put_autosuspend() APIs
> - Added support for smmu->impl->global_fault callback in global fault handler
> - Remove threaded irq context fault restriction to allow modifying stall
> mode for adreno smmu
> - Link to v1: https://patch.msgid.link/20260127-smmu-rpm-v1-1-2ef2f4c85305@oss.qualcomm.com
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 60 +++++++++++++++++++++++------------
> 1 file changed, 39 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 5e690cf85ec9..f4c46491a03d 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -462,10 +462,20 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
> int idx = smmu_domain->cfg.cbndx;
> int ret;
>
> + if (!pm_runtime_get_if_active(smmu->dev))
Note that the pm_runtime_get_if_active(dev) only returns a positive
value if the device state is exactly RPM_ACTIVE. If the device is in the
middle of its runtime_suspend callback, its state is RPM_SUSPENDING.
Thus, if a fault races with the suspend callback, we'll return IRQ_NONE
and the suspend callback doesn't seem to be disabling interrupts.
This isn't any better if we're in a fault-storm caused by
level-triggered interrupts, we'd simply keep entering this handler and
return.
I believe we should clear / handle any pending faults/interrupts or
atleast mask interrupt in the suspend handler to avoid this situation.
> + return IRQ_NONE;
> +
Maybe we could add another wrapped-helper to maintain consistency:
static inline int arm_smmu_rpm_get_if_active(struct arm_smmu_device *smmu)
{
if (!pm_runtime_enabled(smmu->dev))
return 1; // Assume active/powered if RPM is not used
return pm_runtime_get_if_active(smmu->dev);
}
This returns -EINVAL otherwise which isn't a problem for the if
condition but slightly cleaner.
> + if (smmu->impl && smmu->impl->context_fault) {
> + ret = smmu->impl->context_fault(irq, dev);
> + goto out_power_off;
> + }
> +
We've moved impl-specific handlers here, I don't see a functional change.
This looks fine.
> arm_smmu_read_context_fault_info(smmu, idx, &cfi);
>
> - if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT))
> - return IRQ_NONE;
> + if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT)) {
> + ret = IRQ_NONE;
> + goto out_power_off;
> + }
>
> ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
> cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
> @@ -480,7 +490,12 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
> ret == -EAGAIN ? 0 : ARM_SMMU_RESUME_TERMINATE);
> }
>
> - return IRQ_HANDLED;
> + ret = IRQ_HANDLED;
> +
> +out_power_off:
> + pm_runtime_put_autosuspend(smmu->dev);
Nit: Please use arm_smmu_rpm_put() here.. while at it, I guess we can
also bring back pm_runtime_put_autosuspend() in arm_smmu_rpm_put() since
it is updated now to also mark last busy.
> +
> + return ret;
> }
>
> static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> @@ -489,14 +504,25 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> struct arm_smmu_device *smmu = dev;
> static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);
> + int ret;
> +
> + if (!pm_runtime_get_if_active(smmu->dev))
> + return IRQ_NONE;
> +
Same here.
> + if (smmu->impl && smmu->impl->global_fault) {
> + ret = smmu->impl->global_fault(irq, dev);
> + goto out_power_off;
> + }
>
> gfsr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSR);
> gfsynr0 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR0);
> gfsynr1 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR1);
> gfsynr2 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR2);
>
> - if (!gfsr)
> - return IRQ_NONE;
> + if (!gfsr) {
> + ret = IRQ_NONE;
> + goto out_power_off;
> + }
>
> if (__ratelimit(&rs)) {
> if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
> @@ -513,7 +539,11 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> }
>
> arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
> - return IRQ_HANDLED;
> + ret = IRQ_HANDLED;
> +
> +out_power_off:
> + pm_runtime_put_autosuspend(smmu->dev);
> + return ret;
> }
>
> static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> @@ -683,7 +713,6 @@ static int arm_smmu_init_domain_context(struct arm_smmu_domain *smmu_domain,
> enum io_pgtable_fmt fmt;
> struct iommu_domain *domain = &smmu_domain->domain;
> struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
> - irqreturn_t (*context_fault)(int irq, void *dev);
>
> mutex_lock(&smmu_domain->init_mutex);
> if (smmu_domain->smmu)
> @@ -850,19 +879,14 @@ static int arm_smmu_init_domain_context(struct arm_smmu_domain *smmu_domain,
> */
> irq = smmu->irqs[cfg->irptndx];
>
> - if (smmu->impl && smmu->impl->context_fault)
> - context_fault = smmu->impl->context_fault;
> - else
> - context_fault = arm_smmu_context_fault;
> -
> if (smmu->impl && smmu->impl->context_fault_needs_threaded_irq)
> ret = devm_request_threaded_irq(smmu->dev, irq, NULL,
> - context_fault,
> + arm_smmu_context_fault,
> IRQF_ONESHOT | IRQF_SHARED,
> "arm-smmu-context-fault",
> smmu_domain);
> else
> - ret = devm_request_irq(smmu->dev, irq, context_fault, IRQF_SHARED,
> + ret = devm_request_irq(smmu->dev, irq, arm_smmu_context_fault, IRQF_SHARED,
> "arm-smmu-context-fault", smmu_domain);
>
> if (ret < 0) {
> @@ -2125,7 +2149,6 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> int num_irqs, i, err;
> u32 global_irqs, pmu_irqs;
> - irqreturn_t (*global_fault)(int irq, void *dev);
>
> smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
> if (!smmu) {
> @@ -2205,18 +2228,13 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> smmu->num_context_irqs = smmu->num_context_banks;
> }
>
> - if (smmu->impl && smmu->impl->global_fault)
> - global_fault = smmu->impl->global_fault;
> - else
> - global_fault = arm_smmu_global_fault;
> -
> for (i = 0; i < global_irqs; i++) {
> int irq = platform_get_irq(pdev, i);
>
> if (irq < 0)
> return irq;
>
> - err = devm_request_irq(dev, irq, global_fault, IRQF_SHARED,
> + err = devm_request_irq(dev, irq, arm_smmu_global_fault, IRQF_SHARED,
> "arm-smmu global fault", smmu);
> if (err)
> return dev_err_probe(dev, err,
>
Thanks,
Praan
^ permalink raw reply
* Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'
From: Qinxin Xia @ 2026-04-03 2:44 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, xhao, zengheng4, Linuxarm
In-Reply-To: <08aacacc-e3e5-4e97-858b-cbcbdb9a1fcf@arm.com>
On 2026/3/27 18:47:49, Ben Horgan <ben.horgan@arm.com> wrote:
> Hi Qinxin,
>
> On 3/27/26 10:21, Qinxin Xia wrote:
>>
>> Hello everyone!
>>
>> In earlier versions, mpam supports the configuration of iommu_groups.
>>
>> 823 static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
>> 824 char *buf, size_t nbytes,
>> loff_t off)
>> 825 {
>> 826 struct rdtgroup *rdtgrp;
>> 827 int iommu_group_id;
>> 828 bool is_iommu;
>> 829 char *pid_str;
>> 830 int ret = 0;
>> 831 pid_t pid;
>> 832
>> 833 rdtgrp = rdtgroup_kn_lock_live(of->kn);
>> 834 if (!rdtgrp) {
>> 835 rdtgroup_kn_unlock(of->kn);
>> 836 return -ENOENT;
>> 837 }
>> 838 rdt_last_cmd_clear();
>> 839
>> 840 if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
>> 841 rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
>> 842 ret = -EINVAL;
>> 843 rdt_last_cmd_puts("Pseudo-locking in progress\n");
>> 844 goto unlock;
>> 845 }
>> 846
>> 847 while (buf && buf[0] != '\0' && buf[0] != '\n') {
>> 848 pid_str = strim(strsep(&buf, ","));
>> 849
>> 850 is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
>>
>> What puzzles me is why we would put it under 'task'—this seems a little
>> strange to users.It seems they are not related.Why don't we add a new
>> interface like 'iommu'?
>
> I think it is likely that this interface would change if upstream support is added.
>
I have done some work in this direction before, and I will release an
RFC later for further discussion.:-)
>>
>> 851 if (is_iommu)
>> 852 ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
>> 853 else if (kstrtoint(pid_str, 0, &pid)) {
>> 854 rdt_last_cmd_printf("Task list parsing error pid %s\n", pid_str);
>> 855 ret = -EINVAL;
>> 856 break;
>> 857 }
>> 858
>> 859 if (pid < 0) {
>> 860 rdt_last_cmd_printf("Invalid pid %d\n", pid);
>> 861 ret = -EINVAL;
>> 862 break;
>> 863 }
>> 864
>>
>> In future glue versions, will you re-enable support for iommu_group, and
>> if so, will the configuration scheme be changed?
>
> Please can you let us know about your usecase so that we can get more information to decide
> what the best interface would be?
>
> Thanks,
>
> Ben
>
>
>
We want to use the iommu mpam to implement stream control for different
PCIe devices. By limiting the access bandwidth of some PCIe devices, the
high-priority service devices can obtain more resources.
--
Thanks,
Qinxin
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc6, upstream-arm-next, 129fdb45)
From: cki-project @ 2026-04-03 3:33 UTC (permalink / raw)
To: will, linux-arm-kernel, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge remote-tracking branch 'origin/nocache-cleanup' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2427004144
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Frank Li @ 2026-04-03 4:00 UTC (permalink / raw)
To: Florijan Plohl
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <20260402070826.970012-1-florijan.plohl@norik.com>
On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>
> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 4 +
> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> 3 files changed, 288 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
> create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index bae24b53bce6..8f5b3996b678 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -437,17 +437,21 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-kontron-bl-osm-s.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin.dtb
>
> +imx91-phyboard-segin-peb-av-18-dtbs += imx91-phyboard-segin.dtb imx91-phyboard-segin-peb-av-18.dtbo
> imx93-phyboard-nash-jtag-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-jtag.dtbo
> imx93-phyboard-nash-peb-wlbt-07-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-peb-wlbt-07.dtbo
> imx93-phyboard-nash-pwm-fan-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-pwm-fan.dtbo
> imx93-phyboard-segin-peb-av-02-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-02.dtbo
> +imx93-phyboard-segin-peb-av-18-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-18.dtbo
> imx93-phyboard-segin-peb-eval-01-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-eval-01.dtbo
> imx93-phyboard-segin-peb-wlbt-05-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-wlbt-05.dtbo
> imx93-phycore-rpmsg-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-segin.dtb imx93-phycore-rpmsg.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin-peb-av-18.dtb
https://sashiko.dev/#/patchset/20260402070826.970012-1-florijan.plohl%40norik.com
"should this be kept with the other imx91 dtb definition"
Frank Li
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-jtag.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-peb-wlbt-07.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-pwm-fan.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-02.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-18.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-eval-01.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-wlbt-05.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-phycore-rpmsg.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
> new file mode 100644
> index 000000000000..ec6ef2e5a11a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
> @@ -0,0 +1,142 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2026 PHYTEC Messtechnik GmbH
> + *
> + * Author: Florijan Plohl <florijan.plohl@norik.com>
> + */
> +
> +#include <dt-bindings/clock/imx93-clock.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include "imx91-pinfunc.h"
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <5>;
> + power-supply = <®_vcc_3v3_con>;
> + pwms = <&pwm7 0 5000000 0>;
> + };
> +
> + panel {
> + compatible = "powertip,ph800480t032-zhc19";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_panel>;
> +
> + backlight = <&backlight>;
> + enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
> + power-supply = <®_vcc_3v3_con>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dpi_to_panel>;
> + };
> + };
> + };
> +
> + pwm7: pwm-7 {
> + compatible = "pwm-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm7>;
> + gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
> + #pwm-cells = <3>;
> + };
> +
> + reg_vcc_3v3_con: regulator-vcc-3v3-con {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC3V3_CON";
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + };
> +};
> +
> +&dpi_bridge {
> + status = "okay";
> +};
> +
> +&dpi_to_panel {
> + remote-endpoint = <&panel_in>;
> + bus-width = <18>;
> +};
> +
> +&lcdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcdif>;
> + assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
> + assigned-clock-rates = <27272728>;
> + status = "okay";
> +};
> +
> +&lpi2c2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@41 {
> + compatible = "ilitek,ili2130";
> + reg = <0x41>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touchscreen>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + wakeup-source;
> + };
> +};
> +
> +&media_blk_ctrl {
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_lcdif: lcdifgrp {
> + fsl,pins = <
> + MX91_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x50e
> + MX91_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x50e
> + MX91_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x50e
> + MX91_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x50e
> + MX91_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA0 0x50e
> + MX91_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA1 0x50e
> + MX91_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA2 0x50e
> + MX91_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA3 0x50e
> + MX91_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA4 0x50e
> + MX91_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA5 0x51e
> + MX91_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA6 0x50e
> + MX91_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA7 0x50e
> + MX91_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA8 0x50e
> + MX91_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA9 0x50e
> + MX91_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x50e
> + MX91_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x50e
> + MX91_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x506
> + MX91_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x506
> + MX91_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x506
> + MX91_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x506
> + MX91_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x506
> + MX91_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x506
> + >;
> + };
> +
> + pinctrl_panel: panelgrp {
> + fsl,pins = <
> + MX91_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
> + >;
> + };
> +
> + pinctrl_pwm7: pwm7grp {
> + fsl,pins = <
> + MX91_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
> + >;
> + };
> +
> + pinctrl_touchscreen: touchscreengrp {
> + fsl,pins = <
> + MX91_PAD_ENET1_MDIO__GPIO4_IO1 0x11e
> + MX91_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
> + >;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
> new file mode 100644
> index 000000000000..189b0f0472d2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
> @@ -0,0 +1,142 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2026 PHYTEC Messtechnik GmbH
> + *
> + * Author: Florijan Plohl <florijan.plohl@norik.com>
> + */
> +
> +#include <dt-bindings/clock/imx93-clock.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include "imx93-pinfunc.h"
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <5>;
> + power-supply = <®_vcc_3v3_con>;
> + pwms = <&pwm7 0 5000000 0>;
> + };
> +
> + panel {
> + compatible = "powertip,ph800480t032-zhc19";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_panel>;
> +
> + backlight = <&backlight>;
> + enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
> + power-supply = <®_vcc_3v3_con>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dpi_to_panel>;
> + };
> + };
> + };
> +
> + pwm7: pwm-7 {
> + compatible = "pwm-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm7>;
> + gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
> + #pwm-cells = <3>;
> + };
> +
> + reg_vcc_3v3_con: regulator-vcc-3v3-con {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC3V3_CON";
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + };
> +};
> +
> +&dpi_bridge {
> + status = "okay";
> +};
> +
> +&dpi_to_panel {
> + remote-endpoint = <&panel_in>;
> + bus-width = <18>;
> +};
> +
> +&lcdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcdif>;
> + assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
> + assigned-clock-rates = <27272728>;
> + status = "okay";
> +};
> +
> +&lpi2c2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@41 {
> + compatible = "ilitek,ili2130";
> + reg = <0x41>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touchscreen>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + wakeup-source;
> + };
> +};
> +
> +&media_blk_ctrl {
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_lcdif: lcdifgrp {
> + fsl,pins = <
> + MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x50e
> + MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x50e
> + MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x50e
> + MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x50e
> + MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x50e
> + MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x50e
> + MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x50e
> + MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x50e
> + MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x50e
> + MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x51e
> + MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x50e
> + MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x50e
> + MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x50e
> + MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x50e
> + MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x50e
> + MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x50e
> + MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x506
> + MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x506
> + MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x506
> + MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x506
> + MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x506
> + MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x506
> + >;
> + };
> +
> + pinctrl_panel: panelgrp {
> + fsl,pins = <
> + MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
> + >;
> + };
> +
> + pinctrl_pwm7: pwm7grp {
> + fsl,pins = <
> + MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
> + >;
> + };
> +
> + pinctrl_touchscreen: touchscreengrp {
> + fsl,pins = <
> + MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x11e
> + MX93_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
> + >;
> + };
> +};
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] arm64: pi: validate bootargs before parsing them
From: Pengpeng Hou @ 2026-04-03 3:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: linux-arm-kernel, linux-kernel, pengpeng
get_bootargs_cmdline() fetches the raw bootargs property from the FDT
and immediately calls strlen() on it before later passing the same
pointer into the early command-line parser. Flat DT properties are
external boot input, and this path does not prove that bootargs is
NUL-terminated within its declared bounds.
Use fdt_stringlist_get() so malformed unterminated bootargs are
rejected before the local parser treats them as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm64/kernel/pi/idreg-override.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index bc57b290e5e7..310ed279ef26 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -373,11 +373,11 @@ static __init const u8 *get_bootargs_cmdline(const void *fdt, int node)
if (node < 0)
return NULL;
- prop = fdt_getprop(fdt, node, bootargs, NULL);
+ prop = fdt_stringlist_get(fdt, node, bootargs, 0, NULL);
if (!prop)
return NULL;
- return strlen(prop) ? prop : NULL;
+ return *prop ? prop : NULL;
}
static __init void parse_cmdline(const void *fdt, int chosen)
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: compressed: validate memory node device_type strings
From: Pengpeng Hou @ 2026-04-03 3:55 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, pengpeng
fdt_check_mem_start() walks memory nodes in the compressed-kernel early
FDT and fetches device_type directly with fdt_getprop() before
immediately comparing it with strcmp(). Raw FDT properties are external
boot input, and this path does not prove that device_type is
NUL-terminated within its declared bounds.
Use fdt_stringlist_get() so malformed unterminated device_type
properties are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/boot/compressed/fdt_check_mem_start.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c
index aa856567fd33..7c433ef33bcb 100644
--- a/arch/arm/boot/compressed/fdt_check_mem_start.c
+++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
@@ -106,7 +106,7 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
/* Walk all memory nodes and regions */
for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
offset = fdt_next_node(fdt, offset, NULL)) {
- type = fdt_getprop(fdt, offset, "device_type", NULL);
+ type = fdt_stringlist_get(fdt, offset, "device_type", 0, NULL);
if (!type || strcmp(type, "memory"))
continue;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Krzysztof Hałasa @ 2026-04-03 4:36 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <ac6eQcDS8lr-A4ia@shepard>
Hi Paul,
Paul Kocialkowski <paulk@sys-base.io> writes:
> Interestingly I tried to keep the clocks always on as an experiment and it
> had the opposite effect: the DMA engine would get confused every time after the
> first mode set and disable. So for some reason the disabling of the clocks seems
> to mitigate the issue rather than aggravate it.
Interesting. Fortunately we have a workaround.
>> > + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
>> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
>> > + 0, 36000); /* Wait ~2 frame times max */
>>
>> I guess this comment is not necessarily correct - at 2160p30 one frame =
>> ca. 33 ms. Still works, though (I guess anything more than one frame is
>> enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
>> take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
>
> Honestly I think we're good assuming 30 fps (33 ms) is a lower bound.
> And the current 36 ms goes even beyond, so I think it's fine.
Right. It is just the comment in the code which is not exactly true.
I.e., we "wait for at least 1 complete frame time". I guess.
Also, the 25 ms in the patch (commit) message is no longer accurate.
>> Also, found an issue. Perhaps unrelated? Powered the board without HDMI
>> connected. Then connected 1080p60 display. It came in 1024x768, console
>> 64x24 :-)
>
> That looks more related to a failure to fetch the EDID from the monitor.
> 1024x768 is the default fallback that is used in this situation.
> Maybe check if there is something wrong with the DDC lines from the hdmi
> controller, maybe pinmux etc.
No no no, I did that on purpose - the monitor was really disconnected at
the boot time. Only then (but before starting weston) i reconnected it.
But it indeed appears to be a separate issue, a software one - a mutex
deadlock on access to clocks and power management. Both enable and
disable paths interfere there. "I will post a patch when I have a patch
to post" :-)
Thanks,
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* Re: [PATCH] iommu/rockchip: fix page table allocation flags for v2 IOMMU
From: Simon Xue @ 2026-04-03 4:40 UTC (permalink / raw)
To: Jonas Karlman, Midgy BALON
Cc: iommu, joro, will, robin.murphy, heiko, linux-arm-kernel,
linux-rockchip, linux-kernel, stable
In-Reply-To: <89ed223d-1a2c-447d-9f21-76969e668855@rock-chips.com>
在 2026/4/1 18:22, Simon Xue 写道:
> Hi Jonas,
>
> 在 2026/4/1 16:41, Jonas Karlman 写道:
>> Hi Simon,
>>
>> On 4/1/2026 9:48 AM, Simon wrote:
>>> Hi Midgy,
>>>
>>> 在 2026/3/31 15:50, Midgy BALON 写道:
>>>> commit 2a7e6400f72b ("iommu: rockchip: Allocate tables from all
>>>> available memory for IOMMU v2") removed GFP_DMA32 from
>>>> iommu_data_ops_v2, reasoning that RK356x and RK3588 IOMMU v2 hardware
>>>> supports up to 40-bit physical addresses for page tables. However, the
>>>> RK3568 IOMMU page-table walker uses a 32-bit AXI bus: it cannot access
>>>> physical addresses above 4 GB regardless of the address encoding
>>>> range.
>>>>
>>>> On boards with more than 4 GB of RAM (e.g. 8 GB LPDDR4X), removing
>>>> GFP_DMA32 causes two distinct failure modes:
>>>>
>>>> 1. Direct allocation above 4 GB: iommu_alloc_pages_sz() may return
>>>> memory above 0x100000000. The hardware page-table walker
>>>> issues a
>>>> bus error trying to dereference those addresses, causing an IOMMU
>>>> fault on the first DMA transaction.
>>> Which IP block is hitting this? We'd like to take a look on our end.
>> I have seen reports that the NPU MMU on RK3568/RK3566 is having some
>> issue using DTE/PTE with >32-bit addresses, maybe it uses a different
>> MMU hw revision or has some hw errata?
>>
>> From my own testing at least the VOP2 MMU on RK3568 (and RK3588) was
>> able to handle 40-bit addressable DTE/PTE, hence the original commit
>> 2a7e6400f72b ("iommu: rockchip: Allocate tables from all available
>> memory for IOMMU v2").
>>
>> As also mentioned in my reply at [1], maybe the NPU MMU has some hw
>> limitation or errata and may need to use a different compatible.
>
> Yes, We are checking internally whether different IOMMU versions
> integrated.
>
> I will share what we find once we have results.
>
We internally checked that the RK356x SoCs integrate two different IOMMU
versions (v1.0 and v2.0), like NPU and ISP use the v1.0 IOMMU.
Both versions can map 40-bit physical pages, but v1.0 does not support
placing the first-level page table above 4 GB.
To fix this, I think we need to land this patch first:
https://lore.kernel.org/all/20260310105303.128859-1-xxm@rock-chips.com/
Then on top of that, we can add a new compatible string to distinguish
the IOMMU versions.
>> [1]
>> https://lore.kernel.org/r/3cd63b3d-1c5e-4a11-856e-c4aeb5d97d55@kwiboo.se/
>>
>> Regards,
>> Jonas
>>
>>>> 2. SWIOTLB bounce-buffer poisoning: without GFP_DMA32, page tables
>>>> land
>>>> above the SWIOTLB window. dma_map_single() with DMA_BIT_MASK(32)
>>>> then bounces them into a buffer below 4 GB.
>>>> rk_dte_get_page_table()
>>>> returns phys_to_virt() of the bounce buffer address; PTEs are
>>>> written
>>>> there; the next dma_sync_single_for_device(DMA_TO_DEVICE)
>>>> copies the
>>>> original (zero) data back over the bounce buffer, silently
>>>> erasing the
>>>> freshly written PTEs. The IOMMU faults because every PTE
>>>> reads as zero.
>>> This probably need a separate patch. One way to fix it would be to
>>> track the
>>> original L2 page table base addresses in struct rk_iommu_domain,
>>> then have rk_dte_get_page_table() return the tracked address instead of
>>> deriving it from the DTE.
>>>
>>>> Restore GFP_DMA32 (and DMA_BIT_MASK(32)) for iommu_data_ops_v2, which
>>>> currently only serves "rockchip,rk3568-iommu" in mainline.
>>>>
>>>> Tested on Radxa ROCK 3B (RK3568, 8 GB LPDDR4X):
>>>> - MobileNetV1 via RKNN: 5.8 ms/inference (IOMMU mode)
>>>> - YOLOv5s 640x640 via RKNN: ~57 ms/inference (IOMMU mode)
>>>> - No IOMMU faults, correct inference results
>>>>
>>>> Fixes: 2a7e6400f72b ("iommu: rockchip: Allocate tables from all
>>>> available memory for IOMMU v2")
>>>> Cc: stable@vger.kernel.org
>>>> Cc: Jonas Karlman <jonas@kwiboo.se>
>>>> Signed-off-by: Midgy BALON <midgy971@gmail.com>
>>>> ---
>>>> drivers/iommu/rockchip-iommu.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/rockchip-iommu.c
>>>> b/drivers/iommu/rockchip-iommu.c
>>>> index 85f3667e797..8b45db29471 100644
>>>> --- a/drivers/iommu/rockchip-iommu.c
>>>> +++ b/drivers/iommu/rockchip-iommu.c
>>>> @@ -1358,8 +1358,8 @@ static struct rk_iommu_ops iommu_data_ops_v2 = {
>>>> .pt_address = &rk_dte_pt_address_v2,
>>>> .mk_dtentries = &rk_mk_dte_v2,
>>>> .mk_ptentries = &rk_mk_pte_v2,
>>>> - .dma_bit_mask = DMA_BIT_MASK(40),
>>>> - .gfp_flags = 0,
>>>> + .dma_bit_mask = DMA_BIT_MASK(32),
>>>> + .gfp_flags = GFP_DMA32,
>>>> };
>>>> static const struct of_device_id rk_iommu_dt_ids[] = {
>>
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Krzysztof Hałasa @ 2026-04-03 4:43 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <m3ldf4mzh4.fsf@t19.piap.pl>
Krzysztof Hałasa <khalasa@piap.pl> writes:
> Also, the 25 ms in the patch (commit) message is no longer accurate.
Aaah, it's before 7 a.m. here :-)
On the second try I was finally able to parse that sentence. Perhaps.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* [PATCH] ARM: devtree: validate compatible strings before dumping them
From: Pengpeng Hou @ 2026-04-03 2:41 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, pengpeng
setup_machine_fdt() dumps the root compatible list on the
unsupported-machine path by walking raw property bytes with strlen() and
early_print("%s"). Flat DT properties are external boot input, and this
path does not prove that the compatible string list is NUL-terminated
within its declared bounds.
Switch the local walk to fdt_stringlist_get() so malformed
unterminated entries are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/kernel/devtree.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 3b78966e750a..a9593479305e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -10,6 +10,7 @@
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/memblock.h>
+#include <linux/libfdt.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/of_irq.h>
@@ -207,19 +208,16 @@ const struct machine_desc * __init setup_machine_fdt(void *dt_virt)
if (!mdesc) {
const char *prop;
- int size;
+ int idx = 0;
unsigned long dt_root;
early_print("\nError: unrecognized/unsupported "
"device tree compatible list:\n[ ");
dt_root = of_get_flat_dt_root();
- prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
- while (size > 0) {
+ while ((prop = fdt_stringlist_get(initial_boot_params, dt_root,
+ "compatible", idx++, NULL)))
early_print("'%s' ", prop);
- size -= strlen(prop) + 1;
- prop += strlen(prop) + 1;
- }
early_print("]\n\n");
dump_machine_table(); /* does not return */
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: at91: validate memory node device_type strings
From: Pengpeng Hou @ 2026-04-03 2:42 UTC (permalink / raw)
To: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
Cc: linux-arm-kernel, linux-kernel, pengpeng
at91_pm_backup_scan_memcs() fetches the raw device_type property and
immediately compares it with strcmp(). Flat DT properties are external
boot input, and this path does not prove that the property is
NUL-terminated within its declared bounds.
Use fdt_stringlist_get() so malformed unterminated device_type
properties are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/mach-at91/pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 68bb4a86cd94..0767fc9f30ab 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -8,6 +8,7 @@
#include <linux/genalloc.h>
#include <linux/io.h>
+#include <linux/libfdt.h>
#include <linux/of_address.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
@@ -1044,7 +1045,8 @@ static int __init at91_pm_backup_scan_memcs(unsigned long node,
if (*located)
return 0;
- type = of_get_flat_dt_prop(node, "device_type", NULL);
+ type = fdt_stringlist_get(initial_boot_params, node, "device_type",
+ 0, NULL);
/* We are scanning "memory" nodes only. */
if (!type || strcmp(type, "memory"))
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: xen: validate hypervisor compatible before parsing its version
From: Pengpeng Hou @ 2026-04-03 2:42 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, linux-arm-kernel, linux-kernel, pengpeng
fdt_find_hyper_node() reads the raw compatible property and then
derives hyper_node.version from a prefix match before later printing it
with %s. Flat DT properties are external boot input, and this path does
not prove that the compatible string is NUL-terminated within its
declared bounds.
Fetch the first compatible entry with fdt_stringlist_get() so malformed
unterminated properties are rejected before the version suffix is
parsed.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/xen/enlighten.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 4feed2c2498d..f69290a4c639 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -19,6 +19,7 @@
#include <asm/efi.h>
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
+#include <linux/libfdt.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
@@ -218,8 +219,9 @@ static __initdata struct {
static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
int depth, void *data)
{
- const void *s = NULL;
+ const char *s = NULL;
int len;
+ size_t prefix_len = strlen(hyper_node.prefix);
if (depth != 1 || strcmp(uname, "hypervisor") != 0)
return 0;
@@ -227,10 +229,10 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
if (of_flat_dt_is_compatible(node, hyper_node.compat))
hyper_node.found = true;
- s = of_get_flat_dt_prop(node, "compatible", &len);
- if (strlen(hyper_node.prefix) + 3 < len &&
- !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
- hyper_node.version = s + strlen(hyper_node.prefix);
+ s = fdt_stringlist_get(initial_boot_params, node, "compatible", 0, &len);
+ if (s && len > prefix_len + 2 &&
+ !strncmp(hyper_node.prefix, s, prefix_len))
+ hyper_node.version = s + prefix_len;
/*
* Check if Xen supports EFI by checking whether there is the
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: mvebu: validate memory node device_type strings
From: Pengpeng Hou @ 2026-04-03 2:42 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-kernel, pengpeng
mvebu_scan_mem() fetches the raw device_type property and immediately
compares it with strcmp(). Flat DT properties are external boot input,
and this path does not prove that the property is NUL-terminated within
its declared bounds.
Use fdt_stringlist_get() so malformed unterminated device_type
properties are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/mach-mvebu/board-v7.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a0740ab0dca9..f867f6233108 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/libfdt.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
#include <linux/io.h>
@@ -66,7 +67,8 @@ void __iomem *mvebu_get_scu_base(void)
static int __init mvebu_scan_mem(unsigned long node, const char *uname,
int depth, void *data)
{
- const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ const char *type = fdt_stringlist_get(initial_boot_params, node,
+ "device_type", 0, NULL);
const __be32 *reg, *endp;
int l;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [soc:drivers/reset] BUILD SUCCESS d373605cd514837d8a6de3d00c786d4bae6dbaf8
From: kernel test robot @ 2026-04-03 5:57 UTC (permalink / raw)
To: Philipp Zabel; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/reset
branch HEAD: d373605cd514837d8a6de3d00c786d4bae6dbaf8 Merge tag 'reset-fixes-for-v7.0-2' into reset/next
elapsed time: 740m
configs tested: 171
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm vf610m4_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260403 gcc-14
i386 randconfig-002-20260403 gcc-14
i386 randconfig-003-20260403 gcc-14
i386 randconfig-004-20260403 gcc-14
i386 randconfig-005-20260403 gcc-14
i386 randconfig-006-20260403 gcc-14
i386 randconfig-007-20260403 gcc-14
i386 randconfig-011-20260403 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-017-20260403 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc tqm5200_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh magicpanelr2_defconfig gcc-15.2.0
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260403 clang-20
x86_64 randconfig-002-20260403 clang-20
x86_64 randconfig-003-20260403 clang-20
x86_64 randconfig-004-20260403 clang-20
x86_64 randconfig-005-20260403 clang-20
x86_64 randconfig-006-20260403 clang-20
x86_64 randconfig-011-20260403 gcc-14
x86_64 randconfig-012-20260403 gcc-14
x86_64 randconfig-013-20260403 gcc-14
x86_64 randconfig-014-20260403 gcc-14
x86_64 randconfig-015-20260403 gcc-14
x86_64 randconfig-016-20260403 gcc-14
x86_64 randconfig-071-20260403 gcc-14
x86_64 randconfig-072-20260403 gcc-14
x86_64 randconfig-073-20260403 gcc-14
x86_64 randconfig-074-20260403 gcc-14
x86_64 randconfig-075-20260403 gcc-14
x86_64 randconfig-076-20260403 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] arm: kernel: add NULL pointer check in early_mem()
From: Austin Kim @ 2026-04-03 6:08 UTC (permalink / raw)
To: linux; +Cc: linux-arm-kernel, linux-kernel, austindh.kim
The 'early_mem' function handles memory-related boot parameters.
If the parameter 'p' is passed as NULL, it could lead to an
uninitialized or invalid memory access during parsing.
This patch adds a NULL pointer check at the beginning of the
function to return early if no argument is provided, ensuring
system stability during the early boot process.
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
---
arch/arm/kernel/setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 0bfd66c7a..b718a7df3 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -830,6 +830,8 @@ static int __init early_mem(char *p)
u64 start;
char *endp;
+ if (!p)
+ return 1;
/*
* If the user specifies memory size, we
* blow away any automatically generated
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Maxime Chevallier @ 2026-04-03 6:14 UTC (permalink / raw)
To: Russell King (Oracle), Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Ovidiu Panait,
Vladimir Oltean, Baruch Siach, Serge Semin, Giuseppe Cavallaro,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <ac6kfQ98Xjt3dCGj@shell.armlinux.org.uk>
Hi Russell
On 02/04/2026 19:16, Russell King (Oracle) wrote:
> On Tue, Mar 31, 2026 at 09:19:27PM -0700, Sam Edwards wrote:
>> Hi netdev,
>>
>> This is v4 of my series containing a pair of bugfixes for the stmmac driver's
>> receive pipeline. These issues occur when stmmac_rx_refill() does not (fully)
>> succeed, which happens more frequently when free memory is low.
>>
>> The first patch closes Bugzilla bug #221010 [1], where stmmac_rx() can circle
>> around to a still-dirty descriptor (with a NULL buffer pointer), mistake it for
>> a filled descriptor (due to OWN=0), and attempt to dereference the buffer.
>>
>> In testing that patch, I discovered a second issue: starvation of available RX
>> buffers causes the NIC to stop sending interrupts; if the driver stops polling,
>> it will wait indefinitely for an interrupt that will never come. (Note: the
>> first patch makes this issue more prominent -- mostly because it lets the
>> system survive long enough to exhibit it -- but doesn't *cause* it.) The second
>> patch addresses that problem as well.
>>
>> Both patches are minimal, appropriate for stable, and designated to `net`. My
>> focus is on small, obviously-correct, easy-to-explain changes: I'll follow up
>> with another patch/series (something like [2]) for `net-next` that fixes the
>> ring in a more robust way.
>>
>> The tx and zc paths seem to have similar low-memory bugs, to be addressed in
>> separate series.
>
> I've tested this on my Jetson Xavier platform. One of the issues I've
> had is that running iperf3 results in the receive side stalling because
> it runs out of descriptors. However, despite the receive ring
> eventually being re-filled and the hardware appropriately prodded, it
> steadfastly refuses to restart, despite the descriptors having been
> updated.
>
> What I can see is there's 40 packets in the internal FIFOs via the
> PRXQ[13:0] field of the ETH_MTLRXQxDR register.
>
> With your patches applied:
>
> root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
> Connecting to host 192.168.248.1, port 5201
> Reverse mode, remote host 192.168.248.1 is sending
> [ 5] local 192.168.248.174 port 43728 connected to 192.168.248.1 port 5201
> [ ID] Interval Transfer Bitrate
> [ 5] 0.00-1.00 sec 30.3 MBytes 254 Mbits/sec
> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
> ...
Ah !!
I have been struggling with that problem this week too. I stumbled upon
it while trying to test your TSO series, and at firts I thought it was
because of the TSO patches, but turns out it's not, I reproduce it on
net-next.
The main problem for me is that it's not always reproducible, it may or
may not show up when I run iperf3 after a fresh restart.
This is on socfpga (dwmac1000), so it seems the problem exists across IP
versions.
I've been on and off trying to make progress on that during the week,
but without success so far...
Maxime
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Andrew Morton @ 2026-04-03 6:31 UTC (permalink / raw)
To: Sourabh Jain
Cc: Coiby Xu, kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Krzysztof Kozlowski, Rob Herring, Thomas Staudt, Will Deacon,
Christophe Leroy (CS GROUP), Catalin Marinas, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Saravana Kannan, open list
In-Reply-To: <51761fcf-955f-45e2-97a5-2b49d8e79d04@linux.ibm.com>
On Thu, 2 Apr 2026 16:24:14 +0530 Sourabh Jain <sourabhjain@linux.ibm.com> wrote:
> But while reading crash_load_dm_crypt_keys() I noticed a possibility of a
> double free at the address pointed by `keys_header`:
>
> In crash_load_dm_crypt_keys()/crash_dump_dm_crypt.c
> snip...
>
> kbuf.buffer = keys_header;
>
> snip....
>
> r = kexec_add_buffer(&kbuf);
> if (r) {
> pr_err("Failed to call kexec_add_buffer, ret=%d\n", r);
> kvfree((void *)kbuf.buffer); <---
> First Free
> return r;
> }
>
> Since `keys_header` is not reset, the next call to build_keys_header()
> will cause a double free at `keys_header`.
>
> static int build_keys_header(void)
> {
>
> snip...
>
> if (keys_header != NULL)
> kvfree(keys_header);
>
> snip...
> }
>
> What do you think?
It looks that way to me.
^ permalink raw reply
* Re: [PATCH 0/5] crc64: Tweak intrinsics code and enable it for ARM
From: Ard Biesheuvel @ 2026-04-03 6:49 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, linux-arm-kernel, Demian Shulhan
In-Reply-To: <20260402234028.GA2256@sol>
On Fri, 3 Apr 2026, at 01:40, Eric Biggers wrote:
> On Thu, Apr 02, 2026 at 10:52:17AM +0200, Ard Biesheuvel wrote:
>>
>> On Wed, 1 Apr 2026, at 21:59, Eric Biggers wrote:
>> > On Mon, Mar 30, 2026 at 04:46:31PM +0200, Ard Biesheuvel wrote:
>> >> Apply some tweaks to the new arm64 crc64 NEON intrinsics code, and wire
>> >> it up for the 32-bit ARM build. Note that true 32-bit ARM CPUs usually
>> >> don't implement the prerequisite 64x64 PMULL instructions, but 32-bit
>> >> kernels are commonly used on 64-bit capable hardware too, which do
>> >> implement the 32-bit versions of the crypto instructions if they are
>> >> implemented for the 64-bit ISA (as per the architecture).
>> >>
>> >> Cc: Demian Shulhan <demyansh@gmail.com>
>> >> Cc: Eric Biggers <ebiggers@kernel.org>
>> >>
>> >> Ard Biesheuvel (5):
>> >> lib/crc: arm64: Drop unnecessary chunking logic from crc64
>> >> lib/crc: arm64: Use existing macros for kernel-mode FPU cflags
>> >> ARM: Add a neon-intrinsics.h header like on arm64
>> >> lib/crc: arm64: Simplify intrinsics implementation
>> >> lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
>> >
>> > I think patches 3 and 4 should be swapped, so it's cleanups first (which
>> > make sense regardless of the 32-bit ARM support) and then the 32-bit ARM
>> > support.
>> >
>>
>> Ok.
>
> I can also apply patches 1-2 and 4 now if you want. Let me know if I
> should do that or if a new version is coming.
>
Yes, good idea. I'll take care of the ARM stuff next cycle.
^ permalink raw reply
* [PATCH v6 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on tag: next-20260327, linux-next/master
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 46 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 ++++++++++++++++++
3 files changed, 95 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v6 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260403064912.17259-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 8c684756d5fc..786cc2942c3a 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1867,6 +1867,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1898,6 +1902,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1937,6 +1973,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin, Krzysztof Kozlowski
In-Reply-To: <20260403064912.17259-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 46 +++++++++++++++----
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..6596b686980c 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,20 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
+
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
power-domains:
maxItems: 1
@@ -60,6 +67,29 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 1
+ clock-names:
+ minItems: 1
+ maxItems: 1
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ minItems: 2
+ maxItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v6 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin, Krzysztof Kozlowski
In-Reply-To: <20260403064912.17259-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..19948ed25f98 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,16 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
reg:
maxItems: 1
@@ -34,6 +37,10 @@ properties:
items:
- const: jpgenc
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
+
power-domains:
maxItems: 1
--
2.45.2
^ permalink raw reply related
* [PATCH v1 3/4] drm/rockchip: dw_hdmi: Apply DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
In-Reply-To: <20260403070032.447102-1-damon.ding@rock-chips.com>
Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
drm_bridge_connector framework which is the current DRM bridge best
practice.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 +++++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index e7f49fe845ea..69b832d0c8c4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -76,6 +76,7 @@ config ROCKCHIP_DW_DP
config ROCKCHIP_DW_HDMI
bool "Rockchip specific extensions for Synopsys DW HDMI"
+ select DRM_BRIDGE_CONNECTOR
help
This selects support for Rockchip SoC specific extensions
for the Synopsys DesignWare HDMI driver. If you want to
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 21b141b7cb9c..b5cfcb936078 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -13,6 +13,7 @@
#include <linux/regulator/consumer.h>
#include <drm/bridge/dw_hdmi.h>
+#include <drm/drm_bridge_connector.h>
#include <drm/drm_edid.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
@@ -542,6 +543,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
struct drm_device *drm = data;
struct drm_encoder *encoder;
struct rockchip_hdmi *hdmi;
+ struct drm_connector *connector;
int ret;
if (!pdev->dev.of_node)
@@ -608,7 +610,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
- hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, 0);
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -616,12 +618,21 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
*/
if (IS_ERR(hdmi->hdmi)) {
ret = PTR_ERR(hdmi->hdmi);
- goto err_bind;
+ goto err_cleanup_encoder;
}
- return 0;
+ connector = drm_bridge_connector_init(drm, encoder);
+ if (IS_ERR(connector)) {
+ ret = PTR_ERR(connector);
+ dev_err(hdmi->dev, "Failed to initialize bridge_connector\n");
+ goto err_unbind_bridge;
+ }
-err_bind:
+ return drm_connector_attach_encoder(connector, encoder);
+
+err_unbind_bridge:
+ dw_hdmi_unbind(hdmi->hdmi);
+err_cleanup_encoder:
drm_encoder_cleanup(encoder);
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/4] drm/bridge: dw-hdmi: Pass bridge attach flags for dw_hdmi_bind()
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
In-Reply-To: <20260403070032.447102-1-damon.ding@rock-chips.com>
For Rockchip and Allwinner platforms, the HDMI encoder attaches the
dw-hdmi bridge via dw_hdmi_bind(). This additional bridge attach flag
serves as preparation for the Rockchip dw-hdmi driver to support the
bridge-connector framework.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 +++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
include/drm/bridge/dw_hdmi.h | 4 +++-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ada45e8b3e2c..dd50dda3a4f5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3619,7 +3619,8 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
*/
struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
struct drm_encoder *encoder,
- const struct dw_hdmi_plat_data *plat_data)
+ const struct dw_hdmi_plat_data *plat_data,
+ enum drm_bridge_attach_flags flags)
{
struct dw_hdmi *hdmi;
int ret;
@@ -3628,7 +3629,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
if (IS_ERR(hdmi))
return hdmi;
- ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, 0);
+ ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, flags);
if (ret) {
dw_hdmi_remove(hdmi);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 0dc1eb5d2ae3..21b141b7cb9c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -608,7 +608,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
- hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, 0);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 96532709c2a7..04173335f7e7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -188,7 +188,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
- hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, 0);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 8500dd4f99d8..e789fb451ef2 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -6,6 +6,7 @@
#ifndef __DW_HDMI__
#define __DW_HDMI__
+#include <drm/drm_bridge.h>
#include <sound/hdmi-codec.h>
struct drm_display_info;
@@ -182,7 +183,8 @@ void dw_hdmi_remove(struct dw_hdmi *hdmi);
void dw_hdmi_unbind(struct dw_hdmi *hdmi);
struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
struct drm_encoder *encoder,
- const struct dw_hdmi_plat_data *plat_data);
+ const struct dw_hdmi_plat_data *plat_data,
+ enum drm_bridge_attach_flags flags);
void dw_hdmi_resume(struct dw_hdmi *hdmi);
--
2.34.1
^ permalink raw reply related
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