* [PATCH v5 2/2] i2c: imx-lpi2c: reset controller in probe stage
From: carlos.song @ 2026-06-30 10:52 UTC (permalink / raw)
To: Frank.Li, aisheng.dong, andi.shyti, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260630105223.3687516-1-carlos.song@oss.nxp.com>
From: Carlos Song <carlos.song@nxp.com>
Reset I2C controller in probe stage to avoid unexpected LPI2C controller
state left from previous stages and hang system boot.
Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)"
and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states:
"The reset takes effect immediately and remains asserted until negated
by software. There is no minimum delay required before clearing the
software reset."
Therefore, it is safe to write 0 to MCR and SCR immediately after
asserting the RST bit without any additional delay.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 2dc4331ed796..9fbdce85d7ca 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1510,11 +1510,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
if (ret)
lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
- ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
- pdev->name, lpi2c_imx);
- if (ret)
- return dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
-
i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
platform_set_drvdata(pdev, lpi2c_imx);
@@ -1551,6 +1546,22 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
+ /*
+ * Reset all internal controller registers of both Master and Target
+ * to avoid effects of previous status.
+ */
+ writel(MCR_RST, lpi2c_imx->base + LPI2C_MCR);
+ writel(SCR_RST, lpi2c_imx->base + LPI2C_SCR);
+ writel(0, lpi2c_imx->base + LPI2C_MCR);
+ writel(0, lpi2c_imx->base + LPI2C_SCR);
+
+ ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
+ pdev->name, lpi2c_imx);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
+ goto rpm_disable;
+ }
+
temp = readl(lpi2c_imx->base + LPI2C_PARAM);
lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 2/4] firmware: arm_sdei: add SDEI_EVENT_SIGNAL support
From: Usama Arif @ 2026-06-30 10:51 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Usama Arif, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Marc Zyngier, Doug Anderson, Petr Mladek,
Thomas Gleixner, Andrew Morton, Baoquan He, Puranjay Mohan,
Breno Leitao, Julien Thierry, Lecopzer Chen, Sumit Garg,
kernel-team, kexec, linux-arm-kernel, linux-kernel,
Kiryl Shutsemau (Meta)
In-Reply-To: <def2f1a87ea36a5c3817ca5fbed8a01b7422e4c7.1782744912.git.kas@kernel.org>
On Mon, 29 Jun 2026 16:07:16 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Add sdei_event_signal(), a thin wrapper over the SDEI_EVENT_SIGNAL call
> (DEN0054) that makes the software-signalled event (event 0) pending on a
> target PE -- delivered NMI-like even when that PE has interrupts masked.
> It takes no locks, so it is safe to call from NMI / crash context.
>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> ---
> drivers/firmware/arm_sdei.c | 12 ++++++++++++
> include/linux/arm_sdei.h | 6 ++++++
> include/uapi/linux/arm_sdei.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index c161cf263547..e8dd2f0f3919 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -339,6 +339,18 @@ static void _ipi_unmask_cpu(void *ignored)
> sdei_unmask_local_cpu();
> }
>
> +/*
> + * Signal the software-signalled event (event 0) to @mpidr. Does nothing
> + * but the SMC -- no locks, no event lookup -- so it is safe from NMI /
> + * crash context (e.g. the cross-CPU NMI service).
> + */
> +int sdei_event_signal(u32 event_num, u64 mpidr)
> +{
> + return invoke_sdei_fn(SDEI_1_0_FN_SDEI_EVENT_SIGNAL, event_num,
> + mpidr, 0, 0, 0, NULL);
> +}
> +NOKPROBE_SYMBOL(sdei_event_signal);
> +
Same as patch 1, can this be merged in patch 3? Its good to keep functions
where they are used.
> /*
> * Was SDEI firmware probed and is it usable? Lets optional consumers skip
> * registering an event -- and the warning a failed registration emits -- on
> diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
> index b07113eeeff7..b9dc21c241be 100644
> --- a/include/linux/arm_sdei.h
> +++ b/include/linux/arm_sdei.h
> @@ -37,6 +37,12 @@ int sdei_event_unregister(u32 event_num);
> int sdei_event_enable(u32 event_num);
> int sdei_event_disable(u32 event_num);
>
> +/*
> + * Signal the software-signalled event (event 0) to another PE, NMI-like.
> + * @mpidr is the target's MPIDR affinity.
> + */
> +int sdei_event_signal(u32 event_num, u64 mpidr);
> +
> /* Was SDEI firmware probed and usable? */
> bool sdei_is_present(void);
>
> diff --git a/include/uapi/linux/arm_sdei.h b/include/uapi/linux/arm_sdei.h
> index af0630ba5437..22eb61612673 100644
> --- a/include/uapi/linux/arm_sdei.h
> +++ b/include/uapi/linux/arm_sdei.h
> @@ -22,6 +22,7 @@
> #define SDEI_1_0_FN_SDEI_PE_UNMASK SDEI_1_0_FN(0x0C)
> #define SDEI_1_0_FN_SDEI_INTERRUPT_BIND SDEI_1_0_FN(0x0D)
> #define SDEI_1_0_FN_SDEI_INTERRUPT_RELEASE SDEI_1_0_FN(0x0E)
> +#define SDEI_1_0_FN_SDEI_EVENT_SIGNAL SDEI_1_0_FN(0x0F)
> #define SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI_1_0_FN(0x11)
> #define SDEI_1_0_FN_SDEI_SHARED_RESET SDEI_1_0_FN(0x12)
>
> --
> 2.54.0
>
>
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Lorenzo Pieralisi @ 2026-06-30 10:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Sunil V L, Marc Zyngier, Thomas Gleixner, Huacai Chen,
Anup Patel, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-riscv, linux-kernel, linux-acpi,
linux-arm-kernel, loongarch
In-Reply-To: <CAJZ5v0ibZKfzJwGyUb92-K1N9C_ab0QujpAKCrvMdyygquS1Vw@mail.gmail.com>
On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
[...]
> > +#ifdef CONFIG_ACPI
> > + if (has_acpi_companion(&pdev->dev))
> > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > +#endif
>
> I would rather add a wrapper for this, along with an empty stub for
> the !CONFIG_ACPI case.
#ifdef CONFIG_ACPI
static inline void acpi_device_clear_dep(struct device *dev)
{
if (has_acpi_companion(dev))
acpi_dev_clear_dependencies(ACPI_COMPANION(dev));
}
#else
static inline void acpi_device_clear_dep(struct device *dev) {}
#endif
Something like that ?
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v3 12/17] arm64: dts: nvidia: Add EL2 virtual timer interrupt
From: Marc Zyngier @ 2026-06-30 10:54 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
linux-tegra@vger.kernel.org, Lorenzo Pieralisi, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
Mark Rutland, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Ge Gordon, BST Linux Kernel Upstream Group,
Jesper Nilsson, Lars Persson, Alim Akhtar, Ivaylo Ivanov,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dinh Nguyen, Matthias Brugger, AngeloGioacchino Del Regno,
Thierry Reding, Bjorn Andersson, Konrad Dybcio,
Andreas Färber,
"Yu-Chun Lin [林祐君]", Heiko Stuebner,
Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <3c714ae3-8f62-4785-9f61-ba9899fd70d8@nvidia.com>
Hi Jon,
On Tue, 30 Jun 2026 10:42:34 +0100,
Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Marc,
>
> On 23/05/2026 15:02, Marc Zyngier wrote:
> > The ARMv8.2 based CPUs used in a number of nvidia SoCs are missing
> > the EL2 virtual timer interrupt. Add it.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 ++
> > arch/arm64/boot/dts/nvidia/tegra234.dtsi | 3 ++-
> > 2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index 849694f751d90..45cc180ac9973 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -3163,6 +3163,8 @@ timer {
> > <GIC_PPI 11
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 12
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > interrupt-parent = <&gic>;
> > always-on;
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> > index 04a95b6658caa..ab9813f9ba30c 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> > @@ -5872,7 +5872,8 @@ timer {
> > interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > - <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 12 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > interrupt-parent = <&gic>;
> > always-on;
> > };
>
> Sorry for the delay. I gave this a test because I observed the warning
> that was added on the Tegra194 and Tegra234 platforms. This change
> fixes the warning for Tegra234, but on Tegra194 the platforms I tested
> hang on boot. It appears to be similar to the issue that Marek saw on
> his platforms and so I am wondering if Tegra194 also doesn't have this
> wired up?
I think you are in a better position than me to find out. It also
could be a firmware issue not making the PPI a Group-1 interrupt, and
therefore not allow Linux to configure the interrupt.
>
> Was there any resolution to the issue reported by Marek?
>
> FYI, the Tegra194 SoC has the 'NVIDIA Carmel ARM v8.2' CPUs [0].
There is no resolution so far. Florian was going to check what the
deal is with the Broadcom-related systems, but hasn't come back with
an answer yet.
The possibilities are as follows:
- remove the interrupt for the EL2 virtual timer and live with the
warning
- add a patch such as [1], which should document the reason why this
is now working (and fallback to the EL2 physical timer)
I'm happy either way, as long as we know exactly what we are dealing
with on each affected platform.
Thanks,
M.
[1] https://lore.kernel.org/all/878q898ulx.wl-maz@kernel.org/
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Rafael J. Wysocki (Intel) @ 2026-06-30 10:55 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <akOfu2EIQq3CJgqw@lpieralisi>
On Tue, Jun 30, 2026 at 12:51 PM Lorenzo Pieralisi
<lpieralisi@kernel.org> wrote:
>
> On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
>
> [...]
>
> > > +#ifdef CONFIG_ACPI
> > > + if (has_acpi_companion(&pdev->dev))
> > > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > > +#endif
> >
> > I would rather add a wrapper for this, along with an empty stub for
> > the !CONFIG_ACPI case.
>
> #ifdef CONFIG_ACPI
> static inline void acpi_device_clear_dep(struct device *dev)
> {
> if (has_acpi_companion(dev))
> acpi_dev_clear_dependencies(ACPI_COMPANION(dev));
>
> }
> #else
> static inline void acpi_device_clear_dep(struct device *dev) {}
> #endif
>
> Something like that ?
Yup.
^ permalink raw reply
* Re: [PATCH v4] net: stmmac: fix fatal bus error on resume by reinitializing RX buffers
From: Paolo Abeni @ 2026-06-30 10:55 UTC (permalink / raw)
To: Ding Hui, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Maxime Chevallier, Ding Hui,
open list:STMMAC ETHERNET DRIVER,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
Cc: xiasanbo, yangchen11, liuxuanjun
In-Reply-To: <20260627122533.1165324-1-dinghui1111@163.com>
On 6/27/26 2:25 PM, Ding Hui wrote:
> From: Ding Hui <dinghui@lixiang.com>
>
> On suspend, stmmac_suspend() calls stmmac_disable_all_queues() which
> stops the RX NAPI, but the RX DMA engine may still be running for a
> short window before stmmac_stop_all_dma() takes effect. During that
> window the hardware can write incoming frames into the buffers pointed
> to by the RX descriptors and write back the descriptors (clearing the
> OWN bit and overwriting RDES0/1/2 with status/timestamp data). Because
> NAPI is already disabled, the driver never refills these descriptors,
> so the RX ring is left in a "consumed but not refilled" state with
> stale content in the descriptor buffer-address fields.
>
> On resume, stmmac_clear_descriptors() only re-arms the OWN bit and
> does not repopulate the RX buffer address fields. When the DMA is
> restarted it dereferences these stale addresses and triggers a fatal
> bus error (not kernel panic, just a Fatal Bus Error interrupt and
> RX DMA engine halts).
>
> Fix this by introducing stmmac_reinit_rx_descriptors(), called from
> stmmac_resume() immediately after stmmac_clear_descriptors(). The
> helper iterates every RX descriptor slot and re-programs its buffer
> address fields:
>
> - For normal (page_pool) queues: restore RDES0/1 from buf->addr and
> RDES2 from buf->sec_addr. The DMA mapping has remained valid across
> suspend/resume because no pages were freed. Slots left NULL by a
> prior GFP_ATOMIC failure in stmmac_rx_refill() before suspend
> are re-allocated here with GFP_KERNEL;
> -ENOMEM is returned and resume is aborted if allocation fails.
> The slots with null buffer are unacceptable, because they will
> cause a DMA suspend dead lock problem by the condition of
> Current Descriptor Pointer == Descriptor Tail Pointer.
>
> - For AF_XDP zero-copy queues: restore the DMA address from
> xsk_buff_xdp_get_dma(buf->xdp). Slots with no xdp buffer
> (e.g. TX-only socket, empty fill ring) attempt xsk_buff_alloc()
> first; on failure the descriptor is zeroed so the DMA engine skips
> the slot safely via an RBU event.
>
> - For chain mode: call stmmac_mode_init() to rebuild the des3 next-
> descriptor pointer chain, which hardware may have overwritten with
> a PTP timestamp value (as noted in chain_mode.c:refill_desc3()).
>
> After reprogramming all address fields, a final pass restores OWN=1
> on every valid slot. This is necessary because set_sec_addr and
> chain-mode init unconditionally overwrite des3 (clearing the OWN bit
> set by stmmac_clear_descriptors()), and must run after all address
> writes are complete.
>
> Also fix stmmac_init_rx_buffers() to actually use its gfp_t flags
> parameter instead of the hardcoded GFP_ATOMIC | __GFP_NOWARN.
>
> Signed-off-by: Ding Hui <dinghui@lixiang.com>
This looks like 'net' material, it should specify 'net' into the subj
prefix and include a suitable Fixes tag.
> ---
> Changes in v4:
> - Just add description for return value of 'stmmac_reinit_rx_descriptors'.
> - Link to v3:
> https://lore.kernel.org/netdev/20260604144557.3175399-1-dinghui1111@163.com/
>
> Changes in v3:
> - Re-allocate page_pool NULL slots (from prior GFP_ATOMIC failures)
> with GFP_KERNEL in stmmac_reinit_rx_descriptors(); return -ENOMEM and
> abort resume.
> - For XSK NULL slots, attempt xsk_buff_alloc() first; fall back to
> stmmac_clear_desc() only when allocation fails.
> - Add a re-arm loop at the end of stmmac_reinit_rx_descriptors() to
> restore OWN=1 on all valid slots, since set_sec_addr and
> chain-mode init both write des3 unconditionally.
> - stmmac_reinit_rx_descriptors() now returns int; stmmac_resume()
> checks the return value and propagates -ENOMEM with mutex/rtnl cleanup.
> - Fix stmmac_init_rx_buffers() to use its flags parameter instead of
> hardcoded GFP_ATOMIC | __GFP_NOWARN.
> (884d2b845477 ("net: stmmac: Add GFP_DMA32 for rx buffers if no 64
> capability"))
> - Run stmmac_reinit_rx_descriptors() after stmmac_clear_descriptors()
> so that stmmac_clear_desc() on XSK NULL slots overrides the OWN
> bit set by stmmac_clear_descriptors().
> - Update commit message.
> - Link to v2:
> https://lore.kernel.org/netdev/20260526022620.501229-1-dinghui1111@163.com/
>
> Changes in v2:
> - Introducing stmmac_reinit_rx_descriptors() to reinitializing rx
> buffers without any allocation.
> - Modify commit log.
> - Link to v1:
> https://lore.kernel.org/netdev/20260515053856.2310369-1-dinghui1111@163.com/
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 164 +++++++++++++++++-
> 1 file changed, 163 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3591755ea30b..c82f3d5dbd43 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1660,7 +1660,7 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
> {
> struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
> struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
> - gfp_t gfp = (GFP_ATOMIC | __GFP_NOWARN);
> + gfp_t gfp = flags;
The above should go via a separate (net) patch.
>
> if (priv->dma_cap.host_dma_width <= 32)
> gfp |= GFP_DMA32;
> @@ -1693,6 +1693,148 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
> return 0;
> }
>
> +/**
> + * stmmac_reinit_rx_descriptors - re-program RX descriptor buffer addresses
> + * after stmmac_clear_descriptors()
> + * @priv: driver private structure
> + * @dma_conf: structure holding the dma data
> + * @queue: RX queue index
> + *
> + * Description: Called in the resume path after stmmac_clear_descriptors()
> + * has re-armed the OWN bit on every descriptor. Walk buf_pool[] and
> + * re-program the buffer-address fields of every RX descriptor from the
> + * buffers that are already attached to the queue. Slots whose page was
> + * never allocated (GFP_ATOMIC failure before suspend) are re-allocated
> + * here with GFP_KERNEL; the resume path is in process context.
> + *
> + * Between suspend and resume the hardware may have written back status/
> + * length information into the descriptor address fields (RDESx are reused
> + * for status on completion for GMAC4/XGMAC), so the address fields must be
> + * repopulated before the DMA is restarted.
> + *
> + * For XSK slots that have no xdp buffer at suspend time (TX-only socket,
> + * empty fill ring for Rx), xsk_buff_alloc() is attempted but does not
> + * return an error on failure because we can't identify a real TX-only
> + * socket from an alloc error (same as stmmac_alloc_rx_buffers_zc() in
> + * __init_dma_rx_desc_rings); on failure the descriptor is zeroed so the DMA
> + * engine skips the slot safely.
> + *
> + * To avoid the DMA stall after resume in non-XSK mode, this function
> + * re-allocates pages for NULL slots using GFP_KERNEL (the resume path runs
> + * in process context). If allocation fails, -%ENOMEM is returned immediately
> + * and the resume is aborted; the caller should report the error.
> + *
> + * This helper must be called after stmmac_clear_descriptors() and before
> + * stmmac_hw_setup() in stmmac_resume() because we need to wipe the OWN bit
> + * set in stmmac_clear_descriptors() for NULL slots in XSK mode.
Please try to condense the above text in one or 2 paragraph.
> + *
> + * Returns: 0 on success, or a negative errno on allocation failure in
> + * non-XSK mode (e.g. -%ENOMEM).
> + */
> +static int stmmac_reinit_rx_descriptors(struct stmmac_priv *priv,
> + struct stmmac_dma_conf *dma_conf,
> + u32 queue)
> +{
> + struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
> + struct stmmac_rx_buffer *buf;
> + struct dma_desc *p;
> + int i;
> +
> + if (rx_q->xsk_pool) {
> + for (i = 0; i < dma_conf->dma_rx_size; i++) {
> + buf = &rx_q->buf_pool[i];
> + p = stmmac_get_rx_desc(priv, rx_q, i);
> +
> + /* The XSK pool may not be fully populated (e.g.
> + * xdpsock TX-only, empty fill ring). Try to refill
> + * from the pool; on failure zero the descriptor so the
> + * DMA engine skips this slot safely.
> + */
> + if (!buf->xdp) {
> + buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
> + if (!buf->xdp) {
> + stmmac_clear_desc(priv, p);
> + continue;
> + }
> + }
> +
> + stmmac_set_desc_addr(priv, p,
> + xsk_buff_xdp_get_dma(buf->xdp));
> + stmmac_set_desc_sec_addr(priv, p, 0, false);
> + }
> + } else {
> + for (i = 0; i < dma_conf->dma_rx_size; i++) {
> + buf = &rx_q->buf_pool[i];
> + p = stmmac_get_rx_desc(priv, rx_q, i);
> +
> + /* buf->page can be NULL when stmmac_rx_refill() hit a
> + * GFP_ATOMIC failure before suspend and left the slot
> + * without a buffer. The resume path runs in process
> + * context, so re-allocate with GFP_KERNEL. Allocation
> + * failure aborts the resume.
> + */
> + if (!buf->page) {
> + int err;
> +
> + err = stmmac_init_rx_buffers(priv, dma_conf, p,
> + i, GFP_KERNEL,
> + queue);
> + if (err)
> + return err;
> + /* stmmac_init_rx_buffers() already programmed
> + * the descriptor; skip the reprogramming below.
> + */
> + continue;
> + }
> +
> + stmmac_set_desc_addr(priv, p, buf->addr);
> + stmmac_set_desc_sec_addr(priv, p, buf->sec_addr,
> + priv->sph_active &&
> + buf->sec_page);
AFAICS stmmac_rx_refill() can error out after successfully allocating
buf->page, but leaving a NULL sec_page, I think you should try to
realloc even the latter.
Finally this chunk shares quite a bit of code with stmmac_rx_refill()
and stmmac_rx_refill_zc() it would be better try to factor out common
helpers.
/P
^ permalink raw reply
* Re: [PATCH v5 1/4] firmware: arm_sdei: add sdei_is_present()
From: Kiryl Shutsemau @ 2026-06-30 10:57 UTC (permalink / raw)
To: Usama Arif
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Doug Anderson, Petr Mladek, Thomas Gleixner,
Andrew Morton, Baoquan He, Puranjay Mohan, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630104713.3847805-1-usama.arif@linux.dev>
On Tue, Jun 30, 2026 at 03:47:11AM -0700, Usama Arif wrote:
> On Mon, 29 Jun 2026 16:07:15 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> >
> > invoke_sdei_fn() returns -EIO when no SDEI conduit was probed, and the
> > core warns ("Failed to create event ...") on any registration that hits
> > that. An optional consumer that registers an event from an unconditional
> > initcall would therefore make every boot on a non-SDEI system emit that
> > warning for what is simply absent firmware.
> >
> > Expose whether SDEI firmware is present so such a consumer can skip
> > registration -- and the warning -- when there is nothing to talk to.
> >
> > Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > ---
>
> Can this be merged in patch 3 where this function is actually used?
I can do it either way. Standalone commit looks good to me.
But if maintainer wants, I can fold it.
> > drivers/firmware/arm_sdei.c | 10 ++++++++++
> > include/linux/arm_sdei.h | 3 +++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> > index f39ed7ba3a38..c161cf263547 100644
> > --- a/drivers/firmware/arm_sdei.c
> > +++ b/drivers/firmware/arm_sdei.c
> > @@ -339,6 +339,16 @@ static void _ipi_unmask_cpu(void *ignored)
> > sdei_unmask_local_cpu();
> > }
> >
> > +/*
> > + * Was SDEI firmware probed and is it usable? Lets optional consumers skip
> > + * registering an event -- and the warning a failed registration emits -- on
> > + * systems with no SDEI.
> > + */
> > +bool sdei_is_present(void)
> > +{
> > + return sdei_firmware_call;
>
> sdei_firmware_call is a function pointer. The above is correct, but
> can we make it sdei_firmware_call != NULL? I think that looks a lot better.
Again, I don't care much, but checkpatch doesn't like comparison to NULL.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v5 2/4] firmware: arm_sdei: add SDEI_EVENT_SIGNAL support
From: Kiryl Shutsemau @ 2026-06-30 10:58 UTC (permalink / raw)
To: Usama Arif
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Doug Anderson, Petr Mladek, Thomas Gleixner,
Andrew Morton, Baoquan He, Puranjay Mohan, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630105125.4006859-1-usama.arif@linux.dev>
On Tue, Jun 30, 2026 at 03:51:24AM -0700, Usama Arif wrote:
> On Mon, 29 Jun 2026 16:07:16 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> >
> > Add sdei_event_signal(), a thin wrapper over the SDEI_EVENT_SIGNAL call
> > (DEN0054) that makes the software-signalled event (event 0) pending on a
> > target PE -- delivered NMI-like even when that PE has interrupts masked.
> > It takes no locks, so it is safe to call from NMI / crash context.
> >
> > Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > ---
> > drivers/firmware/arm_sdei.c | 12 ++++++++++++
> > include/linux/arm_sdei.h | 6 ++++++
> > include/uapi/linux/arm_sdei.h | 1 +
> > 3 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> > index c161cf263547..e8dd2f0f3919 100644
> > --- a/drivers/firmware/arm_sdei.c
> > +++ b/drivers/firmware/arm_sdei.c
> > @@ -339,6 +339,18 @@ static void _ipi_unmask_cpu(void *ignored)
> > sdei_unmask_local_cpu();
> > }
> >
> > +/*
> > + * Signal the software-signalled event (event 0) to @mpidr. Does nothing
> > + * but the SMC -- no locks, no event lookup -- so it is safe from NMI /
> > + * crash context (e.g. the cross-CPU NMI service).
> > + */
> > +int sdei_event_signal(u32 event_num, u64 mpidr)
> > +{
> > + return invoke_sdei_fn(SDEI_1_0_FN_SDEI_EVENT_SIGNAL, event_num,
> > + mpidr, 0, 0, 0, NULL);
> > +}
> > +NOKPROBE_SYMBOL(sdei_event_signal);
> > +
>
> Same as patch 1, can this be merged in patch 3? Its good to keep functions
> where they are used.
Patch 3 is big as it is. I don't think folding code that can be a
standalone patch helps the situation.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Peter Griffin @ 2026-06-30 11:02 UTC (permalink / raw)
To: Alim Akhtar
Cc: Denzeel Oliva, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Conor Dooley, linux-samsung-soc, linux-clk,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <0f1e01dd0844$01190c40$034b24c0$@samsung.com>
Hi Alim,
On Tue, 30 Jun 2026 at 04:53, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Peter Griffin <peter.griffin@linaro.org>
> > Sent: Monday, June 29, 2026 6:02 PM
> > To: Denzeel Oliva <wachiturroxd150@gmail.com>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>; Sylwester Nawrocki
> > <s.nawrocki@samsung.com>; Chanwoo Choi <cw00.choi@samsung.com>;
> > Alim Akhtar <alim.akhtar@samsung.com>; Michael Turquette
> > <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Brian
> > Masney <bmasney@redhat.com>; Rob Herring <robh@kernel.org>; Conor
> > Dooley <conor+dt@kernel.org>; linux-samsung-soc@vger.kernel.org; linux-
> > clk@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock
> > parents
> >
> > Hi Krysztof & Denzeel,
> >
> > On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <wachiturroxd150@gmail.com>
> > wrote:
> > >
> > > Correct eight PERIS gate clock parents to match the hardware clock
> > > tree and reorder the GIC mux parents so mout_peris_bus_user is the
> > > default source.
> > >
> > > Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
> > > ---
> >
> > Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> >
> > @Krysztof: I was thinking, maybe we should establish a new rule/best
> > practice for Samsung clock upstream submissions whereby patch
> > contributors should link to the downstream cal-if code for the SoC after the --
> > - line. That would make reviewing the patches' correctness a bit easier, as the
> > downstream cal-if code would be readily available to the reviewer.
> >
> We can leave this choice to the reviewer if they want to refer to downstream cal-if code.
Generally I would like to, but I also don't have time to hunt around
the internet for a downstream kernel tree. My rationale was that the
submitter is most likely to know where the downstream code is, and is
likely using it for the upstream clock implementation. So, linking to
it as part of the submission should hopefully be fairly easy.
If it is a Samsung SoC for which no public code is available that's
fine. I didn't intend this to be a hard requirement: "you can't
upstream x,y,z unless you link to the cal-if code". I meant it more as
"best practice/guidance"; if the cal-if code is publicly available,
linking to it would be a useful reference for reviewers.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH v4 01/10] kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n
From: Pratyush Yadav @ 2026-06-30 11:05 UTC (permalink / raw)
To: Wandun Chen
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <20260630074715.4126796-2-chenwandun1@gmail.com>
On Tue, Jun 30 2026, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Prepare for an upcoming change that excludes non-dumpable reserved
> regions from the kdump vmcore and will call crash_exclude_mem_range()
> from generic, non-arch code.
>
> No functional change.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* [PATCH 1/5] arm64: dts: lx2160a: transition to device-specific SerDes compatible strings
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Align to the modern fsl,lynx-28g.yaml binding, where the SoC and SerDes
instance is present in the compatible string, to allow reliable per-lane
capability detection and per-lane customization of electrical properties.
These new bindings have #phy-cells = <0> in per-lane PHY providers, so
we need to update consumer phandles as well.
The modern bindings are backward-incompatible with old kernels, due
to the consumer phandles being either in one form or in another, as
explained here:
https://lore.kernel.org/lkml/20250930140735.mvo3jii7wgmzh2bs@skbuf/
One of the major differences between the LX2160A and LX2162A is the
SerDes. So far, LX2162A has used fsl-lx2160a-rev2.dtsi, but we need to
split that up even further, and derive a fsl-lx2162a.dtsi which
overrides the SerDes properties.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
.../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
.../dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
.../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
.../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
6 files changed, 182 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 4bc151d721dd..1f946d3a4ec0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -135,6 +135,10 @@ &sata3 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 935f421475ac..a40a968b9533 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -329,6 +329,10 @@ &uart0 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart1 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 1d73abffa6b7..a687eb3e3190 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -621,17 +621,163 @@ soc: soc {
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
+ /* Note on the interpretation of SerDes lane numbering from
+ * LX2160ARM lane mappings for RCW[SRDS_PRTCL_S1]:
+ * The letters (A-H) correspond to logical lane numbers in the
+ * SerDes register map (lane A's registers start with LNAGCR0),
+ * while the numbers (0-7) correspond to physical lanes as
+ * routed to pins. SerDes block #1 is flipped in the LX2160A
+ * floorplan (logical lane A goes to physical lane 7's pins),
+ * while SerDes blocks #2 and #3 are not. The lanes below are
+ * listed right to left when looking at that table.
+ * Both the numbers and the letters are according to the logical
+ * numbering scheme, and do not account for the flipping.
+ */
serdes_1: phy@1ea0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
reg = <0x0 0x1ea0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
+ status = "disabled";
+
+ serdes_1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
serdes_2: phy@1eb0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2160a-serdes2", "fsl,lynx-28g";
reg = <0x0 0x1eb0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
status = "disabled";
+
+ serdes_2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes_3: phy@1ec0000 {
+ compatible = "fsl,lx2160a-serdes3";
+ reg = <0x0 0x1ec0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ #phy-cells = <1>;
+
+ serdes_3_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
crypto: crypto@8000000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 99ee2b1c0f13..61e70e9c6e80 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -8,7 +8,7 @@
#include <dt-bindings/leds/common.h>
-#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2162a.dtsi"
#include "fsl-lx2162a-sr-som.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
index 7a595fddc027..0ba56b9819ac 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2162a.dtsi"
/ {
model = "NXP Layerscape LX2162AQDS";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
new file mode 100644
index 000000000000..b9629e074d94
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree Include file for Layerscape-LX2162A family SoC.
+//
+// Copyright 2025 NXP
+
+#include "fsl-lx2160a-rev2.dtsi"
+
+&serdes_1 {
+ compatible = "fsl,lx2162a-serdes1", "fsl,lynx-28g";
+
+ /delete-node/ phy@0;
+ /delete-node/ phy@1;
+ /delete-node/ phy@2;
+ /delete-node/ phy@3;
+};
+
+&serdes_2 {
+ compatible = "fsl,lx2162a-serdes2", "fsl,lynx-28g";
+};
+
+&soc {
+ /delete-node/ serdes@1ec0000;
+};
--
2.25.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS1046A SoC. The nodes are left disabled at the SoC level; board
DTs will be expected to enable them once the consumer Ethernet nodes
appear.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 +++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 6fefe837f434..db935805c379 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -424,6 +424,66 @@ sfp: efuse@1e80000 {
clock-names = "sfp";
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls1046a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ big-endian;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls1046a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ big-endian;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1046a-dcfg", "syscon";
reg = <0x0 0x1ee0000 0x0 0x1000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: ls1028a: describe the Lynx 10G SerDes
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the Lynx 10G SerDes block and its 4 SerDes lanes found on the
LS1028A SoC. The node is left disabled at the SoC level; board DTs will
be expected to enable it once the consumer Ethernet nodes use it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index f4ba3d16ab86..b4abdb5f906a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -250,6 +250,35 @@ ls1028a_uid: unique-id@1c {
};
};
+ serdes: phy@1ea0000 {
+ compatible = "fsl,ls1028a-serdes";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
scfg: syscon@1fc0000 {
compatible = "fsl,ls1028a-scfg", "syscon";
reg = <0x0 0x1fc0000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS1088A SoC. The nodes are left disabled at the SoC level; board
DTs will enable them once there are consumers.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 99016768b73f..dcf13ac1fce5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -239,6 +239,64 @@ reset: syscon@1e60000 {
reg = <0x0 0x1e60000 0x0 0x10000>;
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls1088a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls1088a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
isc: syscon@1f70000 {
compatible = "fsl,ls1088a-isc", "syscon";
reg = <0x0 0x1f70000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS208xA SoC. The nodes are left disabled at the SoC level; board
DTs will enabled them once there are consumers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 +++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 6073e426774a..7d4260661766 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -280,6 +280,104 @@ sfp: efuse@1e80000 {
clock-names = "sfp";
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls2088a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls2088a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
isc: syscon@1f70000 {
compatible = "fsl,ls2080a-isc", "syscon";
reg = <0x0 0x1f70000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 07/10] of: reserved_mem: add kdump helpers to exclude non-dumpable regions
From: Pratyush Yadav @ 2026-06-30 11:06 UTC (permalink / raw)
To: Wandun Chen
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <20260630074715.4126796-8-chenwandun1@gmail.com>
On Tue, Jun 30 2026, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Add two helpers to exclude non-dumpable regions for arch-specific
> code.
>
> - of_reserved_mem_kdump_nr_ranges() returns the count of regions
> that are not dumpable. Each excluded region may split an existing
> crash_mem range into two, so callers use this to calculate
> crash_mem allocation size.
>
> - of_reserved_mem_kdump_exclude() walks reserved_mem[] and calls
> crash_exclude_mem_range() for every non-dumpable region.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
> Tested-by: Meijing Zhao <zhaomeijing@lixiang.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v4 08/10] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Pratyush Yadav @ 2026-06-30 11:06 UTC (permalink / raw)
To: Wandun Chen
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <20260630074715.4126796-9-chenwandun1@gmail.com>
On Tue, Jun 30 2026, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Reserved memory regions are excluded from vmcore by default unless
> marked dumpable. Honor the dumpable flag to filter out device firmware
> regions (e.g., GPU, DSP, modem) reserved via device tree, since they
> typically contain data not useful for kernel crash analysis and can
> significantly increase vmcore size.
>
> Use of_reserved_mem_kdump_exclude() to perform the exclusion, and
> pre-size the crash_mem array via of_reserved_mem_kdump_nr_ranges().
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
> Tested-by: Meijing Zhao <zhaomeijing@lixiang.com>
> Acked-by: Will Deacon <will@kernel.org>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* [PATCH] i2c: mt7621: Use dev_err_probe() for clock acquisition failures
From: phucduc.bui @ 2026-06-30 11:08 UTC (permalink / raw)
To: Stefan Roese, Andi Shyti, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-i2c, linux-kernel, linux-arm-kernel, linux-mediatek,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Use dev_err_probe() when devm_clk_get_enabled() fails. This correctly
handles -EPROBE_DEFER while simplifying the error handling.
No functional change intended.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
drivers/i2c/busses/i2c-mt7621.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt7621.c b/drivers/i2c/busses/i2c-mt7621.c
index 0a288c998419..8b0407d70c4c 100644
--- a/drivers/i2c/busses/i2c-mt7621.c
+++ b/drivers/i2c/busses/i2c-mt7621.c
@@ -280,10 +280,8 @@ static int mtk_i2c_probe(struct platform_device *pdev)
return PTR_ERR(i2c->base);
i2c->clk = devm_clk_get_enabled(&pdev->dev, NULL);
- if (IS_ERR(i2c->clk)) {
- dev_err(&pdev->dev, "Failed to enable clock\n");
- return PTR_ERR(i2c->clk);
- }
+ if (IS_ERR(i2c->clk))
+ dev_err_probe(&pdev->dev, PTR_ERR(i2c->clk), "Failed to enable clock\n");
i2c->dev = &pdev->dev;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 09/10] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Pratyush Yadav @ 2026-06-30 11:12 UTC (permalink / raw)
To: Wandun Chen
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <20260630074715.4126796-10-chenwandun1@gmail.com>
On Tue, Jun 30 2026, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Apply the same non-dumpable reserved memory filtering to RISC-V kdump
> as was done for arm64. Use of_reserved_mem_kdump_exclude() to drop
> flagged regions from the elfcorehdr PT_LOAD segments, and
> of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
> ---
> arch/riscv/kernel/machine_kexec_file.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 59d4bbc848a8..25359d583bc3 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -10,6 +10,7 @@
> #include <linux/elf.h>
> #include <linux/slab.h>
> #include <linux/of.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/libfdt.h>
> #include <linux/types.h>
> #include <linux/memblock.h>
> @@ -64,6 +65,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>
> nr_ranges = 1; /* For exclusion of crashkernel region */
> walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> + nr_ranges += of_reserved_mem_kdump_nr_ranges();
>
> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> if (!cmem)
> @@ -77,6 +79,8 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>
> /* Exclude crashkernel region */
> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> + if (!ret)
> + ret = of_reserved_mem_kdump_exclude(cmem);
> if (!ret)
> ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
Nit: can you do the usual pattern of if (err) goto err; instead?
So this would look like:
/* Exclude crashkernel region */
ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
if (ret)
goto out;
ret = of_reserved_mem_kdump_exclude(cmem);
if (ret)
goto out;
ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
...
With this,
Acked-by: Pratyush Yadav <pratyush@kernel.org>
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Krzysztof Kozlowski @ 2026-06-30 11:12 UTC (permalink / raw)
To: Peter Griffin, Alim Akhtar
Cc: Denzeel Oliva, Sylwester Nawrocki, Chanwoo Choi,
Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Conor Dooley, linux-samsung-soc, linux-clk, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <CADrjBPoZ4G09WGC_b59YWq3_EfTaPFyp0dD7VizKLYBW_eFk+A@mail.gmail.com>
On 30/06/2026 13:02, Peter Griffin wrote:
> Hi Alim,
>
> On Tue, 30 Jun 2026 at 04:53, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: Peter Griffin <peter.griffin@linaro.org>
>>> Sent: Monday, June 29, 2026 6:02 PM
>>> To: Denzeel Oliva <wachiturroxd150@gmail.com>
>>> Cc: Krzysztof Kozlowski <krzk@kernel.org>; Sylwester Nawrocki
>>> <s.nawrocki@samsung.com>; Chanwoo Choi <cw00.choi@samsung.com>;
>>> Alim Akhtar <alim.akhtar@samsung.com>; Michael Turquette
>>> <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Brian
>>> Masney <bmasney@redhat.com>; Rob Herring <robh@kernel.org>; Conor
>>> Dooley <conor+dt@kernel.org>; linux-samsung-soc@vger.kernel.org; linux-
>>> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>>> Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock
>>> parents
>>>
>>> Hi Krysztof & Denzeel,
>>>
>>> On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <wachiturroxd150@gmail.com>
>>> wrote:
>>>>
>>>> Correct eight PERIS gate clock parents to match the hardware clock
>>>> tree and reorder the GIC mux parents so mout_peris_bus_user is the
>>>> default source.
>>>>
>>>> Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
>>>> ---
>>>
>>> Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
>>>
>>> @Krysztof: I was thinking, maybe we should establish a new rule/best
>>> practice for Samsung clock upstream submissions whereby patch
>>> contributors should link to the downstream cal-if code for the SoC after the --
>>> - line. That would make reviewing the patches' correctness a bit easier, as the
>>> downstream cal-if code would be readily available to the reviewer.
>>>
>> We can leave this choice to the reviewer if they want to refer to downstream cal-if code.
>
> Generally I would like to, but I also don't have time to hunt around
> the internet for a downstream kernel tree. My rationale was that the
> submitter is most likely to know where the downstream code is, and is
> likely using it for the upstream clock implementation. So, linking to
> it as part of the submission should hopefully be fairly easy.
>
> If it is a Samsung SoC for which no public code is available that's
> fine. I didn't intend this to be a hard requirement: "you can't
> upstream x,y,z unless you link to the cal-if code". I meant it more as
> "best practice/guidance"; if the cal-if code is publicly available,
> linking to it would be a useful reference for reviewers.
cal-if as vendor tree? Some contributors just base their work on
downstream GPL-compliance dumps from opensource.samsung.com, so not sure
how that link would work.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 10/10] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Pratyush Yadav @ 2026-06-30 11:13 UTC (permalink / raw)
To: Wandun Chen
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <20260630074715.4126796-11-chenwandun1@gmail.com>
On Tue, Jun 30 2026, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Apply the same non-dumpable reserved memory filtering to LoongArch
> kdump as was done for arm64. Use of_reserved_mem_kdump_exclude() to
> drop flagged regions from the elfcorehdr PT_LOAD segments, and
> of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v2 00/11] ASoC: fsl: Use guard() for mutex & spin locks
From: Mark Brown @ 2026-06-29 18:19 UTC (permalink / raw)
To: phucduc.bui
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
On Mon, 15 Jun 2026 16:38:13 +0700, phucduc.bui@gmail.com wrote:
> ASoC: fsl: Use guard() for mutex & spin locks
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Hi all,
>
> This series converts mutex and spinlock handling in the FSL sound drivers
> to use guard() helpers.
> The changes are code cleanup only and should have no functional impact.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
Thanks!
[01/11] ASoC: fsl_asrc: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/d7e261b7ad1b
[02/11] ASoC: fsl_audmix: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/58712476dee2
[03/11] ASoC: fsl_easrc: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/48d84310be60
[04/11] ASoC: fsl_esai: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/cb87bdabd341
[05/11] ASoC: fsl_spdif: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/a1b865cff274
[06/11] ASoC: fsl_ssi: Use guard() for mutex locks
https://git.kernel.org/broonie/sound/c/4d748e7082ec
[07/11] ASoC: fsl_xcvr: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/94b0cb1dd6d9
[08/11] ASoC: imx-audio-rpmsg: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/929d412fdb0d
[09/11] ASoC: fsl_rpmsg: Use guard() for mutex & spin locks
https://git.kernel.org/broonie/sound/c/11ce4dd4e7be
[10/11] ASoC: fsl: mpc5200_dma: Use guard() for spin locks
https://git.kernel.org/broonie/sound/c/caed9fb2e428
[11/11] ASoC: fsl: mpc5200_psc_ac97: Use guard() for mutex locks
https://git.kernel.org/broonie/sound/c/8a2d7e46317a
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] ASoC: meson: Use dev_err_probe() for device reset failures
From: Mark Brown @ 2026-06-29 17:22 UTC (permalink / raw)
To: Jerome Brunet, phucduc.bui
Cc: Liam Girdwood, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Jaroslav Kysela, Takashi Iwai, linux-sound, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20260612020113.9557-1-phucduc.bui@gmail.com>
On Fri, 12 Jun 2026 09:01:12 +0700, phucduc.bui@gmail.com wrote:
> ASoC: meson: Use dev_err_probe() for device reset failures
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
Thanks!
[1/1] ASoC: meson: Use dev_err_probe() for device reset failures
https://git.kernel.org/broonie/sound/c/6ed013a581d0
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 v4] ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
From: Mark Brown @ 2026-06-29 17:31 UTC (permalink / raw)
To: linux-mediatek, Luca Leonardo Scorcia
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, linux-sound,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260615185810.11804-1-l.scorcia@gmail.com>
On Mon, 15 Jun 2026 20:57:50 +0200, Luca Leonardo Scorcia wrote:
> ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
Thanks!
[1/1] ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
https://git.kernel.org/broonie/sound/c/012dfa0c45ec
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] dt-bindings: spi: st,stm32-qspi: Add power-domains property
From: Mark Brown @ 2026-06-29 17:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Christophe Kerello, Patrice Chotard
Cc: 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, 18 Jun 2026 08:46:35 +0200, Patrice Chotard wrote:
> dt-bindings: spi: st,stm32-qspi: Add power-domains property
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3
Thanks!
[1/1] dt-bindings: spi: st,stm32-qspi: Add power-domains property
https://git.kernel.org/broonie/spi/c/7a0d22e632a6
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
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