* Re: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-26 19:40 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-2-sherry.sun@oss.nxp.com>
On Fri, Jun 26, 2026 at 10:31:19AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> suspend to preserve wakeup capability of the devices and also not to power
> on the devices in the init path.
Need empty line here.
> This allows controller power-off to be skipped when some devices(e.g. M.2
> cards key E without auxiliary power) required to support PCIe L2 link state
> and wake-up mechanisms.
>
> Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is only
> called once during probe, similar to other regulator_get calls.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 43 ++++++++++++++++-----------
> 1 file changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 0fa716d1ed75..0685573fee71 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1382,16 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> }
> }
>
> - ret = pci_pwrctrl_create_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to create pwrctrl devices\n");
> - goto err_reg_disable;
> - }
> -
Please two patch do that. one patch move pci_pwrctrl_create_devices() to
probe
one patch check skip_power_off.
> - ret = pci_pwrctrl_power_on_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to power on pwrctrl devices\n");
> - goto err_pwrctrl_destroy;
> + if (!pp->skip_pwrctrl_off) {
> + ret = pci_pwrctrl_power_on_devices(dev);
> + if (ret) {
> + dev_err(dev, "failed to power on pwrctrl devices\n");
> + goto err_reg_disable;
> + }
> }
>
> ret = imx_pcie_clk_enable(imx_pcie);
> @@ -1460,10 +1456,8 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> err_clk_disable:
> imx_pcie_clk_disable(imx_pcie);
> err_pwrctrl_power_off:
> - pci_pwrctrl_power_off_devices(dev);
> -err_pwrctrl_destroy:
> - if (ret != -EPROBE_DEFER)
> - pci_pwrctrl_destroy_devices(dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(dev);
> err_reg_disable:
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> @@ -1482,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
> }
> imx_pcie_clk_disable(imx_pcie);
>
> - pci_pwrctrl_power_off_devices(pci->dev);
> + if (!pci->pp.skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(pci->dev);
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> }
> @@ -1954,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1973,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1985,16 +1984,24 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
Mani said he will fix DEFER problem soon.
Frank
> }
>
> static void imx_pcie_shutdown(struct platform_device *pdev)
> {
> struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> + struct dw_pcie *pci = imx_pcie->pci;
> + struct dw_pcie_rp *pp = &pci->pp;
>
> /* bring down link, so bootloader gets clean state in case of reboot */
> imx_pcie_assert_core_reset(imx_pcie);
> imx_pcie_assert_perst(imx_pcie, true);
> - pci_pwrctrl_power_off_devices(&pdev->dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(&pdev->dev);
> pci_pwrctrl_destroy_devices(&pdev->dev);
> }
>
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH v4 2/2] tracing: Remove trace_printk.h from kernel.h
From: Nathan Chancellor @ 2026-06-26 19:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260626045119.659d1e6b@fedora>
On Fri, Jun 26, 2026 at 04:51:19AM -0400, Steven Rostedt wrote:
> On Thu, 25 Jun 2026 16:41:58 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
>
>
> > The following diff resolves it for me, should I send it as a separate
> > patch or do you want to just fold it in with a note?
> >
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index 621566345406..2301a701ffbb 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -10,6 +10,7 @@
> > #ifndef __LINUX_LOCKDEP_H
> > #define __LINUX_LOCKDEP_H
> >
> > +#include <linux/instruction_pointer.h>
>
> Ah, so the reason for this breakage is because lockdep was relying on
> instruction_pointer.h, that just happened to be included in kernel.h
> via trace_printk.h.
Correct.
> This is a separate issue, so it should be a separate patch. I'll add it
> as patch 1 of this series.
Sounds good, thanks!
> Can you send me the config you used. This didn't trigger in my tests.
It is a plain allmodconfig, for example on arm:
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- allmodconfig lib/test_context-analysis.o
In file included from include/linux/local_lock_internal.h:8,
from include/linux/local_lock.h:5,
from lib/test_context-analysis.c:9:
include/linux/local_lock_internal.h: In function 'local_lock_acquire':
include/linux/lockdep.h:541:87: error: '_THIS_IP_' undeclared (first use in this function)
541 | #define lock_map_acquire(l) lock_acquire_exclusive(l, 0, 0, NULL, _THIS_IP_)
| ^~~~~~~~~
include/linux/lockdep.h:509:88: note: in definition of macro 'lock_acquire_exclusive'
509 | #define lock_acquire_exclusive(l, s, t, n, i) lock_acquire(l, s, t, 0, 1, n, i)
| ^
include/linux/local_lock_internal.h:46:9: note: in expansion of macro 'lock_map_acquire'
46 | lock_map_acquire(&l->dep_map);
| ^~~~~~~~~~~~~~~~
include/linux/lockdep.h:541:87: note: each undeclared identifier is reported only once for each function it appears in
...
I also reproduced it on top of allnoconfig:
$ cat allno.config
CONFIG_CONTEXT_ANALYSIS_TEST=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_EXPERT=y
CONFIG_MMU=y
CONFIG_RUNTIME_TESTING_MENU=y
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=1 clean allnoconfig lib/test_context-analysis.o
<same error as above>
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v2] irqchip/gic-v3-its: Fix OF node reference leak
From: 최유호 @ 2026-06-26 18:37 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <867bnlqv0e.wl-maz@kernel.org>
Thanks for the review, Marc.
> Please keep this on a single line. I find nothing more irritating than
> these split assignments.
>
> Worth taking this opportunity to fix the indentation here.
I will fix the assignment formatting and indentation and send v3.
Thanks,
Yuho
^ permalink raw reply
* [PATCH 1/1] dt-bindings: mfd: st,stmpe: document st,stmpe610 compatible
From: Frank.Li @ 2026-06-26 18:31 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Linus Walleij,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
Cc: imx, Frank Li
From: Frank Li <Frank.Li@nxp.com>
The STMPE610 has long been supported by the STMPE I2C MFD driver, but its
compatible string was never documented.
Add the missing st,stmpe610 compatible string to fix below CHECK_DTBS
warnings:
imx53-m53evk.dtb: /soc/bus@60000000/i2c@63fc4000/touchscreen@41: failed to match any schema with compatible: ['st,stmpe610']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/mfd/st,stmpe.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
index 4bb05d544901c..70afdf68a0546 100644
--- a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
@@ -21,6 +21,7 @@ properties:
compatible:
enum:
- st,stmpe601
+ - st,stmpe610
- st,stmpe801
- st,stmpe811
- st,stmpe1600
--
2.43.0
^ permalink raw reply related
* [PATCH v2 03/17] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-26 18:00 UTC (permalink / raw)
To: Linus Torvalds, Greg Kroah-Hartman
Cc: Nicolas Frattaroli, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Heiko Stuebner, linux-rockchip, linux-sound,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1782490566.git.u.kleine-koenig@baylibre.com>
Currently that header is only included via:
<sound/dmaengine_pcm.h> ->
<sound/soc.h> ->
<linux/platform_device.h>
which doesn't look reliable, still more in the presence of the comment:
/* For the current users of sound/soc.h to avoid build issues */
in <sound/soc.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
sound/soc/rockchip/rockchip_sai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..37e81d56bc16 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/of_device.h>
#include <linux/clk.h>
+#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/reset.h>
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Chris Lu (陸稚泓) @ 2026-06-26 17:56 UTC (permalink / raw)
To: luiz.dentz@gmail.com, i@rong.moe
Cc: marcel@holtmann.org, AngeloGioacchino Del Regno,
SS Wu (巫憲欣), linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
patchwork-bot+bluetooth@kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <CABBYNZ+rR71SKUEuZBTf+E3SwRNzV2-s-zt8EwNJM3PSx9qB_A@mail.gmail.com>
Hi Rong and Luiz,
On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> Hi,
>
>
> On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> >
> > Hi Chris,
> >
> > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > <Chris.Lu@mediatek.com> 写道：
> > > Hi Luiz,
> > >
> > > Could we revert this change?
> >
> > Please don't. The fundamental goal of the patch is to make
> > MT7922/MT7925 *usable* on affected platforms.
> >
> > Moreover, almost all recent AMD platforms ship with MT7922/MT7925,
> > reverting this patch affects quite a lot of users. Almost every AMD
> > platform I've met suffers from the issue, and there are plenty of
> > bug reports.
> >
> > Intel platforms never ship with MTK WLAN NICs, so I can't tell if
> > the issue is reproducible on them.
>
We still have non-AMD platforms with MT7922/7925, where
"wakeup by Bluetooth" is an essential feature. In other word, this
change will have a serious impact to them.
> We cannot really remove it anymore, since it has already been pulled.
> Therefore, I strongly prefer that the issue is fixed somehow or if
> there is no other way then a proper revert patch must be sent, since
> I
> don't have any hardware with this controller I cannot really test
> this
> myself.
>
Got it.
> > >
> > > Sorry, MediaTek wasn't aware someone submitted this change and it
> > > had
> > > already been merged.
> > >
> > > MTK believes this issue is strongly related to the platform's USB
> > > hub
> > > behavior,
> >
> > Still, I believe that there are some interoperability issues in
> > MT7922/MT7925's hardware or firmware, as reinitializing the XHCI
> > root hub (by logically removing it from the PCI bus and probing it
> > again) doesn't make it recover at all.
> >
> > > The product lines MTK directly support haven't reported such
> > > issue.
> >
> > ...or did you mean none of the existing AMD platforms are supported
> > by MTK?
> >
I'll report it to corresponding department to see if they have such
issue. (I'm not from Bluetooth with AMD platform support team)
> > >
> > > Disable wake capability would severely impact wake on Bluetooth
> > > on
> > > MTK's official product lines.
> >
> > Could you kindly explain "MTK's official product lines"?
> >
Some products are module makers selling our modules to downstream
customers directly.
> > > Furthermore, this patch looks like a
> > > workaround. There should be a better way to handle this issue. We
> > > hope
> > > this change can be reverted.
> >
> > The issue is severe on affected platforms by making the Bluetooth
> > interface completely gone. IMHO, we must figure out the "better
> > way" before reverting it, or else it's more like burying your head
> > into sand by shouting "works fine on our platforms" (TM).
> >
> > That being said, I think we can narrow the range of the quirk down
> > to AMD platforms only. Does it make sense to you? If so, I will
> > submit a patch for this.
>
As I mentioned above, we have many platforms using the kernel driver,
not just AMD,
If this change can be limited to specific platform , it would be the
best way so far.
> Ok, then you guys please coordinate. I don't want to start requiring
> Sign-Off-By (SOB) from driver authors because this instance shows
> that
> response time can be very long. Therefore, the best way forward in my
> opinion, is to have the issue fixed in a way that works for both of
> you.
Of course, Mediatek BT team also agree that any issue need to be
resolved, However, original issue for this change requires further
verification of Hardware/firmware and even USB behavior. A device that
can reproduce the issue stably is required in order to experiment and
identify the root cause.
As mentioned, I'll deliver internally to relate support team. If they
have similar settings, MTK will attempt to reproduce it and provide an
official solution.
Thanks very much for your input and understanding.
Best Regards,
Chris Lu
^ permalink raw reply
* Re: [PATCH 5.15.y] selftests: arm64: signal: skip SVE VL change test with single VL
From: Sasha Levin @ 2026-06-26 17:54 UTC (permalink / raw)
To: stable, gregkh
Cc: Sasha Levin, shuah, linux-kernel, will, catalin.marinas, broonie,
linux-arm-kernel, linux-kselftest, cristian.marussi, Yijia Wang
In-Reply-To: <20260626-b4-arm64-515-preview-clean-v1-1-ad19e286e322@bytedance.com>
> [PATCH 5.15.y] selftests: arm64: signal: skip SVE VL change test with single VL
Can we keep the commit message the same as upstream? Is there a reason to
rewrite it?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] soc: imx8m: fix clock reference leak in imx8m_soc_prepare()
From: Frank Li @ 2026-06-26 16:17 UTC (permalink / raw)
To: Felix Gu
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Marco Felsch, Peng Fan, Shawn Guo, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260626-soc-imx8m-v1-1-62657e3376dc@gmail.com>
On Fri, Jun 26, 2026 at 10:37:35PM +0800, Felix Gu wrote:
> When clk_prepare_enable() fails, the error path does not release the
> clock reference obtained by of_clk_get_by_name(). Add clk_put() to
> the error path before iounmap().
>
> Fixes: 390c01073f5d ("soc: imx8m: Cleanup with adding imx8m_soc_[un]prepare")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
Thanks for your fix
> drivers/soc/imx/soc-imx8m.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
> index fc080e56f50d..de19972435f9 100644
> --- a/drivers/soc/imx/soc-imx8m.c
> +++ b/drivers/soc/imx/soc-imx8m.c
> @@ -150,10 +150,12 @@ static int imx8m_soc_prepare(struct platform_device *pdev, const char *ocotp_com
>
> ret = clk_prepare_enable(drvdata->clk);
> if (ret)
> - goto err_clk;
> + goto put_clk;
imx8m_soc_prepare() call be from probe(), can your use
devm_clk_get_enabled() to combine clk get and enable together.
And use new patch change ioremap() to devm_ioremap().
Frank
>
> return 0;
>
> +put_clk:
> + clk_put(drvdata->clk);
> err_clk:
> iounmap(drvdata->ocotp_base);
> return ret;
>
> ---
> base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
> change-id: 20260626-soc-imx8m-938e89104044
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
>
^ permalink raw reply
* Re: [PATCH v4 3/4] drivers/firmware: add SDEI cross-CPU NMI service for arm64
From: Catalin Marinas @ 2026-06-26 17:11 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <ab745689c0bfd01438d98ed1c79328bf2121be3b.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:04PM +0100, Kiryl Shutsemau wrote:
> +/*
> + * Raise callback for nmi_trigger_cpumask_backtrace(): signal event 0
> + * at every CPU still pending in @mask. The framework excludes the local
> + * CPU from @mask before calling us.
> + */
> +static void sdei_nmi_raise_backtrace(cpumask_t *mask)
> +{
> + unsigned int cpu;
> +
> + for_each_cpu(cpu, mask)
> + sdei_nmi_fire(cpu);
> +}
Does this need a barrier as in patch 4? Sashiko spotted that
backtrace_mask won't be visible without a dsb(ishst). Again, as per my
comment in patch 4, we get away with this because of the TF-A
implementation but that's not guaranteed (we could ask for the SDEI spec
to be updated assuming all firmware implementations do this).
--
Catalin
^ permalink raw reply
* Re: [PATCH v5 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-06-26 17:34 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam, Vincent Mailhol
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
On 6/9/2026 5:29 PM, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Hello Marc,
I just want to ping for the status of this series.
Please let me know if you expect any more changes.
Best Regards,
Ciprian
>
> This patch series adds FlexCAN support for the NXP S32N79 SoC.
>
> The S32N79 is an automotive-grade processor from NXP with multiple
> FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
> other SoCs in the interrupt routing - it uses two separate interrupt
> lines:
> - one interrupt for mailboxes 0-127
> - one interrupt for bus error detection and device state changes
>
> The CAN controllers are connected through an irqsteer interrupt
> controller in the RCU (Resource Control Unit) domain.
>
> This series:
> 1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
> 2. Adds dt-bindings documentation for S32N79 FlexCAN
> 3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
> configuration
> 4. Adds S32N79 device data and compatible string to the driver
> 5. Adds FlexCAN device tree nodes for S32N79 SoC
> 6. Enables FlexCAN devices on the S32N79-RDB board
>
> Tested on S32N79-RDB board with CAN and CAN FD communication.
>
> v5 -> v4
> - Simplified splitting rx/tx masks per mailbox IRQ line
>
> v4 -> v3
> - flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
> (not just dev->irq) during IMASK register writes
> - Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
> each handler on S32G2 only processes its own MB range
> - Added received Acked-by tag on DT bindings patch
>
> v3 -> v2
> - Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
> flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
> processing when multiple IRQ lines run concurrently (new patch).
> - Added flexcan_irq_esr() handler composing state + berr for S32N79
> - Ordered quirks used by s32n devtype data by value.
>
> v2 -> v1
> - Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
> describe the actual hardware feature
> - Appended new quirk at the end
> - Switched from platform_get_irq to platform_get_irq_byname usage
> - Updated interrupt description in dt-bindings
>
> Ciprian Marian Costea (8):
> can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
> can: flexcan: disable all IRQ lines in
> flexcan_chip_interrupts_enable()
> can: flexcan: split rx/tx masks per mailbox IRQ line
> dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
> can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
> can: flexcan: add NXP S32N79 SoC support
> arm64: dts: s32n79: add FlexCAN nodes
> arm64: dts: s32n79: enable FlexCAN devices
>
> .../bindings/net/can/fsl,flexcan.yaml | 30 ++-
> arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
> arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
> drivers/net/can/flexcan/flexcan-core.c | 227 +++++++++++++++---
> drivers/net/can/flexcan/flexcan.h | 2 +
> 5 files changed, 292 insertions(+), 29 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] media: meson: vdec: fix use-after-free of prev_frame in codec_vp9_rm_noshow_frame()
From: Dan Carpenter @ 2026-06-26 17:29 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: Neil Armstrong, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Hans Verkuil, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-media, linux-amlogic, linux-staging, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260626164025.52694-1-doruk@0sec.ai>
On Fri, Jun 26, 2026 at 06:40:25PM +0200, Doruk Tan Ozturk wrote:
> codec_vp9_rm_noshow_frame() frees the first non-shown reference frame on
> ref_frames_list without excluding vp9->prev_frame. When the previously
> decoded frame was a non-show (alt-ref) frame and the current frame is a
> non-show inter frame, the freed object is the one vp9->prev_frame still
> points to; codec_vp9_set_mpred_mv() then dereferences the stale pointer
> (use_prev_frame_mvs and codec_vp9_get_frame_mv_paddr()), a use-after-free.
>
> The sibling cleanup codec_vp9_show_frame() already guards this pointer
> (tmp == vp9->prev_frame); rm_noshow_frame() simply omits the same check.
> Add it.
>
> The fields that drive this path (show_frame, frame_type, intra_only) are
> parsed from the VP9 bitstream, so a crafted stream fed to the stateless
> decoder can trigger the free-then-use.
>
> Found by static analysis; not yet runtime-reproduced (Amlogic Meson
> hardware required).
>
> Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
>
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> ---
> drivers/staging/media/meson/vdec/codec_vp9.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
> index 8e80ecf84..572f418c9 100644
> --- a/drivers/staging/media/meson/vdec/codec_vp9.c
> +++ b/drivers/staging/media/meson/vdec/codec_vp9.c
> @@ -1247,6 +1247,15 @@ static void codec_vp9_rm_noshow_frame(struct amvdec_session *sess)
> if (tmp->show)
> continue;
>
> + /*
> + * prev_frame is still referenced by the MV predictor in
> + * codec_vp9_set_mpred_mv(); the sibling codec_vp9_show_frame()
> + * already excludes it before freeing. Do the same here to avoid
> + * a use-after-free of vp9->prev_frame.
> + */
> + if (tmp == vp9->prev_frame)
> + continue;
I have not looked at this code before so I'm speaking from a position
of ignorance but codec_vp9_show_frame() checks vp9->cur_frame as well.
Shouldn't we check that here as well?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] fpga: xilinx-pr-decoupler: Use devm_clk_get_prepared()
From: Xu Yilun @ 2026-06-26 17:22 UTC (permalink / raw)
To: Pandey, Radhey Shyam
Cc: Michal Simek, linux-kernel, monstr, git, Moritz Fischer, Tom Rix,
Xu Yilun, moderated list:ARM/ZYNQ ARCHITECTURE,
open list:FPGA MANAGER FRAMEWORK
In-Reply-To: <5bd0f7db-7ec0-4390-b6ea-1edca46e1ca7@amd.com>
On Tue, Jun 23, 2026 at 04:31:28PM +0530, Pandey, Radhey Shyam wrote:
> > The driver keeps the "aclk" clock prepared but disabled in its idle
> > state, toggling only the atomic clk_enable()/clk_disable() around
> > register accesses in the bridge enable_set/enable_show callbacks.
> >
> > At probe time this was open-coded as clk_prepare_enable() immediately
> > followed by clk_disable(), leaving the clock prepared, with a matching
> > clk_unprepare() in the error path and in remove().
> >
> > devm_clk_get_prepared() expresses exactly this: it gets and prepares the
> > clock and unprepares it automatically on driver detach.
> >
> > Use it to drop the manual prepare/disable dance, the error-path
> > unprepare, and the now-empty clock teardown in remove().
> >
> > Signed-off-by: Michal Simek <michal.simek@amd.com>
>
> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Xu Yilun <yilun.xu@intel.com>
Will apply to for-next when 7.2-rc1 comes.
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Nathan Morrisson @ 2026-06-26 16:10 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: afd, sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream
In-Reply-To: <20260626161014.1146128-1-nmorrisson@phytec.com>
Add support for the PHYTEC phyCORE-AM67x SoM [1] and the
corresponding phyBOARD-Rigel carrier board [2]. The phyCORE-AM67x SoM
uses the TI AM67x SoC and can come with different sizes and models of
DDR, eMMC, and SPI NOR Flash.
Supported features:
* Audio playback and recording
* CAN
* Debug UART
* eMMC
* Ethernet
* GPIO buttons
* Heartbeat LED
* I2C Current sensor
* I2C EEPROM
* I2C Light sensor
* I2C RTC
* Micro SD card
* PCIe
* SPI NOR flash
* USB
[1] https://www.phytec.com/product/phycore-am67x/
[2] https://www.phytec.com/product/phyboard-am67x-development-kit/
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
---
Changes in v2:
* Move k3-j722s.dtsi include from the phyboard to phycore dts
* Remove cpsw_port2 node because it was already disabled
* Remove mcasp1 because it is used by HDMI, and HDMI is not included in this dts
* Fix typo in audio codec properties ai3xx-micbias-vg -> ai31xx-micbias-vg
* Use IRQ_TYPE_EDGE_FALLING instead of IRQ_TYPE_LEVEL_LOW for gpio expanders
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am67-phycore-som.dtsi | 325 ++++++++++++
.../boot/dts/ti/k3-am6754-phyboard-rigel.dts | 478 ++++++++++++++++++
3 files changed, 804 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 371f9a043fe5..623ee2369132 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
+dtb-$(CONFIG_ARCH_K3) += k3-am6754-phyboard-rigel.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
diff --git a/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
new file mode 100644
index 000000000000..1bbd6d024c60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 PHYTEC America LLC
+ * Author: Nathan Morrisson <nmorrisson@phytec.com>
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "k3-j722s.dtsi"
+
+/ {
+ compatible = "phytec,am67-phycore-som", "ti,j722s";
+ model = "PHYTEC phyCORE-AM67";
+
+ aliases {
+ ethernet0 = &cpsw_port1;
+ gpio0 = &main_gpio0;
+ mmc0 = &sdhci0;
+ rtc0 = &i2c_som_rtc;
+ rtc1 = &wkup_rtc0;
+ spi0 = &ospi0;
+ };
+
+ memory@80000000 {
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ device_type = "memory";
+ bootph-all;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_tfa_ddr: tfa@9e780000 {
+ reg = <0x00 0x9e780000 0x00 0x80000>;
+ no-map;
+ };
+
+ secure_ddr: optee@9e800000 {
+ reg = <0x00 0x9e800000 0x00 0x01800000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dma_memory_region: memory@a0000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0000000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_memory_region: memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0100000 0x00 0xf00000>;
+ no-map;
+ };
+ };
+
+ vcc_5v0_som: regulator-vcc-5v0-som {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V0_SOM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ led-0 {
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&main_gpio0 13 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ function = LED_FUNCTION_HEARTBEAT;
+ };
+ };
+};
+
+&main_pmx0 {
+ leds_pins_default: leds-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x034, PIN_OUTPUT, 7) /* (K22) OSPI0_CSN2.GPIO0_13 */
+ >;
+ };
+
+ mdio_pins_default: mdio-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
+ J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
+ >;
+ bootph-all;
+ };
+
+ ospi0_pins_default: ospi0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
+ J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
+ J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
+ J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
+ J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
+ J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
+ J722S_IOPAD(0x01c, PIN_INPUT, 0) /* (L21) OSPI0_D4 */
+ J722S_IOPAD(0x020, PIN_INPUT, 0) /* (M26) OSPI0_D5 */
+ J722S_IOPAD(0x024, PIN_INPUT, 0) /* (N27) OSPI0_D6 */
+ J722S_IOPAD(0x028, PIN_INPUT, 0) /* (M27) OSPI0_D7 */
+ J722S_IOPAD(0x008, PIN_INPUT, 0) /* (L22) OSPI0_DQS */
+ J722S_IOPAD(0x038, PIN_INPUT, 7) /* (J22) OSPI0_CSn3.GPIO0_14 */
+ >;
+ bootph-all;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x030, PIN_INPUT, 7) /* (K23) OSPI0_CSN1.GPIO0_12 */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
+ J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
+ J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
+ J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
+ J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
+ J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
+ J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
+ J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
+ J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
+ J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
+ J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
+ J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
+ >;
+ bootph-all;
+ };
+};
+
+&mcu_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (B9) WKUP_I2C0_SCL */
+ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (D11) WKUP_I2C0_SDA */
+ >;
+ bootph-all;
+ };
+};
+
+&cpsw3g {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&cpsw3g_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins_default>;
+ status = "okay";
+
+ cpsw3g_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,min-output-impedance;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-id";
+ phy-handle = <&cpsw3g_phy1>;
+ status = "okay";
+};
+
+&ospi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ospi0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ serial_flash: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <25000000>;
+ vcc-supply = <&vdd_1v8>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <0>;
+ };
+};
+
+&sdhci0 {
+ non-removable;
+ bootph-all;
+ ti,driver-strength-ohm = <50>;
+ status = "okay";
+};
+
+&wkup_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ bootph-all;
+ status = "okay";
+
+ pmic@30 {
+ compatible = "ti,tps65219";
+ reg = <0x30>;
+ buck1-supply = <&vcc_5v0_som>;
+ buck2-supply = <&vcc_5v0_som>;
+ buck3-supply = <&vcc_5v0_som>;
+ ldo1-supply = <&vdd_3v3>;
+ ldo2-supply = <&vdd_1v8>;
+ ldo3-supply = <&vdd_3v3>;
+ ldo4-supply = <&vdd_3v3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ system-power-controller;
+ ti,power-button;
+
+ regulators {
+ vdd_3v3: buck1 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v8: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_lpddr4: buck3 {
+ regulator-name = "VDD_LPDDR4";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vddshv_sdio: ldo1 {
+ regulator-name = "VDDSHV_SDIO";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allow-bypass;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v2: ldo2 {
+ regulator-name = "VDD_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdda_1v8_phy: ldo3 {
+ regulator-name = "VDDA_1V8_PHY";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v8_pll: ldo4 {
+ regulator-name = "VDD_1V8_PLL";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+
+ vdd_core: regulator-vdd-core@44 {
+ compatible = "ti,tps62873";
+ reg = <0x44>;
+ bootph-pre-ram;
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ som_eeprom_opt: eeprom@51 {
+ compatible = "atmel,24c32";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+
+ i2c_som_rtc: rtc@52 {
+ compatible = "microcrystal,rv3028";
+ reg = <0x52>;
+ };
+};
+
+#include "k3-j722s-ti-ipc-firmware.dtsi"
diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
new file mode 100644
index 000000000000..e6e74910e0bb
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
@@ -0,0 +1,478 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 PHYTEC America LLC
+ * Author: Nathan Morrisson <nmorrisson@phytec.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "k3-serdes.h"
+#include "k3-am67-phycore-som.dtsi"
+
+/ {
+ compatible = "phytec,am6754-phyboard-rigel",
+ "phytec,am67-phycore-som", "ti,j722s";
+ model = "PHYTEC phyBOARD-Rigel AM67";
+
+ aliases {
+ gpio1 = &main_gpio1;
+ mmc1 = &sdhci1;
+ serial2 = &main_uart0;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ };
+
+ can_tc0: can-phy0 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <8000000>;
+ standby-gpios = <&gpio_exp1 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb0_connector: connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ label = "USB-C";
+ data-role = "dual";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_usbc_power_pins_default>;
+
+ id-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
+
+ port {
+ usb0_con: endpoint {
+ remote-endpoint = <&usb0_ep>;
+ };
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pins_default>;
+
+ key-home {
+ label = "home";
+ linux,code = <KEY_HOME>;
+ gpios = <&main_gpio1 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ key-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ pcie_refclk0: pcie-refclk0 {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_pcie_usb_sel_pins_default>;
+ clocks = <&serdes_refclk>;
+ #clock-cells = <0>;
+ enable-gpios = <&main_gpio0 22 GPIO_ACTIVE_LOW>;
+ };
+
+ vcc_1v8: regulator-vcc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_aud: regulator-vcc-3v3-aud {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_AUD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_mmc: regulator-vcc-3v3-mmc {
+ /* TPS22963C OUTPUT */
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_MMC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_sw: regulator-vcc-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_SW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_speaker: regulator-vcc-speaker {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_SPEAKER";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Stereo Jack",
+ "Speaker", "L SPKR",
+ "Speaker", "R SPKR";
+ simple-audio-card,routing =
+ "MIC1RP", "Mic Jack",
+ "Mic Jack", "MICBIAS",
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "MIC1LM", "Stereo Jack",
+ "MIC1LP", "Stereo Jack",
+ "SPL", "L SPKR",
+ "SPR", "R SPKR";
+ simple-audio-card,name = "phyBOARD-Rigel";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp0>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&audio_codec>;
+ clocks = <&audio_refclk1>;
+ };
+ };
+};
+
+&main_pmx0 {
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (N24) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+
+ gpio_exp0_int_pins_default: gpio-exp0-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0054, PIN_INPUT, 7) /* (T21) GPMC0_AD6.GPIO0_21 */
+ >;
+ };
+
+ gpio_exp1_int_pins_default: gpio-exp1-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0244, PIN_INPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
+ >;
+ };
+
+ gpio_exp2_int_pins_default: gpio-exp2-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0050, PIN_INPUT, 7) /* (T24) GPMC0_AD5.GPIO0_20 */
+ >;
+ };
+
+ gpio_keys_pins_default: gpio-keys-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01d4, PIN_INPUT, 7) /* (B21) UART0_RTSn.GPIO1_23 */
+ >;
+ };
+
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
+ J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_i2c1_pins_default: main-i2c1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
+ J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_mcan0_pins_default: main-mcan0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1dc, PIN_INPUT, 0) /* (C22) MCAN0_RX */
+ J722S_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (D22) MCAN0_TX */
+ >;
+ };
+
+ main_mcasp0_pins_default: main-mcasp0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1a8, PIN_INPUT, 0) /* (C26) MCASP0_AFSX */
+ J722S_IOPAD(0x1a4, PIN_INPUT, 0) /* (D25) MCASP0_ACLKX */
+ J722S_IOPAD(0x198, PIN_OUTPUT, 0) /* (A26) MCASP0_AXR2 */
+ J722S_IOPAD(0x194, PIN_INPUT, 0) /* (A25) MCASP0_AXR3 */
+ >;
+ };
+
+ main_mmc1_pins_default: main-mmc1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
+ J722S_IOPAD(0x0234, PIN_INPUT, 0) /* (H24) MMC1_CLK */
+ J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
+ J722S_IOPAD(0x022c, PIN_INPUT, 0) /* (H20) MMC1_DAT1 */
+ J722S_IOPAD(0x0228, PIN_INPUT, 0) /* (J23) MMC1_DAT2 */
+ J722S_IOPAD(0x0224, PIN_INPUT, 0) /* (H25) MMC1_DAT3 */
+ J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
+ >;
+ bootph-all;
+ };
+
+ main_pcie_pins_default: main-pcie-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x07c, PIN_INPUT, 7) /* (T23) GPMC0_CLK.GPIO0_31 */
+ >;
+ };
+
+ main_pcie_usb_sel_pins_default: main-pcie-usb-sel-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x058, PIN_INPUT, 7) /* (T22) GPMC0_AD7.GPIO0_22 */
+ >;
+ };
+
+ main_uart0_pins_default: main-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (F19) UART0_RXD */
+ J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (F20) UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ main_usbc_power_pins_default: main-usbc-power-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1b4, PIN_INPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
+ >;
+ };
+};
+
+&audio_refclk1 {
+ assigned-clock-rates = <25000000>;
+};
+
+&main_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ veml6030: light-sensor@10 {
+ compatible = "vishay,veml6030";
+ reg = <0x10>;
+ vdd-supply = <&vcc_3v3_sw>;
+ };
+};
+
+&main_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ audio_codec: audio-codec@18 {
+ compatible = "ti,tlv320aic3110";
+ reg = <0x18>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+ #sound-dai-cells = <0>;
+ ai31xx-micbias-vg = <2>;
+ reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
+
+ HPVDD-supply = <&vcc_3v3_aud>;
+ SPRVDD-supply = <&vcc_speaker>;
+ SPLVDD-supply = <&vcc_speaker>;
+ AVDD-supply = <&vcc_3v3_aud>;
+ IOVDD-supply = <&vcc_3v3_aud>;
+ DVDD-supply = <&vcc_1v8>;
+ };
+
+ gpio_exp0: gpio@20 {
+ compatible = "nxp,pcf8574";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp0_int_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
+ "CSI3_SHUTTER", "CSI3_OE",
+ "CSI2_STROBE", "CSI2_TRIGGER",
+ "CSI2_SHUTTER", "CSI2_OE";
+ };
+
+ gpio_exp1: gpio@21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp1_int_pins_default>;
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN_nEN",
+ "GPIO2_LED", "GPIO3_MCU_CAN0_nEN",
+ "GPIO4_BUT2", "GPIO5_MCU_CAN1_nEN",
+ "GPIO6_AUDIO_GPIO", "GPIO7_AUDIO_USER_RESET";
+ };
+
+ gpio_exp2: gpio@23 {
+ compatible = "nxp,pcf8574";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp2_int_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "CSI1_STROBE", "CSI1_TRIGGER",
+ "CSI1_SHUTTER", "CSI1_OE",
+ "CSI0_STROBE", "CSI0_TRIGGER",
+ "CSI0_SHUTTER", "CSI0_OE";
+ };
+
+ current-sensor@40 {
+ compatible = "ti,ina233";
+ reg = <0x40>;
+ shunt-resistor = <18000>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ pagesize = <16>;
+ };
+};
+
+&main_mcan0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan0_pins_default>;
+ phys = <&can_tc0>;
+ status = "okay";
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&mcasp0 {
+ #sound-dai-cells = <0>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp0_pins_default>;
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ status = "okay";
+};
+
+&pcie0_rc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_pcie_pins_default>;
+ num-lanes = <1>;
+ phys = <&serdes1_pcie_link>;
+ phy-names = "pcie-phy";
+ reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vcc_3v3_mmc>;
+ vqmmc-supply = <&vddshv_sdio>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ disable-wp;
+ no-1-8-v;
+ bootph-all;
+ status = "okay";
+};
+
+&serdes_ln_ctrl {
+ idle-states = <J722S_SERDES0_LANE0_USB>,
+ <J722S_SERDES1_LANE0_PCIE0_LANE0>;
+};
+
+&serdes0 {
+ status = "okay";
+
+ serdes0_usb_link: phy@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_USB3>;
+ resets = <&serdes_wiz0 1>;
+ };
+};
+
+&serdes_wiz0 {
+ status = "okay";
+};
+
+&serdes1 {
+ status = "okay";
+
+ serdes1_pcie_link: phy@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_PCIE>;
+ resets = <&serdes_wiz1 1>;
+ };
+};
+
+&serdes_wiz1 {
+ clocks = <&k3_clks 280 0>, <&k3_clks 280 1>, <&pcie_refclk0>;
+ status = "okay";
+};
+
+&usbss0 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb0 {
+ dr_mode = "otg";
+ usb-role-switch;
+ maximum-speed = "high-speed";
+
+ port {
+ usb0_ep: endpoint {
+ remote-endpoint = <&usb0_con>;
+ };
+ };
+};
+
+&usbss1 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ phys = <&serdes0_usb_link>;
+ phy-names = "cdns3,usb3-phy";
+ maximum-speed = "super-speed";
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 4/4] arm64: escalate smp_send_stop() to an SDEI NMI as a last resort
From: Catalin Marinas @ 2026-06-26 17:08 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <97a870d0670b7e1c2fb9f5142f6e36c594282017.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:05PM +0100, Kiryl Shutsemau wrote:
> +void sdei_nmi_stop_cpus(const cpumask_t *mask)
> +{
> + unsigned int cpu;
> +
> + WRITE_ONCE(sdei_nmi_stopping, true);
> +
> + /*
> + * Publish the flag before signalling. The SMC is a context-sync
> + * event, not a barrier, so WRITE_ONCE() alone could let the store be
> + * observed after the event it triggers. The barrier is cumulative: a
> + * target that sees the event is guaranteed to see the flag.
> + */
> + smp_wmb();
> +
> + for_each_cpu(cpu, mask)
> + sdei_nmi_fire(cpu);
> +}
The smp_wmb() is not sufficient here. In the GIC IPI code we use a
dsb(ishst). It should be similar here. I think TF-A does this already
but it's unclear from the SDEI spec that it is mandated.
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Catalin Marinas @ 2026-06-26 17:07 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <cover.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:01PM +0100, Kiryl Shutsemau wrote:
> - A CPU stopped by the SDEI rung is parked, not powered off via PSCI
> CPU_OFF. Reaching and dumping the wedged CPU -- the point of the
> series -- works, and it matches the shared stop path's own park
> fallback when CPU_OFF is unavailable. The consequence is that an SMP
> crash-capture kernel cannot re-online such a CPU (it stays "already
> on"); the capture kernel boots and runs on the remaining CPUs.
> Powering the stopped CPU off so a capture kernel can reclaim it
> requires completing the SDEI event and then CPU_OFF, which hit a
> firmware-specific issue still under investigation; it is left as a
> follow-up and does not affect the dump's contents.
Just to understand, your firmware cannot cope with a PSCI CPU_OFF from
the SDEI handler? This is one of the required calls to be supported.
--
Catalin
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-06-26 17:09 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Andrea della Porta, Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
mbrugger, Krzysztof Kozlowski
In-Reply-To: <5b167316-ed50-448c-aa05-6a041a6544d5@suse.de>
Hi Stan,
On 18:24 Fri 12 Jun , Stanimir Varbanov wrote:
>
>
> On 6/12/26 5:01 PM, Andrea della Porta wrote:
> > From: Naushir Patuck <naush@raspberrypi.com>
> >
> > Add the devicetree binding documentation for the PWM
> > controller found in the Raspberry Pi RP1 chipset.
> >
> > Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> > Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> > Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > .../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> > new file mode 100644
> > index 0000000000000..6f8461d0454f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> > @@ -0,0 +1,54 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/raspberrypi,rp1-pwm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Raspberry Pi RP1 PWM controller
> > +
> > +maintainers:
> > + - Naushir Patuck <naush@raspberrypi.com>
>
> Could you add you or me as a maintainer as well. I'm not sure Naushir
> had agreed to maintain the bindings in mainline.
>
Sure, will do.
Thanks,
Andrea
> ~Stan
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 16:58 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626143310.GF2363897@killaraus.ideasonboard.com>
Quoting Laurent Pinchart (2026-06-26 15:33:10)
> On Fri, Jun 26, 2026 at 01:07:56PM +0100, Kieran Bingham wrote:
> > The orientation property for video interface devices now has definitions
> > to prevent hardcoded integer values for the enum options.
> >
> > Update the users throughout the nvidia device trees to use the new
> > definitions.
> >
> > Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> > ---
> > arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
> > arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
> > arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
> > arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
> > 4 files changed, 9 insertions(+), 4 deletions(-)
> >
<snip>
> > diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > index 60e8a19aa70e..c58e3026a115 100644
> > --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > @@ -4,6 +4,7 @@
> > #include <dt-bindings/input/input.h>
> > #include <dt-bindings/leds/common.h>
> > #include <dt-bindings/media/video-interfaces.h>
> > +#include <dt-bindings/media/video-interface-devices.h>
> > #include <dt-bindings/mfd/max77620.h>
> > #include <dt-bindings/thermal/thermal.h>
> >
> > @@ -1216,7 +1217,7 @@ rear-camera@10 {
> > dvdd-supply = <&vdd_1v2_rear>;
> > avdd-supply = <&vdd_2v7_rear>;
> >
> > - orientation = <1>; /* Rear camera */
> > + orientation = <MEDIA_ORIENTATION_REAR>;
>
It must have been hot when I typed that one out...
> This should be MEDIA_ORIENTATION_BACK. And you should compile all the
> device trees the series touch.
Indeed, I got caught out by these being in arm, with the others in arm64
even though I explicitly pulled these out to a separate patch!
Fixed up and now I have compiled also with:
make O=arm32 ARCH=arm multi_v7_defconfig
make O=arm32 ARCH=arm dtbs -j32
which looks clean.
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks
Kieran
>
> > rotation = <90>;
> >
> > nvmem = <&m24c08>;
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Luiz Augusto von Dentz @ 2026-06-26 16:54 UTC (permalink / raw)
To: Rong Zhang
Cc: Chris Lu (陸稚泓),
patchwork-bot+bluetooth@kernel.org, marcel@holtmann.org,
AngeloGioacchino Del Regno, SS Wu (巫憲欣),
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <17FE08E9-2229-4C97-846F-6FA099E22C90@rong.moe>
Hi,
On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
>
> Hi Chris,
>
> 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com> 写道：
> >Hi Luiz,
> >
> >Could we revert this change?
>
> Please don't. The fundamental goal of the patch is to make MT7922/MT7925 *usable* on affected platforms.
>
> Moreover, almost all recent AMD platforms ship with MT7922/MT7925, reverting this patch affects quite a lot of users. Almost every AMD platform I've met suffers from the issue, and there are plenty of bug reports.
>
> Intel platforms never ship with MTK WLAN NICs, so I can't tell if the issue is reproducible on them.
We cannot really remove it anymore, since it has already been pulled.
Therefore, I strongly prefer that the issue is fixed somehow or if
there is no other way then a proper revert patch must be sent, since I
don't have any hardware with this controller I cannot really test this
myself.
> >
> >Sorry, MediaTek wasn't aware someone submitted this change and it had
> >already been merged.
> >
> >MTK believes this issue is strongly related to the platform's USB hub
> >behavior,
>
> Still, I believe that there are some interoperability issues in MT7922/MT7925's hardware or firmware, as reinitializing the XHCI root hub (by logically removing it from the PCI bus and probing it again) doesn't make it recover at all.
>
> > The product lines MTK directly support haven't reported such
> >issue.
>
> ...or did you mean none of the existing AMD platforms are supported by MTK?
>
> >
> >Disable wake capability would severely impact wake on Bluetooth on
> >MTK's official product lines.
>
> Could you kindly explain "MTK's official product lines"?
>
> > Furthermore, this patch looks like a
> >workaround. There should be a better way to handle this issue. We hope
> >this change can be reverted.
>
> The issue is severe on affected platforms by making the Bluetooth interface completely gone. IMHO, we must figure out the "better way" before reverting it, or else it's more like burying your head into sand by shouting "works fine on our platforms" (TM).
>
> That being said, I think we can narrow the range of the quirk down to AMD platforms only. Does it make sense to you? If so, I will submit a patch for this.
Ok, then you guys please coordinate. I don't want to start requiring
Sign-Off-By (SOB) from driver authors because this instance shows that
response time can be very long. Therefore, the best way forward in my
opinion, is to have the issue fixed in a way that works for both of
you.
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Luca Ceresoli @ 2026-06-26 16:51 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260626-classy-nightingale-of-romance-1cacad@houat>
On Fri Jun 26, 2026 at 4:38 PM CEST, Maxime Ripard wrote:
> On Fri, Jun 26, 2026 at 04:16:39PM +0200, Luca Ceresoli wrote:
>> Hi Maxime,
>>
>> On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
>> > On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
>> >> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
>> >> > Hi,x
>> >> >
>> >> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
>> >> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
>> >> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
>> >> >> >> In preparation to introduce bridge hotplug, split out from
>> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
>> >> >> >> dedicated function. This will be needed to be able to add (and re-add) the
>> >> >> >> connector from different code paths.
>> >> >> >
>> >> >> > Same story here, explaining what you need later on that calls for that
>> >> >> > change would be nice.
>> >> >>
>> >> >> Here's a more verbose version:
>> >> >>
>> >> >> Currently drm_bridge_connector_init() does two things:
>> >> >>
>> >> >> * allocate and initialize the drm_bridge_connector
>> >> >> (which embeds a drm_connector)
>> >> >> * initialize and register the embedded drm_connector
>> >> >>
>> >> >> For bridge hotplug we need to separate these two actions:
>> >> >>
>> >> >> * the drm_connector needs to be added and removed at any time based on
>> >> >> hotplug events
>> >> >> * the drm_bridge_connector is designated to create and remove the
>> >> >> drm_connector, so it must be persistent for the card lifetime
>> >> >>
>> >> >> As the lifetimes of drm_bridge_connector and drm_connector become
>> >> >> different, we need to create them in different moments.
>> >> >>
>> >> >> In preparation to support that, split out from
>> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
>> >> >> dedicated function. No functional changes, just moving code around for
>> >> >> now. A future commit will make the drm_connector be created based on
>> >> >> hotplug events.
>> >> >>
>> >> >> Looks good?
>> >> >
>> >> > The message itself, yes, thanks.
>> >> >
>> >> > However, I have questions now :)
>> >> >
>> >> > Do we really expect drm_bridge_connector to stick around when a bridge
>> >> > gets unplugged? If so, how does it cope with having, say, an HDMI
>> >> > connector, and then swapping out the hotplugged part for an LVDS one?
>> >> > Does the HDMI connector sticks around indefinitely?
>> >>
>> >> In your example, the HDMI drm_connector would be unregistered and put on
>> >> hotunplug. Its allocation will stick around until the last put but that's
>> >> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
>> >> drm_connector will be created and registered.
>> >>
>> >> > *Especially* if we're using overlays for this, I'd expect everything
>> >> > after the first hotplugged bridge to be destroyed, no?
>> >>
>> >> As said, it would be unregistered immediately but might be freed later on
>> >> if still refcounted.
>> >>
>> >> This is visible in patches 36+15, the path to follow is:
>> >>
>> >> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
>> >> -> drm_bridge_connector_dynconn_release() [patch 15]
>> >>
>> >> Does this solve your concern?
>> >
>> > Not really, I'm talking about drm_bridge_connector. The fact that
>> > bridges are destroyed make sense to me. The fact that
>> > drm_bridge_connector sticks around doesn't. It's supposed to be a
>> > connector for bridges. If you don't have bridges because they got
>> > destroyed, and connector, drm_bridge_connector doesn't have a reason to
>> > exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
>>
>> It is not a hotplug-bridge in a trench coat, no :) The code is clear about
>> this.
>>
>> I'd say with this series a "drm_bridge_connector" is just becoming
>> something more (perhaps something else too). Somewhat as "a drm_bridge is
>> either a bridge or something else". :)
>>
>>
>> But let's leave names aside for a moment. If just looking at the current
>> code, the drm_bridge_connector is "a handler, owned by the card/encoder and
>> having the same lifetime, which takes care of drm_connector
>> creation/destruction at card probe/removal".
>>
>> What we need now is just the same plug " and on hotplug events" appended.
>>
>> So in both cases there needs to be "a handler persitent with the card".
>>
>> Do we agree so far?
>
> Ish. If we go for that, then we need to update the name.
drm_connector_manager?
drm_bridge_connector_manager?
> drm_bridge_connector for something that is neither a bridge or a
> connector is not great.
>
> But even then, I'm not even sure why we need to have that "manager" in
> the first place. You want to make bridges be aware if they are the last
> in the chain or not. Use that property in attach to either create a
> drm_bridge_connector instance if you're last, or attach the next bridge
> if you aren't.
What? o_O
Several encoder drivers have been painfully converted to create a
drm_bridge_connector. Now if the bridges start doing it themselves we
should go back to those encoder drivers and ditch all the
drm_bridge_connector from there?
I must be missing something. Can you elaborate on this?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Frank Li @ 2026-06-26 16:47 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner, linux-kernel, linux-media, devicetree,
linux-tegra, linux, imx, linux-arm-kernel, linux-arm-msm,
linux-renesas-soc, linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-2-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:54PM +0100, Kieran Bingham wrote:
> Expand the documentation of the video-interface-devices orientation to
> reference the include/dt-bindings/media/video-interface-devices.h header
> which provides human readable defines for the orientation enum, to help
> avoid hardcoding values in dts.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> .../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> index a81d2a155fe6..c9c3f4f16719 100644
> --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -392,17 +392,22 @@ properties:
> The orientation of a device (typically an image sensor or a flash LED)
> describing its mounting position relative to the usage orientation of the
> system where the device is installed on.
> + See include/dt-bindings/media/video-interface-devices.h.
> +
> $ref: /schemas/types.yaml#/definitions/uint32
> enum:
> - # Front. The device is mounted on the front facing side of the system. For
> - # mobile devices such as smartphones, tablets and laptops the front side
> - # is the user facing side.
> + # MEDIA_ORIENTATION_FRONT
> + # The device is mounted on the front facing side of the system. For
> + # mobile devices such as smartphones, tablets and laptops the front
> + # side is the user facing side.
> - 0
> - # Back. The device is mounted on the back side of the system, which is
> + # MEDIA_ORIENTATION_BACK
> + # The device is mounted on the back side of the system, which is
> # defined as the opposite side of the front facing one.
> - 1
> - # External. The device is not attached directly to the system but is
> - # attached in a way that allows it to move freely.
> + # MEDIA_ORIENTATION_EXTERNAL
> + # The device is not attached directly to the system but is attached in
> + # a way that allows it to move freely.
> - 2
>
> additionalProperties: true
>
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Frank Li @ 2026-06-26 16:47 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner, linux-kernel, linux-media, devicetree,
linux-tegra, linux, imx, linux-arm-kernel, linux-arm-msm,
linux-renesas-soc, linux-rockchip, Conor Dooley
In-Reply-To: <20260626-kbingham-orientation-v2-1-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:53PM +0100, Kieran Bingham wrote:
> Add a new dt-bindings/media/video-interface-devices.h header that
> defines macros corresponding to the orientation enumeration types from
> media/video-interface-devices.yaml.
>
> This allows avoiding hardcoded constants in device tree sources.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/dt-bindings/media/video-interface-devices.h b/include/dt-bindings/media/video-interface-devices.h
> new file mode 100644
> index 000000000000..d2340b457292
> --- /dev/null
> +++ b/include/dt-bindings/media/video-interface-devices.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> +/*
> + * Copyright (C) 2026 Kieran Bingham <kieran.bingham@ideasonboard.com>
> + */
> +
> +#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +
> +#define MEDIA_ORIENTATION_FRONT 0
> +#define MEDIA_ORIENTATION_BACK 1
> +#define MEDIA_ORIENTATION_EXTERNAL 2
> +
> +#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__ */
>
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Lorenzo Pieralisi @ 2026-06-26 16:44 UTC (permalink / raw)
To: Gavin Shan
Cc: Suzuki K Poulose, Steven Price, kvm, kvmarm, Catalin Marinas,
Marc Zyngier, Will Deacon, James Morse, Oliver Upton, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <8f81ed99-c53a-4196-baa2-adea9239a000@redhat.com>
On Fri, Jun 26, 2026 at 09:43:03PM +1000, Gavin Shan wrote:
> On 6/26/26 6:47 PM, Suzuki K Poulose wrote:
> > On 26/06/2026 08:43, Gavin Shan wrote:
> > > On 6/26/26 1:58 AM, Suzuki K Poulose wrote:
> > > > On 25/06/2026 14:53, Gavin Shan wrote:
> > > > > On 6/6/26 12:35 AM, Lorenzo Pieralisi wrote:
> > > > > > On Fri, Jun 05, 2026 at 06:11:11PM +1000, Gavin Shan wrote:
> > > > > > > On 6/5/26 5:28 PM, Lorenzo Pieralisi wrote:
> > > > > > > > On Fri, Jun 05, 2026 at 04:23:15PM +1000, Gavin Shan wrote:
> > >
> > > [...]
> > >
> > > > > > >
> > > > > > > I tried to rebase Jean's latest QEMU series [1] to upstream QEMU, and found
> > > > > > > that memory slots backed by THP are broken. With THP disabled on the host and
> > > > > > > other fixes (mentioned in my prevous replies) applied on the top of this (v14)
> > > > > > > series, I'm able to boot a realm guest with rebased QEMU series [2], plus more
> > > > > > > fxies on the top.
> > > > > > >
> > > > > > > [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/ latest)
> > > > > > > [2] https://git.qemu.org/git/qemu.git (branch: cca/ gavin)
> > > > > > >
> > > > > > > Lorenzo, You may be saying there is someone making QEMU to support ARM/CCA?
> > > > > >
> > > > > > Mathieu and I are working on that yes and with Steven/Suzuki to fix the THP
> > > > > > issues you pointed out above.
> > > > > >
> > > > > > > If so, I'm not sure if there is a QEMU repository for me to try?
> > > > > >
> > > > > > We should be able to submit patches by end of June - we shall let you know
> > > > > > whether we can make something available earlier.
> > > > > >
> > > > >
> > > > > Not sure if there are other known issues in this series. It seems the stage2
> > > > > page fault handling on the shared space isn't working well. In my test, the
> > > > > vring (struct vring_desc) of virtio-net-pci is updated by the guest, and the
> > > > > data isn't seen by QEMU, I'm suspecting if the host-page-frame-number is properly
> > > > > resolved in the s2 page fault handler for shared (unprotected) space.
> > > > >
> > > > > - I rebased Jean's latest qemu branch to the upstream qemu;
> > > > >
> > > > > - On the host, which is emulated by qemu/tcg, the THP (transparent huge page) is
> > > > > disabled.
> > > > >
> > > > > - On the guest, I can see the virtio vring (struct vring_desc) is updated. The
> > > > > S1 page-table entry looks correct because the corresponding physical address
> > > > > 0x10046880000 is a sane shared (unprotected) space address.
> > > > >
> > > > > [ 52.094143] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
> > > > > [ 52.289746] virtqueue_add_desc_split: desc[0]@0xffff000006880000, [00000100b983f000 00000640 0002 0001]
> > > > > [ 52.432150] PTE 0x00e8010046880707 at address 0xffff000006880000
> > > > >
> > > > > - On the host, the s2 page-table-entry is unmapped due to attribute transition (private -> shared).
> > > > > A subsequent S2 page fault is raised against the adress and the s2 page-table-entry is built.
> > > > >
> > > > > [ 109.259077] ====> realm_unmap_shared_range: tracked_unprot_addr=0x10046880000
> > > > > [ 109.260249] realm_unmap_shared_range: unmapped shared range at 0x10046880000
> > > > > [ 109.317786] realm_unmap_shared_range: unmapped shared range at 0x10046880000
> > > > > [ 109.629939] ====> kvm_handle_guest_abort: fault_ipa=0x10046880000, esr=0x92000007
> > > > > [ 109.630245] realm_map_non_secure: ipa=0x10046880000, pfn=0xb8b59, size=0x1000, prot=0xf
> > > > > [ 109.630331] realm_map_non_secure: ipa=0x10046880000, ipa_top=0x10046881000, flags=0x1e0001, range_desc=0xb8b59004
> > > >
> > > > Are you able to correlate the order of the transitions and the Guest
> > > > access with RMM log ? We haven't seen this from our end. We are aware
> > > > of permission fault issues with Unprotected IPA when backing the memslot
> > > > with MAP_PRIVATE areas. But this looks different.
> > > >
> > > > Lorenzo, have you run into this ?
> > > >
> > >
> > > It's hard to correlate the order since the logs are collected from two separate
> > > consoles. For the write permission, I add code to the host where the permission
> > > is always added for all s2 page faults in the shared space. Otherwise, qemu can
> > > be killed by -EFAULT or similar error.
> >
> > This is the problem. We can't add WRITE permission by default. I believe
> > you may have MAP_PRIVATE mapping and it has to be mapped as READ only
> > and on a permission fault, we replace it with a writable page. By
> > overriding the WRITE permission, you let the guest write to a page
> > that may not be seen by the VMM.
> >
> > We identified this as a bug in the KVM driver in this series (reported
> > by Lorenzo) and there is a corresponding tf-RMM change that is required
> > to get this working. So, please could you wait until the next series
> > when this will be addressed ? Or you could switch to using MAP_SHARED
> > for the "shared" memory in the memslot.
> >
>
> Exactly. the syntax for MAP_PRIVATE is broken if the write permission is
> enforced for a read fault in the shared space. In my case, the host page can
> be the zero page and eventually multiple s2 page-table entries (for multiple
> unprotected or shared pages) point to the zero page. It's why clearing the
> 3rd queue (Ctrl queue) also clears the first queue (Rx queue) in my case.
>
> Yes, this issue can be avoid by using a shared memory backend in qemu, something
> like below. With this, I'm able to see virtio-net-pci starts to work...
>
> -object memory-backend-ram,id=mem0,size=2G,share=yes
Yes, as Suzuki said that's what we have been fixing. QEmu patches
will be on the mailing lists very shortly - the KVM/tf-RMM fixes
to make MAP_PRIVATE work will be included in the next posting.
Feel free to drop your QEmu command line so that I can give it
a shot and check whether the fixes solve the problem you hit
(I think so because that's precisely the kind of issue I got
into when I started debugging THP/MAP_PRIVATE but it is better
to check).
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH] media: meson: vdec: fix use-after-free of prev_frame in codec_vp9_rm_noshow_frame()
From: Doruk Tan Ozturk @ 2026-06-26 16:40 UTC (permalink / raw)
To: Neil Armstrong, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Hans Verkuil, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, linux-media, linux-amlogic, linux-staging,
linux-arm-kernel, linux-kernel, Doruk Tan Ozturk
codec_vp9_rm_noshow_frame() frees the first non-shown reference frame on
ref_frames_list without excluding vp9->prev_frame. When the previously
decoded frame was a non-show (alt-ref) frame and the current frame is a
non-show inter frame, the freed object is the one vp9->prev_frame still
points to; codec_vp9_set_mpred_mv() then dereferences the stale pointer
(use_prev_frame_mvs and codec_vp9_get_frame_mv_paddr()), a use-after-free.
The sibling cleanup codec_vp9_show_frame() already guards this pointer
(tmp == vp9->prev_frame); rm_noshow_frame() simply omits the same check.
Add it.
The fields that drive this path (show_frame, frame_type, intra_only) are
parsed from the VP9 bitstream, so a crafted stream fed to the stateless
decoder can trigger the free-then-use.
Found by static analysis; not yet runtime-reproduced (Amlogic Meson
hardware required).
Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
drivers/staging/media/meson/vdec/codec_vp9.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
index 8e80ecf84..572f418c9 100644
--- a/drivers/staging/media/meson/vdec/codec_vp9.c
+++ b/drivers/staging/media/meson/vdec/codec_vp9.c
@@ -1247,6 +1247,15 @@ static void codec_vp9_rm_noshow_frame(struct amvdec_session *sess)
if (tmp->show)
continue;
+ /*
+ * prev_frame is still referenced by the MV predictor in
+ * codec_vp9_set_mpred_mv(); the sibling codec_vp9_show_frame()
+ * already excludes it before freeing. Do the same here to avoid
+ * a use-after-free of vp9->prev_frame.
+ */
+ if (tmp == vp9->prev_frame)
+ continue;
+
pr_debug("rm noshow: %u\n", tmp->index);
v4l2_m2m_buf_queue(sess->m2m_ctx, tmp->vbuf);
list_del(&tmp->list);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 3/4] drm/bridge: analogix_dp: Add validation for samsung,lane-count property
From: Luca Ceresoli @ 2026-06-26 16:29 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260604085220.2862986-4-damon.ding@rock-chips.com>
On Thu, 04 Jun 2026 16:52:19 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
Hello Damon,
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 7a85774aaac1..e120ef3320c1 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1261,8 +1262,11 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
> */
> of_property_read_u32(dp_node, "samsung,link-rate",
> &video_info->max_link_rate);
> - of_property_read_u32(dp_node, "samsung,lane-count",
> - &video_info->max_lane_count);
> + ret = of_property_read_u32(dp_node, "samsung,lane-count",
> + &video_info->max_lane_count);
> + if (ret || !drm_dp_lane_count_is_valid(video_info->max_lane_count))
> + return dev_err_probe(dp->dev, ret ? ret : -EINVAL,
> + "failed to parse samsung,lane-count\n");
I think this report by sashiko makes sense:
> sashiko-bot@kernel.org <sashiko-bot@kernel.org>:
>
> [Severity: High]
> Does this make the optional and deprecated samsung,lane-count property a
> strict requirement?
>
> If samsung,lane-count is absent from the device tree, of_property_read_u32()
> returns -EINVAL. This causes the condition to evaluate to true, aborting the
> probe with an error.
>
> According to the device tree bindings
> (Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml),
> this property is marked as deprecated and explicitly optional because the
> lane count can be read from the monitor. Does this patch break compatibility
> with device trees that rightfully omit this deprecated property?
(via: https://patch.msgid.link/20260604090935.7FC051F00898@smtp.kernel.org)
Can you comment on this?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 2/4] drm/dp: Add helper to validate DP lane counts
From: Luca Ceresoli @ 2026-06-26 16:29 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260604085220.2862986-3-damon.ding@rock-chips.com>
On Thu, 04 Jun 2026 16:52:18 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
> Add a generic helper function drm_dp_lane_count_is_valid() to check
> if a DisplayPort lane count is valid. According to the DP specification,
> only 1, 2, or 4 lanes are supported.
>
> This helper avoids duplicating DP lane count validation logic across
> individual DisplayPort drivers.
>
> [...]
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox