* Re: [PATCH v2 1/2] dt-bindings: soc: xilinx: Add MYIR MYS-7Z020-V2 board
From: Krzysztof Kozlowski @ 2026-06-22 12:25 UTC (permalink / raw)
To: Liu Yu
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <SY3PPF19552C607716AE1AA440C85D348B6C7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On Fri, Jun 19, 2026 at 09:23:54PM +0800, Liu Yu wrote:
> Add compatible string for the MYIR MYS-7Z020-V2 board, based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> Signed-off-by: Liu Yu <f78fk@live.com>
You should not use outlook to send messages. That platform really sucks,
meaning:
1. You might not receive answer for me, because outlook/M$ treats kernel
maintainers as spam and does not care to change it,
2. outlook rewrites message ids making threading often broken.
Recommended is to use b4 relay in such case. You have been warned...
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Lorenzo Bianconi @ 2026-06-22 13:11 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260622123136.GC827683@horms.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
> On Fri, Jun 19, 2026 at 01:37:14PM +0200, Lorenzo Bianconi wrote:
> > airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> > index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> > real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> > channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> > 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> > accesses in the networking stack.
> > For example, allocating channel 0 then channel 3 results in
> > real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> > Fix this by computing real_num_tx_queues based on the highest active
> > channel index rather than using a simple counter, in both the allocation
> > and deletion paths.
> >
> > Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Thanks for the update since v1.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
Hi Simon,
thx for the review.
>
> FTR, there is an AI-generated review of this patch on sashiko.dev.
> I do not think that should impede the progress of this patch but
> you may want to consider it in the context of follow-up.
Even if it is not introduced by this patch, I do not think what is reported
by Sashiko is a real issue since airoha_eth driver implements
ndo_select_queue() callback and the selected queue is always in the range
[0, AIROHA_NUM_TX_RING[. HTB queues (in the range
[AIROHA_NUM_TX_RING, AIROHA_NUM_TX_RING + AIROHA_NUM_QOS_CHANNELS[) are just
'offloaded' and never used in the TC sw path. Agree?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Yury Norov @ 2026-06-22 13:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christophe Leroy (CS GROUP), 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: <20260622090826.20efadb3@fedora>
On Mon, Jun 22, 2026 at 09:08:26AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jun 2026 10:05:13 +0200
> "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
>
> > > There's been complaints about trace_printk() being defined in kernel.h as it
> > > can increase the compilation time. As it is only used by some developers for
> > > debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> > > cycles for those that do not ever care about it.
> >
> > Do we have a measurement of the increased compilation time ?
>
> I believe Yury does.
I re-run compilation is a more strict environment, and the difference
is negligible.
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Krzysztof Kozlowski @ 2026-06-22 13:12 UTC (permalink / raw)
To: Frieder Schrempf, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <085262ba-32e5-4011-8df3-5a677575b2db@kontron.de>
On 17/06/2026 13:36, Frieder Schrempf wrote:
> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
>> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>
>>> Some SoCs like the i.MX9 family allow full access to the fuses only
>>> through the secure enclave firmware API. Add a property to reference
>>> the secure enclave node and let the driver use the API.
>>>
>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>>> ---
>>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> index a8076d0e2737..14a6429f4a4c 100644
>>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> @@ -53,6 +53,10 @@ properties:
>>> reg:
>>> maxItems: 1
>>>
>>> + secure-enclave:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: A phandle to the secure enclave node
>>
>> Two things here:
>> 1. Here you describe what for is that phandle, how it is used by the
>> hardware. Currently the description repeats the property name and type,
>> so not much useful.
>
> Ok, agree.
>
>>
>> 2. If you access OTP via firmware, then this is completely different
>> interface than MMIO, thus:
>> A. reg is not appropriate
>> B. Device is very different thus it has different compatible and I even
>> claim should be in different binding. Devices having completely
>> different SW interface should not be in the same binding, at least
>> usually.
>>
>> If any of above is not accurate, then your commit msg should answer why
>> and give some background.
>
> Thanks for the feedback!
>
> The driver currently uses the limited MMIO (FSB) interface to access the
> OTPs. The intention is to support the firmware interface alongside the
> MMIO interface so the driver can pick the interface that is available
> (firmware might not be loaded) and fallback to MMIO.
>
> Following your argument would mean a driver deciding by itself which
> interface to use at runtime is not something we want to have in general,
> right?
No, the property fits DT, but above information should be in commit msg.
If this SoC has indeed both interfaces - MMIO and firmware calls - then
everything is in general fine. I assumed that is not the case and MMIO
is not really working.
What was confusing is that it feels like you are changing existing
interface, but why wasn't all this documented in the beginning? There is
imx9 in this binding already, so was it working? Was it not working at
all? Commit msg must clarify that.
>
> In turn this would mean we need two drivers, or at least two
> compatibles/bindings for something that is effectively the same hardware.
Driver design is orthogonal choice here.
It can reside in separate binding, if MMIO is still valid, but till
everything is not yet too complex can be also this binding file.
If it stays in this binding, then you need to restrict properties per
variant, so add if:then: block which will disallow the phandle for other
variants.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm: dts: xilinx: Add support for MYIR MYS-7Z020-V2 board
From: Michal Simek @ 2026-06-22 13:15 UTC (permalink / raw)
To: Liu Yu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel
In-Reply-To: <SY3PPF19552C60735AFA1041A0183DCA07CC7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On 6/19/26 15:23, Liu Yu wrote:
> Add device tree support for the MYIR MYS-7Z020-V2 board based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> The board supports:
> - UART serial console
> - MicroSD card interface
> - Gigabit Ethernet
> - QSPI NOR flash
> - GPIO-based user LEDs and push-button
>
> Link: https://www.myirtech.com/list.asp?id=708
this is pointing to Z-turn Board V2 and above you are using MYS-7Z020-V2
which is not available on this link.
Why should this be merged? What's so special about this board?
Zynq went to production in 2013. Why should we merge description for "unknown"
board using 13 years old chip?
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH RFC v8 04/24] arm64: Introduce por_elx_set_pkey_perms() helper
From: David Hildenbrand (Arm) @ 2026-06-22 13:16 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <20260526-kpkeys-v8-4-eaaacdacc67c@arm.com>
On 5/26/26 13:15, Kevin Brodsky wrote:
> Introduce a helper that sets the permissions of a given pkey
> (POIndex) in the POR_ELx format, and make use of it in
> arch_set_user_pkey_access().
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/por.h | 7 +++++++
> arch/arm64/mm/mmu.c | 26 ++++++++++----------------
> 2 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/por.h b/arch/arm64/include/asm/por.h
> index d913d5b529e4..bffb4d2b1246 100644
> --- a/arch/arm64/include/asm/por.h
> +++ b/arch/arm64/include/asm/por.h
> @@ -31,4 +31,11 @@ static inline bool por_elx_allows_exec(u64 por, u8 pkey)
> return perm & POE_X;
> }
>
> +static inline u64 por_elx_set_pkey_perms(u64 por, u8 pkey, u64 perms)
> +{
> + u64 shift = POR_ELx_PERM_SHIFT(pkey);
> +
> + return (por & ~(POE_MASK << shift)) | (perms << shift);
> +}
> +
> #endif /* _ASM_ARM64_POR_H */
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index dd85e093ffdb..493310cf0486 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -2339,8 +2339,8 @@ void __cpu_replace_ttbr1(pgd_t *pgdp, bool cnp)
> #ifdef CONFIG_ARCH_HAS_PKEYS
> int arch_set_user_pkey_access(int pkey, unsigned long init_val)
> {
> - u64 new_por;
> - u64 old_por;
> + u64 new_perms;
You should spell out the renaming of the variable.
Given that perms is 4bit per key, should we use a u8 for it instead?
> + u64 por;
>
> if (!system_supports_poe())
> return -ENOSPC;
> @@ -2354,25 +2354,19 @@ int arch_set_user_pkey_access(int pkey, unsigned long init_val)
> return -EINVAL;
>
> /* Set the bits we need in POR: */
> - new_por = POE_RWX;
> + new_perms = POE_RWX;
> if (init_val & PKEY_DISABLE_WRITE)
> - new_por &= ~POE_W;
> + new_perms &= ~POE_W;
> if (init_val & PKEY_DISABLE_ACCESS)
> - new_por &= ~POE_RW;
> + new_perms &= ~POE_RW;
> if (init_val & PKEY_DISABLE_READ)
> - new_por &= ~POE_R;
> + new_perms &= ~POE_R;
> if (init_val & PKEY_DISABLE_EXECUTE)
> - new_por &= ~POE_X;
> + new_perms &= ~POE_X;
>
> - /* Shift the bits in to the correct place in POR for pkey: */
> - new_por = POR_ELx_PERM_PREP(pkey, new_por);
> -
> - /* Get old POR and mask off any old bits in place: */
> - old_por = read_sysreg_s(SYS_POR_EL0);
> - old_por &= ~(POE_MASK << POR_ELx_PERM_SHIFT(pkey));
> -
> - /* Write old part along with new part: */
> - write_sysreg_s(old_por | new_por, SYS_POR_EL0);
> + por = read_sysreg_s(SYS_POR_EL0);
> + por = por_elx_set_pkey_perms(por, pkey, new_perms);
> + write_sysreg_s(por, SYS_POR_EL0);
Was wondering whether to move reading+writing of the register into the same
helper, but you cannot reuse this exactly the same way for SYS_POR_EL1 as it seems.
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
From: Adam Thiede @ 2026-06-22 13:23 UTC (permalink / raw)
To: Gary Bisson
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <ajka2220depklK1_@owl5>
On 6/22/26 06:22, Gary Bisson wrote:
> Hi,
>
> On Thu, Jun 18, 2026 at 04:06:28PM -0500, Adam Thiede wrote:
>> On 1/20/26 05:36, Gary Bisson wrote:
>>> Some bridges, such as the TI SN65DSI83, require the HS clock to be
>>> running in order to lock its PLL during its own pre-enable function.
>>>
>>> Without this change, the bridge gives the following error:
>>> sn65dsi83 14-002c: failed to lock PLL, ret=-110
>>> sn65dsi83 14-002c: Unexpected link status 0x01
>>> sn65dsi83 14-002c: reset the pipe
>>>
>>> Move the necessary functions from enable to pre-enable.
>>>
>>> Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
>>> ---
>>> Tested on Tungsten510 module with sn65dsi83 + tm070jdhg30 panel.
>>>
>>> Left mtk_dsi_set_mode() as part of the enable function to mimic what is
>>> done in the Samsung DSIM driver which is known to be working the TI
>>> bridge.
>>> ---
>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 35 +++++++++++++++++------------------
>>> 1 file changed, 17 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> index 0e2bcd5f67b7..b560245d1be9 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> @@ -672,6 +672,21 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
>>> }
>>> }
>>> +static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
>>> +{
>>> + if (!dsi->lanes_ready) {
>>> + dsi->lanes_ready = true;
>>> + mtk_dsi_rxtx_control(dsi);
>>> + usleep_range(30, 100);
>>> + mtk_dsi_reset_dphy(dsi);
>>> + mtk_dsi_clk_ulp_mode_leave(dsi);
>>> + mtk_dsi_lane0_ulp_mode_leave(dsi);
>>> + mtk_dsi_clk_hs_mode(dsi, 0);
>>> + usleep_range(1000, 3000);
>>> + /* The reaction time after pulling up the mipi signal for dsi_rx */
>>> + }
>>> +}
>>> +
>>> static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>>> {
>>> struct device *dev = dsi->host.dev;
>>> @@ -724,6 +739,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>>> mtk_dsi_set_vm_cmd(dsi);
>>> mtk_dsi_config_vdo_timing(dsi);
>>> mtk_dsi_set_interrupt_enable(dsi);
>>> + mtk_dsi_lane_ready(dsi);
>>> + mtk_dsi_clk_hs_mode(dsi, 1);
>>> return 0;
>>> err_disable_engine_clk:
>>> @@ -769,30 +786,12 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>>> dsi->lanes_ready = false;
>>> }
>>> -static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
>>> -{
>>> - if (!dsi->lanes_ready) {
>>> - dsi->lanes_ready = true;
>>> - mtk_dsi_rxtx_control(dsi);
>>> - usleep_range(30, 100);
>>> - mtk_dsi_reset_dphy(dsi);
>>> - mtk_dsi_clk_ulp_mode_leave(dsi);
>>> - mtk_dsi_lane0_ulp_mode_leave(dsi);
>>> - mtk_dsi_clk_hs_mode(dsi, 0);
>>> - usleep_range(1000, 3000);
>>> - /* The reaction time after pulling up the mipi signal for dsi_rx */
>>> - }
>>> -}
>>> -
>>> static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>>> {
>>> if (dsi->enabled)
>>> return;
>>> - mtk_dsi_lane_ready(dsi);
>>> mtk_dsi_set_mode(dsi);
>>> - mtk_dsi_clk_hs_mode(dsi, 1);
>>> -
>>> mtk_dsi_start(dsi);
>>> dsi->enabled = true;
>>>
>>> ---
>>> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
>>> change-id: 20260120-mtkdsi-29e4c84e7b38
>>>
>>> Best regards,
>>
>> Hello,
>> This commit was part of 7.1 and caused a problem for me.
>> I'm running postmarketOS (basically Alpine Linux) on a Lenovo C330
>> chromebook with a Mediatek MT8173 processor.
>> The problem: when the display on my laptop powers off (via suspend or idle,
>> like xset dpms off) the picture does not come back when the display powers
>> back on (from resume). The display backlight comes on and brightness is
>> adjustable but there is no picture. The only fix is to reboot.
>>
>> Reverting this commit and applying it as a patch on top of 7.1 addresses the
>> issue for me.
>>
>> You can view the config I'm using here:
>> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8819
>>
>> Is there any sort of testing or other debugging info I can provide to help
>> address this issue?
>
> Thanks for reporting the issue, could you share some logs? Is the driver
> saying anything during resume? Also, what type of panel is used on that
> chromebook?
>
> Thanks,
> Gary
The curious thing is that there are no real logs in dmesg or
/var/log/messages about this. This picture just fails to come back. If
there are some kernel params I can set to get deeper logging, that would
help, but I'm not aware of any.
I think the panel is a "BOE NV116WHM-T00" - I used this command to get
info: cat /sys/class/drm/card0-eDP-1/edid | edid-decode
Output: https://termbin.com/8nbd
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: display: vop2: Add missing reset properties
From: Krzysztof Kozlowski @ 2026-06-22 13:25 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Sandy Huang, Heiko Stübner, Andy Yan, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
kernel, Andy Yan, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260617-dw-hdmi-qp-yuv-v1-1-a665cfd06d7d@collabora.com>
On Wed, Jun 17, 2026 at 09:51:54PM +0300, Cristian Ciocaltea wrote:
> Document the VOP2 resets corresponding to the AXI, AHB and DCLK_VP0..2
> clocks, which are common to all supported SoCs, plus DCLK_VP3 which is
> provided only on RK3588.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> .../bindings/display/rockchip/rockchip-vop2.yaml | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: spi: st,stm32-qspi: Add power-domains property
From: Krzysztof Kozlowski @ 2026-06-22 13:26 UTC (permalink / raw)
To: Patrice Chotard
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Christophe Kerello, linux-spi,
devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-add_power_domain_for_qpsi-v1-1-4d7e57bcfb9a@foss.st.com>
On Thu, Jun 18, 2026 at 08:46:35AM +0200, Patrice Chotard wrote:
> STM32 QSPI may be in a power domain. Allow a single 'power-domains'
> entry for STM32 QSPI.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
> Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC v8 05/24] arm64: Implement asm/kpkeys.h using POE
From: David Hildenbrand (Arm) @ 2026-06-22 13:35 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <20260526-kpkeys-v8-5-eaaacdacc67c@arm.com>
On 5/26/26 13:15, Kevin Brodsky wrote:
> Implement the kpkeys interface if CONFIG_ARM64_POE is enabled.
> The permissions for KPKEYS_PKEY_DEFAULT (pkey 0) are set to RWX as
> this pkey is also used for code mappings.
>
> To allow <asm/kpkeys.h> to be included from assembly, also add
> appropriate #ifdef's to <asm/por.h>.
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/kpkeys.h | 59 +++++++++++++++++++++++++++++++++++++++++
> arch/arm64/include/asm/por.h | 4 +++
> 2 files changed, 63 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kpkeys.h b/arch/arm64/include/asm/kpkeys.h
> new file mode 100644
> index 000000000000..4dbfeb3dfcfe
> --- /dev/null
> +++ b/arch/arm64/include/asm/kpkeys.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_KPKEYS_H
> +#define __ASM_KPKEYS_H
> +
> +#include <asm/barrier.h>
> +#include <asm/cpufeature.h>
> +#include <asm/por.h>
> +
> +#include <asm-generic/kpkeys.h>
> +
> +/*
> + * Equivalent to por_set_kpkeys_context(0, KPKEYS_CTX_DEFAULT), but can also be
> + * used in assembly.
> + */
> +#define POR_EL1_INIT POR_ELx_PERM_PREP(KPKEYS_PKEY_DEFAULT, POE_RWX)
Okay, this matches
#define POR_EL0_INIT POR_ELx_PERM_PREP(0, POE_RWX)
Is there a good reason we need KPKEYS_PKEY_DEFAULT at all (and not similarly
just hardcode it to 0)?
Just wondering, because apparently we didn't care about adding an indicator for
user space pkey 0.
> +
> +#ifndef __ASSEMBLY__
> +
> +static inline bool arch_supports_kpkeys(void)
> +{
> + return system_supports_poe();
> +}
> +
> +#ifdef CONFIG_ARM64_POE
> +
> +static inline u64 por_set_kpkeys_context(u64 por, int ctx)
> +{
> + por = por_elx_set_pkey_perms(por, KPKEYS_PKEY_DEFAULT, POE_RWX);
> +
> + return por;
Why not
return por_elx_set_pkey_perms(por, KPKEYS_PKEY_DEFAULT, POE_RWX);
?
In light of API discussions, it would be nicer if arch_kpkeys_set_context()
would just return the old context. But that would mean that restoring the
context would require another read_sysreg_s(SYS_POR_EL1);
So instead of returning magic register values, that should be wrapped in some
arch state struct as mentioned as reply to a previous patch.
> +}
> +
> +static __always_inline void __kpkeys_set_pkey_reg_nosync(u64 pkey_reg)
> +{
> + write_sysreg_s(pkey_reg, SYS_POR_EL1);
> +}
> +
> +static __always_inline u64 arch_kpkeys_set_context(int ctx)
> +{
> + u64 prev_por = read_sysreg_s(SYS_POR_EL1);
> + u64 new_por = por_set_kpkeys_context(prev_por, ctx);
Both can be const.
But maybe you just use a single "por" variable.
> +
> + __kpkeys_set_pkey_reg_nosync(new_por);
> + isb();
> +
> + return prev_por;
> +}
> +
> +static __always_inline void arch_kpkeys_restore_pkey_reg(u64 pkey_reg)
> +{
> + __kpkeys_set_pkey_reg_nosync(pkey_reg);
> + isb();
Why is that isb() for both callers outside of the function? Do you expect
another user that doesn't need the isb?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Marek Vasut @ 2026-06-22 13:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <CAMuHMdUEPR0xWXRwLjBt5sF7i4HxcDLHCQGmc=gGvFmHRDv-Jw@mail.gmail.com>
On 6/22/26 12:35 PM, Geert Uytterhoeven wrote:
Hello Geert,
> On Sun, 21 Jun 2026 at 04:51, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
>> which already has that soc: label. The soc: label is useful in U-Boot
>> where it is used in U-Boot extras DT fragments.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> For the whole series:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-devel for v7.3, squashed into a single
> commit. Unfortunately there is no cover letter, so I will have to add
> all nine Link-tags.
Is that why cover letter helps you ?
If so, I will start generating ones ?
Thank you for your help !
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Kiryl Shutsemau @ 2026-06-22 13:56 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
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
In-Reply-To: <868q8asj1u.wl-maz@kernel.org>
On Fri, Jun 19, 2026 at 03:26:21PM +0100, Marc Zyngier wrote:
> > Does your firmware set ICC_CTLR_EL1.PMHE? I'd be curious to see the
> > numbers if the DSB was omitted on the enable path.
>
> I certainly don't observe this sort of overhead on the HW I have
> access to, and would like to understand where this is coming from with
> actual profiling data.
Full disclosure: the ~66% figures come from internal testing about a year ago.
I no longer have the details of the machine it ran on and can't confirm whether
ICC_CTLR_EL1.PMHE was set there -- it may well have been. I shouldn't have
carried those numbers forward without being able to stand behind them, so
please disregard them.
Here are fresh numbers from NVIDIA Grace (Neoverse V2). Importantly, this
box reports:
GICv3: Pseudo-NMIs enabled using relaxed ICC_PMR_EL1 synchronisation
i.e. PMHE == 0, so the synchronising DSB on the unmask path is already
patched to a NOP (ARM64_HAS_GIC_PRIO_RELAXED_SYNC). What's left is the
floor cost of PMR-based masking itself plus the PMR save/restore on
exception entry/exit -- not the DSB. So this is the case Catalin asked
about (DSB omitted), and there is still a measurable cost.
A trivial single-threaded gettid() loop (1e6 calls, median of 5,
performance governor, ASLR off):
pseudo_nmi=0 (DAIF): 178.4 ns/call
pseudo_nmi=1 (PMR): 252.5 ns/call
delta: +74.1 ns/call (~230-250 cycles)
+41.5% wall time / 0.706 throughput
--- u-bench.c ---
#include <unistd.h>
#include <sys/syscall.h>
#include <time.h>
#include <stdio.h>
int main(void) {
struct timespec a, b;
clock_gettime(CLOCK_MONOTONIC, &a);
for (long i = 0; i < 1000000; i++)
syscall(SYS_gettid);
clock_gettime(CLOCK_MONOTONIC, &b);
printf("%f ns\n", (b.tv_sec-a.tv_sec)*1e9 + (b.tv_nsec-a.tv_nsec));
return 0;
}
will-it-scale agrees independently. sched_yield (ops/s, median of 5):
1 task 72 tasks
pseudo_nmi=0 3,195,656 230,824,534
pseudo_nmi=1 2,253,753 163,914,837
ratio 0.705 0.710
The ratio is flat across the whole 1-to-72 sweep, so -- relevant to the
scalability question -- it's a constant per-syscall tax, not a contention
effect. The impact tracks syscall/exception density: page_fault1, a more
realistic workload, stays within ~5%.
> The direction of travel is to deprecate SDEI. I wouldn't add more stuff
> on top of this interface.
I understand FEAT_NMI is the long-term answer, and I'm not arguing against
deprecating SDEI. My concern is the gap in between. By our estimate it's
10+ years before the last non-FEAT_NMI machine retires from the fleet --
for scale, we're still running Skylake today. So there's roughly a
decade where a large installed base has neither FEAT_NMI nor affordable
pseudo-NMI, and no way to reach a DAIF-masked CPU for an all-CPU
backtrace or to capture a wedged CPU in a crash dump. That's the
functional gap this series tries to cover.
Given the deprecation direction, I deliberately kept the SDEI footprint as
small as I could. The series adds no new firmware interface and no vendor
SMC -- it uses only the standard software-signalled event (event 0) via
SDEI_EVENT_SIGNAL, which is already present on these systems for
firmware-first RAS (APEI/GHES). And SDEI is only ever invoked in a "bad
state": to deliver a backtrace signal to a CPU that a normal IPI can't
reach, or to stop a CPU that ignored the stop IPIs. Nothing on any hot or
steady-state path touches it.
If even that minimal use is unacceptable on a deprecated interface, I'd
rather know now and redirect the effort -- but I'd appreciate a pointer to
what should cover this gap for existing silicon in the meantime.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frank Li @ 2026-06-22 14:14 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Krzysztof Kozlowski, Frieder Schrempf, Srinivas Kandagatla,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <085262ba-32e5-4011-8df3-5a677575b2db@kontron.de>
On Wed, Jun 17, 2026 at 01:36:30PM +0200, Frieder Schrempf wrote:
> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> > On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >>
> >> Some SoCs like the i.MX9 family allow full access to the fuses only
> >> through the secure enclave firmware API. Add a property to reference
> >> the secure enclave node and let the driver use the API.
> >>
> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> ---
> >> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> index a8076d0e2737..14a6429f4a4c 100644
> >> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> @@ -53,6 +53,10 @@ properties:
> >> reg:
> >> maxItems: 1
> >>
> >> + secure-enclave:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description: A phandle to the secure enclave node
> >
> > Two things here:
> > 1. Here you describe what for is that phandle, how it is used by the
> > hardware. Currently the description repeats the property name and type,
> > so not much useful.
>
> Ok, agree.
>
> >
> > 2. If you access OTP via firmware, then this is completely different
> > interface than MMIO, thus:
> > A. reg is not appropriate
> > B. Device is very different thus it has different compatible and I even
> > claim should be in different binding. Devices having completely
> > different SW interface should not be in the same binding, at least
> > usually.
> >
> > If any of above is not accurate, then your commit msg should answer why
> > and give some background.
>
> Thanks for the feedback!
>
> The driver currently uses the limited MMIO (FSB) interface to access the
> OTPs. The intention is to support the firmware interface alongside the
> MMIO interface so the driver can pick the interface that is available
> (firmware might not be loaded) and fallback to MMIO.
Does ELE and MMIO access the same bank of fuse? If access the same bank,
why not always use MMIO. Any beneafit from ELE firmware?
Frank
>
> Following your argument would mean a driver deciding by itself which
> interface to use at runtime is not something we want to have in general,
> right?
>
> In turn this would mean we need two drivers, or at least two
> compatibles/bindings for something that is effectively the same hardware.
>
> Actually, my first RFC approach [1] was to create a separate driver. But
> in the end it seemed very weird to have two drivers and two DT nodes for
> the same hardware block. Also I have no idea what happens if both
> interfaces are used at the same time.
>
> The other idea from back then was to replace the MMIO (FSB) interface
> with ELE, but this would mean that we rely on the proprietary ELE
> firmware to be available for simple things like reading a MAC address,
> which is not desirable either, I guess.
>
> In which direction should I move on with this?
>
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
>
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marek Vasut @ 2026-06-22 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Marc Zyngier, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdUxT87M1oQvPP_h4YX4vXFaVbbG+LCG8EdmuLTuHNtybQ@mail.gmail.com>
On 6/22/26 11:52 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
>> return true;
>> }
>>
>> -static bool __maybe_unused its_enable_rk3568002(void *data)
>> +static const char * const dma_32bit_impaired_platforms[] = {
>> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
>> + "rockchip,rk3566",
>> + "rockchip,rk3568",
>> +#endif
>> + NULL,
>> +};
>> +
>> +static bool __maybe_unused its_enable_dma32(void *data)
>
> __maybe_unused can be dropped...
I will fix that in V3. Thank you !
^ permalink raw reply
* [PATCH 0/4] media: add and use fwnode_graph_for_each_endpoint_scoped()
From: Frank.Li @ 2026-06-22 14:30 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
Add new helper macro fwnode_graph_for_each_endpoint_scoped() and use it
simplify media code.
Typical example should qualcomm's driver (camss.c), the v4l2_mc.c and
rkisp1-dev.c only silience improvement.
Anyways, *_for_each_*_scoped() already use widely and make code clean.
Build test only.
Sakari Ailus:
when I try to improve the patch
"Add common helper library for 1-to-1 subdev registration", I found need
camss.c pattern, so I create this small improvement firstly.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (4):
device property: Introduce fwnode_graph_for_each_endpoint_scoped()
media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
media: rkisp1: use fwnode_graph_for_each_endpoint_scoped() to simplify code
media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simpifly code
drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 +---
drivers/media/v4l2-core/v4l2-mc.c | 5 +----
include/linux/property.h | 5 +++++
4 files changed, 12 insertions(+), 19 deletions(-)
---
base-commit: 3ce97bd3c4f18608335e709c24d6a40e7036cab8
change-id: 20260620-fw_scoped-5dab644510a1
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: Frank.Li @ 2026-06-22 14:30 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260622-fw_scoped-v1-0-a37d0aac0a68@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Similar to recently propose for_each_child_of_node_scoped() this new
version of the loop macro instantiates a new local struct fwnode_handle *
that uses the __free(fwnode_handle) auto cleanup handling so that if a
reference to a node is held on early exit from the loop the reference will
be released. If the loop runs to completion, the child pointer will be NULL
and no action will be taken.
The reason this is useful is that it removes the need for
fwnode_handle_put() on early loop exits. If there is a need to retain the
reference, then return_ptr(child) or no_free_ptr(child) may be used to
safely disable the auto cleanup.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
include/linux/property.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/property.h b/include/linux/property.h
index 14c304db46648..ade194c462d42 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -545,6 +545,11 @@ unsigned int fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child; \
child = fwnode_graph_get_next_endpoint(fwnode, child))
+#define fwnode_graph_for_each_endpoint_scoped(fwnode, child) \
+ for (struct fwnode_handle *child __free(fwnode_handle) = \
+ fwnode_graph_get_next_endpoint(fwnode, NULL); \
+ child; child = fwnode_graph_get_next_endpoint(fwnode, child))
+
int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
struct fwnode_endpoint *endpoint);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: Frank.Li @ 2026-06-22 14:30 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260622-fw_scoped-v1-0-a37d0aac0a68@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
code.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/media/v4l2-core/v4l2-mc.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-mc.c
index 937d358697e19..5d7fcd67dc42e 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -324,12 +324,10 @@ EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
struct media_pad *sink, u32 flags)
{
- struct fwnode_handle *endpoint;
-
if (!(sink->flags & MEDIA_PAD_FL_SINK))
return -EINVAL;
- fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
+ fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint) {
struct fwnode_handle *remote_ep;
int src_idx, sink_idx, ret;
struct media_pad *src;
@@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
src_sd->entity.name, src_idx,
sink->entity->name, sink_idx, ret);
- fwnode_handle_put(endpoint);
return ret;
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] media: rkisp1: use fwnode_graph_for_each_endpoint_scoped() to simplify code
From: Frank.Li @ 2026-06-22 14:30 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260622-fw_scoped-v1-0-a37d0aac0a68@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use fwnode_graph_for_each_endpoint_scoped() to simplify code.
No functional changes.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 1791c02a40ae1..f90e01301943c 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -187,7 +187,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
{
struct v4l2_async_notifier *ntf = &rkisp1->notifier;
struct fwnode_handle *fwnode = dev_fwnode(rkisp1->dev);
- struct fwnode_handle *ep;
unsigned int index = 0;
int ret = 0;
@@ -195,7 +194,7 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
ntf->ops = &rkisp1_subdev_notifier_ops;
- fwnode_graph_for_each_endpoint(fwnode, ep) {
+ fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
struct fwnode_handle *port;
struct v4l2_fwnode_endpoint vep = { };
struct rkisp1_sensor_async *rk_asd;
@@ -286,7 +285,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
}
if (ret) {
- fwnode_handle_put(ep);
v4l2_async_nf_cleanup(ntf);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simpifly code
From: Frank.Li @ 2026-06-22 14:30 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260622-fw_scoped-v1-0-a37d0aac0a68@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use fwnode_graph_for_each_endpoint_scoped() to simpifly code.
No functional changes.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 2123f6388e3d7..23f3cc30a15a5 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4793,30 +4793,23 @@ static int camss_parse_endpoint_node(struct device *dev,
static int camss_parse_ports(struct camss *camss)
{
struct device *dev = camss->dev;
- struct fwnode_handle *fwnode = dev_fwnode(dev), *ep;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
int ret;
- fwnode_graph_for_each_endpoint(fwnode, ep) {
+ fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
struct camss_async_subdev *csd;
csd = v4l2_async_nf_add_fwnode_remote(&camss->notifier, ep,
typeof(*csd));
- if (IS_ERR(csd)) {
- ret = PTR_ERR(csd);
- goto err_cleanup;
- }
+ if (IS_ERR(csd))
+ return PTR_ERR(csd);
ret = camss_parse_endpoint_node(dev, ep, csd);
if (ret < 0)
- goto err_cleanup;
+ return ret;
}
return 0;
-
-err_cleanup:
- fwnode_handle_put(ep);
-
- return ret;
}
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 5/5] dmaengine: sun6i-dma: Add support for Allwinner A733 DMA controller
From: Frank Li @ 2026-06-22 14:35 UTC (permalink / raw)
To: Yuanshen Cao
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel
In-Reply-To: <20260622-sun60i-a733-dma-v3-5-f697ef296cbc@gmail.com>
On Mon, Jun 22, 2026 at 01:36:27AM +0000, Yuanshen Cao wrote:
> Support Allwinner A733 DMA controller. Define new register offsets,
> bitfield mappings and dma_config required for the A733, which slightly
> differs from the older `sun6i` DMA controllers.
>
> Changes:
> - New register macros for A733 interrupt enable `DMA_IRQ_EN_A733`,
> status `DMA_IRQ_STAT_A733`, and channel count `DMA_IRQ_CHAN_NR_A733`.
> - New `SRC_HIGH_ADDR_32G` and `DST_HIGH_ADDR_32G` macro to handle the
> 32G high-address field in the LLI.
> - Implemented `sun6i_dma_set_addr_a733` and A733-specific interrupt
> register accessors.
> - Added `sun60i_a733_dma_cfg`, which ties all the refactored
> functionality together for this specific hardware.
>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 196a0d73b221..4808015934cc 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -52,6 +52,15 @@
> #define SUNXI_H3_SECURE_REG 0x20
> #define SUNXI_H3_DMA_GATE 0x28
> #define SUNXI_H3_DMA_GATE_ENABLE 0x4
> +
> +/*
> + * sun60i specific registers
> + */
> +#define DMA_IRQ_EN_A733(x) ((x) * 0x40 + 0x134)
> +#define DMA_IRQ_STAT_A733(x) ((x) * 0x40 + 0x138)
> +
> +#define DMA_IRQ_CHAN_NR_A733 1
> +
> /*
> * Channels specific registers
> */
> @@ -100,6 +109,8 @@
> */
> #define SRC_HIGH_ADDR(x) (((x) & 0x3U) << 16)
> #define DST_HIGH_ADDR(x) (((x) & 0x3U) << 18)
> +#define SRC_HIGH_ADDR_32G(x) (((x) & 0x7U) << 11)
> +#define DST_HIGH_ADDR_32G(x) (((x) & 0x7U) << 15)
Because the previous code use this pattern, I provide my reviewed-by tags.
I suggest change to use GEN_MASK and FIELD_PREP macro in future.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> /*
> * Various hardware related defines
> @@ -257,6 +268,23 @@ static inline void sun6i_dma_dump_com_regs(struct sun6i_dma_dev *sdev)
> DMA_STAT, readl(sdev->base + DMA_STAT));
> }
>
> +static inline void sun6i_dma_dump_com_regs_a733(struct sun6i_dma_dev *sdev)
> +{
> + int i;
> +
> + for (i = 0; i < sdev->num_pchans / sdev->cfg->num_channels_per_reg; i++) {
> + dev_dbg(sdev->slave.dev, "Common register:\n"
> + "chan num %d\n"
> + "\tmask(%04x): 0x%08x\n"
> + "\tpend(%04x): 0x%08x\n"
> + "\tstats(%04x): 0x%08x\n",
> + i,
> + DMA_IRQ_EN_A733(i), readl(sdev->base + DMA_IRQ_EN_A733(i)),
> + DMA_IRQ_STAT_A733(i), readl(sdev->base + DMA_IRQ_STAT_A733(i)),
> + DMA_STAT, readl(sdev->base + DMA_STAT));
> + }
> +}
> +
> static inline void sun6i_dma_dump_chan_regs(struct sun6i_dma_dev *sdev,
> struct sun6i_pchan *pchan)
> {
> @@ -360,21 +388,41 @@ static u32 sun6i_read_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg)
> return readl(sdev->base + DMA_IRQ_EN(irq_reg));
> }
>
> +static u32 sun6i_read_irq_en_a733(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_EN_A733(irq_reg));
> +}
> +
> static void sun6i_write_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> {
> writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> }
>
> +static void sun6i_write_irq_en_a733(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> +{
> + writel(irq_val, sdev->base + DMA_IRQ_EN_A733(irq_reg));
> +}
> +
> static u32 sun6i_read_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg)
> {
> return readl(sdev->base + DMA_IRQ_STAT(irq_reg));
> }
>
> +static u32 sun6i_read_irq_stat_a733(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_STAT_A733(irq_reg));
> +}
> +
> static void sun6i_write_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> {
> writel(status, sdev->base + DMA_IRQ_STAT(irq_reg));
> }
>
> +static void sun6i_write_irq_stat_a733(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> +{
> + writel(status, sdev->base + DMA_IRQ_STAT_A733(irq_reg));
> +}
> +
> static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
> {
> struct sun6i_desc *txd = pchan->desc;
> @@ -695,6 +743,17 @@ static void sun6i_dma_set_addr_a100(struct sun6i_dma_dev *sdev,
> DST_HIGH_ADDR(upper_32_bits(dst));
> }
>
> +static void sun6i_dma_set_addr_a733(struct sun6i_dma_dev *sdev,
> + struct sun6i_dma_lli *v_lli,
> + dma_addr_t src, dma_addr_t dst)
> +{
> + v_lli->src = lower_32_bits(src);
> + v_lli->dst = lower_32_bits(dst);
> +
> + v_lli->para |= SRC_HIGH_ADDR_32G(upper_32_bits(src)) |
> + DST_HIGH_ADDR_32G(upper_32_bits(dst));
> +}
> +
> static inline void sun6i_dma_set_addr(struct sun6i_dma_dev *sdev,
> struct sun6i_dma_lli *v_lli,
> dma_addr_t src, dma_addr_t dst)
> @@ -1339,6 +1398,33 @@ static struct sun6i_dma_config sun50i_h6_dma_cfg = {
> SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> +/*
> + * The A733 binding uses the number of dma channels from the
> + * device tree node.
> + */
> +static struct sun6i_dma_config sun60i_a733_dma_cfg = {
> + .clock_autogate_enable = sun6i_enable_clock_autogate_h3,
> + .set_burst_length = sun6i_set_burst_length_h3,
> + .set_drq = sun6i_set_drq_h6,
> + .set_mode = sun6i_set_mode_h6,
> + .set_addr = sun6i_dma_set_addr_a733,
> + .dump_com_regs = sun6i_dma_dump_com_regs_a733,
> + .read_irq_en = sun6i_read_irq_en_a733,
> + .write_irq_en = sun6i_write_irq_en_a733,
> + .read_irq_stat = sun6i_read_irq_stat_a733,
> + .write_irq_stat = sun6i_write_irq_stat_a733,
> + .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .num_channels_per_reg = DMA_IRQ_CHAN_NR_A733,
> + .has_mbus_clk = true,
> +};
> +
> /*
> * The V3s have only 8 physical channels, a maximum DRQ port id of 23,
> * and a total of 24 usable source and destination endpoints.
> @@ -1375,6 +1461,7 @@ static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
> { .compatible = "allwinner,sun50i-a100-dma", .data = &sun50i_a100_dma_cfg },
> { .compatible = "allwinner,sun50i-h6-dma", .data = &sun50i_h6_dma_cfg },
> + { .compatible = "allwinner,sun60i-a733-dma", .data = &sun60i_a733_dma_cfg },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Geert Uytterhoeven @ 2026-06-22 14:37 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <8cb1c3cb-3d8f-4e76-99e9-ad78ee149556@mailbox.org>
Hi Marek,
On Mon, 22 Jun 2026 at 15:56, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 6/22/26 12:35 PM, Geert Uytterhoeven wrote:
> > On Sun, 21 Jun 2026 at 04:51, Marek Vasut
> > <marek.vasut+renesas@mailbox.org> wrote:
> >> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
> >> which already has that soc: label. The soc: label is useful in U-Boot
> >> where it is used in U-Boot extras DT fragments.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > For the whole series:
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > i.e. will queue in renesas-devel for v7.3, squashed into a single
> > commit. Unfortunately there is no cover letter, so I will have to add
> > all nine Link-tags.
>
> Is that why cover letter helps you ?
Another reason is that my scripting turns cover letters into empty
commits in my local tree, serving as separators between patch series.
> If so, I will start generating ones ?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Ben Dooks @ 2026-06-22 14:37 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Ben Dooks, Maxime Chevallier, netdev,
linux-stm32, linux-arm-kernel, linux-kernel
The print in ndesc_display_ring() sends the des2 and des3
to the pr_info() without passing them through the relevant
conversion to cpu order.
Fix the (prototype) sparse warnings by using le32_to_cpu():
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index c4b613564f87..74c9b7b1fe8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -258,7 +258,7 @@ static void ndesc_display_ring(void *head, unsigned int size, bool rx,
pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x",
i, &dma_addr,
(unsigned int)x, (unsigned int)(x >> 32),
- p->des2, p->des3);
+ le32_to_cpu(p->des2), le32_to_cpu(p->des3));
p++;
}
pr_info("\n");
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Liam R. Howlett @ 2026-06-22 14:50 UTC (permalink / raw)
To: Barry Song
Cc: Matthew Wilcox, Suren Baghdasaryan, Lorenzo Stoakes,
David Hildenbrand (Arm), akpm, linux-mm, vbabka, rppt, mhocko,
jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4ybg5LGYopTUJTh5R2rN6X3uR9xoJSL+RdTYVtm1-xqLg@mail.gmail.com>
On 26/06/22 08:15AM, Barry Song wrote:
> On Mon, Jun 22, 2026 at 4:49 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Sat, Jun 20, 2026 at 04:48:57PM -0700, Suren Baghdasaryan wrote:
> > > Just checking in on the followup plans. IIUC the RFC mentioned will
> > > try to implement the solution we discussed at LSFMM: splitting
> > > VM_FAULT_RETRY into two flags - one for retrying under per-VMA locks
> > > and another one to fallback to mmap_lock.
> >
> > I continue to hate this idea. I don't believe that those who were
> > pushing for it have ever tried to understand the whole fault path.
> > It's utterly byzantine.
> >
> > I defy anyone to make sense of this:
> >
> > /*
> > * NOTE! This will make us return with VM_FAULT_RETRY, but with
> > * the fault lock still held. That's how FAULT_FLAG_RETRY_NOWAIT
> > * is supposed to work. We have way too many special cases..
> > */
> > if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> > return 0;
> >
> > *fpin = maybe_unlock_mmap_for_io(vmf, *fpin);
> > if (vmf->flags & FAULT_FLAG_KILLABLE) {
> > if (__folio_lock_killable(folio)) {
> > /*
> > * We didn't have the right flags to drop the
> > * fault lock, but all fault_handlers only check
> > * for fatal signals if we return VM_FAULT_RETRY,
> > * so we need to drop the fault lock here and
> > * return 0 if we don't have a fpin.
> > */
> > if (*fpin == NULL)
> > release_fault_lock(vmf);
> > return 0;
> > }
> >
> > Wed need to simplify the fault path, not add additional complexity.
> > Josef has said he wouldn't've done the lock dropping had we had per-VMA
> > locks. We should rip it out.
>
> I think you have agreed that, at least for anon vma, we can
> keep the current policy, since anon vma is much more volatile
> than file vma.
I don't think any of the above has to do with anon vmas. Does any anon
vma handling have anything to do with your problem?
This would be needed if anon vmas were being faulted while being
unmapped or merged? Do we really need a fast path for that? Note that
anon vmas cannot be merged if the vma chain... you know what, I wonder
how many people know what I'm talking about here... Let's just say that
they can't be merged if they were around for a fork.
So, then, we're looking at anon vmas taking the mmap lock on:
1. single task anon vmas being expanded and faulted at the same time
2. single task anon vmas being unmapped and faulted at the same time
I think that's it?
But maybe I missed something critical about your use case here?
I don't understand why you are involving anon vmas in this discussion,
so I must have missed something with your IO completion issue. Is there
an anon vma causing your priority inversion?
> Concurrent page faults and VMA modifications can happen more
> often than with file VMAs.
But it's only a problem for anon vmas with per-vma locking if it's the
same vma (or the vma lock sequence counter overflows, but let's say
that's a statistically insignificant non-zero value).
>
> For file vmas, how much code can we actually remove, given that
> the first page fault might already be holding mmap_lock?
How much complexity can we remove and maintain the performance, might be
a better question.
> It could be the case that lock_vma_under_rcu() fails, and then
> on the first page fault we end up holding mmap_lock before
> retrying. So are we also going to rip out the lock release,
> even if it risks holding mmap_lock for a long time?
>
> vma = lock_vma_under_rcu(mm, addr);
> if (!vma)
> goto lock_mmap;
> ...
> lock_mmap:
>
> vma = lock_mm_and_find_vma(mm, addr, regs);
> if (unlikely(!vma)) {
> fault = 0;
> si_code = SEGV_MAPERR;
> goto bad_area;
> }
>
> If we still need to keep the page fault retry code there, it
> doesn't seem like "ripping out" really reduces complexity in
> the page fault code?
This seems unrelated to be above complexity that might be the target of
removal?
Thanks,
Liam
^ permalink raw reply
* Re: [PATCH] PCI: cadence: skip the link polling when endpoint not connected
From: Manivannan Sadhasivam @ 2026-06-22 14:52 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, vigneshr, s-vadapalli, lpieralisi, kwilczynski, robh,
bhelgaas, mpillai, unicorn_wang, me, 18255117159,
linux-arm-kernel, linux-kernel, danishanwar
In-Reply-To: <20260605071922.1724499-1-a-garg7@ti.com>
On Fri, Jun 05, 2026 at 12:49:22PM +0530, Aksh Garg wrote:
> cdns_pcie_host_wait_for_link() polls on link-up for 10 retries with a
> delay of 90-100ms each (~1 second). A call to cdns_pcie_host_link_setup()
> during the resume operation blocks the resume operation unnecessarily for
> ~1s even when no endpoint device is connected.
>
> Add skip_link_polling flag to track link state across suspend/resume
> cycles. If link was down before suspend, skip the expensive polling
> in resume since no endpoint was present.
>
Won't you need the delay if a device gets plugged while the host was suspended?
We had this same concern with the DWC drivers and we left the delay as-is as
nothing prevents an user to connect a device when the host was suspended.
- Mani
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
> drivers/pci/controller/cadence/pci-j721e.c | 5 +++++
> drivers/pci/controller/cadence/pcie-cadence-host-hpa.c | 3 +++
> drivers/pci/controller/cadence/pcie-cadence-host.c | 3 +++
> drivers/pci/controller/cadence/pcie-cadence.h | 3 +++
> 4 files changed, 14 insertions(+)
>
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index bfdfe98d5aba..849eb8bb9e45 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -686,6 +686,11 @@ static int j721e_pcie_suspend_noirq(struct device *dev)
> struct j721e_pcie *pcie = dev_get_drvdata(dev);
>
> if (pcie->mode == PCI_MODE_RC) {
> + struct cdns_pcie_rc *rc = cdns_pcie_to_rc(pcie->cdns_pcie);
> +
> + /* If link is down before suspend, skip polling in resume */
> + rc->skip_link_polling = !j721e_pcie_link_up(pcie->cdns_pcie);
> +
> gpiod_set_value_cansleep(pcie->reset_gpio, 0);
> clk_disable_unprepare(pcie->refclk);
> }
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
> index 0f540bed58e8..d78c1282a5ee 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
> @@ -301,6 +301,9 @@ int cdns_pcie_hpa_host_link_setup(struct cdns_pcie_rc *rc)
> return ret;
> }
>
> + if (rc->skip_link_polling)
> + return 0;
> +
> ret = cdns_pcie_host_wait_for_link(pcie, cdns_pcie_hpa_link_up);
> if (ret)
> dev_dbg(dev, "PCIe link never came up\n");
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 0bc9e6e90e0e..026414c21ee1 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -352,6 +352,9 @@ int cdns_pcie_host_link_setup(struct cdns_pcie_rc *rc)
> return ret;
> }
>
> + if (rc->skip_link_polling)
> + return 0;
> +
> ret = cdns_pcie_host_start_link(rc, cdns_pcie_link_up);
> if (ret)
> dev_dbg(dev, "PCIe link never came up\n");
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index 574e9cf4d003..01e49ecccc7b 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -117,6 +117,8 @@ struct cdns_pcie {
> * @no_inbound_map: Whether inbound mapping is supported
> * @quirk_broken_aspm_l0s: Disable ASPM L0s support as quirk
> * @quirk_broken_aspm_l1: Disable ASPM L1 support as quirk
> + * @skip_link_polling: Skip link polling in resume if link was down before
> + * suspend, to avoid long delay in resume
> */
> struct cdns_pcie_rc {
> struct cdns_pcie pcie;
> @@ -131,6 +133,7 @@ struct cdns_pcie_rc {
> unsigned int no_inbound_map:1;
> unsigned int quirk_broken_aspm_l0s:1;
> unsigned int quirk_broken_aspm_l1:1;
> + unsigned int skip_link_polling:1;
> };
>
> /**
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 2/2] media: i2c: ov5640: Add reset controller support with GPIO fallback
From: Frank Li @ 2026-06-22 15:02 UTC (permalink / raw)
To: Philipp Zabel
Cc: robby.cai, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
kieran.bingham, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <7ee62b699c5cabb00cd7706ea42573da81c5bc84.camel@pengutronix.de>
On Mon, Jun 22, 2026 at 11:05:34AM +0200, Philipp Zabel wrote:
> On Fr, 2026-06-19 at 09:18 -0500, Frank Li wrote:
> > On Fri, Jun 19, 2026 at 06:05:32PM +0800, robby.cai@oss.nxp.com wrote:
> > > [You don't often get email from robby.cai@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > From: Robby Cai <robby.cai@nxp.com>
> > >
> > > Add support for the reset controller framework by acquiring the reset
> > > line using devm_reset_control_get_optional_shared_deasserted(). This
> > > allows the driver to handle reset lines provided by a reset controller,
> > > including shared ones, while avoiding unbalanced deassert counts.
> > >
> > > Retain support for legacy reset-gpios as a fallback when no reset
> > > controller is defined. In that case, request the GPIO and keep it in the
> > > deasserted state as the initial configuration.
> > >
> > > This enables the driver to support both reset-controller-backed reset
> > > lines and older GPIO-based descriptions while preserving the existing
> > > power-up sequencing behavior.
> > >
> > > Signed-off-by: Robby Cai <robby.cai@nxp.com>
> > > ---
> > > drivers/media/i2c/ov5640.c | 80 +++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 70 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index 85ecc23b3587..5e6db8aacb11 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/module.h>
> > > #include <linux/pm_runtime.h>
> > > #include <linux/regulator/consumer.h>
> > > +#include <linux/reset.h>
> > > #include <linux/slab.h>
> > > #include <linux/types.h>
> > > #include <media/v4l2-async.h>
> > > @@ -442,6 +443,7 @@ struct ov5640_dev {
> > > u32 xclk_freq;
> > >
> > > struct regulator_bulk_data supplies[OV5640_NUM_SUPPLIES];
> > > + struct reset_control *reset;
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *pwdn_gpio;
> > > bool upside_down;
> > > @@ -2431,6 +2433,48 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
> > > return ov5640_set_framefmt(sensor, &sensor->fmt);
> > > }
> > >
> > > +static int ov5640_get_reset(struct device *dev, struct ov5640_dev *sensor)
> > > +{
> > > + /* use deasserted version to avoid unbalanced deassert counts */
> > > + sensor->reset =
> > > + devm_reset_control_get_optional_shared_deasserted(dev, NULL);
> > > + if (IS_ERR(sensor->reset))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset),
> > > + "Failed to get reset\n");
> > > + else if (sensor->reset)
> > > + return 0;
> > > +
> > > + /*
> > > + * fallback to legacy reset-gpios
> > > + * GPIOD_OUT_HIGH ensures deasserted state for ACTIVE_LOW reset
> > > + */
> > > + sensor->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(sensor->reset_gpio))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset_gpio),
> > > + "Failed to get reset gpio");
> >
> > I think needn't fallback here, NO ABI change, just change to use reset-gpio
> > driver.
>
> Please keep the gpiod fallback, the reset-gpio driver may not be
> available on all platforms using ov5640.
Maybe try promote reset-gpio is default build in / as module. Leave such
fallback every where make code complex.
Krysztof:
Any suggestion?
Frank
>
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int ov5640_reset_assert(struct ov5640_dev *sensor)
> > > +{
> > > + if (sensor->reset)
> > > + return reset_control_assert(sensor->reset);
> >
> > needn't check sensor->reset, reset_control_assert() is no ops if NULL.
> >
> > > +
> > > + gpiod_set_value_cansleep(sensor->reset_gpio, 1);
> >
> > Needn't fallback, directly replace.
>
> See above.
>
>
> regards
> Philipp
^ 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