* Re: [PATCH 1/3] xfrm: extend ESP offload infrastructure for packet engines
From: Leon Romanovsky @ 2026-06-11 11:56 UTC (permalink / raw)
To: Jihong Min
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steffen Klassert, linux-kernel,
linux-crypto, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260523121522.3023992-2-hurryman2212@gmail.com>
On Sat, May 23, 2026 at 09:15:20PM +0900, Jihong Min wrote:
> Some ESP offload engines operate on whole ESP packets rather than the
> generic software trailer layout. They can generate outbound ESP padding,
> next-header and ICV bytes in hardware, and inbound decapsulation can
> return an already-trimmed packet with the recovered next-header value.
How does this differ from the existing IPsec packet‑offload support in the
Linux kernel?
Thanks
^ permalink raw reply
* Re: [PATCH 00/11] pinctrl: airoha: small fixes
From: Linus Walleij @ 2026-06-11 11:53 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Lorenzo Bianconi, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
On Sat, Jun 6, 2026 at 4:04 AM Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> wrote:
> This is a set of small fixes for Airoha pinctrl driver.
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 04/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Petr Tesarik @ 2026-06-11 11:50 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <20260611113740.GB1066031@ziepe.ca>
On Thu, 11 Jun 2026 08:37:40 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Thu, Jun 11, 2026 at 10:55:47AM +0530, Aneesh Kumar K.V wrote:
> > Jason Gunthorpe <jgg@ziepe.ca> writes:
> >
> > > The sashiko note does look legit though:
> > >
> > > if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > > !gfpflags_allow_blocking(gfp) && !coherent) {
> > > page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
> > > gfp, attrs, NULL);
> > > if (!page)
> > > return NULL;
> > >
> > > I don't see anything doing the force_dma_unencrypted test along this
> > > callchain..
> > >
> > > I guess it should be done one step up in dma_alloc_attrs() instead of
> > > in dma_direct_alloc()?
> > >
> >
> > I think we should do something similar to what dma_map_phys() does here,
> > considering that we only support DMA direct with DMA_ATTR_CC_SHARED/DMA_ATTR_ALLOC_CC_SHARED.
>
> Yeah, I think that's the right idea for now..
>
> > + if (force_dma_unencrypted(dev))
> > + attrs |= DMA_ATTR_ALLOC_CC_SHARED;
> > +
> > + is_cc_shared = attrs & DMA_ATTR_CC_SHARED;
> > +
> > if (dma_alloc_direct(dev, ops) || arch_dma_alloc_direct(dev)) {
> > cpu_addr = dma_direct_alloc(dev, size, dma_handle, flag, attrs);
> > + } else if (is_cc_shared) {
> > + trace_dma_alloc(dev, NULL, 0, size, DMA_BIDIRECTIONAL, flag,
> > + attrs);
>
> But it would be clearer to put the test in the iommu_ functions I
> think, since they are the ones that have the issue. We will need to
> fix it someday..
>
> I think we can ignore the op-> functions, arches cannot support CC and
> still use dma_map_ops..
Hm, sounds reasonable. Should we probably enforce this at configure or
build time?
Petr T
^ permalink raw reply
* Re: [PATCH v2 0/3] pinctrl: sunxi: a523: fix GPIO IRQ operation
From: Linus Walleij @ 2026-06-11 11:49 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, linux-gpio, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260327113006.3135663-1-andre.przywara@arm.com>
On Fri, Mar 27, 2026 at 12:30 PM Andre Przywara <andre.przywara@arm.com> wrote:
> this is the minimal fix version for the GPIO IRQ operation on the
> Allwinner A523/A527/T527 SoCs. SD card detection is broken as a result,
> which is a major annoyance. Those patches here fix that problem, and
> should go into v7.0 still, if possible.
Patches 1 & 2 applied to the pinctrl tree, please send patch 3 to
the SoC tree.
Sorry for missing this, dunno what happened. Probably it got
lost by me trying to use korgalore and screwing up.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] spi: xilinx: use FIFO occupancy register to determine buffer size
From: Michal Simek @ 2026-06-11 11:46 UTC (permalink / raw)
To: Lars Pöschel, Mark Brown, linux-spi, linux-arm-kernel,
linux-kernel
Cc: Mahapatra, Amit Kumar, lars.poeschel
In-Reply-To: <e6af23c7-1ba9-4acc-af16-394fde75b4da@edag.com>
On 6/11/26 13:36, Lars Pöschel wrote:
> On 6/11/26 10:52 Michal Simek wrote:
>> +Amit,
>>
>> On 6/11/26 09:10, lars.poeschel.linux@edag.com wrote:
>>> From: Lars Pöschel <lars.poeschel@edag.com>
>>>
>>> The method the driver uses to determine the size of the FIFO has a
>>> problem. What it currently does is this:
>>> It stops the SPI hardware and writes to the TX FIFO register until TX
>>> FIFO FULL asserts in the status register. But the hardware does not only
>>> have the FIFO, it also seems to have a shift register. This can be seen,
>>
>> I don't think you should guess here
>
> Ok, I will change that.
>
>>> when writing a byte to the FIFO (while the SPI hardware is stopped,) the
>>> TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for
>>> example, the current method returns a 17.
>>
>>
>>
>>
>>> This is a problem, at least when using the driver in irq mode. The same
>>> size determined for the TX FIFO is also assumed for the RX FIFO. When an
>>> SPI transaction wants to write the amount of the FIFO size or more
>>> bytes, the following happens, let's assume 16 bytes FIFO size:
>>
>> s/let's/for example/
>
> Ok.
>
>>> The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and
>>> starts the SPI hardware and goes sleep.
>>> The hardware then shifts out 17 bytes (FIFO + shift register) and
>>> simultaneously reads bytes into the RX FIFO, but it only has 16 places,
>>> so it looses one byte. Then TX FIFO empty asserts, wakes the driver
>>> again, which has a fast path and reads 16 bytes from the RX FIFO, but
>>> before reading the last 17th byte (which is lost) it does this:
>>>
>>> sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
>>> if (!(sr & XSPI_SR_RX_EMPTY_MASK)) {
>>> xilinx_spi_rx(xspi);
>>> rx_words--;
>>> }
>>>
>>> It reads the status register and checks if the RX FIFO is not empty.
>>> But it is empty in our case. So this check spins in a while loop
>>> forever locking the driver.
>>>
>>> The new method for determining the FIFO size is to read the SPITFOR (TX
>>> FIFO occupancy register, value = occupancy - 1) after filling the TX
>>> FIFO to obtain the true FIFO storage depth, which also equals the RX
>>> FIFO depth. In non-FIFO configurations (n_words == 1) the register does
>>> not exist; return 1 directly in that case.
>>>
>>
>> missing fix tag.
>
> Ok, I will add one.
>
>>> Signed-off-by: Lars Pöschel <lars.poeschel@edag.com>
>>> ---
>>> drivers/spi/spi-xilinx.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
>>> index 9f065d4e27d1..2d31e30fc4eb 100644
>>> --- a/drivers/spi/spi-xilinx.c
>>> +++ b/drivers/spi/spi-xilinx.c
>>> @@ -54,6 +54,7 @@
>>> #define XSPI_RXD_OFFSET 0x6c /* Data Receive Register */
>>> #define XSPI_SSR_OFFSET 0x70 /* 32-bit Slave Select Register */
>>> +#define XSPI_TFOR_OFFSET 0x74 /* Transmit FIFO Occupancy Register */
>>> /* Register definitions as per "OPB IPIF (v3.01c) Product Specification",
>>> DS414
>>> * IPIF registers are 32 bit
>>> @@ -377,7 +378,9 @@ static int xilinx_spi_find_buffer_size(struct xilinx_spi
>>> *xspi)
>>> n_words++;
>>> } while (!(sr & XSPI_SR_TX_FULL_MASK));
>>> - return n_words;
>>> + if (n_words == 1)
>>> + return 1;
>>> + return xspi->read_fn(xspi->regs + XSPI_TFOR_OFFSET) + 1;
>>
>> Based on pg153
>> Exists only when FIFO Depth is set to 16 or 256
>>
>> Based on ds570
>> This register does not exist if C_FIFO_EXIST = 0
>>
>> It means this is not going to work with all HW configurations.
>
> I think it will work with all HW configurations, even with no FIFO configured.
> You are right, TFOR does not exist in non-FIFO configurations, but then you will
> take the
>
> if (n_words ==1)
> return 1;
>
> path and exit before reading this register. And then according to PG153, Table
> 2-6, Tx_Full bit:
> "Note: When FIFOs do not exist, this bit is set High when an AXI write to the
> transmit register has been made (this option is available only in standard SPI
> mode). This bit is cleared when the SPI transfer is completed."
> So n_words should be 1 in this case and I think this should still work.
>
>> Pretty much you wanted to use this register to find out how big is the fifo
>> but I think in this case you should be just fixing logic around +-1 caused by
>> n_words++ in a loop.
>>
>> What about to change logic to be like this? It is clear and it is without any
>> +1 logic and no fifo is handled separately?
>>
>> while (1) {
>>
>> xspi->write_fn(0, xspi->regs + XSPI_TXD_OFFSET);
>>
>> sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
>>
>> if (sr & XSPI_SR_TX_FULL_MASK)
>>
>> break;
>>
>> n_words++;
>>
>> }
>>
>>
>>
>>
>> /* Handle NO FIFO case separately */
>>
>> if (!n_words)
>>
>> return 1;
>>
>>
>>
>>
>> return n_words;
>
> If you still think, this is more clear or better readable, then I can change it
> like this. Let me know!
I understand that without FIFO you should never reach that code but I still
think it is better not to deal with it. Pretty much if you want to wire this
register I think dt binding should be extended to cover this optional feature.
That's why I think it is better not to introduce it.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v6 04/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Jason Gunthorpe @ 2026-06-11 11:37 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <yq5aa4t1myw4.fsf@kernel.org>
On Thu, Jun 11, 2026 at 10:55:47AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
>
> > The sashiko note does look legit though:
> >
> > if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > !gfpflags_allow_blocking(gfp) && !coherent) {
> > page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
> > gfp, attrs, NULL);
> > if (!page)
> > return NULL;
> >
> > I don't see anything doing the force_dma_unencrypted test along this
> > callchain..
> >
> > I guess it should be done one step up in dma_alloc_attrs() instead of
> > in dma_direct_alloc()?
> >
>
> I think we should do something similar to what dma_map_phys() does here,
> considering that we only support DMA direct with DMA_ATTR_CC_SHARED/DMA_ATTR_ALLOC_CC_SHARED.
Yeah, I think that's the right idea for now..
> + if (force_dma_unencrypted(dev))
> + attrs |= DMA_ATTR_ALLOC_CC_SHARED;
> +
> + is_cc_shared = attrs & DMA_ATTR_CC_SHARED;
> +
> if (dma_alloc_direct(dev, ops) || arch_dma_alloc_direct(dev)) {
> cpu_addr = dma_direct_alloc(dev, size, dma_handle, flag, attrs);
> + } else if (is_cc_shared) {
> + trace_dma_alloc(dev, NULL, 0, size, DMA_BIDIRECTIONAL, flag,
> + attrs);
But it would be clearer to put the test in the iommu_ functions I
think, since they are the ones that have the issue. We will need to
fix it someday..
I think we can ignore the op-> functions, arches cannot support CC and
still use dma_map_ops..
Jason
^ permalink raw reply
* [PATCH net 1/2] net/stmmac: Apply TBS config only to used queues
From: Jakub Raczynski @ 2026-06-11 11:33 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, linux-kernel, linux-arm-kernel, k.domagalski,
k.tegowski, Jakub Raczynski, Chang-Sub Lee
In-Reply-To: <20260611113358.3379518-1-j.raczynski@samsung.com>
While opening stmmac driver, there is enabling of TBS (Time-Based Scheduling)
option in dma config. Currently this is executed for all possible TX queues via
MTL_MAX_TX_QUEUES macro, but actual number of queues used might differ.
While setting this is generally harmless, since memory for MTL_MAX_TX_QUEUES
is allocated, it is incorrect, because it prepares config for unused queues.
Change this to apply tbs config only to tx_queues_to_use.
Fixes: 4896bb7c0b31a ("net: stmmac: do not clear TBS enable bit on link up/down")
Co-developed-by: Chang-Sub Lee <cs0617.lee@samsung.com>
Signed-off-by: Chang-Sub Lee <cs0617.lee@samsung.com>
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3591755ea30b..5917bf47c7de 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4140,7 +4140,7 @@ static int __stmmac_open(struct net_device *dev,
u8 chan;
int ret;
- for (int i = 0; i < MTL_MAX_TX_QUEUES; i++)
+ for (int i = 0; i < priv->plat->tx_queues_to_use; i++)
if (priv->dma_conf.tx_queue[i].tbs & STMMAC_TBS_EN)
dma_conf->tx_queue[i].tbs = priv->dma_conf.tx_queue[i].tbs;
memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));
--
2.34.1
^ permalink raw reply related
* [PATCH net 0/2] net/stmmac: Fixes for maximum TX/RX queues to use by driver
From: Jakub Raczynski @ 2026-06-11 11:33 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, linux-kernel, linux-arm-kernel, k.domagalski,
k.tegowski, Jakub Raczynski
In-Reply-To: <CGME20260611113403eucas1p1f4b61896c875f1f6833d6ca136472af8@eucas1p1.samsung.com>
When contributing other changes preparing functions for new XGMAC hardware
https://lore.kernel.org/netdev/20260601162537.553512-1-j.raczynski@samsung.com/
there have been reports by Sashiko AI review about pre-existing issues
in the code. These problems are non-insignificant and are 'net' material fixes,
rather than net-next features.
One issue in this patchset was reported by Sashiko AI, while other
technically part of new patchset, but is reasonable related fix.
All of issues are wrong DTS configuration, but kernel needs to handle it.
Jakub Raczynski (2):
net/stmmac: Apply TBS config only to used queues
net/stmmac: Apply MTL_MAX queue limit if config missing
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-11 11:31 UTC (permalink / raw)
To: Mark Brown, linux-spi
Cc: linux-arm-kernel, linux-kernel, Kunihiko Hayashi, Sangyun Kim,
Kyungwook Boo, stable, Masami Hiramatsu
The driver calls devm_request_irq() before initializing the completion
used by the interrupt handler. Because the interrupt may occur immediately
after devm_request_irq(), the handler may execute before init_completion().
This may result in calling complete() on an uninitialized completion,
causing undefined behavior. This has been observed with KASAN.
Fix this by initializing the completion before registering the IRQ.
Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/spi/spi-uniphier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index 9e1d364a6198..6d3463fe0e3c 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -659,6 +659,8 @@ static int uniphier_spi_probe(struct platform_device *pdev)
priv->host = host;
priv->is_save_param = false;
+ init_completion(&priv->xfer_done);
+
priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(priv->base)) {
ret = PTR_ERR(priv->base);
@@ -690,8 +692,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
goto out_disable_clk;
}
- init_completion(&priv->xfer_done);
-
clk_rate = clk_get_rate(priv->clk);
host->max_speed_hz = DIV_ROUND_UP(clk_rate, SSI_MIN_CLK_DIVIDER);
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: David Hildenbrand (Arm) @ 2026-06-11 11:28 UTC (permalink / raw)
To: Lance Yang, akpm
Cc: xueyuan.chen21, linux-mm, linux-kernel, linux-arm-kernel, x86,
catalin.marinas, will, tglx, mingo, bp, dave.hansen, luto, peterz,
hpa, ljs, liam, vbabka, rppt, surenb, mhocko, ziy, baolin.wang,
npache, ryan.roberts, dev.jain, baohua, yang, jannh, dave.hansen
In-Reply-To: <20260610021508.46000-1-lance.yang@linux.dev>
On 6/10/26 04:15, Lance Yang wrote:
>
> On Tue, Jun 09, 2026 at 12:45:49PM -0700, Andrew Morton wrote:
>> On Tue, 9 Jun 2026 22:37:59 +0800 Xueyuan Chen <xueyuan.chen21@gmail.com> wrote:
>>
>>> The huge zero folio is shared globally, and its contents should never
>>> change after initialization. As Jann Horn pointed out[1], the kernel has
>>> had bugs, including security bugs, where read-only pages were later written
>>> to. If the persistent huge zero folio is read-only in the direct map, such
>>> writes fault instead of silently corrupting the shared zero contents.
>>>
>>> Add arch_make_pages_readonly() so mm code can request read-only direct-map
>>> protection for a page range. Direct-map protection is
>>> architecture-specific, so the generic weak implementation does nothing.
>>>
>>> This was inspired by Jann Horn's read-only zero page work[1] and follow-up
>>> discussion[2] with Yang Shi.
>>>
>>> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
>>> [2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
>>>
>>> ...
>>>
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink,
>>> return 0;
>>> }
>>>
>>> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
>>> +{
>>> + return false;
>>> +}
>>> +
>>> static struct shrinker *huge_zero_folio_shrinker;
>>>
>>> #ifdef CONFIG_SYSFS
>>> @@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void)
>>> * that get_huge_zero_folio() will most likely not fail as
>>> * thp_shrinker_init() is invoked early on during boot.
>>> */
>>> - if (!get_huge_zero_folio())
>>> + if (!get_huge_zero_folio()) {
>>> pr_warn("Allocating persistent huge zero folio failed\n");
>>> + return 0;
>>> + }
>>> +
>>> + arch_make_pages_readonly(folio_page(huge_zero_folio, 0),
>>> + HPAGE_PMD_NR);
>>
>> Can it simply pass the folio?
>
> Right, this came from the RFC v1 discussion[1]. David preferred a page-
> range helper for possible future non-folio callers, not something folio-
> only.
>
> Of course, we could also add a folio wrapper on top of that if needed :)
Best to document that as part of the patch description: we don't really expect
to have a lot of read-only folios in the near future (zero page is rather
special; maybe it won't even be a folio in the future).
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Vinod Koul @ 2026-06-11 11:26 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <ebcad67e-e14a-4d0e-b3e0-79ae1d146eaf@collabora.com>
On 03-06-26, 13:27, Cristian Ciocaltea wrote:
> On 5/20/26 10:05 PM, Cristian Ciocaltea wrote:
> > Hi Vinod,
> >
> > On 5/11/26 9:21 PM, Cristian Ciocaltea wrote:
> >> This series provides a set of bug fixes and cleanups for the Rockchip
> >> Samsung HDPTX PHY driver.
> >>
> >> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
> >> calculation and synchronization issues. Specifically, it fixes edge
> >> cases where the PHY PLL is pre-programmed by an external component (like
> >> a bootloader) or when changing the color depth (bpc) while keeping the
> >> modeline constant. Because the Common Clock Framework .set_rate()
> >> callback might not be invoked if the pixel clock remains unchanged, this
> >> previously led to out-of-sync states between CCF and the actual HDMI PHY
> >> configuration.
> >>
> >> The second part focuses on code cleanups and modernizing the register
> >> access. Now that dw_hdmi_qp driver has fully switched to using
> >> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
> >> and the restrict_rate_change flag logic. Finally, it refactors the
> >> driver to consistently use standard bitfield macros.
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >> Changes in v2:
> >> - Collected Tested-by tags from Thomas and Simon
> >> - Fixed a typo in commit description of patch 1
> >> - Added a comment in patch 2 explaining why PLL config errors are
> >> ignored for rk_hdptx_phy_consumer_get()
> >> - Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
> >> - Rebased onto latest phy/fixes
> >> - Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
> >
> > In case you missed my comments from last week on the Sashiko AI review findings
> > - in short, I don't think there is anything to worry about and the series should
> > be fine to apply as-is. Please let me know if you would still prefer a new
> > revision.
> Kind reminder..
Please post a new revision based on phy/next
Thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Use common error handling code in __scmi_device_create()
From: Cristian Marussi @ 2026-06-11 11:20 UTC (permalink / raw)
To: Markus Elfring
Cc: arm-scmi, linux-arm-kernel, Cristian Marussi, Sudeep Holla, LKML,
kernel-janitors
In-Reply-To: <545ffb86-55f5-46b2-83ca-285cd8d540d7@web.de>
On Thu, Jun 11, 2026 at 10:34:52AM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 11 Jun 2026 10:27:45 +0200
>
> Use an additional label so that a bit of exception handling can be better
> reused at the end of an if branch.
>
Hi,
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/firmware/arm_scmi/bus.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 793be9eabaed..8c20ed1a8243 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -450,14 +450,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> return NULL;
>
> scmi_dev->name = kstrdup_const(name ?: "unknown", GFP_KERNEL);
> - if (!scmi_dev->name) {
> - kfree(scmi_dev);
> - return NULL;
> - }
> + if (!scmi_dev->name)
> + goto free_scmi_dev;
>
> id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> if (id < 0) {
> kfree_const(scmi_dev->name);
> +free_scmi_dev:
> kfree(scmi_dev);
I can understand the aim, but jumping in the middle of another block
just to reuse the cleanup statement is far less readable (and ugly)
Cleanup handlers probably a better solution here...but I have NOT looked
at all the sorrounding code here recently...so I maybe wrong and keeping
the current code could be even bette.
Thanks,
Cristian
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] arm64: realm: Support for probing RSI earlier
From: Catalin Marinas @ 2026-06-11 11:14 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: linux-arm-kernel, linux-kernel, will, ardb, lpieralisi,
mark.rutland, steven.price, aneesh.kumar, sudeep.holla, robh, maz
In-Reply-To: <470678cb-b8b0-4b09-bf32-97fb037ed849@arm.com>
On Fri, May 29, 2026 at 01:27:01PM +0100, Suzuki K Poulose wrote:
> On 28/05/2026 17:06, Catalin Marinas wrote:
> > On Tue, May 05, 2026 at 04:57:38PM +0100, Suzuki K Poulose wrote:
> > > This is an updated series, addressing the review comments from AI agent on
> > > the version 1 [0] of the series, (some of which were documented as short comings).
> > > See below for the changes.
> > >
> > > The Realm Guest linux support is broken without rodata=full (fortunately default
> > > for arm64), as we detect the RSI support after we have created the Linear map
> > > with Block/Contiguous mappings. If the boot CPU doesn't support BBML2_NOABORT
> > > (there are CPUs out there with FEAT_RME and no - useable - BBML2_NOABORT)
> > > we are then not able to split the page tables down to PTE level if the system
> > > as such doesn't support BBML2.
> > >
> > > See the following link for the discussion.
> > >
> > > https://lore.kernel.org/all/20260330161705.3349825-2-ryan.roberts@arm.com/
> > >
> > > The available options are :
> > > 1. Start with PTE level mappings at paging_init() and then "FOLD" the page tables
> > > to Block/Cont mappings after we have the full picture available. Looking at the
> > > future (with BBML3), this might mean "additional work" for most of the systems
> > > at boot. But not bad as splitting them ?
> > > 2. Hold the secondary CPUs in busy loop with MMU disabled and split the mappings
> > > by the boot CPU with MMU off (if Boot CPU can't support BBML2). This is tricky
> > > with the page allocations required to add the page-tables.
> > > 3. Move the detection of Realm support earlier to make a better decision for
> > > paging_init(), with an added bonus of earlycon support for Realms without
> > > the user having to work out the "top bit" for the Realm.
> > >
> > > This series is an attempt to implement (3) (without the earlycon support). We try
> > > to probe the PSCI conduit early from the DT/ACPI. DT is not flattened at this time.
[...]
> > Could we instead add a more informative message in arm64_rsi_init() if
> > !force_pte_mappings() && !cpu_supports_bbml2_noabort() (before
> > is_realm_world() becomes true)? Well, it may not print anything if the
> > early console is not set up yet.
>
> That is true, but with some expertise you may be able to enable earlycon
> and may be we could get some new mechanism for "earlycon" for Realms.
>
> The other way to look at is:
>
> When the system doesn't support BBML2 Abort:
>
> Creating block/Cont mappings to start with and then splitting it to PTE
> is quite difficult as we :
> 1. Need to allocate pages for leaf level tables
> 2. Hold the other CPUs in tight loop
Agree, that's not easily possible at runtime.
> Instead, creating the block/CONT levels from a fully "page level"
> mappings are easier, as we can:
>
> 1. Can easily fold the tables to Block mapping with reclaiming the leaf
> level pagetables.
>
> 2. Avoid the secondary CPUs dance, as they all support BBML2_NOABORT.
>
> This shouldn't be that bad as the opposite ?
I don't think it solves our problem. Aren't we concerned with the
rodata=off && !BBML2_NOABORT && is_realm_world() case? I don't think
your second point stands.
Currently we have:
rodata=full && BBML2_NOABORT => block mappings irrespective of realms
rodata=off && BBML2_NOABORT => block mappings first, can be split later
if is_realm_world()
rodata=off && !BBML2_NOABORT => block mappings first, serious problem if
is_realm_world()
It's the last case we need to fix. Starting with page mappings does
avoid the in-realm failure but the !is_realm_world() case folding to
block mappings still requires proper BBM.
--
Catalin
^ permalink raw reply
* [PATCH] firmware: imx: Fix device context UAF in close
From: Harshit Mogalapalli @ 2026-06-11 11:05 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta, Peng Fan, Frieder Schrempf, Harshit Mogalapalli,
imx, linux-arm-kernel, linux-kernel
Cc: kernel-janitors, error27, sashiko-bot
se_if_fops_close() frees dev_ctx while still inside a
scoped_cond_guard() that holds dev_ctx->fops_lock. During the cleanup
phase it would do a mutex_unlock(dev_ctx->fops_lock) leading to UAF.
Fix it by freeing dev_ctx only after leaving the guarded scope.
Fixes: 2768fdfd5585 ("firmware: drivers: imx: adds miscdev")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260528094337.9C1D41F00A3A@smtp.kernel.org/
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
---
Only compile tested.
drivers/firmware/imx/se_ctrl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/imx/se_ctrl.c b/drivers/firmware/imx/se_ctrl.c
index 8fab3b7767b7..fc3bbd1788bd 100644
--- a/drivers/firmware/imx/se_ctrl.c
+++ b/drivers/firmware/imx/se_ctrl.c
@@ -887,9 +887,10 @@ static int se_if_fops_close(struct inode *nd, struct file *fp)
list_del(&dev_ctx->link);
kfree(dev_ctx->devname);
- kfree(dev_ctx);
}
+ kfree(dev_ctx);
+
return 0;
}
--
2.50.1
^ permalink raw reply related
* [GIT PULL] pmdomain fixes for v7.1-rc8
From: Ulf Hansson @ 2026-06-11 11:05 UTC (permalink / raw)
To: Linus, linux-pm, linux-kernel; +Cc: Ulf Hansson, linux-arm-kernel
Hi Linus,
Here's a pull-request with a couple of pmdomain fixes intended for v7.1-rc8.
Details about the highlights are as usual found in the signed tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 5d6919055dec134de3c40167a490f33c74c12581:
Linux 7.1-rc3 (2026-05-10 14:08:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git tags/pmdomain-v7.1-rc3
for you to fetch changes up to fba0510cd62666951dcc0221527edc0c47ae6599:
pmdomain: imx: fix OF node refcount (2026-06-03 11:49:37 +0200)
----------------------------------------------------------------
pmdomain providers:
- imx: Fix OF node refcount
- ti: Fix wakeup configuration for parent devices of wakeup sources
----------------------------------------------------------------
Bartosz Golaszewski (1):
pmdomain: imx: fix OF node refcount
Kendall Willis (1):
pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source
drivers/pmdomain/imx/gpc.c | 2 +-
drivers/pmdomain/ti/ti_sci_pm_domains.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] phy: nuvoton: Add MA35D1 USB2 OTG PHY driver
From: Vinod Koul @ 2026-06-11 11:04 UTC (permalink / raw)
To: Joey Lu
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260604101220.1092822-3-a0987203069@gmail.com>
On 04-06-26, 18:12, Joey Lu wrote:
> Add a PHY driver for the USB 2.0 PHYs in the Nuvoton MA35D1 SoC,
> intended for use with the EHCI and OHCI host controllers.
>
> The MA35D1 SoC has two USB ports:
>
> - USB0: an OTG port shared between a DWC2 gadget controller and
> EHCI0/OHCI0 host controllers. A hardware mux automatically routes
> the physical USB0 signals to the appropriate controller based on the
> USB ID pin state. The DWC2 IP is device-only in hardware,
> so host-mode operation on USB0 is handled entirely by EHCI0/OHCI0.
>
> - USB1: a dedicated host-only port served by EHCI1/OHCI1.
>
> The driver implements:
> - Power-On Reset sequence with a guard that skips re-initialization if
> the PHY is already operational. This protects PHY0 when the DWC2
> gadget driver has already run its own init before EHCI0 probes.
> - Optional resistor calibration trim via nuvoton,rcalcode.
> - Optional over-current detect polarity via nuvoton,oc-active-high.
> - For PHY0 only: a USB role switch that exposes the hardware ID pin
> state (PWRONOTP[16]).
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/phy/nuvoton/Kconfig | 15 ++
> drivers/phy/nuvoton/Makefile | 1 +
> drivers/phy/nuvoton/phy-ma35d1-otg.c | 264 +++++++++++++++++++++++++++
> 3 files changed, 280 insertions(+)
> create mode 100644 drivers/phy/nuvoton/phy-ma35d1-otg.c
>
> diff --git a/drivers/phy/nuvoton/Kconfig b/drivers/phy/nuvoton/Kconfig
> index d02cae2db315..5fdd13f841e7 100644
> --- a/drivers/phy/nuvoton/Kconfig
> +++ b/drivers/phy/nuvoton/Kconfig
> @@ -10,3 +10,18 @@ config PHY_MA35_USB
> help
> Enable this to support the USB2.0 PHY on the Nuvoton MA35
> series SoCs.
> +
> +config PHY_MA35_USB_OTG
> + tristate "Nuvoton MA35 USB2.0 OTG PHY driver"
> + depends on ARCH_MA35 || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + select MFD_SYSCON
> + select USB_ROLE_SWITCH
> + help
> + Enable this to support the USB2.0 OTG PHY on the Nuvoton MA35
> + series SoCs. This driver handles PHY initialization for the
> + EHCI/OHCI host controllers, including per-PHY power-on reset,
> + resistor calibration trim, and over-current polarity
> + configuration. For the OTG port (PHY0), it also monitors the
> + USB ID pin and registers a USB role switch.
> diff --git a/drivers/phy/nuvoton/Makefile b/drivers/phy/nuvoton/Makefile
> index 2937e3921898..3ecd76f35d7c 100644
> --- a/drivers/phy/nuvoton/Makefile
> +++ b/drivers/phy/nuvoton/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
>
> obj-$(CONFIG_PHY_MA35_USB) += phy-ma35d1-usb2.o
> +obj-$(CONFIG_PHY_MA35_USB_OTG) += phy-ma35d1-otg.o
Have you considered reusing usb2 driver with a different power_on
function? Or handle the differences internally in the driver. There are
few similarities in two and some things are different
--
~Vinod
^ permalink raw reply
* Re: [PATCH 2/3] remoteproc: abort subdev stop sequence on first failure
From: Mukesh Ojha @ 2026-06-11 10:55 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-msm, linux-remoteproc,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <aiqF5mh1PvWpH3L5@linaro.org>
On Thu, Jun 11, 2026 at 11:54:46AM +0200, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 03:18:51PM +0530, Mukesh Ojha wrote:
> > On Tue, Jun 09, 2026 at 01:43:17PM +0200, Stephan Gerhold wrote:
> > > On Tue, Jun 09, 2026 at 03:52:52PM +0530, Mukesh Ojha wrote:
> > > > If a subdevice fails to stop, it indicates broken communication with the
> > > > DSP. Continuing to stop further subdevices against an unresponsive
> > > > remote processor could close rpmsg devices that could remove the memory
> > > > mapping from HLOS and in case if remote processor touches those memory
> > > > can result in SMMU fault.
> > > >
> > > > Change rproc_stop_subdevices() to return int and abort on the first
> > > > failing subdev. Propagate the error through rproc_stop() and
> > > > __rproc_detach() so callers are aware the teardown did not complete
> > > > cleanly.
> > > >
> > > > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > >
> > > But what would callers do about this? If you abort the teardown sequence
> > > half-way through you now have an inconsistent half-stopped state that
> > > neither a new call to stop() nor a new call to start() could recover
> > > from. That doesn't sound much better than the SMMU fault. Or am I
> > > missing something here?
> >
> > SMMU fault result in device crash while other is non-functional remote
> > processor. From Linux side, we do not know the state of remote processor
> > when the timeout happens..cleaning the subdevices can result in the
> > debug data being lost for hung remote processor.
> >
>
> Ok, but how do we go from here? Do we expect that the system would have
> some userspace monitoring daemon that would collect the debug data and
> then reboot the device to make the remoteproc work again?
I would expect the manually collected crash dump in this state to find
out the exact reason for remoteproc being stuck instead of ignoring it
and claiming a graceful shutdown.
Whatever we do here, the remote may be dysfunctional without a reboot,
but cleaning the rpmsg device will clean all the required debug data, or
at least if possible, tell the rpmsg driver with the rproc state that
shutdown was tried but was not graceful.
>
> With these changes, I don't see how you would start the remoteproc again
> without fully rebooting the board. Calling start()/stop() on the
> subdevices again would lead to crashes because some of them are in
> started state and some of them are in stopped state and we don't even
> know which one is in which state.
>
> Thanks,
> Stephan
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - remove stale comments in atmel_ecc_remove
From: Thorsten Blum @ 2026-06-11 10:55 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <aipH0NgL4Gbe7Oz1@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 01:29:52PM +0800, Herbert Xu wrote:
> On Tue, Jun 02, 2026 at 06:52:49PM +0200, Thorsten Blum wrote:
> > atmel_ecc_remove() no longer returns -EBUSY since commit 7df7563b16aa
> > ("crypto: atmel-ecc - Remove duplicated error reporting in .remove()")
> > and is a void function since commit ed5c2f5fd10d ("i2c: Make remove
> > callback return void").
> >
> > Remove and update the outdated comments.
> >
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > ---
> > drivers/crypto/atmel-ecc.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
> > index 9c380351d2f9..e6068dc0a0c1 100644
> > --- a/drivers/crypto/atmel-ecc.c
> > +++ b/drivers/crypto/atmel-ecc.c
> > @@ -347,13 +347,11 @@ static void atmel_ecc_remove(struct i2c_client *client)
> > {
> > struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
> >
> > - /* Return EBUSY if i2c client already allocated. */
> > if (atomic_read(&i2c_priv->tfm_count)) {
> > /*
> > * After we return here, the memory backing the device is freed.
> > - * That happens no matter what the return value of this function
> > - * is because in the Linux device model there is no error
> > - * handling for unbinding a driver.
> > + * That happens because in the Linux device model there is no
> > + * error handling for unbinding a driver.
> > * If there is still some action pending, it probably involves
> > * accessing the freed memory.
> > */
>
> Please fix this properly rather than fiddling with the comments.
>
> Drivers should always fail gracefully if the hardware disappears.
Yes, I'm working on a fix, but it's not ready yet.
Thanks,
Thorsten
^ permalink raw reply
* [PATCH] crypto: atmel-ecc - drop unused curve id from atmel_ecdh_ctx
From: Thorsten Blum @ 2026-06-11 10:52 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
->curve_id is only set once, but never used - remove it.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9da9dd6585df..93f219558c2f 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -33,7 +33,6 @@ static struct atmel_ecc_driver_data driver_data;
* @public_key : generated when calling set_secret(). It's the responsibility
* of the user to not call set_secret() while
* generate_public_key() or compute_shared_secret() are in flight.
- * @curve_id : elliptic curve id
* @do_fallback: true when the device doesn't support the curve or when the user
* wants to use its own private key.
*/
@@ -41,7 +40,6 @@ struct atmel_ecdh_ctx {
struct i2c_client *client;
struct crypto_kpp *fallback;
const u8 *public_key;
- unsigned int curve_id;
bool do_fallback;
};
@@ -250,7 +248,6 @@ static int atmel_ecdh_init_tfm(struct crypto_kpp *tfm)
struct crypto_kpp *fallback;
struct atmel_ecdh_ctx *ctx = kpp_tfm_ctx(tfm);
- ctx->curve_id = ECC_CURVE_NIST_P256;
ctx->client = atmel_ecc_i2c_client_alloc();
if (IS_ERR(ctx->client)) {
pr_err("tfm - i2c_client binding failed\n");
^ permalink raw reply related
* [PATCH] i2c: stm32f7: truncate clock period instead of rounding it
From: Guillermo Rodríguez @ 2026-06-11 10:48 UTC (permalink / raw)
To: Pierre-Yves MORDRET, Alain Volmat, Andi Shyti, Maxime Coquelin,
Alexandre Torgue, M'boumba Cedric Madianga, Wolfram Sang
Cc: Guillermo Rodríguez, Pierre-Yves MORDRET, linux-i2c,
linux-stm32, linux-arm-kernel, linux-kernel
stm32f7_i2c_compute_timing() derives the I2C clock source period
(i2cclk) with DIV_ROUND_CLOSEST, which may round it up. When the
period is overestimated, all timings computed from it (SCLDEL,
SDADEL, SCLL, SCLH) come out shorter on the wire than calculated,
and the resulting bus rate can exceed the requested speed, violating
the I2C specification minimums for tLOW and tHIGH.
For example, with a 104.45 MHz clock source (e.g. PCLK1, the
reset-default I2C clock source on STM32MP1), i2cclk is rounded from
9.574 ns up to 10 ns. Requesting a 400 kHz fast mode bus with
72/27 ns rise/fall times and no analog/digital filters then produces
an actual bus rate of 415.6 kHz with tLOW = 1254 ns, violating both
the 400 kHz maximum rate and the 1300 ns tLOW minimum of the
specification.
Truncate the period instead, so that it can only be underestimated.
The error then falls on the safe side: the programmed timings come
out slightly longer than computed and the bus runs marginally below
the target rate (375.3 kHz in the example above) while meeting the
specification.
i2cbus is left rounded-to-closest: it is only used as the target of
the clk_error comparison and is never multiplied into the programmed
timings, so nearest rounding remains accurate there.
Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guillermo Rodríguez <guille.rodriguez@gmail.com>
---
drivers/i2c/busses/i2c-stm32f7.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 53d9df70ebe4..6439620d6bed 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -464,8 +464,13 @@ static int stm32f7_i2c_compute_timing(struct stm32f7_i2c_dev *i2c_dev,
{
struct stm32f7_i2c_spec *specs;
u32 p_prev = STM32F7_PRESC_MAX;
- u32 i2cclk = DIV_ROUND_CLOSEST(NSEC_PER_SEC,
- setup->clock_src);
+ /*
+ * Truncate instead of rounding to closest: if the clock period is
+ * overestimated, the computed SCL timings will come out shorter on
+ * the wire, which can push the bus above the target rate and below
+ * the spec's tLOW/tHIGH minimums.
+ */
+ u32 i2cclk = NSEC_PER_SEC / setup->clock_src;
u32 i2cbus = DIV_ROUND_CLOSEST(NSEC_PER_SEC,
setup->speed_freq);
u32 clk_error_prev = i2cbus;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 09/10] iio: dac: add mcf54415 DAC
From: Jonathan Cameron @ 2026-06-11 10:48 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, David Lechner, Nuno Sá,
Andy Shevchenko, Greg Ungerer, linux-m68k, linux-kernel,
linux-stm32, linux-arm-kernel, linux-iio, Michael Turquette,
Stephen Boyd, Brian Masney
In-Reply-To: <20260610-wip-stmark2-dac-v5-9-b76b83366d5c@baylibre.com>
On Wed, 10 Jun 2026 22:35:14 +0200
Angelo Dureghello <adureghello@baylibre.com> wrote:
> From: Angelo Dureghello <adureghello@baylibre.com>
>
> Add basic version of mcf54415 DAC driver. DAC is embedded in the SoC and
> DAC configuration registers are mapped in the internal IO address space.
>
> The DAC accepts a 12-bit digital signal and creates a monotonic 12-bit
> analog output varying from DAC_VREFL to DAC_VREFH. The DAC module
> consists of a conversion unit, an output amplifier, and the associated
> digital control blocks. Default register values for DAC_VREFL and DAC_VREFH
> are respectively 0 and 0xfff, left untouched in this initial version.
>
> This initial version of the driver is minimalistic, "output raw" only, to
> be extended in the future. DMA and external sync are disabled, default mode
> is high speed, default format is right-justified 12-bit on 16-bit word.
>
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
I'm lazy so didn't check earlier versions but assume the two bits
of feedback from Sashiko are false positives:
https://sashiko.dev/#/patchset/20260610-wip-stmark2-dac-v5-0-b76b83366d5c%40baylibre.com
The one about clock underflow if resume fails, and then devm cleanup happens later
is a bit nasty.
I did a bit of digging and maybe it is better to just leave the clock on?
The status dev.power.is_suspended is set to false whether or not resume succeeded
and I believe a following suspend will not take into account that resume failed.
I'm not set up to poke the combinations but it might be worth trying that.
+CC common clk people who may immediately know what the right answer is.
Otherwise just a few minor style comments inline.
Thanks,
Jonathan
> ---
> Changes in v2:
> - remove tests from commit message, moved to patch 0
> - remove additional blank lines
> - remove dead code and unused definitions
> - use regmap
> - add limit check on raw write
> - non functional style fixes
> - add COMPILE_TEST to Kconfig
> Changes in v3:
> - add comments where needed
> - code style changes
> - remove unneeded variables
> - use regmap_set_bits where possible
> - remove macro not needed to define a single channel
> - set up regmap to big_endian accesses for next patches that will come,
> that will adjust ColdFire readx/writex as standard LE (links in 0/x).
> - add return value check on regmap calls
> - sashiko: remove unneeded .io_port from regmap init.
> - sashiko: add select REGMAP_MMIO in Kconfig
> Changes in v4:
> - remove unused includes
> - sashiko: return "ret" as regmap_read ret value in case of error
> - sashiko: using u32 as regmap_read value
> - use local variable in mcf54415_dac_init() for better readability
> - sashiko: check mcf54415_dac_init return value also in resume()
> Changes in v5:
> - commit syntax fixes
> - minor code style fixes
> - use include <linux/type.h>
> - removed unneeded cast
> - disable clock in case of DAC init error
> - use unsigned int for regmap_read and GENMASK for masking 12 bits
> - add id table to match "mcfdac" platform device name
> ---
> drivers/iio/dac/Kconfig | 11 +++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/mcf54415_dac.c | 216 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 228 insertions(+)
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index cd4870b65415..b1a578076188 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -516,6 +516,17 @@ config MAX5821
> Say yes here to build support for Maxim MAX5821
> 10 bits DAC.
>
> +config MCF54415_DAC
> + tristate "NXP MCF54415 DAC driver"
> + depends on M5441x || COMPILE_TEST
> + select REGMAP_MMIO
> + help
> + Say yes here to build support for NXP MCF54415
> + 12bit DAC.
Rewrap this.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called mcf54415_dac.
> +
> diff --git a/drivers/iio/dac/mcf54415_dac.c b/drivers/iio/dac/mcf54415_dac.c
> new file mode 100644
> index 000000000000..f223aa80aabf
> --- /dev/null
> +++ b/drivers/iio/dac/mcf54415_dac.c
> +
> +static int mcf54415_dac_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct iio_dev *indio_dev;
> + struct mcf54415_dac *info;
> + void __iomem *regs;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> +
> + regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(regs))
> + return dev_err_probe(dev, PTR_ERR(regs), "failed to get io regs\n");
> +
> + info->map = devm_regmap_init_mmio(dev, regs, &mcf54415_dac_regmap_config);
> + if (IS_ERR(info->map))
> + return PTR_ERR(info->map);
> +
> + info->clk = devm_clk_get_enabled(dev, "dac");
> + if (IS_ERR(info->clk))
> + return dev_err_probe(dev, PTR_ERR(info->clk), "failed getting clock\n");
> +
> + platform_set_drvdata(pdev, indio_dev);
> +
> + indio_dev->name = "mcf54415";
> + indio_dev->info = &mcf54415_dac_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = &mcf54415_dac_iio_channel;
> + indio_dev->num_channels = 1;
> +
> + ret = mcf54415_dac_init(info);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev, mcf54415_dac_exit, info);
> + if (ret)
> + return ret;
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static int mcf54415_dac_suspend(struct device *dev)
> +{
> + struct mcf54415_dac *info = iio_priv(dev_get_drvdata(dev));
> +
> + mcf54415_dac_exit(info);
> + clk_disable_unprepare(info->clk);
> +
> + return 0;
> +}
> +
> +static int mcf54415_dac_resume(struct device *dev)
> +{
> + struct mcf54415_dac *info = iio_priv(dev_get_drvdata(dev));
> + int ret;
> +
> + ret = clk_prepare_enable(info->clk);
> + if (ret)
> + return ret;
> +
> + ret = mcf54415_dac_init(info);
> + if (ret) {
> + dev_err(dev, "could not resume device\n");
> + clk_disable_unprepare(info->clk);
> + }
> +
> + return ret;
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(mcf54415_dac_pm_ops,
> + mcf54415_dac_suspend, mcf54415_dac_resume);
> +
> +static const struct platform_device_id mcf54415_dac_ids[] = {
> + { .name = "mcfdac", .driver_data = 0 },
Don't set .driver_data if you aren't using it. Given very strong
preference for always using a pointer for that (rather than a numeric
value) this line will change if you ever add support for more devices
anyway, so no value in having that there now.
> + { }, /* sentinel */
{ }
No comma and I don't see value in the sentinel marking given that is
fairly obvious.
> +};
> +
No blank line here. Intent is to keep the macro and the function closely
coupled.
> +MODULE_DEVICE_TABLE(platform, mcf54415_dac_ids);
^ permalink raw reply
* [PATCH net-next] net: airoha: better handle MIBs for GDM ports with multiple devs attached
From: Lorenzo Bianconi @ 2026-06-11 10:43 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, Christian Marangi
In the context of a GDM port that can have multiple net_devices attached
(GDM3 and GDM4), the HW counters (MIBs) are global for the GDM port.
This cause duplicated stats reported to the kernel for the related
net_device.
The SoC supports a split MIB feature where each counter is tracked based
on the relevant HW channel (NBQ) to account for this scenario and
provide a way to select the related counter on accessing the MIB
registers.
Enable this feature for GDM3 and GDM4 and configure the relevant HW
channel before updating the HW stats to report correct HW counter to the
kernel for the related interface.
Move the stats struct from port to dev since HW counter are now specific
to the network device instead of the GDM port. Refactor
airoha_update_hw_stats() to take airoha_eth and airoha_gdm_port
parameters since the function operates on the entire port.
Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 191 +++++++++++++++++--------------
drivers/net/ethernet/airoha/airoha_eth.h | 7 +-
2 files changed, 112 insertions(+), 86 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..7676ec9b3129 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -556,6 +556,14 @@ static int airoha_fe_init(struct airoha_eth *eth)
airoha_fe_set(eth, REG_GDM_FWD_CFG(AIROHA_GDM3_IDX), GDM_PAD_EN_MASK);
airoha_fe_set(eth, REG_GDM_FWD_CFG(AIROHA_GDM4_IDX), GDM_PAD_EN_MASK);
+ /* Enable split for MIB counters for GDM3 and GDM4 */
+ airoha_fe_set(eth, REG_FE_GDM_MIB_CFG(AIROHA_GDM3_IDX),
+ FE_GDM_TX_MIB_SPLIT_EN_MASK |
+ FE_GDM_RX_MIB_SPLIT_EN_MASK);
+ airoha_fe_set(eth, REG_FE_GDM_MIB_CFG(AIROHA_GDM4_IDX),
+ FE_GDM_TX_MIB_SPLIT_EN_MASK |
+ FE_GDM_RX_MIB_SPLIT_EN_MASK);
+
airoha_fe_crsn_qsel_init(eth);
airoha_fe_clear(eth, REG_FE_CPORT_CFG, FE_CPORT_QUEUE_XFC_MASK);
@@ -1626,149 +1634,169 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
}
}
-static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
+static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
{
struct airoha_gdm_port *port = dev->port;
struct airoha_eth *eth = dev->eth;
u32 val, i = 0;
- spin_lock(&port->stats.lock);
- u64_stats_update_begin(&port->stats.syncp);
+ /* Read relevant MIB for GDM with multiple port attached */
+ if (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)
+ airoha_fe_rmw(eth, REG_FE_GDM_MIB_CFG(port->id),
+ FE_TX_MIB_ID_MASK | FE_RX_MIB_ID_MASK,
+ FIELD_PREP(FE_TX_MIB_ID_MASK, dev->nbq) |
+ FIELD_PREP(FE_RX_MIB_ID_MASK, dev->nbq));
+
+ u64_stats_update_begin(&dev->stats.syncp);
/* TX */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
- port->stats.tx_ok_pkts += ((u64)val << 32);
+ dev->stats.tx_ok_pkts += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
- port->stats.tx_ok_pkts += val;
+ dev->stats.tx_ok_pkts += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
- port->stats.tx_ok_bytes += ((u64)val << 32);
+ dev->stats.tx_ok_bytes += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
- port->stats.tx_ok_bytes += val;
+ dev->stats.tx_ok_bytes += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
- port->stats.tx_drops += val;
+ dev->stats.tx_drops += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
- port->stats.tx_broadcast += val;
+ dev->stats.tx_broadcast += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
- port->stats.tx_multicast += val;
+ dev->stats.tx_multicast += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
- port->stats.tx_len[i] += val;
+ dev->stats.tx_len[i] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
- port->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_H(port->id));
- port->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_H(port->id));
- port->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_H(port->id));
- port->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_H(port->id));
- port->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_H(port->id));
- port->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_LONG_CNT(port->id));
- port->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += val;
/* RX */
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_H(port->id));
- port->stats.rx_ok_pkts += ((u64)val << 32);
+ dev->stats.rx_ok_pkts += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
- port->stats.rx_ok_pkts += val;
+ dev->stats.rx_ok_pkts += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_H(port->id));
- port->stats.rx_ok_bytes += ((u64)val << 32);
+ dev->stats.rx_ok_bytes += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
- port->stats.rx_ok_bytes += val;
+ dev->stats.rx_ok_bytes += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_DROP_CNT(port->id));
- port->stats.rx_drops += val;
+ dev->stats.rx_drops += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_BC_CNT(port->id));
- port->stats.rx_broadcast += val;
+ dev->stats.rx_broadcast += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_MC_CNT(port->id));
- port->stats.rx_multicast += val;
+ dev->stats.rx_multicast += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ERROR_DROP_CNT(port->id));
- port->stats.rx_errors += val;
+ dev->stats.rx_errors += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_CRC_ERR_CNT(port->id));
- port->stats.rx_crc_error += val;
+ dev->stats.rx_crc_error += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OVERFLOW_DROP_CNT(port->id));
- port->stats.rx_over_errors += val;
+ dev->stats.rx_over_errors += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_FRAG_CNT(port->id));
- port->stats.rx_fragment += val;
+ dev->stats.rx_fragment += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_JABBER_CNT(port->id));
- port->stats.rx_jabber += val;
+ dev->stats.rx_jabber += val;
i = 0;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
- port->stats.rx_len[i] += val;
+ dev->stats.rx_len[i] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
- port->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_H(port->id));
- port->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_H(port->id));
- port->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_H(port->id));
- port->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_H(port->id));
- port->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_H(port->id));
- port->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += ((u64)val << 32);
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_LONG_CNT(port->id));
- port->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i++] += val;
+
+ u64_stats_update_end(&dev->stats.syncp);
+}
- /* reset mib counters */
- airoha_fe_set(eth, REG_FE_GDM_MIB_CLEAR(port->id),
+static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
+{
+ struct airoha_gdm_port *port = dev->port;
+ int i;
+
+ spin_lock(&port->stats_lock);
+
+ for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
+ if (port->devs[i])
+ 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);
- u64_stats_update_end(&port->stats.syncp);
- spin_unlock(&port->stats.lock);
+ spin_unlock(&port->stats_lock);
}
static int airoha_dev_open(struct net_device *netdev)
@@ -2043,23 +2071,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
struct rtnl_link_stats64 *storage)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_gdm_port *port = dev->port;
unsigned int start;
airoha_update_hw_stats(dev);
do {
- start = u64_stats_fetch_begin(&port->stats.syncp);
- storage->rx_packets = port->stats.rx_ok_pkts;
- storage->tx_packets = port->stats.tx_ok_pkts;
- storage->rx_bytes = port->stats.rx_ok_bytes;
- storage->tx_bytes = port->stats.tx_ok_bytes;
- storage->multicast = port->stats.rx_multicast;
- storage->rx_errors = port->stats.rx_errors;
- storage->rx_dropped = port->stats.rx_drops;
- storage->tx_dropped = port->stats.tx_drops;
- storage->rx_crc_errors = port->stats.rx_crc_error;
- storage->rx_over_errors = port->stats.rx_over_errors;
- } while (u64_stats_fetch_retry(&port->stats.syncp, start));
+ start = u64_stats_fetch_begin(&dev->stats.syncp);
+ storage->rx_packets = dev->stats.rx_ok_pkts;
+ storage->tx_packets = dev->stats.tx_ok_pkts;
+ storage->rx_bytes = dev->stats.rx_ok_bytes;
+ storage->tx_bytes = dev->stats.tx_ok_bytes;
+ storage->multicast = dev->stats.rx_multicast;
+ storage->rx_errors = dev->stats.rx_errors;
+ storage->rx_dropped = dev->stats.rx_drops;
+ storage->tx_dropped = dev->stats.tx_drops;
+ storage->rx_crc_errors = dev->stats.rx_crc_error;
+ storage->rx_over_errors = dev->stats.rx_over_errors;
+ } while (u64_stats_fetch_retry(&dev->stats.syncp, start));
}
static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
@@ -2310,20 +2337,19 @@ static void airoha_ethtool_get_mac_stats(struct net_device *netdev,
struct ethtool_eth_mac_stats *stats)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_gdm_port *port = dev->port;
unsigned int start;
airoha_update_hw_stats(dev);
do {
- start = u64_stats_fetch_begin(&port->stats.syncp);
- stats->FramesTransmittedOK = port->stats.tx_ok_pkts;
- stats->OctetsTransmittedOK = port->stats.tx_ok_bytes;
- stats->MulticastFramesXmittedOK = port->stats.tx_multicast;
- stats->BroadcastFramesXmittedOK = port->stats.tx_broadcast;
- stats->FramesReceivedOK = port->stats.rx_ok_pkts;
- stats->OctetsReceivedOK = port->stats.rx_ok_bytes;
- stats->BroadcastFramesReceivedOK = port->stats.rx_broadcast;
- } while (u64_stats_fetch_retry(&port->stats.syncp, start));
+ start = u64_stats_fetch_begin(&dev->stats.syncp);
+ stats->FramesTransmittedOK = dev->stats.tx_ok_pkts;
+ stats->OctetsTransmittedOK = dev->stats.tx_ok_bytes;
+ stats->MulticastFramesXmittedOK = dev->stats.tx_multicast;
+ stats->BroadcastFramesXmittedOK = dev->stats.tx_broadcast;
+ stats->FramesReceivedOK = dev->stats.rx_ok_pkts;
+ stats->OctetsReceivedOK = dev->stats.rx_ok_bytes;
+ stats->BroadcastFramesReceivedOK = dev->stats.rx_broadcast;
+ } while (u64_stats_fetch_retry(&dev->stats.syncp, start));
}
static const struct ethtool_rmon_hist_range airoha_ethtool_rmon_ranges[] = {
@@ -2343,8 +2369,7 @@ airoha_ethtool_get_rmon_stats(struct net_device *netdev,
const struct ethtool_rmon_hist_range **ranges)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_gdm_port *port = dev->port;
- struct airoha_hw_stats *hw_stats = &port->stats;
+ struct airoha_hw_stats *hw_stats = &dev->stats;
unsigned int start;
BUILD_BUG_ON(ARRAY_SIZE(airoha_ethtool_rmon_ranges) !=
@@ -2357,7 +2382,7 @@ airoha_ethtool_get_rmon_stats(struct net_device *netdev,
do {
int i;
- start = u64_stats_fetch_begin(&port->stats.syncp);
+ start = u64_stats_fetch_begin(&dev->stats.syncp);
stats->fragments = hw_stats->rx_fragment;
stats->jabbers = hw_stats->rx_jabber;
for (i = 0; i < ARRAY_SIZE(airoha_ethtool_rmon_ranges) - 1;
@@ -2365,7 +2390,7 @@ airoha_ethtool_get_rmon_stats(struct net_device *netdev,
stats->hist[i] = hw_stats->rx_len[i];
stats->hist_tx[i] = hw_stats->tx_len[i];
}
- } while (u64_stats_fetch_retry(&port->stats.syncp, start));
+ } while (u64_stats_fetch_retry(&dev->stats.syncp, start));
}
static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
@@ -3205,6 +3230,7 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
netdev->dev.of_node = of_node_get(np);
dev = netdev_priv(netdev);
+ u64_stats_init(&dev->stats.syncp);
dev->port = port;
dev->eth = eth;
dev->nbq = nbq;
@@ -3244,9 +3270,8 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
if (!port)
return -ENOMEM;
- u64_stats_init(&port->stats.syncp);
- spin_lock_init(&port->stats.lock);
port->id = id;
+ spin_lock_init(&port->stats_lock);
eth->ports[p] = port;
err = airoha_metadata_dst_alloc(port);
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 8f42973f9cf5..46b1c31939de 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -215,8 +215,6 @@ struct airoha_tx_irq_queue {
};
struct airoha_hw_stats {
- /* protect concurrent hw_stats accesses */
- spinlock_t lock;
struct u64_stats_sync syncp;
/* get_stats64 */
@@ -554,6 +552,8 @@ struct airoha_gdm_dev {
u32 flags;
int nbq;
+
+ struct airoha_hw_stats stats;
};
struct airoha_gdm_port {
@@ -561,7 +561,8 @@ struct airoha_gdm_port {
int id;
int users;
- struct airoha_hw_stats stats;
+ /* protect concurrent hw_stats accesses */
+ spinlock_t stats_lock;
struct metadata_dst *dsa_meta[AIROHA_MAX_DSA_PORTS];
};
---
base-commit: c8459ee2fef502d6ef6c063751c33d9ac7943eab
change-id: 20260611-airoha-eth-multi-serdes-stats-df2dc16c2dd6
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH v2] crypto: atmel-tdes - use scatterlist length before DMA mapping
From: Thorsten Blum @ 2026-06-11 10:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Nicolas Royer, Eric Bénard
Cc: Thorsten Blum, stable, linux-crypto, linux-arm-kernel,
linux-kernel
Using sg_dma_len() is only valid after mapping the scatterlist with
dma_map_sg(). However, atmel_tdes_crypt_start() uses it before mapping
to compare input/output lengths and to compute the transfer count.
Use the original scatterlist lengths before DMA mapping to avoid reading
stale or uninitialized DMA lengths when CONFIG_NEED_SG_DMA_LENGTH=y.
Drop the output scatterlist length in the fast path since it is equal to
->in_sg->length and does not change the transfer count.
Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver")
Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Drop ->out_sg->length in the fast path (Herbert)
- v1: https://lore.kernel.org/lkml/20260531204115.689052-3-thorsten.blum@linux.dev/
---
drivers/crypto/atmel-tdes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index 643e507f9c02..d380f6741a2c 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers/crypto/atmel-tdes.c
@@ -463,14 +463,13 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd)
IS_ALIGNED(dd->out_sg->length, dd->ctx->block_size);
fast = in && out;
- if (sg_dma_len(dd->in_sg) != sg_dma_len(dd->out_sg))
+ if (dd->in_sg->length != dd->out_sg->length)
fast = 0;
}
if (fast) {
- count = min_t(size_t, dd->total, sg_dma_len(dd->in_sg));
- count = min_t(size_t, count, sg_dma_len(dd->out_sg));
+ count = min_t(size_t, dd->total, dd->in_sg->length);
err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
if (!err) {
^ permalink raw reply related
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Lance Yang @ 2026-06-11 10:35 UTC (permalink / raw)
To: rppt
Cc: lance.yang, dave.hansen, xueyuan.chen21, akpm, linux-mm,
linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, surenb, mhocko, ziy, baolin.wang, npache, ryan.roberts,
dev.jain, baohua, yang, jannh
In-Reply-To: <aipacpSZrO1DKooO@kernel.org>
On Thu, Jun 11, 2026 at 09:49:22AM +0300, Mike Rapoport wrote:
>Hi,
Hi,
>
>On Wed, Jun 10, 2026 at 11:20:22AM +0800, Lance Yang wrote:
>> Hi Dave,
>>
>> Thanks for taking the time to review.
>>
>> On Tue, Jun 09, 2026 at 12:33:36PM -0700, Dave Hansen wrote:
>> >On 6/9/26 07:37, Xueyuan Chen wrote:
>> >> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
>> >> +{
>> >> + return false;
>> >> +}
>> >
>> >This is a rather wonky function. It's going to cause all kinds of fun if
>> >it is used like this:
>> >
>> > arch_make_pages_readonly(syscall_table, 1);
>>
>> Ouch, yeah, it is ...
>
>We already have set_direct_map* APIs, why don't you add a new one there?
>set_direct_map_ro() for example.
Good point. I was trying to make this generic, but that's a bit too cute.
This is really a direct-map thing, so adding a set_direct_map_ro() helper
there makes more sense.
>
>> >It's also kinda weird to have it return a bool, and not check that bool
>> >at the single call site. Some things come to mind:
>> >
>> >1. This function needs commenting. It needs to say what it does, when
>> > architectures should override it and what their implementations
>> > should look like. It needs to be clear that this can't be used for
>> > anything really important. What should architectures do with alias
>> > mappings? Are they allowed to touch non-direct map aliases? Are they
>> > required to?
>>
>> Agreed. Needs a real comment ...
>>
>> Just meant as a best-effort direct/linear-map permission chang, nothing
>> stronger than that. I should spell out what happens, or does not happen,
>> to non-direct-map aliases, if anything, and make clear callers cannot
>> treat this as a hard guarantee :D
>
>It's not only about highmem, anything that changes the direct map might
>fail to allocate memory when splitting larger mappings.
Yes, exactly.
>
>> >2. The return type needs to be reconsidered. Is 'bool' even acceptable?
>> > Should it just be 'void' if callers can't do anything when it fails?
>>
>> Maybe ignoring it is OK now, but someone may need the return value later?
>>
>> >3. What should the naming be? "readonly" vs "ro". Should it have a
>> > "maybe" since it's kinda optional?
>>
>> Fair point. "make" may be overstating it a bit ...
>>
>> With a return value, arch_try_make_pages_readonly() sounds about right
>> to me. If we end up with void and pure best-effort semantics, maybe
>> arch_maybe_make_pages_readonly() fits better :)
>
>Realistically, I wouldn't expect 32-bit configs to enable
>PERSISTENT_HUGE_ZERO_FOLIO or even THP, so naming this function to reflect
>32-bit behaviour seems odd going forward.
Cool with that, if no one objects. No need to bake that into the name I
guess. int return plus a comment should be enough, just like
set_direct_map_*() family already does :)
>> >4. Should this new API be folio or page-based in the first place?
>>
>> For page vs folio, I was mostly following David's RFC v1 suggestion.
>>
>> Current caller is a folio, sure, but the page-range helper leaves room
>> for non-folio users later. Happy to add a simple folio wrapper if that
>> reads better ;)
>>
>> >5. Is mm/huge_memory.c the right place to define a generic mm function,
>> > even a stub?
>>
>> Ah, you're right! My bad, wrong place for a generic stub. Will move it
>> out for RFC v3.
>
>We have include/linux/set_memory.h for such function declarations and their
>stubs.
Yep, will move it there :)
Thanks, Lance
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding
From: Fredrik Markstrom @ 2026-06-11 10:32 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Santosh Shilimkar, Olof Johansson, Tony Lindgren,
linux-arm-kernel, linux-kernel, linux-kselftest, linux-perf-users,
Nicolas Pitre, Ivar Holmqvist, Malin Jonsson
In-Reply-To: <agweYAbxRWOs41BE@elx-5cg6022w5t>
Hello, is there anything I can do at this point to address this issue ?
/Fredrik
On Tue, May 19, 2026 at 10:25:04AM +0200, Fredrik Markstrom wrote:
> On Mon, May 18, 2026 at 04:06:11PM +0100, Will Deacon wrote:
> > On Thu, Apr 30, 2026 at 12:55:12PM +0200, Fredrik Markstrom wrote:
> > > Perf callchain unwinding follows userspace frame pointers via
> > > copy_from_user. A corrupted or malicious frame pointer can point
> > > into device I/O memory mapped into the process (e.g. via UIO or
> > > /dev/mem), causing the kernel to read from MMIO regions in PMU
> > > interrupt context. Such reads can have side effects on hardware
> > > (clearing status registers, advancing FIFOs, triggering DMA) and
> > > on arm64 can produce a synchronous external abort that panics the
> > > kernel.
> >
> > Hmm, but why is unwinding special in this case? If userspace has access
> > to sensitive MMIO/device mappings, it can presumably pass them to
> > syscalls and trigger crashes all over the place?
>
> You’re totally right, a broken app with access to hardware like this can
> already cause chaos by passing bad pointers to syscalls etc. But the big
> difference here is who is to blame when things crash.
>
> If an app passes a bad pointer to a syscall, it’s self-inflicted.
>
> Unwinding here is asynchronous and unrelated to the application.
> Perf interrupts a perfectly healthy app at a random moment. If that app
> is using the frame pointer as a normal register (totally legal in
> optimized code), it might hold a junk value that points to MMIO memory.
>
> If the kernel blindly follows that junk pointer during an unwind, perf
> causes the crash. I think it's acceptable that an app (with hardware
> access) causes a crash if buggy, but I don't think it's acceptable that
> a profiling tool is causing a crash just by looking at it.
>
> Fredrik
>
>
> >
> > Will
^ 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