* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Bryan O'Donoghue @ 2026-06-09 8:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Andi Shyti,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-1-ca1936bf1219@oss.qualcomm.com>
On 08/06/2026 15:06, Nihal Kumar Gupta wrote:
> Shikra contains the same Camera Subsystem IP as QCM2290. Document the
> platform-specific compatible string, using qcom,qcm2290-camss as
> fallback.
>
> Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
> single IOMMU context bank instead of four.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> .../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> index 391d0f6f67ef5fdfea31dd3683477561516b1556..4f39eefb4898ebc22117407f26cfb4f41deb111b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> @@ -14,8 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,qcm2290-camss
> -
> + oneOf:
> + - items:
> + - const: qcom,shikra-camss
> + - const: qcom,qcm2290-camss
> + - const: qcom,qcm2290-camss
> reg:
> maxItems: 9
>
> @@ -76,7 +79,14 @@ properties:
> - const: sf_mnoc
>
> iommus:
> - maxItems: 4
> + oneOf:
> + - items:
> + - description: S1 HLOS VFE non-protected (VFE only)
> + - items:
> + - description: S1 HLOS VFE non-protected
> + - description: S1 HLOS CDM non-protected
> + - description: S1 HLOS OPE read non-protected
> + - description: S1 HLOS OPE write non-protected
>
> power-domains:
> items:
>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
bod
^ permalink raw reply
* Re: [Question] Enabling CoreSight TRBE in firmware on CIX Orion O6
From: Yunseong Kim @ 2026-06-09 8:50 UTC (permalink / raw)
To: Yunseong Kim, Peter Chen, Fugang Duan, Guomin Chen, Hans Zhang,
Gary Yang, Joakim Zhang, Jerry Zhu
Cc: CIX Linux Kernel Upstream Group, devicetree, linux-arm-kernel,
linux-kernel@vger.kernel.org, Yunseong Kim
In-Reply-To: <5d1bdf6d-ed77-4de9-b788-cf04a98d054d@est.tech>
I wrote the wrong output:
> $ perf record -e cs_etm// -- ls
> intel_pt: aux mmap: Cannot allocate memory
Current output:
$ perf record -e cs_etm// -- ls
cs_etm: Not found on CPU 0. Check hardware and firmware support and that all Coresight drivers are loaded
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Alexis Lothoré @ 2026-06-09 8:47 UTC (permalink / raw)
To: bot+bpf-ci, alexis.lothore, ast, daniel, andrii, martin.lau,
eddyz87, memxor, song, yonghong.song, jolsa, john.fastabend, tglx,
mingo, bp, dave.hansen, x86, hpa, shuah, mcoquelin.stm32,
alexandre.torgue, ihor.solodrai
Cc: ebpf, bastien.curutchet, thomas.petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel, martin.lau, clm
In-Reply-To: <1e7ab52954b9ff584d6871c2ec234a7155b577f29128564d0d597809cafad826@mail.kernel.org>
On Thu Jun 4, 2026 at 11:13 PM CEST, bot+bpf-ci wrote:
>> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
>> index eb3de35734f0..a8e004f88b92 100644
>> --- a/kernel/bpf/Kconfig
>> +++ b/kernel/bpf/Kconfig
>
> [ ... ]
>
>> @@ -101,4 +105,9 @@ config BPF_LSM
>>
>> If you are unsure how to answer this question, answer N.
>>
>> +config BPF_JIT_KASAN
>> + bool
>> + depends on HAVE_EBPF_JIT_KASAN
>> + default y if BPF_JIT && KASAN_GENERIC && KASAN_VMALLOC && VMAP_STACK
>> +
>> endmenu # "BPF subsystem"
>
> This isn't a bug, but a design concern raised on an earlier posting of
> this work doesn't look fully resolved.
>
> In the v1 (RFC) discussion, the suggestion was to not add a config knob
> at all and instead do the instrumentation inside the JIT whenever
> KASAN_GENERIC is set:
>
> "Let's not add more config knobs. Even this patch looks redundant.
> Inside JIT do instrumentation when KASAN_GENERIC is set."
>
> https://lore.kernel.org/bpf/CAADnVQLj=UosnsC-4V2+mN92Fe0-kW++U+m-O9c93kk6BwiXgw@mail.gmail.com/
>
> The reasoning given for keeping the internal Kconfig was that it lets
> selftests adapt their behavior without sprinkling arch and KASAN
> conditionals, and another reviewer agreed that approach was reasonable.
>
> That "this patch looks redundant" objection was never explicitly
> retracted or re-acked, yet the BPF_JIT_KASAN config is retained here.
>
> Has this design point been settled?
I still advocate to keep this BPF_JIT_KASAN, which is used later in
patch 7/8 to check whether kasan tests should be executed or not.
Alexis
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26978380520
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend()
From: Mark Brown @ 2026-06-08 18:02 UTC (permalink / raw)
To: lgirdwood, perex, tiwai, matthias.bgg, angelogioacchino.delregno,
kuninori.morimoto.gx, ckeepax, vulab, Tuo Li
Cc: linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260528064107.470824-1-islituo@gmail.com>
On Thu, 28 May 2026 14:41:06 +0800, Tuo Li wrote:
> ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend()
https://git.kernel.org/broonie/sound/c/b8948ac26efc
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 0/3] ASoC: imx-rpmsg: Add headphone jack detection and driver_name support
From: Mark Brown @ 2026-06-08 17:53 UTC (permalink / raw)
To: lgirdwood, robh, krzk+dt, conor+dt, Chancel Liu
Cc: shengjiu.wang, shengjiu.wang, Xiubo.Lee, festevam, nicoleotsuka,
perex, tiwai, Frank.Li, s.hauer, linux-sound, devicetree,
linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20260528020725.2265321-1-chancel.liu@nxp.com>
On Thu, 28 May 2026 11:07:22 +0900, Chancel Liu wrote:
> ASoC: imx-rpmsg: Add headphone jack detection and driver_name support
>
> This series adds two features to the i.MX RPMSG ASoC card:
> 1. Headphone jack detection via GPIO: Introduce the "hp-det-gpios"
> device tree property and use simple_util_init_jack() to
> register a headphone jack with GPIO-based insertion detection.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/3] ASoC: dt-bindings: fsl,rpmsg: Add hp-det-gpios property
https://git.kernel.org/broonie/sound/c/1558039bea60
[2/3] ASoC: imx-rpmsg: Support headphone jack detection
https://git.kernel.org/broonie/sound/c/ec74d4f934a6
[3/3] ASoC: imx-rpmsg: Set driver_name for snd_soc_card
https://git.kernel.org/broonie/sound/c/af0d8aa7fcd5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [Question] Enabling CoreSight TRBE in firmware on CIX Orion O6
From: Yunseong Kim @ 2026-06-09 8:40 UTC (permalink / raw)
To: Peter Chen, Fugang Duan, Guomin Chen, Hans Zhang, Gary Yang,
Joakim Zhang, Jerry Zhu
Cc: CIX Linux Kernel Upstream Group, devicetree, linux-arm-kernel,
linux-kernel@vger.kernel.org, Yunseong Kim, Yunseong Kim
Hi CIX team,
I'm working on vock (https://github.com/yskzalloc/vock), a tool that maps
userspace programs to the exact kernel code they exercise using hardware
trace. On arm64, this relies on CoreSight ETM (--mode hw, for non-kcov
enabled kernel) to collect kernel coverage without requiring CONFIG_KCOV.
Without firmware enabling TRBE or exposing TMC/ETR, I cannot verify or test
the arm64 CoreSight code path on the Orion O6 at all.
I've been testing on a CIX Orion O6 board running Debian sid latest generic kernel
and found that CoreSight trace is not functional due to firmware-level restrictions.
Test environment running Debian sid arm64 kernel:
Board: CIX Orion O6
Kernel: Debian arm64 generic (7.1+unreleased-arm64, CONFIG_CORESIGHT=m)
CPU: Cortex-A520 (0xd81) + Cortex-A720 (0xd80), 12 cores
Firmware: UEFI/ACPI (no device tree)
What works:
- coresight_etm4x module loads successfully
- cs_etm PMU appears at /sys/bus/event_source/devices/cs_etm (type=12)
- nr_addr_filters = 8
$ lsmod | grep coresight
coresight_etm4x 118784 0
coresight 110592 1 coresight_etm4x
$ ls /sys/bus/event_source/devices/cs_etm/type
12
What fails:
1. No CoreSight bus devices are registered:
$ ls /sys/bus/coresight/devices/
(empty)
2. perf AUX mmap fails (no trace sink available):
$ perf record -e cs_etm// -- ls
intel_pt: aux mmap: Cannot allocate memory
3. TRBE module loads but registers no devices (firmware blocks access):
$ sudo modprobe coresight-trbe
$ ls /sys/bus/coresight/devices/
(empty)
4. dmesg shows only configuration manager, no ETM/TRBE device probes:
[ 4479.881313] cs_system_cfg: CoreSight Configuration manager initialised
5. DSDT has no CoreSight ACPI devices (no ARMHC500/ARMHC501/ARMHC97C HIDs)
Root cause:
The Cortex-A520 and Cortex-A720 cores support both ETM and TRBE in
hardware, but the firmware (TF-A/EL3) does not enable OS-level access:
- TRBE: MDCR_EL3.NSTBE is likely not set, preventing non-secure
trace buffer access
- TMC/ETR: No MMIO-mapped trace sinks are described in the ACPI DSDT
- Self-hosted trace: MDCR_EL3.NSTB / CPTR_EL3.TTA may not be configured
Can you check enabling CoreSight trace support in the Orion O6 firmware by either:
(1) (Preferred) Enable TRBE access from non-secure EL1/EL2:
- Set MDCR_EL3.NSTBE = 1 in TF-A
- This allows the per-CPU Trace Buffer Extension to work as a sink
without any additional MMIO hardware
(2) Or expose the full CoreSight topology in ACPI:
- Add ARMHC97C (TMC-ETR) device with MMIO base address
- Add ARMHC502 (funnel) devices if applicable
- Reference: ARM DEN0067 (CoreSight Architecture ACPI bindings)
(1) is simpler and doesn't require ACPI table changes, it's a single register
bit in the secure firmware.
Thank you!
Best regards
^ permalink raw reply
* Re: [net-next v24 3/7] net: mtip: Add buffers management functions to the L2 switch driver
From: Łukasz Majewski @ 2026-06-09 8:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, richardcochran, lgirdwood,
nathan, linux-kernel, netdev, krzk+dt, imx, linux-arm-kernel,
robh, Andrew Lunn
In-Reply-To: <20260605021853.3594553-1-kuba@kernel.org>
Hi Jakub,
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: mtip: Add buffers management functions to the L2 switch driver
>
> This patch fills in mtip_alloc_buffers() and mtip_free_buffers() for
> the MTIP L2 switch driver, replacing the previously empty stubs with
> real page_pool setup/teardown and tx_bounce buffer allocation/free.
>
> > diff --git a/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c
> > b/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c index
> > 1d1005a42306..5b5229ee411d 100644 ---
> > a/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c +++
> > b/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c @@ -892,11
> > +892,101 @@ static void mtip_get_drvinfo(struct net_device *dev,
> > static void mtip_free_buffers(struct net_device *dev)
> > {
> > + struct mtip_ndev_priv *priv = netdev_priv(dev);
> > + struct switch_enet_private *fep = priv->fep;
> > + int i;
> > +
> > + for (i = 0; i < RX_RING_SIZE; i++) {
> > + if (!fep->page[i])
> > + continue;
> > +
> > + page_pool_put_full_page(fep->page_pool,
> > + fep->page[i], false);
> > + fep->page[i] = NULL;
> > + }
> > +
> > + page_pool_destroy(fep->page_pool);
> > + fep->page_pool = NULL;
> > +
> > + for (i = 0; i < TX_RING_SIZE; i++) {
> > + kfree(fep->tx_bounce[i]);
> > + fep->tx_bounce[i] = NULL;
> > + }
> > +}
>
> [High]
> Now that mtip_free_buffers() is no longer an empty stub, can the
> mtip_open() error path tear down buffers that another active port is
> still using?
>
> Looking at mtip_open():
>
> if (fep->usage_count == 0) {
> ...
> ret = mtip_alloc_buffers(dev);
> if (ret)
> goto mtip_alloc_buffers_err;
> }
> ...
> ret = mtip_mii_probe(dev);
> if (ret)
> goto mtip_mii_probe_err;
> ...
> mtip_mii_probe_err:
> mtip_free_buffers(dev);
> mtip_alloc_buffers_err:
> if (fep->usage_count == 0) {
> netif_napi_del(&fep->napi);
> clk_disable(fep->clk_ipg);
> }
> return ret;
>
> mtip_alloc_buffers() only runs when fep->usage_count == 0, so the
> page_pool, fep->page[] and fep->tx_bounce[] are shared across switch
> ports and only allocated on first open. mtip_close() reflects this and
> only calls mtip_free_buffers() when fep->usage_count == 1.
>
> When a second port is opened (fep->usage_count > 0) and
> mtip_mii_probe() fails, the mtip_mii_probe_err label still calls
> mtip_free_buffers() unconditionally, which destroys the page_pool and
> frees the tx_bounce buffers that the first, still-active port is
> using.
>
> Should the mtip_mii_probe_err teardown also be guarded by
> fep->usage_count == 0 (or the labels reordered) so buffers are only
> freed for the last user, similar to mtip_close()?
>
> After this change the previously harmless call becomes a real
> teardown, so the surviving port's NAPI path (mtip_switch_rx() and the
> later mtip_update_cbd() refill) would dereference a freed
> fep->page_pool and NULL fep->page[] / fep->tx_bounce[] entries
> whenever the second port's PHY probe fails while the first port is up.
>
> >
> > +static int mtip_create_page_pool(struct switch_enet_private *fep,
> > int size) +{
> [ ... ]
> > +}
> >
> > static int mtip_alloc_buffers(struct net_device *dev)
> > {
> [ ... ]
> > return 0;
> > +
> > + err:
> > + mtip_free_buffers(dev);
> > + return -ENOMEM;
> > }
> >
Thank you for sending the AI review.
Please find my comments:
- I've gone through them and yes, there are a few issues found.
However, those are IMHO not critical ones.
- Some issues are not valid at all - like concern what happens when the
switch is run on multi processor chip - both imx287 and vf610 are
single core chips.
- It seems like the AI review is "progressing" - i.e. there were no
issues found with v23 for this particular patch. I do guess that the
new Orc Mode from [1] has found it.
- I do guess that different AI agent would generate different review
- The aforementioned issues could be addressed with a fix patches -
dragging along (and preparing for upstream) patch set with ~3400
LOC (which is rejected by non-deterministic AI review) takes too much
resources now.
To sum up:
----------
The MTIP driver for v6.6 kernel (YPRR Scarthgap) with and without
PREEMPT_RT for vf610 and imx287 as well as the v24 for net-next can be
found at [2].
Links:
[1] - https://netdev-ai.bots.linux.dev/ai-local.html
[2] - https://github.com/lmajewski/linux-imx28-l2switch/branches
--
Best regards,
Łukasz Majewski
^ permalink raw reply
* [PATCH] regulator: mt6359: Fix vbbck default internal supply name
From: Chen-Yu Tsai @ 2026-06-09 8:36 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, linux-kernel
This issue was pointed out by Sashiko.
vbbck is fed internally from vio18. For the MT6359, the default supply
name was incorrectly set as "VIO18", instead of the supply's default
"VIO18". In practice this still works, but it causes the regulator
description copy and replace to always happen. For the MT6359P the
name is correct.
Fix the supply name for MT6359 so that both instances are the same and
correct. Also copy the comment about the internal supply from the MT6359
list to the MT6359P list.
Fixes: 10be8fc1d534 ("regulator: mt6359: Add regulator supply names")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6359-regulator.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index a27427974186..d9afbcc6a97c 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -706,7 +706,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
/* vbbck is fed from vio18 internally. */
- MT6359_LDO("ldo_vbbck", VBBCK, "VIO18", vbbck_voltages,
+ MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359_RG_LDO_VBBCK_EN_ADDR, MT6359_RG_LDO_VBBCK_EN_SHIFT,
MT6359_DA_VBBCK_B_EN_ADDR, MT6359_RG_VBBCK_VOSEL_ADDR,
MT6359_RG_VBBCK_VOSEL_MASK << MT6359_RG_VBBCK_VOSEL_SHIFT,
@@ -947,6 +947,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_DA_VM18_B_EN_ADDR, MT6359P_RG_VM18_VOSEL_ADDR,
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
+ /* vbbck is fed from vio18 internally. */
MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359P_RG_LDO_VBBCK_EN_ADDR, MT6359P_RG_LDO_VBBCK_EN_SHIFT,
MT6359P_DA_VBBCK_B_EN_ADDR, MT6359P_RG_VBBCK_VOSEL_ADDR,
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* Re: -next boot failures during KVM setup
From: Mark Brown @ 2026-06-09 8:36 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Ard Biesheuvel, Marc Zyngier, Will Deacon, Catalin Marinas,
Oliver Upton, Aishwarya.TCV, linux-arm-kernel
In-Reply-To: <20260608232753.GA2993766@ax162>
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
On Mon, Jun 08, 2026 at 04:27:53PM -0700, Nathan Chancellor wrote:
> On Mon, Jun 08, 2026 at 10:56:12PM +0200, Ard Biesheuvel wrote:
> > Given we're at -rc7, I'd lean towards dropping the whole branch for now, or
> > alternatively, only drop/revert "arm64: mm: Unmap kernel data/bss entirely from the
> > linear map" (and its followup fix "arm64: mm: Defer remap of linear alias of
> > data/bss") so that the region always remains readable via the linear map.
> FWIW, I can confirm that "arm64: mm: Unmap kernel data/bss entirely from
> the linear map" is the culprit for this particular issue based on my
> bisect. Reverting those two changes on top of next-20260608 avoids the
> issue.
Yes, same result here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3] clk: imx: Add audio PLL debugfs for K-divider control
From: Peng Fan @ 2026-06-09 8:33 UTC (permalink / raw)
To: Jacky Bai
Cc: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd,
Brian Masney, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-clk, imx, linux-arm-kernel
In-Reply-To: <20260604-imx8m_pll_debugfs-v3-1-4e331ebc85d7@nxp.com>
On Thu, Jun 04, 2026 at 09:48:01PM +0800, Jacky Bai wrote:
>Add debugfs support for runtime tuning of the audio PLL K divider,
>which enables fine-grained frequency adjustments for audio PLL.
>This is used for:
> - Audio clock calibration and testing
> - Debugging audio synchronization issues
>
>Two debug interfaces are exported to userspace:
> - delta_k: It is used to adjust the K divider in PLL based on small
> steps
> - pll_parameter: It is used for get PLL's current M-divider,
> P-divider, S-divider & K-divider setting in PLL register
>
>Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Krzysztof Kozlowski @ 2026-06-09 8:30 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260608-shikra-display-v4-1-88a846afdd5d@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 12:31:42PM +0530, Nabige Aala wrote:
> Shikra reuses the same MDSS/DPU 6.5 hardware as QCM2290. Extend
> the existing qcm2290 bindings to cover Shikra by adding fallback
> compatible chains for MDSS, DPU and DSI controller nodes rather
> than introducing a separate binding file.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v6 08/21] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing
From: Atish Patra @ 2026-06-09 6:01 UTC (permalink / raw)
To: James Clark, Rob Herring, Atish Patra, Arnaldo Carvalho de Melo,
Jiri Olsa, Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers
Cc: linux-riscv, linux-kernel, linux-perf-users, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <20260608-counter_delegation-v6-0-285b72ed65a9@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Smcdeleg extension allows the M-mode to delegate selected counters
to S-mode so that it can access those counters and correpsonding
hpmevent CSRs without M-mode.
Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level
extension, ‘ccfg’ for Counter Configuration) provides access to
delegated counters and new supervisor-level state.
This patch just enables these definitions and enable parsing.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/hwcap.h | 2 ++
arch/riscv/kernel/cpufeature.c | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 51ad55b9677a..089353b250b0 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -115,6 +115,8 @@
#define RISCV_ISA_EXT_SSCSRIND 106
#define RISCV_ISA_EXT_SMCSRIND 107
#define RISCV_ISA_EXT_SMCNTRPMF 108
+#define RISCV_ISA_EXT_SSCCFG 109
+#define RISCV_ISA_EXT_SMCDELEG 110
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 1452521d740a..1fe647e03515 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -330,6 +330,27 @@ static const unsigned int riscv_a_exts[] = {
RISCV_ISA_EXT_ZKNE, \
RISCV_ISA_EXT_ZKNH
+static int riscv_ext_smcdeleg_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SSCSRIND) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZIHPM) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZICNTR))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
+static int riscv_ext_ssccfg_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (!riscv_ext_smcdeleg_validate(data, isa_bitmap) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SMCDELEG))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
static const unsigned int riscv_zk_bundled_exts[] = {
RISCV_ISA_EXT_ZKN,
RISCV_ISA_EXT_ZKR,
@@ -576,12 +597,15 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_BUNDLE_VALIDATE(zvksg, riscv_zvksg_bundled_exts, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zvkt, RISCV_ISA_EXT_ZVKT, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+ __RISCV_ISA_EXT_DATA_VALIDATE(smcdeleg, RISCV_ISA_EXT_SMCDELEG,
+ riscv_ext_smcdeleg_validate),
__RISCV_ISA_EXT_DATA(smcntrpmf, RISCV_ISA_EXT_SMCNTRPMF),
__RISCV_ISA_EXT_DATA(smcsrind, RISCV_ISA_EXT_SMCSRIND),
__RISCV_ISA_EXT_DATA(smmpm, RISCV_ISA_EXT_SMMPM),
__RISCV_ISA_EXT_SUPERSET(smnpm, RISCV_ISA_EXT_SMNPM, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_DATA(smstateen, RISCV_ISA_EXT_SMSTATEEN),
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+ __RISCV_ISA_EXT_DATA_VALIDATE(ssccfg, RISCV_ISA_EXT_SSCCFG, riscv_ext_ssccfg_validate),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
__RISCV_ISA_EXT_DATA(sscsrind, RISCV_ISA_EXT_SSCSRIND),
__RISCV_ISA_EXT_SUPERSET(ssnpm, RISCV_ISA_EXT_SSNPM, riscv_xlinuxenvcfg_exts),
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Vladimir Murzin @ 2026-06-09 8:26 UTC (permalink / raw)
To: Marek Szyprowski, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
Hi,
On 6/9/26 07:28, Marek Szyprowski wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
>> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> The linear aliases of the kernel text and rodata are also mapped
>>> read-only in the linear map. Given that the contents of these regions
>>> are mostly identical to the version in the loadable image, mapping them
>>> read-only and leaving their contents visible is a reasonable hardening
>>> measure.
>>>
>>> Data and bss, however, are now also mapped read-only but the contents of
>>> these regions are more likely to contain data that we'd rather not leak.
>>> So let's unmap these entirely in the linear map when the kernel is
>>> running normally.
>>>
>>> When going into hibernation or waking up from it, these regions need to
>>> be mapped, so map the region initially, and toggle the valid bit so
>>> map/unmap the region as needed.
>>>
>>> Doing so is required because pages covering the kernel image are marked
>>> as PageReserved, and therefore disregarded for snapshotting by the
>>> hibernate logic unless they are mapped.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
>> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
>> In my tests I found that it breaks booting of RaspberryPi3 and
>> RaspberryPi4 boards with the following kernel panic:
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
>
Thanks for report! It seems it already has been reported and discussed in
another thread [1].
[1] https://lore.kernel.org/linux-arm-kernel/aicVyebkEMs6w6UV@sirena.co.uk/
Cheers
Vladimir
> Best regards
> -- Marek Szyprowski, PhD Samsung R&D Institute Poland
>
^ permalink raw reply
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Liu Ying @ 2026-06-09 8:26 UTC (permalink / raw)
To: Marek Vasut
Cc: Piyush Patle, dri-devel, imx, linux-arm-kernel, linux-clk,
devicetree, Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <9ece4e08-a77f-4410-ba16-a77b9bd0aace@mailbox.org>
On Mon, Jun 08, 2026 at 06:29:32PM +0200, Marek Vasut wrote:
> On 6/8/26 9:48 AM, Liu Ying wrote:
>
> Hello everyone,
>
> > > I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
> > > LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
> > > LVDS format handling, and DC enable sequencing which needed rework before
> > > HDMI would come up reliably on the board.
> > >
> > > I don't see a v2 of the series and things seem to have been quiet since
> > > November. Are you planning to post an updated version?
> >
> > My plan was to enable prefetch engine support[1] for i.MX8QXP display
> > controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
> > before adding i.MX95 display controller support.
> >
> > Unfortunately, it seems that Marek is not a big fan of [1]
>
> I am fine with [1] as long as it can be isolated and does not affect every
> SoC that might reuse this driver, which I think it can be done.
How can it be isolated?
>
> > and I'm busy
> > with downstream development so the plan doesn't move forward well. I still
> > think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
> > so I'd like to see review comments on [1] and hopefully people think that
> > the overall idea of [1] is ok.
>
> My only concern is, to keep it isolated to MX8Q, so this driver can be
> reused by MX95.
>
> > > I've accumulated a fair amount of rework while getting this running on the
> > > FRDM. If you're not planning a v2, I can clean things up and send one based
> > > on the current series.
> >
> > I still think that i.MX95 display controller driver should be in a separate
> > driver, rather than sharing the same driver with i.MX8QXP display controller
> > like this patch series does, because the two display controllers are quite
> > different as I mentioned in comments on this patch series and in discussion
> > in [1]. Also, the common part between the two display controllers should
> > be extracted to a common helper library as I mentioned there too.
> Are they really? It seems this series adds support for the MX95 DC without
> that many changes, so are the DCs really that different ? It seems the MX95
> DC is simply a reuse/evolution of the MX8Q DC blocks, so duplicating the
> code seems like the wrong direction, it will only lead to disparate sets of
> bugs in two drivers, which isn't desired.
I pointed out a lot of H/W differences between the two display controllers
during the discussions for this patch series and my i.MX8QXP prefetch engine
patch series[1]. Please take a look at [1], which clearly shows that the
prefetch engine would considerably impact CRTC/plane atomic callback
implementations. Display controller internal blocks would also impact
the implementations, e.g., DomainBlend block in i.MX95 display controller
doesn't present in i.MX8QXP display controller. It makes sense to use
separate drivers for the two display controllers instead of adding 'if/else'
checks to a single driver's atomic callbacks or introducing two pairs of
atomic callbacks to that single driver. I mentioned before, the code to
simply add a DRM driver(struct drm_driver) is fairly limited.
I also mentioned before that separate drivers make them easier to maintain:
we don't have to test both i.MX8QXP and i.MX95 if only one display controller
specific code is changed.
>
> (I might not fully understand what you have in mind with the helper library
> though?)
I said this could be something like imx-ldb-helper.c and plus perhaps some
callbacks like fg->dc_fg_cfg_videomode().
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
From: Luca Ceresoli @ 2026-06-09 8:23 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: <20260608-shapeless-opal-ferret-c8b105@houat>
Hi Maxime,
thanks for the review of this long series!
On Mon Jun 8, 2026 at 2:34 PM CEST, Maxime Ripard wrote:
...
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -78,6 +78,19 @@ struct drm_bridge_funcs {
>> int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encoder,
>> enum drm_bridge_attach_flags flags);
>>
>> + /**
>> + * @is_tail:
>> + *
>> + * Returns true if this is a tail bridge, i.e. it does not need a
>> + * next bridge to work. E.g. a panel_bridge is a tail bridge, a
>> + * DSI-to-LVDS bridge is not a tail bridge (no matter whether the
>> + * next bridge is present or not).
>
> Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel
> next, right?
Uhm, good point, but I'd say it can be a tail bridge or not: in the
ATTACH_NO_CONNECTOR case it will need a bridge (a panel_bridge most
likely), no?
However this is possibly irrelevant as the whole .is_tail is meant to
disappear in v2, see below.
>> + * The @is_tail callback is optional but it is required if the
>> + * bridge is part of a pipeline with hot-pluggable components.
>> + */
>> + bool (*is_tail)(struct drm_bridge *bridge);
>> +
>
> I don't think that's the right way to think about it, if only because
> you never really know at the driver level if you're supposed to be last
> or not. A DSI-to-LVDS bridge might just as well be chained with an
> LVDS-to-eDP bridge, or feed the panel directly without any additional
> bridge.
>
> I *think* that what you're trying to find out here is whether the chain
> is complete or not.
You nailed it.
That was the main point discussed during the Display Next Hackfest 2026
(see the report [0]) and we all agreed the .is_tail along with the
-EPROBE_DEFER changes (patches 20+35) are not a good approach.
This is actually the most crucial aspect of the whole work still not having
no well-defined solution.
> I think you can get the same information by checking
> whether you have a connector for that bridge chain. If you don't, you
> know the chain isn't complete, and if you do, it's supposed to be.
There's a checken-egg problem here. Knowing whether the pipeline is
complete or not is needed to know whether we have to create a
connector. See patch 36:
+ if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
+ drm_bridge_connector_add_connector(bridge_connector);
So the question is still open, what I need the most right now is comments
on the overall architecture of this aspecs. Maybe replying to [0] can be
more effective than here.
In a nutshell what we need is:
* when a bridge needs a following element (a bridge, or a panel which
however might/should have a panel_bridge), but that element is not
present, instead of deferring the whole card probe the card should be
allowed to probe but without a connector
* when something is added to an incomplete pipeline we need to know
whether the pipeline has become complete (in order to create the
connector)
How to implement this is still an open point. I'll welcome proposals in
addition to the ones in [0].
[0] https://lore.kernel.org/all/DIXTUCXAU68V.1T7X89LMEUF2F@bootlin.com/
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Jakob Unterwurzacher @ 2026-06-09 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Jakob Unterwurzacher, Quentin Schulz
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
From: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Technically, the reset signal is active low - it's called RST_n after all.
But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
is set in the emmc. It is 0 per default.
For emmcs that have RST_n_FUNCTION=1 we failed like this:
[ 3.074480] mmc1: Failed to initialize a non-removable card
With this change they work normally.
Cc: stable@vger.kernel.org
Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
---
v2: Add correct "From: " line
arch/arm64/boot/dts/rockchip/px30-cobra.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
index b7e669d8ba4d..90751b04f95c 100644
--- a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
@@ -35,7 +35,7 @@ emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
pinctrl-0 = <&emmc_reset>;
pinctrl-names = "default";
- reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
};
gpio-leds {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan()
From: Andi Shyti @ 2026-06-09 8:16 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: aisheng.dong, Frank.Li, s.hauer, kernel, festevam, carlos.song,
linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260520093323.2882070-1-carlos.song@oss.nxp.com>
Hi Carlos,
On Wed, May 20, 2026 at 05:33:23PM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> The LPI2C driver requests DMA channels using dma_request_chan(), but
> never releases them in lpi2c_imx_remove(), resulting in DMA channel
> leaks every time the driver is unloaded.
>
> Additionally, when lpi2c_dma_init() successfully requests the TX DMA
> channel but fails to request the RX DMA channel, the probe falls back
> to PIO mode and completes successfully. Since probe succeeds, the devres
> framework will not trigger any cleanup, leaving the TX DMA channel and
> the memory allocated for the dma structure held for the lifetime of the
> device even though DMA is never used.
>
> Switch to devm_dma_request_chan() to let the device core manage DMA
> channel lifetime automatically. Wrap all allocations within a devres
> group so that devres_release_group() can release all partially acquired
> resources when DMA init fails and probe continues in PIO mode.
>
> Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
merged to i2c/i2c-host-fixes.
Thanks,
Andi
^ permalink raw reply
* [PATCH] net: ethernet: mediatek: fix refcount leak in mtk_probe()
From: Wentao Liang @ 2026-06-09 8:13 UTC (permalink / raw)
To: nbd, lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno
Cc: netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Wentao Liang, stable
If mtk_sgmii_init() fails after successfully creating some PCS
instances, it returns an error without cleaning up the partially
created ones. mtk_pcs_lynxi_create() increments the fwnode
refcount for each PCS it creates, but this refcount is never
released because mtk_probe() uses a plain "return err" instead of
a goto to the err_destroy_sgmii label. This leaks both the PCS
devices and their fwnode references.
Fix the leak by jumping to the existing err_destroy_sgmii path
which calls mtk_sgmii_destroy() to safely release all allocated
resources.
Cc: stable@vger.kernel.org
Fixes: 9ffee4a8276c ("net: ethernet: mediatek: Extend SGMII related functions")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8d225bc9f063..0f185462cf85 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -5169,7 +5169,7 @@ static int mtk_probe(struct platform_device *pdev)
err = mtk_sgmii_init(eth);
if (err)
- return err;
+ goto err_destroy_sgmii;
}
if (eth->soc->required_pctl) {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Jakob Unterwurzacher @ 2026-06-09 8:10 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Quentin Schulz, Jakob Unterwurzacher
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <3631825.d7IHhHJzqS@phil>
On 6/2/26 23:08, Heiko Stuebner wrote:
>
> as Quentin remarked, author (@gmail) and signed-off-by do not match.
> While I'm generally open to fixing things, when it touches the DCO this
> isn't the case.
>
> So please resend this with the correct author.
>
> In general "git send-email" will do the correct thing (that From: line),
> when patch author and email-id do not match.
For posterity:
What seems to be happening is that Gmail rewrites the "From: " header on
the server side. git send-email does now know this, so doesn't add the
extra "From: " line.
Making the final "From: " explicit in .gitconfig using
[sendemail]
from = Jakob Unterwurzacher <jakobunt@gmail.com>
now makes git send-email add that extra "From: " line in the email body
as expected.
I'll resend the patch now.
Thanks, Jakob
^ permalink raw reply
* [RESEND PATCH v3] coresight: etm-perf: Fix reference count leak in etm_setup_aux
From: Ma Ke @ 2026-06-09 8:02 UTC (permalink / raw)
To: suzuki.poulose, mike.leach, james.clark, leo.yan,
alexander.shishkin, mathieu.poirier
Cc: coresight, linux-arm-kernel, linux-kernel, akpm, Ma Ke, stable
bus_find_device() returns a device with its reference count
incremented. When a user-selected sink is obtained through
coresight_get_sink_by_id(), etm_setup_aux() keeps using the returned
sink while building the path and allocating the sink buffer.
Therefore the lookup reference must remain valid while etm_setup_aux()
is still using the sink, otherwise the sink could be removed under the
caller. Drop the lookup reference on the common exit path, after
etm_setup_aux() no longer directly uses the user-selected sink.
The CoreSight path code takes the references it needs for built paths,
so the initial lookup reference from coresight_get_sink_by_id() is no
longer needed after setup_aux finishes.
Found by code review.
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Cc: stable@vger.kernel.org
Fixes: 0e6c20517596 ("coresight: etm-perf: Allow an event to use different sinks")
---
Changes in v3:
- do not drop the lookup reference in coresight_get_sink_by_id(), as
that would return a sink pointer without keeping the device reference
while etm_setup_aux() is still using it.
- dropped the lookup reference in etm_setup_aux on the common exit path,
as suggested by Suzuki.
- updated the commit message to describe why the reference is kept
until etm_setup_aux() finishes using the sink.
Changes in v2:
- modified the patch as suggestions.
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f85dedf89a3f..d5116177c1b9 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -456,6 +456,11 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
goto err;
out:
+ if (user_sink) {
+ put_device(&user_sink->dev);
+ user_sink = NULL;
+ }
+
return event_data;
err:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 00/37] drm bridge hotplug
From: Luca Ceresoli @ 2026-06-09 7:47 UTC (permalink / raw)
To: Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
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
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DIXTUCXAU68V.1T7X89LMEUF2F@bootlin.com>
Hello,
On Mon Jun 1, 2026 at 5:44 PM CEST, Luca Ceresoli wrote:
> Hello,
>
> I presented this series last Friday during the Display Next Hackfest
> 2026. Here's a summary of the discussion.
For the records, the presentation slides are available at
https://bootlin.com/pub/conferences/2026/display-next-hackfest/ceresoli-drm-bridge-hotplug.pdf
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [GIT PULL] Microchip ARM64 device tree updates for v7.2
From: Claudiu Beznea @ 2026-06-09 7:41 UTC (permalink / raw)
To: soc, arm
Cc: claudiu.beznea, nicolas.ferre, alexandre.belloni,
linux-arm-kernel, conor
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-dt64-7.2
for you to fetch changes up to 8071815790141d3f05e32b972a6c79fdbbb88cfa:
arm64: dts: microchip: lan969x: add OTP node (2026-05-25 22:59:07 +0300)
----------------------------------------------------------------
Microchip ARM64 device tree updates for v7.2
This update includes:
- the device tree node for the OTP controller on LAN9691 SoC
----------------------------------------------------------------
Robert Marko (1):
arm64: dts: microchip: lan969x: add OTP node
arch/arm64/boot/dts/microchip/lan9691.dtsi | 5 +++++
1 file changed, 5 insertions(+)
^ permalink raw reply
* [GIT PULL] Microchip AT91 device tree updates for v7.2
From: Claudiu Beznea @ 2026-06-09 7:39 UTC (permalink / raw)
To: soc, arm; +Cc: claudiu.beznea, nicolas.ferre, alexandre.belloni,
linux-arm-kernel
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-7.2
for you to fetch changes up to 96b33938cf783c790036e35860b206cf029f2e2a:
ARM: dts: microchip: add I3C controller (2026-05-25 22:54:37 +0300)
----------------------------------------------------------------
Microchip AT91 device tree updates for v7.2
This update includes:
- I3C controller device tree node for SAMA7D65 SoC
----------------------------------------------------------------
Durai Manickam KR (1):
ARM: dts: microchip: add I3C controller
arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
^ permalink raw reply
* [GIT PULL] Microchip AT91 defconfig updates for v7.2
From: Claudiu Beznea @ 2026-06-09 7:39 UTC (permalink / raw)
To: soc, arm; +Cc: claudiu.beznea, nicolas.ferre, alexandre.belloni,
linux-arm-kernel
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-defconfig-7.2
for you to fetch changes up to ac75ae436723e5fe68dcc8e806f66d0358dd56f7:
ARM: configs: at91: sama7: add sama7d65 i3c-hci (2026-05-25 22:55:30 +0300)
----------------------------------------------------------------
Microchip AT91 defconfig updates for v7.2
This update includes:
- I3C flags for the SAMA7 family of SoCs
----------------------------------------------------------------
Manikandan Muralidharan (1):
ARM: configs: at91: sama7: add sama7d65 i3c-hci
arch/arm/configs/sama7_defconfig | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [PATCH] gpio: zynq: fix runtime PM leak on remove
From: Ruoyu Wang @ 2026-06-09 7:33 UTC (permalink / raw)
To: Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Linus Walleij,
Bartosz Golaszewski
Cc: Harini Katakam, Soren Brinkmann, linux-gpio, linux-arm-kernel,
linux-kernel, Ruoyu Wang
pm_runtime_get_sync() increments the runtime PM usage counter even when it
returns an error. zynq_gpio_remove() uses it to keep the controller active
while removing the GPIO chip, but never drops the usage counter again.
Balance the get with pm_runtime_put_noidle() after disabling runtime PM.
Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
drivers/gpio/gpio-zynq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 571e366624d2a..fafca91128b2e 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -1014,6 +1014,7 @@ static void zynq_gpio_remove(struct platform_device *pdev)
gpiochip_remove(&gpio->chip);
device_set_wakeup_capable(&pdev->dev, 0);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static struct platform_driver zynq_gpio_driver = {
--
2.51.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