* Re: [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Vincent Donnefort @ 2026-03-31 2:41 UTC (permalink / raw)
To: Sebastian Ene
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <20260330105441.3226904-1-sebastianene@google.com>
On Mon, Mar 30, 2026 at 10:54:41AM +0000, Sebastian Ene wrote:
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field un-handled in pKVM when an SMC instruction is
> trapped.
> Since the HVC is a private interface between EL2 and the host,
> enforce the host kernel running under pKVM to use an immediate value
> of 0 only when using SMCs to make it clear for non-compliant software
> talking to Trustzone that we only use SMCCC.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> v2 -> current:
> - move the ESR decoding of the imm16 in the handle_host_smc where it
> was supposed to be
> - updated the commit message to include the reason behind while we are
> not doing for HVCs as well
> - updated the commit message to clarify that pKVM is not handling the
> imm16
>
> v1 -> v2:
> - Dropped injecting an UNDEF and return an error instead
> (SMCCC_RET_NOT_SUPPORTED)
> - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> - Updated the title of the commit message from:
> "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> smc with imm16 != 0"
>
> Link to v2:
> https://lore.kernel.org/all/20260325113138.4171430-1-sebastianene@google.com/
> Link to v1:
> https://lore.kernel.org/all/20260324135728.3532400-1-sebastianene@google.com/
>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..461cf5cb5ac7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -676,8 +676,14 @@ static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
> static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> + u64 esr = read_sysreg_el2(SYS_ESR);
> bool handled;
>
> + if (esr & ESR_ELx_xVC_IMM_MASK) {
> + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> + goto exit_skip_instr;
> + }
> +
> func_id &= ~ARM_SMCCC_CALL_HINTS;
>
> handled = kvm_host_psci_handler(host_ctxt, func_id);
> @@ -686,6 +692,7 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> if (!handled)
> default_host_smc_handler(host_ctxt);
>
> +exit_skip_instr:
> /* SMC was trapped, move ELR past the current PC. */
> kvm_skip_host_instr();
> }
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* [GIT PULL] arm64: dts: socfpga: updates for v7.1, version 2
From: Dinh Nguyen @ 2026-03-31 2:36 UTC (permalink / raw)
To: linux-arm-kernel, soc; +Cc: dinguyen
Change from v1:
- Correct the commit message in commit "dt-bindings: intel: Add Agilex5
SoCFPGA modular board"
- Used b4 to apply patch
Thanks,
Dinh
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v7.1_v2
for you to fetch changes up to 625af11fb9885f202e028ea5afa0037f3014e376:
arm64: dts: intel: agilex5: Drop CPU masks from GICv3 PPI interrupts (2026-03-30 21:27:28 -0500)
----------------------------------------------------------------
SoCFPGA DTS updates for v7.1
- dt-bindings updates:
- Document fallback compatible for Stratix10 SoCDK eMMC board
- Document compatible for the Agilex5 SoCFPGA modular board
- Add emmc support for the Stratix10
- Drop CPU masks from the GICv3 PPI interrupts for Agilex5
----------------------------------------------------------------
Dinh Nguyen (1):
dt-bindings: intel: Add Agilex5 SoCFPGA modular board
Geert Uytterhoeven (1):
arm64: dts: intel: agilex5: Drop CPU masks from GICv3 PPI interrupts
Ng Tze Yee (2):
dt-bindings: altera: Add fallback compatible for Stratix 10 SoCDK eMMC variant
arm64: dts: socfpga: stratix10: Add emmc support
Documentation/devicetree/bindings/arm/altera.yaml | 7 ++
arch/arm64/boot/dts/altera/Makefile | 1 +
.../boot/dts/altera/socfpga_stratix10_socdk.dts | 67 +-----------------
.../boot/dts/altera/socfpga_stratix10_socdk.dtsi | 71 +++++++++++++++++++
.../dts/altera/socfpga_stratix10_socdk_emmc.dts | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 8 +--
6 files changed, 166 insertions(+), 69 deletions(-)
create mode 100755 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtsi
create mode 100755 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_emmc.dts
^ permalink raw reply
* Re: [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Xu Yang @ 2026-03-31 2:01 UTC (permalink / raw)
To: Frank Li
Cc: gregkh, s.hauer, kernel, festevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <acqJ0Q_Ux8PvGT7s@lizhi-Precision-Tower-5810>
On Mon, Mar 30, 2026 at 10:33:53AM -0400, Frank Li wrote:
> On Mon, Mar 30, 2026 at 05:31:33PM +0800, Xu Yang wrote:
> > The usb phy registers are not fully reset on warm reset under stress
> > conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
>
> Avoid the words "we ..."
>
> So need manually reset CTRL, PWD, DEBUG, PLL_SIC ...
OK.
>
> > regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
> > CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
> >
> > ERR051269: USB PHY registers not fully resetting on warm reset under
> > stress conditions
> >
> > The following USB PHY registers must be written by SW to restore the reset
> > value after a warm reset:
> >
> > Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
> > Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
> > Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
> > Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > ---
> > drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> > index 7069dd3f4d0d..dd42db8a0829 100644
> > --- a/drivers/usb/phy/phy-mxs-usb.c
> > +++ b/drivers/usb/phy/phy-mxs-usb.c
> > @@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
> > static const struct mxs_phy_data imx7ulp_phy_data = {
> > };
> >
> > +static const struct mxs_phy_data imx8ulp_phy_data = {
> > +};
> > +
> > static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
> > { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> > @@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> > { .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
> > { .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
> > + { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
> > @@ -248,6 +252,11 @@ static inline bool is_imx7ulp_phy(struct mxs_phy *mxs_phy)
> > return mxs_phy->data == &imx7ulp_phy_data;
> > }
> >
> > +static inline bool is_imx8ulp_phy(struct mxs_phy *mxs_phy)
> > +{
> > + return mxs_phy->data == &imx8ulp_phy_data;
>
> don't use this kind check.
>
> Add field 'need_reset_reg' in mxs_phy_data
>
> imx8ulp_phy_data = {
> .need_reset_reg = true;
> }
>
> if (mxs->data->need_reset_reg)
> ...
>
> The same logic for
> if (is_imx7ulp_phy(mxs_phy) || is_imx8ulp_phy(mxs_phy))
> mxs_phy_pll_enable(phy->io_priv, false);
>
> add 'need_phy_pull_enable' in mxs_phy_data. (new patch for it)
> set it true at both imx7ulp_phy_data and imx8ulp_phy_data.
OK.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Xu Yang @ 2026-03-31 1:59 UTC (permalink / raw)
To: Greg KH
Cc: Frank.Li, s.hauer, kernel, festevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <2026033057-sixties-erupt-fea7@gregkh>
On Mon, Mar 30, 2026 at 04:19:24PM +0200, Greg KH wrote:
> On Mon, Mar 30, 2026 at 05:31:33PM +0800, Xu Yang wrote:
> > The usb phy registers are not fully reset on warm reset under stress
> > conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
> > regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
> > CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
> >
> > ERR051269: USB PHY registers not fully resetting on warm reset under
> > stress conditions
> >
> > The following USB PHY registers must be written by SW to restore the reset
> > value after a warm reset:
> >
> > Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
> > Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
> > Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
> > Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > ---
> > drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> > index 7069dd3f4d0d..dd42db8a0829 100644
> > --- a/drivers/usb/phy/phy-mxs-usb.c
> > +++ b/drivers/usb/phy/phy-mxs-usb.c
> > @@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
> > static const struct mxs_phy_data imx7ulp_phy_data = {
> > };
> >
> > +static const struct mxs_phy_data imx8ulp_phy_data = {
> > +};
> > +
> > static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
> > { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> > @@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> > { .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
> > { .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
> > + { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
>
> Why can't you use &imx7ulp_phy_data here as it's all just empty?
Thanks for your review.
Because it's imx8ulp specific errata. Let me add more info in the commit message.
Thanks,
Xu Yang
^ permalink raw reply
* RE: [PATCH] clk: visconti: pll: use kzalloc_flex
From: nobuhiro.iwamatsu.x90 @ 2026-03-31 1:05 UTC (permalink / raw)
To: rosenp, linux-clk
Cc: mturquette, sboyd, kees, gustavoars, linux-arm-kernel,
linux-kernel, linux-hardening
In-Reply-To: <20260326042317.122536-1-rosenp@gmail.com>
Hi Rosen,
Thanks for your patch.
> -----Original Message-----
> From: Rosen Penev <rosenp@gmail.com>
> Sent: Thursday, March 26, 2026 1:23 PM
> To: linux-clk@vger.kernel.org
> Cc: Michael Turquette <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; iwamatsu nobuhiro(岩松 信洋
> □ＤＩＴＣ○ＣＰＴ) <nobuhiro.iwamatsu.x90@mail.toshiba>; Kees Cook <kees@kernel.org>; Gustavo A. R. Silva
> <gustavoars@kernel.org>; moderated list:ARM/TOSHIBA VISCONTI ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; open list <linux-kernel@vger.kernel.org>; open list:KERNEL HARDENING (not
> covered by other areas):Keyword:\b__counted_by(_le|_be)?\b <linux-hardening@vger.kernel.org>
> Subject: [PATCH] clk: visconti: pll: use kzalloc_flex
>
> Simplify allocation by using a flexible array member and kzalloc_flex.
>
> Add __counted_by for extra runtime analysis. Assign after allocation as required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Best regards,
Nobuhiro
> ---
> drivers/clk/visconti/pll.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/visconti/pll.c b/drivers/clk/visconti/pll.c index 6fd02c4b641e..ca29d12f9316 100644
> --- a/drivers/clk/visconti/pll.c
> +++ b/drivers/clk/visconti/pll.c
> @@ -21,9 +21,9 @@ struct visconti_pll {
> void __iomem *pll_base;
> spinlock_t *lock;
> unsigned long flags;
> - const struct visconti_pll_rate_table *rate_table;
> size_t rate_count;
> struct visconti_pll_provider *ctx;
> + struct visconti_pll_rate_table rate_table[] __counted_by(rate_count);
> };
>
> #define PLL_CONF_REG 0x0000
> @@ -255,10 +255,6 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
> size_t len;
> int ret;
>
> - pll = kzalloc_obj(*pll);
> - if (!pll)
> - return ERR_PTR(-ENOMEM);
> -
> init.name = name;
> init.flags = CLK_IGNORE_UNUSED;
> init.parent_names = &parent_name;
> @@ -266,11 +262,13 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
>
> for (len = 0; rate_table[len].rate != 0; )
> len++;
> +
> + pll = kzalloc_flex(*pll, rate_table, len);
> + if (!pll)
> + return ERR_PTR(-ENOMEM);
> +
> pll->rate_count = len;
> - pll->rate_table = kmemdup_array(rate_table,
> - pll->rate_count, sizeof(*pll->rate_table),
> - GFP_KERNEL);
> - WARN(!pll->rate_table, "%s: could not allocate rate table for %s\n", __func__, name);
> + memcpy(pll->rate_table, rate_table, len * sizeof(*pll->rate_table));
>
> init.ops = &visconti_pll_ops;
> pll->hw.init = &init;
> @@ -282,7 +280,6 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
> ret = clk_hw_register(NULL, &pll->hw);
> if (ret) {
> pr_err("failed to register pll clock %s : %d\n", name, ret);
> - kfree(pll->rate_table);
> kfree(pll);
> pll_hw_clk = ERR_PTR(ret);
> }
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Yaxiong Tian @ 2026-03-31 1:30 UTC (permalink / raw)
To: Jie Zhan, cw00.choi, myungjoo.ham, kyungmin.park
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <1774919144945331.7.seg@mailgw.kylinos.cn>
在 2026/3/30 14:29, Jie Zhan 写道:
>
> On 3/27/2026 10:06 AM, Yaxiong Tian wrote:
>> 在 2026/3/26 21:14, Jie Zhan 写道:
>>> On 3/26/2026 8:34 PM, Jie Zhan wrote:
>>>> When compiled as a kernel module, the governor module can be dynamically
>>>> inserted or removed. 'devfreq->governor' would become NULL if the governor
>>>> module is removed when it's in use, and NULL pointer dereference would be
>>>> triggered. A similar issue was also reported in [1].
>>>>
>>>> To address this issue:
>>>>
>>>> Patch 1-5 rework mutex, factor out a common governor setting function, and
>>>> clean up some unreachable code.
>>>>
>>>> Patch 6-8 prevent a governor module in use from being removed (except for
>>>> force unload) by getting/putting a refcount of the governor's module when
>>>> switching governors.
>>>>
>>>> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
>>>> when a governor module in use is force unloaded.
>>>>
>>>> Note that this series is based on [1] or devfreq-next, otherwise code
>> Sorry, please ignore the "remember to CC me on the patches." in my previous email.
>>
>> In my opinion, it would be better to prioritize the FIX first before proceeding with the lock mechanism optimizations and other work. This would make it easier to backport the patches to lower-version kernels. I noticed the patch is already in the devfreq-testing branch. I hope the FIX work can be moved forward smoothly to resolve the null pointer and other bugs. Thank you!
> Hi Yaxiong,
>
> I don't think this issue is urgent because it can only possibly happen when
> governors are built as loadable modules, which is typically used for
> development rather than production.
No, loading/unloading modules is also a user operational requirement,
not just for development.
>
> For downstream kernels, feel free to go ahead with quick fixes. For the
> upstream kernel, however, I'd prefer to make the devfreq core clean and
> sensible.
I don't think code cleanup should take priority over bug fixes,
especially when you already know there's an issue with the
functionality. In fact, the version users are running is not the
upstream version, but rather individual stable releases.
Most users don't have the time or energy to research and fix kernel
issues themselves; they rely on upstream community patches most of the time.
By the way, although your patch subject says "FIX", I don't see any fix tag.
>
> Your approach is to prevent kernel panics when unloading governor modules
> before changing governors.
>
> This patchset achieves that, and additionally let userspace get a friendly
> warning when trying to remove a governor module in use, e.g.
> "rmmod: ERROR: Module governor_performance is in use".
> This requires using the module refcount stuff, and brings out a set of
> cleanups and refactoring. BTW, cpufreq implements a similar mechanism like
> this.
>
> I may carry your fourth patch that changes the return code of
> governor_show() in v2 and address some Sashiko review comments along the
> way.
>
> Please let me know if this works for you?
So I don't approve of this. Maybe you should ask for others' opinions,
such as Chanwoo Choi.
>
> Regards,
> Jie
>>
>>
>>> sorry, based on [2] or devfreq-next
>>>> would conflict.
>>>>
>>>> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
>>>> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 1:29 UTC (permalink / raw)
To: James Clark, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <95610981-ad68-4a31-a776-27894b7bca59@linaro.org>
Hi James,
On 3/30/2026 10:55 PM, James Clark wrote:
>
>
> On 25/03/2026 3:10 am, Jie Gan wrote:
>> Save the trace ID in drvdata during TPDM enablement and expose it
>> to userspace to support trace data parsing.
>>
>> The TPDM device’s trace ID corresponds to the trace ID allocated
>> to the connected TPDA device.
>>
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>> Changes in v3:
>> 1. Only allow user to read the traceid while the TPDM device is enabled.
>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-
>> tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>
>> Changes in V2:
>> 1. Use sysfs_emit instead of sprintf.
>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>> ---
>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++++++
>> +++++++++-
>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/
>> hwtracing/coresight/coresight-tpdm.c
>> index da77bdaad0a4..c8339b973bfc 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>> *drvdata)
>> static int tpdm_enable(struct coresight_device *csdev, struct
>> perf_event *event,
>> enum cs_mode mode,
>> - __maybe_unused struct coresight_path *path)
>> + struct coresight_path *path)
>> {
>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>> *csdev, struct perf_event *event,
>> }
>> __tpdm_enable(drvdata);
>> + drvdata->traceid = path->trace_id;
>> drvdata->enable = true;
>> spin_unlock(&drvdata->spinlock);
>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>> .attrs = tpdm_attrs,
>> };
>> +static ssize_t traceid_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + unsigned long val;
>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>> + return -EINVAL;
>> +
>> + val = drvdata->traceid;
>
> You probably need to take the coresight_mutex here otherwise you could
> still return an invalid or stale value despite checking the mode.
>
Acked. I have missed this potential race condition.
> There might also be some value in it returning the last used trace ID
> even if the mode isn't enabled anymore. Because you can still read out
> of the sink after disabling, so it makes more sense for a script to read
> it at that point rather than when it's enabled. Also, you probably don't
> want to be doing other things in your script in the point between
> enabling and disabling.
That's making sense. I shouldnt add such restriction for the read process.
Scenarios for reading:
1. device is enabled -> trace ID is valid
2. device is enabled then disabled -> trace ID is valid for the last
trace event
3. device is never enabled -> invalid trace ID (value 0)
we only need to check the validation of the trace ID.
mutex_lock(&coresight_mutex);
val = drvdata->traceid;
mutex_unlock(&coresight_mutex);
if (!val)
return -EINVAL;
return sysfs_emit(buf, "%#lx\n", val);
Thanks,
Jie
>
>> + return sysfs_emit(buf, "%#lx\n", val);
>> +}
>> +static DEVICE_ATTR_RO(traceid);
>> +
>> +static struct attribute *traceid_attrs[] = {
>> + &dev_attr_traceid.attr,
>> + NULL,
>> +};
>> +
>> +static struct attribute_group traceid_attr_grp = {
>> + .attrs = traceid_attrs,
>> +};
>> +
>> static ssize_t dsb_mode_show(struct device *dev,
>> struct device_attribute *attr,
>> char *buf)
>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>> *tpdm_attr_grps[] = {
>> &tpdm_cmb_patt_grp,
>> &tpdm_cmb_msr_grp,
>> &tpdm_mcmb_attr_grp,
>> + &traceid_attr_grp,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>> + &traceid_attr_grp,
>> NULL,
>> };
>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct
>> resource *res)
>> desc.access = CSDEV_ACCESS_IOMEM(base);
>> if (res)
>> desc.groups = tpdm_attr_grps;
>> + else
>> + desc.groups = static_tpdm_attr_grps;
>> drvdata->csdev = coresight_register(&desc);
>> if (IS_ERR(drvdata->csdev))
>> return PTR_ERR(drvdata->csdev);
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/
>> hwtracing/coresight/coresight-tpdm.h
>> index 2867f3ab8186..11da64e1ade8 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>> * @cmb Specifics associated to TPDM CMB.
>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>> + * @traceid Trace ID of the path.
>> */
>> struct tpdm_drvdata {
>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>> struct cmb_dataset *cmb;
>> u32 dsb_msr_num;
>> u32 cmb_msr_num;
>> + u8 traceid;
>> };
>> /* Enumerate members of various datasets */
>>
>> ---
>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>
>> Best regards,
>
^ permalink raw reply
* [PATCH v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Chancel Liu @ 2026-03-31 1:24 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
Currently this binding only lists i2s and dsp_b formats that are used
by existing sound cards. However, DT bindings should describe the full
hardware capabilities rather than only the formats of current usage.
The SAI audio controller of i.MX audio sound card supports multiple DAI
formats, including:
- i2s
- left_j
- right_j
- dsp_a
- dsp_b
- pdm
- msb
- lsb
Complete the full list of formats supported by i.MX audio sound card to
ensure the binding correctly describes hardware.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
Changes in v4:
- Completed the full list of DAI formats (i2s, left_j, right_j, dsp_a,
dsp_b, pdm, msb, lsb) supported by i.MX sound card.
- Rewrote commit message to focus on describing hardware capability
rather than current usage.
Changes in v3:
- Rewrote commit message completely to describe hardware requirements.
Explicitly documented why only dsp_a is added and why other formats
are not included.
- Rebased on latest code base. No functional changes.
Changes in v2:
- Updated commit message to explain current support for i2s and dsp_b
formats and new support for dsp_a. No code changes.
Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index 5424d4f16f52..950e3eab2942 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -37,7 +37,13 @@ patternProperties:
items:
enum:
- i2s
+ - left_j
+ - right_j
+ - dsp_a
- dsp_b
+ - pdm
+ - msb
+ - lsb
dai-tdm-slot-num: true
--
2.50.1
^ permalink raw reply related
* Re: [PATCH net-next v2] net: airoha: Delay offloading until all net_devices are fully registered
From: patchwork-bot+netdevbpf @ 2026-03-31 1:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260329-airoha-regiser-race-fix-v2-1-f4ebb139277b@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 29 Mar 2026 12:32:27 +0200 you wrote:
> Netfilter flowtable can theoretically try to offload flower rules as soon
> as a net_device is registered while all the other ones are not
> registered or initialized, triggering a possible NULL pointer dereferencing
> of qdma pointer in airoha_ppe_set_cpu_port routine. Moreover, if
> register_netdev() fails for a particular net_device, there is a small
> race if Netfilter tries to offload flowtable rules before all the
> net_devices are properly unregistered in airoha_probe() error patch,
> triggering a NULL pointer dereferencing in airoha_ppe_set_cpu_port
> routine. In order to avoid any possible race, delay offloading until
> all net_devices are registered in the networking subsystem.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: airoha: Delay offloading until all net_devices are fully registered
https://git.kernel.org/netdev/net/c/cedc1bf327de
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v5 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-03-31 0:54 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: <20260331005458.24010-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: 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 v5 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-03-31 0:54 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: <20260331005458.24010-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 v5 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-03-31 0:54 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 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 | 44 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
3 files changed, 93 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v5 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-03-31 0:54 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: <20260331005458.24010-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: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
1 file changed, 36 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..601fe05b73e7 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,22 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ minItems: 1
+ maxItems: 2
+ 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 +69,25 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net-next v2 00/15] net: stmmac: qcom-ethqos: more cleanups
From: patchwork-bot+netdevbpf @ 2026-03-31 0:50 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-arm-msm, linux-stm32, mohd.anwar, netdev,
pabeni
In-Reply-To: <acZDEg9wdjhBTHlL@shell.armlinux.org.uk>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 27 Mar 2026 08:42:58 +0000 you wrote:
> Further cleanups to qcom-ethqos, mainly concentrating on the RGMII
> code, making it clearer what the differences are for each speed, thus
> making the code more readable.
>
> I'm still not really happy with this. The speed specific configuration
> remains split between ethqos_fix_mac_speed_rgmii() and
> ethqos_rgmii_macro_init(), where the latter is only ever called from
> the former. So, I think further work is needed here - maybe it needs
> restructuring into the various componenet parts of the RGMII block?
>
> [...]
Here is the summary with links:
- [net-next,v2,01/15] net: stmmac: qcom-ethqos: remove ethqos_configure()
https://git.kernel.org/netdev/net-next/c/c3dd3b1e76e0
- [net-next,v2,02/15] net: stmmac: qcom-ethqos: pass ethqos to ethqos_pcs_set_inband()
https://git.kernel.org/netdev/net-next/c/673416fb5b41
- [net-next,v2,03/15] net: stmmac: qcom-ethqos: eliminate configure_func
https://git.kernel.org/netdev/net-next/c/e9ed46a0b129
- [net-next,v2,04/15] net: stmmac: qcom-ethqos: move detection of invalid RGMII speed
https://git.kernel.org/netdev/net-next/c/426ce4677e81
- [net-next,v2,05/15] net: stmmac: qcom-ethqos: move RGMII_CONFIG_DDR_MODE
https://git.kernel.org/netdev/net-next/c/6be23c4c636a
- [net-next,v2,06/15] net: stmmac: qcom-ethqos: move 1G vs 100M/10M RGMII settings
https://git.kernel.org/netdev/net-next/c/82d5fdc82a33
- [net-next,v2,07/15] net: stmmac: qcom-ethqos: move two more RGMII_IO_MACRO_CONFIG2 out
https://git.kernel.org/netdev/net-next/c/dd07f2f9149a
- [net-next,v2,08/15] net: stmmac: qcom-ethqos: move 100M/10M speed programming
https://git.kernel.org/netdev/net-next/c/8b19a9184420
- [net-next,v2,09/15] net: stmmac: qcom-ethqos: move RGMII_CONFIG2_RSVD_CONFIG15 out
https://git.kernel.org/netdev/net-next/c/dae1de3df3e1
- [net-next,v2,10/15] net: stmmac: qcom-ethqos: move RGMII_CONFIG2_RX_PROG_SWAP
https://git.kernel.org/netdev/net-next/c/432c8a9f5528
- [net-next,v2,11/15] net: stmmac: qcom-ethqos: finally eliminate the switch
https://git.kernel.org/netdev/net-next/c/439a27f21ecc
- [net-next,v2,12/15] net: stmmac: qcom-ethqos: simplify prg_rclk_dly programming
https://git.kernel.org/netdev/net-next/c/3df0e86f8f8d
- [net-next,v2,13/15] net: stmmac: qcom-ethqos: move loopback decision next to reg update
https://git.kernel.org/netdev/net-next/c/67343aa24e59
- [net-next,v2,14/15] net: stmmac: qcom-ethqos: correct prg_rclk_dly comment
https://git.kernel.org/netdev/net-next/c/2d350a892aad
- [net-next,v2,15/15] net: stmmac: qcom-ethqos: move phase_shift to register update site
https://git.kernel.org/netdev/net-next/c/7f9f30166005
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: lpc_eth: Fix a possible memory leak in lpc_mii_probe()
From: Ma Ke @ 2026-03-31 0:43 UTC (permalink / raw)
To: vz
Cc: alexandre.belloni, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-kernel, make24, netdev, pabeni,
piotr.wojtaszczyk, stable
In-Reply-To: <b44db9e6-f820-439d-a7ed-c1e2514579a8@mleia.com>
On 3/30/26 13:04, Vladimir Zapolskiy wrote:
> On 3/30/26 11:16, Ma Ke wrote:
> > lpc_mii_probe() calls of_phy_find_device() to obtain a phy_device
> > pointer. of_phy_find_device() increments the refcount of the device.
> > The current implementation does not decrement the refcount after using
> > the pointer, which leads to a memory leak.
>
> this is correct, there is an actual detected bug.
>
> >
> > Add phy_device_free() to balance the refcount.
>
> But this does not sound right, you shoud use of_node_put(pldat->phy_node).
>
> >
> > Found by code review.
> >
> > Signed-off-by: Ma Ke <make24@iscas.ac.cn>
> > Cc: stable@vger.kernel.org
> > Fixes: 3503bf024b3e ("net: lpc_eth: parse phy nodes from device tree")
> > ---
> > drivers/net/ethernet/nxp/lpc_eth.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> > index 8b9a3e3bba30..8ce7c9bb6dd6 100644
> > --- a/drivers/net/ethernet/nxp/lpc_eth.c
> > +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> > @@ -751,7 +751,7 @@ static void lpc_handle_link_change(struct net_device *ndev)
> > static int lpc_mii_probe(struct net_device *ndev)
> > {
> > struct netdata_local *pldat = netdev_priv(ndev);
> > - struct phy_device *phydev;
> > + struct phy_device *phydev, *phydev_tmp;
> >
> > /* Attach to the PHY */
> > if (lpc_phy_interface_mode(&pldat->pdev->dev) == PHY_INTERFACE_MODE_MII)
> > @@ -760,17 +760,18 @@ static int lpc_mii_probe(struct net_device *ndev)
> > netdev_info(ndev, "using RMII interface\n");
> >
> > if (pldat->phy_node)
> > - phydev = of_phy_find_device(pldat->phy_node);
> > + phydev_tmp = of_phy_find_device(pldat->phy_node);
> > else
> > - phydev = phy_find_first(pldat->mii_bus);
> > - if (!phydev) {
> > + phydev_tmp = phy_find_first(pldat->mii_bus);
> > + if (!phydev_tmp) {
>
> I didn't get it, why the new phydev_tmp is needed above, please
> restore the original code above.
>
> > netdev_err(ndev, "no PHY found\n");
> > return -ENODEV;
> > }
> >
> > - phydev = phy_connect(ndev, phydev_name(phydev),
> > + phydev = phy_connect(ndev, phydev_name(phydev_tmp),
> > &lpc_handle_link_change,
> > lpc_phy_interface_mode(&pldat->pdev->dev));
> > + phy_device_free(phydev_tmp);
>
> This is plainly wrong and has to be dropped or changed to
>
> if (pldat->phy_node)
> of_node_put(pldat->phy_node);
>
> > if (IS_ERR(phydev)) {
> > netdev_err(ndev, "Could not attach to PHY\n");
> > return PTR_ERR(phydev);
>
> Is it AI generated fix or what?.. The change looks bad, it introduces
> more severe issues than it fixes.
>
> If you think you cannot create a proper change, let me know.
>
> --
> Best wishes,
> Vladimir
Thank you very much for your detailed review and guidance.
Now I think your point probably is: you are saying that the real leak is not from of_phy_find_device(), but from the device node pldat->phy_node which was obtained earlier (probably by of_parse_phandle()) and never freed by of_node_put(). And you suggest to add of_node_put(pldat->phy_node) instead of my wrong phy_device_free().
However, I am still a little confused. In lpc_mii_probe(), of_phy_find_device() is called. From my understanding, this function increases the reference count of the device. To balance it, I thought phy_device_free() (which calls put_device()) should be used.
Could you please kindly advise the correct patch? I will follow your guidance and submit a proper fix.
I apologize again for my previous wrong patch. Thank you very much for your help.
Best regards,
Ma Ke
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: patchwork-bot+netdevbpf @ 2026-03-31 0:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev, Madhur.Agrawal
In-Reply-To: <20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 27 Mar 2026 10:48:21 +0100 you wrote:
> In order to properly cleanup hw rx QDMA queues and bring the device to
> the initial state, reset rx DMA queue head/tail index. Moreover, reset
> queued DMA descriptor fields.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
https://git.kernel.org/netdev/net/c/514aac359987
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: Jakub Kicinski @ 2026-03-31 0:28 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org>
On Fri, 27 Mar 2026 10:48:21 +0100 Lorenzo Bianconi wrote:
> In order to properly cleanup hw rx QDMA queues and bring the device to
> the initial state, reset rx DMA queue head/tail index. Moreover, reset
> queued DMA descriptor fields.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Take a look at sashiko, please:
https://sashiko.dev/#/patchset/20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org
Looks somewhat orthogonal to the current patch but probably worth
fixing.
^ permalink raw reply
* [PATCH] drm/mediatek: simplify mtk_crtc allocation
From: Rosen Penev @ 2026-03-31 0:23 UTC (permalink / raw)
To: dri-devel
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno,
moderated list:DRM DRIVERS FOR MEDIATEK,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use a flexible array member to combine allocations.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
index fcb16f3f7b23..914841d2396e 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -62,7 +62,6 @@ struct mtk_crtc {
struct device *dma_dev;
struct mtk_mutex *mutex;
unsigned int ddp_comp_nr;
- struct mtk_ddp_comp **ddp_comp;
unsigned int num_conn_routes;
const struct mtk_drm_route *conn_routes;
@@ -71,6 +70,8 @@ struct mtk_crtc {
bool config_updating;
/* lock for config_updating to cmd buffer */
spinlock_t config_lock;
+
+ struct mtk_ddp_comp *ddp_comp[];
};
struct mtk_crtc_state {
@@ -1048,18 +1049,12 @@ int mtk_crtc_create(struct drm_device *drm_dev, const unsigned int *path,
}
}
- mtk_crtc = devm_kzalloc(dev, sizeof(*mtk_crtc), GFP_KERNEL);
+ mtk_crtc = devm_kzalloc(dev, struct_size(mtk_crtc, ddp_comp, path_len + (conn_routes ? 1 : 0)), GFP_KERNEL);
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->ddp_comp_nr = path_len;
- mtk_crtc->ddp_comp = devm_kcalloc(dev,
- mtk_crtc->ddp_comp_nr + (conn_routes ? 1 : 0),
- sizeof(*mtk_crtc->ddp_comp),
- GFP_KERNEL);
- if (!mtk_crtc->ddp_comp)
- return -ENOMEM;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->mutex = mtk_mutex_get(priv->mutex_dev);
if (IS_ERR(mtk_crtc->mutex)) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-30 23:56 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, 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,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acclgID7lSVNten2@intel.com>
On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrjälä wrote:
> On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > > > + * semantics.
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > >
> > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > should be for each format.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > by other properties.
> > > > > > > > > >
> > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > >
> > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > >
> > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > >
> > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > field of its own?
> > > > > > >
> > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > I think the assumption is limited range everywhere.
> > > > > > >
> > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > will want to know what the new property actually does so the
> > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > is no clear specification.
> > > > > >
> > > > > > Ack
> > > > > >
> > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > - YCbCr limited range
> > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > >
> > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > anything else full range?
> > > > >
> > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > those would always go hand in hand now.
> > > >
> > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > and uses the HDMI state helpers.
> > > >
> > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > drm_default_rgb_quant_range() which seems suspicious?
> > >
> > > If they want just manual full vs. limited then they should
> > > limit the property to not expose the "auto" option at all.
> > >
> > > amdgpu also ties this in with the "colorspace" property, which
> > > originally in i915 only controlled the infoframes/etc. But on
> > > amdgpu it now controls various aspects of output color
> > > transformation. The end result is that the property is a complete
> > > mess with most of the values making no sense. And for whatever
> > > reason everyone involved refused to remove/deprecate the
> > > nonsensical values :/
> > >
> > > Looks like this series should make sure the documentation for
> > > the "colorspace" property is in sync with the new property
> > > as well. Currently now it's giving conflicting information.
> > >
> >
> > I take it the problematic information is in
> >
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> >
> > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > that they "produce RGB content".
> >
> > I think we probably just have to change the statement "The variants
> > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > RGB and YCbCr on its own."
> >
> > The "on its own" here would get turned into "based on the color format
> > property".
> >
> > Speaking of i915, that patch is one of the very few (5) patches in
> > this series still lacking a review (hint hint nudge nudge). I'd like
> > to get some more feedback on the remaining patches before I send out
> > another revision, so that it's hopefully not just docs changes (I
> > know better than to think those patches must be perfect and won't
> > need revision.)
>
> The i915 code around this is already a big mess, and I don't really
> adding to that mess. So I think we'll need to do some refactoring before
> we add anything there. I already started typing something and so far
> it looks fairly straightforward, so I should have something soon.
OK, posted something
https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@linux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f
Are the wayland/compositor/color management folks on board with
these new properties? I don't think I see the usual suspects on
the cc list.
>
> While doing that several questions came to my mind though:
>
> * More interactions with the colorspace property, but I sent
> a separate mail already about that
>
> * Which conversion matrix to use, and the answer I suspect
> should be "ask the colorspace property", as mentioned in the
> other mail
>
> * Should we flat out reject color formats (and I suppose also
> colorspace prop values) the sink doesn't claim to support?
>
> If yes, then I think we'll have to forget about adding anything
> to i915 MST code. The way the MST stuff works is that if one
> stream needs a modeset then all the related streams get modeset
> as well. Thus if the user replaces a monitor getting fed with a
> YCbCr stream just as another stream is being modeset, then the
> entire atomic commit could fail due to the YCbCr stream getting
> rejected.
>
> I think eventually we might have to invent some mechanism where
> all the input into the modeset computation is cached somehow,
> and said cache updated only on explicit userspace modesets.
> Either that or we have to come up with a way to skip some of
> the calculations that depend on external factors. Either way
> it's going to be a pain.
>
> OTOH if we don't mind feeding the sink with stuff it can't
> understand, then I suppose we might add YCbCr 4:4:4 support
> for MST. It shouldn't be any different from RGB apart from
> the RGB->YCbCr conversion, which is handled elsewhere. But
> YCbCr 4:2:0 is definitely out either way, the MST code has
> no support for that currently.
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
From: Jakub Kicinski @ 2026-03-30 23:42 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <acl0pTqJ97o0PRxY@shell.armlinux.org.uk>
On Sun, 29 Mar 2026 19:51:17 +0100 Russell King (Oracle) wrote:
> > While I have you - you have a significantly negative "reviewer score".
> > You post much more than you review. Which should earn you extra 24h
> > of delay in our system. I've been trying to ignore that and prioritize
> > applying your patches but it'd be great if you could review a bit more.
>
> Sorry, but given the effort that stmmac is taking, I don't have much
> capacity to extend mental cycles elsewhere.
>
> This two patch series wouldn't have exploded into ten (or maybe even
> more) patches had someone not pointed out the problem with
> suspend/resume interacting with disabling TSO... which prompted me to
> look deeper and discover a multitude of other problems. Should I
> instead ignore these bugs and not bother trying to fix this stuff?
>
> Honestly, I'm getting tired of stmmac with it sucking lots of my time,
> and I suspect you're getting tired of the constant stream of patches
> for it - but the reason there's a constant stream is because there's
> so much that's wrong or broken in this driver.
>
> So either we let the driver rot, or... what?
I was hoping to nudge you towards reviewing more rather than have you
slow down TBH :) Your patches are generally excellent so not a burden
for my PoV. And stmmac is a toilet, a very popular one at that, so
efforts to clean it up are most appreciated. If you could review a
couple of series every time you post - the balance should be restored
to our tooling universe.
^ permalink raw reply
* Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control
From: Vladimir Oltean @ 2026-03-30 23:35 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, kernel, linux-phy,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <f2827d9f-ddba-4fbd-8d1f-a1a2d1b94708@collabora.com>
On Tue, Mar 31, 2026 at 01:56:32AM +0300, Cristian Ciocaltea wrote:
> On 3/30/26 11:57 AM, Vladimir Oltean wrote:
> > On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
> >> ---
> >> base-commit: f7b64ed948718290209074a50bb0df17e5944873
> >> change-id: 20260328-hdptx-ffe-a89c51e66904
> >> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
> >> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
> >> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
> >> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
> >> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
> >> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
> >> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
> >
> > Sorry for my ignorance; who is supposed to act upon this git-format-patch
> > base tree information and in what way?
> >
> > As things stand today, the build infrastructure we have in place will
> > not be able to apply and test your series unless it applies directly
> > onto the linux-phy/next branch.
>
> Oh, I assumed that since b4 makes managing series dependencies straightforward
> on the preparation/submission side, there would be similar tooling support on
> the build/integration side as well.
Sorry to disappoint - linux-phy doesn't use b4 to build-test patches. It
gets them from Patchwork directly (as you'd get by clicking the 'diff' button),
then figures out whether to apply to the next or to the fixes branch
using the git-format-patch --subject-prefix string ('phy-next' or 'phy-fixes'),
then posts the checks back to Patchwork.
I can somehow imagine why no one rushed to improve this. While sometimes
somewhat useful, I can see the risk of such feature getting abused to
create a giant cobweb of dependencies that is suddenly no longer the
developer's problem, but passed on to somebody else.
In the future, please submit as RFC the patch sets that you know don't
directly apply, and mention that you're only posting them for early
feedback.
^ permalink raw reply
* Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control
From: Cristian Ciocaltea @ 2026-03-30 22:56 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, kernel, linux-phy,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260330085723.4rewkbs76lz3scum@skbuf>
On 3/30/26 11:57 AM, Vladimir Oltean wrote:
> On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
>> During HDMI 2.1 Fixed Rate Link training, the source and sink may
>> negotiate a Transmitter Feed Forward Equalizer (TxFFE) level to
>> compensate for signal quality degradation on the physical channel. The
>> source starts at level 0 and may increment it up to a maximum agreed
>> upon during LTS3 in response to persistent link failures reported by the
>> sink. TxFFE adjustment is optional and entirely independent of the FRL
>> rate and lane count selection.
>>
>> Patch 1 extends the HDMI PHY configuration API with two new fields in
>> the frl sub-struct: ffe_level to carry the requested level, and a
>> set_ffe_level flag that switches the semantics of a phy_configure() call
>> to a pure equalizer update, leaving all other fields ignored.
>>
>> Patch 2 implements the new interface in the Rockchip Samsung HDPTX PHY
>> driver.
>>
>> The series depends on the "[PATCH 0/6] phy: rockchip: samsung-hdptx:
>> Clock fixes and API transition cleanups" patchset:
>>
>> https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> Cristian Ciocaltea (2):
>> phy: hdmi: Add optional FRL TxFFE config options
>> phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
>>
>> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
>> include/linux/phy/phy-hdmi.h | 6 ++
>> 2 files changed, 75 insertions(+), 5 deletions(-)
>> ---
>> base-commit: f7b64ed948718290209074a50bb0df17e5944873
>> change-id: 20260328-hdptx-ffe-a89c51e66904
>> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
>> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
>> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
>> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
>> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
>> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
>> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
>
> Sorry for my ignorance; who is supposed to act upon this git-format-patch
> base tree information and in what way?
>
> As things stand today, the build infrastructure we have in place will
> not be able to apply and test your series unless it applies directly
> onto the linux-phy/next branch.
Oh, I assumed that since b4 makes managing series dependencies straightforward
on the preparation/submission side, there would be similar tooling support on
the build/integration side as well.
^ permalink raw reply
* [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: 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,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
It is necessary to wait for the full frame to finish streaming
through the DMA engine before we can safely disable it by removing
the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
hardware confused and unable to resume streaming for the next frame.
This causes the FIFO underrun and empty status bits to be set and
a single solid color to be shown on the display, coming from one of
the pixels of the previous frame. The issue occurs sporadically when
a new mode is set, which triggers the crtc disable and enable paths.
Setting the shadow load bit and waiting for it to be cleared by the
DMA engine allows waiting for completion.
The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 1aac354041c7..7dce7f48d938 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
if (ret)
drm_err(lcdif->drm, "Failed to disable controller!\n");
+ /*
+ * It is necessary to wait for the full frame to finish streaming
+ * through the DMA engine before we can safely disable it by removing
+ * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
+ * hardware confused and unable to resume streaming for the next frame.
+ */
+ reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
+ reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
+ writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
+
+ ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
+ reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
+ 0, 36000); /* Wait ~2 frame times max */
+ if (ret)
+ drm_err(lcdif->drm, "Failed to disable controller!\n");
+
reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
reg &= ~DISP_PARA_DISP_ON;
writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: 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,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
The lcdif v3 hardware comes with dedicated registers to set and clear
polarity bits in the CTRL register. It is unclear if there is a
difference with writing to the CTRL register directly.
Follow the NXP BSP reference by using these registers, in case there is
a subtle difference caused by using them.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index a00c4f6d63f4..1aac354041c7 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -296,18 +296,27 @@ static void lcdif_set_formats(struct lcdif_drm_private *lcdif,
static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
{
struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
- u32 ctrl = 0;
+ u32 ctrl;
if (m->flags & DRM_MODE_FLAG_NHSYNC)
- ctrl |= CTRL_INV_HS;
+ writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
+
if (m->flags & DRM_MODE_FLAG_NVSYNC)
- ctrl |= CTRL_INV_VS;
+ writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
+
if (bus_flags & DRM_BUS_FLAG_DE_LOW)
- ctrl |= CTRL_INV_DE;
- if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
- ctrl |= CTRL_INV_PXCK;
+ writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_CLR);
- writel(ctrl, lcdif->base + LCDC_V8_CTRL);
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
+ writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_CLR);
writel(DISP_SIZE_DELTA_Y(m->vdisplay) |
DISP_SIZE_DELTA_X(m->hdisplay),
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] drm: lcdif: Set undocumented bit to clear FIFO at vsync
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: 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,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
There is an undocumented bit used in the NXP BSP to clear the FIFO
systematically at vsync. In normal operation, the FIFO should already
be empty but it doesn't hurt to add it as an extra safety measure.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 3 ++-
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index ef3250a5c54f..a00c4f6d63f4 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -338,7 +338,8 @@ static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
* Downstream set it to 256B burst size to improve the memory
* efficiency so set it here too.
*/
- ctrl = CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
+ ctrl = CTRLDESCL0_3_STATE_CLEAR_VSYNC |
+ CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
CTRLDESCL0_3_PITCH(lcdif->crtc.primary->state->fb->pitches[0]);
writel(ctrl, lcdif->base + LCDC_V8_CTRLDESCL0_3);
}
diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h b/drivers/gpu/drm/mxsfb/lcdif_regs.h
index c55dfb236c1d..17882c593d27 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_regs.h
+++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h
@@ -190,6 +190,7 @@
#define CTRLDESCL0_1_WIDTH(n) ((n) & 0xffff)
#define CTRLDESCL0_1_WIDTH_MASK GENMASK(15, 0)
+#define CTRLDESCL0_3_STATE_CLEAR_VSYNC BIT(23)
#define CTRLDESCL0_3_P_SIZE(n) (((n) << 20) & CTRLDESCL0_3_P_SIZE_MASK)
#define CTRLDESCL0_3_P_SIZE_MASK GENMASK(22, 20)
#define CTRLDESCL0_3_T_SIZE(n) (((n) << 16) & CTRLDESCL0_3_T_SIZE_MASK)
--
2.53.0
^ 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