* RE: [EXT] i.MX95: EdgeLock Enclave secure storage
From: Pankaj Gupta @ 2026-06-30 12:06 UTC (permalink / raw)
To: Fabio Estevam
Cc: Schrempf Frieder,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Peng Fan,
Stefano Babic, Frank Li
In-Reply-To: <CAOMZO5DgENq8RU6s2CPnKsf53i=7zoBeO38m_BtV=w54hr2hgQ@mail.gmail.com>
Hi Fabio,
Thank you for your kind words and for your interest in the upstream EdgeLock Enclave (ELE) work.
Regarding the specific areas you mentioned, please find my comments inline below.
Regards,
Pankaj Gupta
NXP Semiconductor
> -----Original Message-----
> From: Fabio Estevam <festevam@gmail.com>
> Sent: 13 June 2026 19:29
> To: Pankaj Gupta <pankaj.gupta@nxp.com>
> Cc: Schrempf Frieder <frieder.schrempf@kontron.de>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-arm-
> kernel@lists.infradead.org>; open list:HARDWARE RANDOM NUMBER
> GENERATOR CORE <linux-crypto@vger.kernel.org>; Peng Fan
> <peng.fan@nxp.com>; Stefano Babic <sbabic@nabladev.com>; Frank Li
> <frank.li@nxp.com>
> Subject: [EXT] i.MX95: EdgeLock Enclave secure storage
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> Hi Pankaj,
>
> First of all, thank you for your work on upstreaming the EdgeLock Enclave (ELE)
> support. It is great to finally see the ELE framework landing upstream after a
> long development effort.
>
> I am currently evaluating the state of i.MX95 secure-boot and storage-security
> support based on current linux-next, with the goal of understanding what can
> already be achieved using upstream software and what pieces are still under
> development.
>
> From my review, it appears that the following infrastructure is already available
> upstream:
>
> - ELE/V2X mailbox support for i.MX95.
The current upstream driver only supports i.MX8ULP. However, it establishes the foundation for ELE/V2X mailbox support on i.MX95.
> - OCOTP/ELE nvmem support for fuse access.
The upstream OCOTP/ELE nvmem support is independent of the recently accepted Secure Enclave driver for i.MX8ULP.
> - Secure-enclave bindings documenting the i.MX95 ELE HSM.
>
> However, I could not find upstream support for several capabilities that would
> be useful for secure storage deployments on i.MX95, including:
>
> - An ELE-backed trusted-key provider for the Linux trusted key framework.
Work in this area is currently ongoing. The intention is to provide an ELE-backed trusted key implementation that can integrate with the Linux trusted key framework.
> - Integration allowing Linux to use ELE as a key-sealing/ unsealing backend.
Support for using ELE as a backend for key sealing and unsealing is also under development and is planned to build on top of the trusted key support.
> - i.MX95-specific crypto acceleration exposed through the Linux crypto API for
> dm-crypt use cases.
ELE itself is not designed to act as a general-purpose cryptographic accelerator.
For dm-crypt use cases, the current direction is to perform the cryptographic operations through OP-TEE using Arm Cryptography Extensions (Arm-CE),
while ensuring that plaintext keys are only present in on-chip OCRAM and never leave the SoC.
Upstream discussions and corresponding RFC patches are expected once the related OP-TEE PTA support is available for review in OP-TEE OS.
>
> Are you aware of any ongoing upstream or planned development activities in
> these areas, particularly for i.MX95?
The activities mentioned above are the primary ongoing efforts related to secure storage and key management on i.MX95.
As these developments progress, they will be proposed and discussed through the relevant upstream mailing lists.
>
> Any information about the upstream roadmap, ongoing development, or
> expected direction for these features would be greatly appreciated.
>
> Thanks again for your work and for any insights you can share.
>
> Regards,
>
> Fabio Estevam
^ permalink raw reply
* Re: [PATCH v4 09/10] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun @ 2026-06-30 12:00 UTC (permalink / raw)
To: Pratyush Yadav
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, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <2vxzechoi8o0.fsf@kernel.org>
On 6/30/26 19:12, Pratyush Yadav wrote:
> 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?
>
Sure, will fix in the next version.
Best regards,
Wandun
> 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>
>
^ permalink raw reply
* [PATCH 0/5] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
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
This patch set adds the device tree nodes for the Lynx10G SerDes blocks
found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
The first patch also transitions the LX2160A SoC dtsi to use the
device-specific Lynx28G SerDes compatible.
Ioana Ciornei (1):
arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
Vladimir Oltean (4):
arm64: dts: lx2160a: transition to device-specific SerDes compatible
strings
arm64: dts: ls1028a: describe the Lynx 10G SerDes
arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 ++++
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 +++++++
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 +++++++
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 ++++++++++++
.../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 +++
10 files changed, 427 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
--
2.25.1
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: aspeed: Make AST2700 SoC1 JTAG master TRST optional
From: Linus Walleij @ 2026-06-30 11:52 UTC (permalink / raw)
To: Billy Tsai
Cc: Andrew Jeffery, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, linux-aspeed, openbmc, linux-gpio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260616-pinctrl-fix-v1-0-621036e45c7c@aspeedtech.com>
On Tue, Jun 16, 2026 at 4:30 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> The JTAGM1 pin group of the AST2700 SoC1 includes ball D12, which
> carries the TRST signal. TRST is an optional signal for a JTAG master:
> designs that do not wire it may need the D12 ball for other functions,
> but with TRST embedded in the group they cannot use the JTAG master at
> all.
>
> Split D12 into a new JTAGM1TRST group under the existing JTAGM1
> function, so TRST is only muxed when a board explicitly requests it.
> Patch 1 adds the new group to the device tree binding and patch 2
> splits the group in the driver.
>
> Note that this changes the meaning of the existing JTAGM1 group: boards
> that do use TRST now need to select both the JTAGM1 and JTAGM1TRST
> groups.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Vinod Koul @ 2026-06-30 11:34 UTC (permalink / raw)
To: Hongling Zeng
Cc: Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd, dmaengine,
linux-arm-kernel, linux-sunxi, linux-kernel, zhongling0719,
Frank Li
In-Reply-To: <20260618020609.1155962-1-zenghongling@kylinos.cn>
On 18-06-26, 10:06, Hongling Zeng wrote:
> When terminating DMA transfers, active descriptors are not properly
> reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
> descriptors and their LLI chains to be permanently leaked.
>
> Fix by using vchan_terminate_vdesc() which handles both cyclic and
> non-cyclic descriptors by adding them to desc_terminated queue for
> proper cleanup.
>
> Add pchan->desc != pchan->done check to prevent double-adding completed
> descriptors, which would corrupt the list.
Thanks for the patch. Please consider revising the subject which should
describe the changes in the patch and not the fix/issue.
A better one would be "fix reclaim descriptors while terminating"
>
> Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> Suggested-by: Frank Li <Frank.li@oss.nxp.com>
>
> ---
> Change in v2;
> -Add pchan->desc != pchan->done check to prevent race condition
> where completed descriptors could be double-added to desc_completed
> list, causing list corruption
> ---
> Change in v3:
> -Fix by using vchan_terminate_vdesc() as suggested by Frank Li
> ---
> Change in v4:
> -Correct the commit message
> ---
> drivers/dma/sun6i-dma.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 7a79f346250a..134ae840f176 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
>
> spin_lock_irqsave(&vchan->vc.lock, flags);
>
> - if (vchan->cyclic) {
> - vchan->cyclic = false;
> - if (pchan && pchan->desc) {
> - struct virt_dma_desc *vd = &pchan->desc->vd;
> - struct virt_dma_chan *vc = &vchan->vc;
> -
> - list_add_tail(&vd->node, &vc->desc_completed);
> - }
> + if (pchan && pchan->desc && pchan->desc != pchan->done) {
> + struct virt_dma_desc *vd = &pchan->desc->vd;
> +
> + vchan_terminate_vdesc(vd);
> }
>
> + vchan->cyclic = false;
> vchan_get_all_descriptors(&vchan->vc, &head);
>
> if (pchan) {
> --
> 2.25.1
--
~Vinod
^ permalink raw reply
* Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Peter Griffin @ 2026-06-30 11:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, 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: <b035916c-e985-4acf-930b-bb74814ae748@kernel.org>
Hi Krzysztof,
On Tue, 30 Jun 2026 at 12:12, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> 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.
Urgh, I see. My suggestion kind of assumed the downstream vendor tree
had been pushed to a public Git repository, similar to how Google used
to push their gs101 sources, for example:
https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/drivers/soc/google/cal-if/
A link to a tarball for sure isn't as easy to just click through and
take a look which is what I was hoping to achieve. Thanks for the link
though, maybe that will come in useful at some point.
Peter
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Thorsten Leemhuis @ 2026-06-30 11:29 UTC (permalink / raw)
To: Jiajia Liu, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Ming Yen Hsieh, Leon Yen
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Linux kernel regressions list
In-Reply-To: <20260528033814.46418-1-liujiajia@kylinos.cn>
On 5/28/26 05:38, Jiajia Liu wrote:
> Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
> to avoid reinitializing the wcid->poll_list.
>
> Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
Jiajia Liu, Felox: given that the problem seems to be in 7.1, should we
ask the stable team to pick this regression fix up, as this change was
mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
Ciao, Thorsten
> According to the corruption information, prev->next was changed to itself.
>
> wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
> wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
> wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
> slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
> list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
>
> mt76_wcid_add_poll+0x95/0xd0 [mt76]
> mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
> mt7925_rx_check+0xa7/0xc0 [mt7925_common]
> mt76_dma_rx_poll+0x50d/0x790 [mt76]
> mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
>
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
>
> Changes in v2:
> - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
> wcid publish check suggested by Sean
> - subject and commit message update
>
> ---
> drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
> index 4ae5e4715a9c..b78b4cd206e0 100644
> --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
> +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
> @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> {
> struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
> struct mt76_dev *dev = phy->dev;
> + struct mt76_wcid *published;
> int ret;
> int i;
>
> @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> mtxq->wcid = wcid->idx;
> }
>
> - ewma_signal_init(&wcid->rssi);
> - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> + published = rcu_dereference_protected(dev->wcid[wcid->idx],
> + lockdep_is_held(&dev->mutex));
> + if (published != wcid) {
> + WARN_ON_ONCE(published);
> + ewma_signal_init(&wcid->rssi);
> + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> + mt76_wcid_init(wcid, phy->band_idx);
> + } else {
> + wcid->phy_idx = phy->band_idx;
> + }
> +
> phy->num_sta++;
>
> - mt76_wcid_init(wcid, phy->band_idx);
> out:
> mutex_unlock(&dev->mutex);
>
^ permalink raw reply
* Re: [PATCH] PCI: dwc: meson: Fix reset GPIO initial state
From: Manivannan Sadhasivam @ 2026-06-30 11:28 UTC (permalink / raw)
To: Yue Wang, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Remi Pommarel, Ronald Claveau
Cc: linux-pci, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20260616-fix-meson-pcie-reset-gpio-v1-1-fca404b4c8be@aliel.fr>
On Tue, 16 Jun 2026 09:07:25 +0200, Ronald Claveau wrote:
> Commit 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio
> descriptor") inverted the reset assertion logic to use proper gpio
> descriptor semantics, and moved the polarity configuration to the
> device tree as GPIO_ACTIVE_LOW. However, the initial GPIO state
> "GPIOD_OUT_LOW" was not updated accordingly.
>
> Change GPIOD_OUT_LOW to GPIOD_OUT_HIGH to get the right behaviour.
>
> [...]
Applied, thanks!
[1/1] PCI: dwc: meson: Fix reset GPIO initial state
commit: 702c89eec25a10932bed074cb9adf0fcfcb6652c
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* RE: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Alim Akhtar @ 2026-06-30 11:28 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Peter Griffin'
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: <b035916c-e985-4acf-930b-bb74814ae748@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Tuesday, June 30, 2026 4:43 PM
> To: Peter Griffin <peter.griffin@linaro.org>; Alim Akhtar
> <alim.akhtar@samsung.com>
> Cc: Denzeel Oliva <wachiturroxd150@gmail.com>; Sylwester Nawrocki
> <s.nawrocki@samsung.com>; Chanwoo Choi <cw00.choi@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
>
> 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.
>
Right, I am not against adding any best practice guideline, but I wonder only few of us will end up reviewing those patches.
And for other reviewer, cal-if will add more confusion as it is completely out of {tree / clk subsystem} interface.
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v6 06/16] arm64: dts: st: add i2c1 pins for stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add the i2c1 pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v1)
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 456ece7f8ebc..db485b9ed904 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -203,6 +203,25 @@ pins {
};
};
+ /omit-if-no-ref/
+ i2c1_pins_a: i2c1-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 13, AF9)>, /* I2C1_SCL */
+ <STM32_PINMUX('A', 2, AF10)>; /* I2C1_SDA */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ /omit-if-no-ref/
+ i2c1_sleep_pins_a: i2c1-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 13, ANALOG)>, /* I2C1_SCL */
+ <STM32_PINMUX('A', 2, ANALOG)>; /* I2C1_SDA */
+ };
+ };
+
/omit-if-no-ref/
i2c2_pins_a: i2c2-0 {
pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v2] i2c: mt7621: Use dev_err_probe() for clock acquisition failures
From: phucduc.bui @ 2026-06-30 11:19 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>
---
update in v2 :
Add the missing return after dev_err_probe().
drivers/i2c/busses/i2c-mt7621.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt7621.c b/drivers/i2c/busses/i2c-mt7621.c
index 0a288c998419..8ab7a304a02c 100644
--- a/drivers/i2c/busses/i2c-mt7621.c
+++ b/drivers/i2c/busses/i2c-mt7621.c
@@ -280,10 +280,9 @@ 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))
+ return 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
* [PATCH] net: airoha: fix MIB stats collection to be lossless
From: Aniket Negi @ 2026-06-30 11:18 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Christian Marangi, Simon Horman, linux-arm-kernel,
linux-mediatek, netdev, linux-kernel, Aniket Negi
The airoha_dev_get_hw_stats() function had two correctness issues in the
way it collects hardware MIB counters.
Bug 1: Read-clear race causes silent packet loss in statistics
airoha_update_hw_stats() read all MIB registers and then cleared them
via REG_FE_GDM_MIB_CLEAR. There is a time window between the last
register read and the hardware clear. Any packet that the hardware
counts during this window is lost: the register is incremented, then
cleared, without the increment ever being read by software. Under
sustained traffic this causes a permanent and growing undercount in all
reported statistics.
This is particularly misleading for tx_ok_pkts and tx_ok_bytes, which
routers and traffic monitors use to detect packet forwarding loss
between two points in a hardware-accelerated path (e.g., between two
netdevs in the QDMA/PPE fast-path). An inaccurate count makes it
impossible to reliably attribute drops in the forwarding pipeline
without capturing traffic at both ends independently.
Bug 2: 32-bit counter overflow causes stat corruption
Several MIB registers are only 32 bits wide: tx_drops, tx_broadcast,
tx_multicast, rx_drops, rx_broadcast, rx_multicast, rx_errors,
rx_crc_error, rx_over_errors, rx_fragment, rx_jabber, and the runt and
long buckets of the tx_len[]/rx_len[].
The original code relied on MIB_CLEAR to keep register values small
enough that a simple '+= val' per cycle did not lose data across a
wrap. Once clearing is removed (to fix Bug 1), raw '+= val' silently
corrupts the accumulated software counter on overflow.
Fix both issues together:
- 64-bit H+L register pairs (tx_ok_pkts, tx_ok_bytes, tx_len[1..5],
rx_ok_pkts, rx_ok_bytes, rx_len[1..5]): read directly from hardware
without clearing. Hardware accumulates the full running total; a
single direct assignment per poll is correct and lossless.
- 32-bit registers (tx_drops, tx_broadcast, tx_multicast, rx_drops,
rx_broadcast, rx_multicast, rx_errors, rx_crc_error, rx_over_errors,
rx_fragment, rx_jabber, and the runt/long buckets in tx_len[0]/[6]
and rx_len[0]/[6]): track the previous hardware value in a new
hw_prev_stats sub-struct inside airoha_hw_stats and accumulate
(u32)(curr - prev) into the 64-bit software counter. Unsigned
subtraction handles wrap-around transparently:
prev=0xFFFFFF00, curr=0x00000010 -> delta=(u32)(0x10-0xFFFFFF00)=0x110
Remove the REG_FE_GDM_MIB_CLEAR write from airoha_update_hw_stats()
entirely. Because the driver no longer clears hardware counters, the
read-clear race window is eliminated.
The hw_prev_stats fields are zero-initialised by the existing
devm_kzalloc() call in airoha_alloc_gdm_device().
Fixes: 8f4695fb67b2 ("net: airoha: better handle MIBs for GDM ports with multiple devs attached")
Signed-off-by: Aniket Negi <aniket.negi03@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 132 +++++++++++------------
drivers/net/ethernet/airoha/airoha_eth.h | 22 ++++
2 files changed, 86 insertions(+), 68 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 1caf6766f2c0..7ae4e294478e 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1696,133 +1696,133 @@ static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
u64_stats_update_begin(&dev->stats.syncp);
- /* TX */
+ /* TX - 64-bit H+L registers: hw accumulates the total, read directly. */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
- dev->stats.tx_ok_pkts += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
- dev->stats.tx_ok_pkts += val;
+ dev->stats.tx_ok_pkts = (u64)val << 32;
+ dev->stats.tx_ok_pkts += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
- dev->stats.tx_ok_bytes += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
- dev->stats.tx_ok_bytes += val;
+ dev->stats.tx_ok_bytes = (u64)val << 32;
+ dev->stats.tx_ok_bytes += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
+ /* TX - 32-bit registers: accumulate delta to handle wrap-around. */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
- dev->stats.tx_drops += val;
+ dev->stats.tx_drops += (u32)(val - dev->stats.hw_prev_stats.tx_drops);
+ dev->stats.hw_prev_stats.tx_drops = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
- dev->stats.tx_broadcast += val;
+ dev->stats.tx_broadcast += (u32)(val - dev->stats.hw_prev_stats.tx_broadcast);
+ dev->stats.hw_prev_stats.tx_broadcast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
- dev->stats.tx_multicast += val;
+ dev->stats.tx_multicast += (u32)(val - dev->stats.hw_prev_stats.tx_multicast);
+ dev->stats.hw_prev_stats.tx_multicast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
- dev->stats.tx_len[i] += val;
+ dev->stats.tx_len[i] += (u32)(val - dev->stats.hw_prev_stats.tx_len[i]);
+ dev->stats.hw_prev_stats.tx_len[i] = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] += (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_LONG_CNT(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] += (u32)(val - dev->stats.hw_prev_stats.tx_len[i]);
+ dev->stats.hw_prev_stats.tx_len[i++] = val;
/* RX */
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_H(port->id));
- dev->stats.rx_ok_pkts += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
- dev->stats.rx_ok_pkts += val;
+ dev->stats.rx_ok_pkts = (u64)val << 32;
+ dev->stats.rx_ok_pkts += airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_H(port->id));
- dev->stats.rx_ok_bytes += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
- dev->stats.rx_ok_bytes += val;
+ dev->stats.rx_ok_bytes = (u64)val << 32;
+ dev->stats.rx_ok_bytes += airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_DROP_CNT(port->id));
- dev->stats.rx_drops += val;
+ dev->stats.rx_drops += (u32)(val - dev->stats.hw_prev_stats.rx_drops);
+ dev->stats.hw_prev_stats.rx_drops = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_BC_CNT(port->id));
- dev->stats.rx_broadcast += val;
+ dev->stats.rx_broadcast += (u32)(val - dev->stats.hw_prev_stats.rx_broadcast);
+ dev->stats.hw_prev_stats.rx_broadcast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_MC_CNT(port->id));
- dev->stats.rx_multicast += val;
+ dev->stats.rx_multicast += (u32)(val - dev->stats.hw_prev_stats.rx_multicast);
+ dev->stats.hw_prev_stats.rx_multicast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ERROR_DROP_CNT(port->id));
- dev->stats.rx_errors += val;
+ dev->stats.rx_errors += (u32)(val - dev->stats.hw_prev_stats.rx_errors);
+ dev->stats.hw_prev_stats.rx_errors = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_CRC_ERR_CNT(port->id));
- dev->stats.rx_crc_error += val;
+ dev->stats.rx_crc_error += (u32)(val - dev->stats.hw_prev_stats.rx_crc_error);
+ dev->stats.hw_prev_stats.rx_crc_error = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OVERFLOW_DROP_CNT(port->id));
- dev->stats.rx_over_errors += val;
+ dev->stats.rx_over_errors += (u32)(val - dev->stats.hw_prev_stats.rx_over_errors);
+ dev->stats.hw_prev_stats.rx_over_errors = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_FRAG_CNT(port->id));
- dev->stats.rx_fragment += val;
+ dev->stats.rx_fragment += (u32)(val - dev->stats.hw_prev_stats.rx_fragment);
+ dev->stats.hw_prev_stats.rx_fragment = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_JABBER_CNT(port->id));
- dev->stats.rx_jabber += val;
+ dev->stats.rx_jabber += (u32)(val - dev->stats.hw_prev_stats.rx_jabber);
+ dev->stats.hw_prev_stats.rx_jabber = val;
i = 0;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
- dev->stats.rx_len[i] += val;
+ dev->stats.rx_len[i] += (u32)(val - dev->stats.hw_prev_stats.rx_len[i]);
+ dev->stats.hw_prev_stats.rx_len[i] = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] += (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_LONG_CNT(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] += (u32)(val - dev->stats.hw_prev_stats.rx_len[i]);
+ dev->stats.hw_prev_stats.rx_len[i++] = val;
u64_stats_update_end(&dev->stats.syncp);
}
@@ -1839,10 +1839,6 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
airoha_dev_get_hw_stats(port->devs[i]);
}
- /* Reset MIB counters */
- airoha_fe_set(dev->eth, REG_FE_GDM_MIB_CLEAR(port->id),
- FE_GDM_MIB_RX_CLEAR_MASK | FE_GDM_MIB_TX_CLEAR_MASK);
-
spin_unlock(&port->stats_lock);
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 2765244d937c..af12ad6eac17 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -244,6 +244,28 @@ struct airoha_hw_stats {
u64 rx_fragment;
u64 rx_jabber;
u64 rx_len[7];
+
+ struct {
+ /* Previous HW register values for 32-bit counter delta tracking.
+ * Storing the last seen value and accumulating (u32)(curr - prev)
+ * in 64-bit software counter & handles wrap-around transparently
+ * via unsigned arithmetic. These fields are never reported to
+ * userspace.
+ */
+ u32 tx_drops;
+ u32 tx_broadcast;
+ u32 tx_multicast;
+ u32 tx_len[7];
+ u32 rx_drops;
+ u32 rx_broadcast;
+ u32 rx_multicast;
+ u32 rx_errors;
+ u32 rx_crc_error;
+ u32 rx_over_errors;
+ u32 rx_fragment;
+ u32 rx_jabber;
+ u32 rx_len[7];
+ } hw_prev_stats;
};
enum {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v8 6/6] pinctrl: mediatek: Add MT6735 pinctrl driver
From: Linus Walleij @ 2026-06-30 11:17 UTC (permalink / raw)
To: Yassine Oudjana
Cc: Yassine Oudjana, Sean Wang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Andy Teng, linux-mediatek, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <PjcK3j_TxnXwwBQ8ATPAPOO6LJl5b0Laa_6eSBTVfEfqsxIcaeDEVS4q4UkvGQA7CLQbuGxopLF6p3eIh1JAIDTkPFIgwp-hVP-fex_WEqU=@protonmail.com>
On Sat, Jun 13, 2026 at 11:20 AM Yassine Oudjana
<y.oudjana@protonmail.com> wrote:
> On Monday, June 8th, 2026 at 9:41 PM, Linus Walleij <linusw@kernel.org> wrote:
> > > From: Yassine Oudjana <y.oudjana@protonmail.com>
> > >
> > > Add a driver for the MediaTek MT6735 SoC pin controller. This driver
> > > also supports the pin controller on MT6735M, which lacks 6 physical
> > > pins (198-203) used for MSDC2 on MT6735.
> > >
> > > Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> >
> > Sashiko has good comments on this driver, look into them!
>
> Didn't receive any comments and I don't see anything on the mailing list
> archives either. Am I missing something?
https://lore.kernel.org/linux-devicetree/20260530155503.9A6C41F00893@smtp.kernel.org/
Yours,
Linus Walleij
^ 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
* 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] 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 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 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 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 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
* [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 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
* 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
* [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
* [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
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