From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Alex Elder <elder@riscstar.com>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sashiko <sashiko-bot@kernel.org>
Subject: Re: [PATCH] net: stmmac: use dma_addr_t for DMA addresses
Date: Wed, 12 Aug 2026 14:33:34 +0200 [thread overview]
Message-ID: <a15dda96-9a91-4055-b394-618ebd99b4df@bootlin.com> (raw)
In-Reply-To: <72848f5d-768a-4d06-82d1-1168cae8c5b6@riscstar.com>
Hi,
On 8/12/26 14:25, Alex Elder wrote:
> On 8/12/26 2:23 AM, Maxime Chevallier wrote:
>> Hi Alex,
>>
>> On 8/11/26 21:27, Alex Elder wrote:
>>> In jumbo_frm() (implemented in both "chain_mode.c" and "ring_mode.c"),
>>> an unsigned integer local variable is used to hold the value returned
>>> by dma_map_single(). On systems where a dma_addr_t is 64 bits, the
>>> subsequent dma_mapping_error() check of the returned value operates
>>> only on the low 32 bits (whose high bit won't be sign-extended). In
>>> this case, dma_mapping_error() would return 0 (no error) even if there
>>> were one.
>>>
>>> Fix this in both spots by using a dma_addr_t for the local variable.
>>
>> Thanks :)
>>
>> I was wondering if it would silently hides another address size related
>> issue a little bit lower, as we now have :
>>
>> dma_addr_t des2;
>>
>> des2 = dma_map_single(...);
>>
>> desc->des2 = cpu_to_le32(des2);
>>
>> desc->des2 is __le32, so for 64 bit addresses we silently truncate the
>> address.
>
> I saw that too. Everything is unsigned, and only the lower
> 32 bits will be used, but I'd rather see the dma_addr_t
> explicitly converted to u32 before being passed to cpu_to_le32().
> This should work regardless of the size of dma_addr_t:
>
> desc->des2 = cpu_to_le32(lower_32_bits(des2));
Fine by me, if you add that in V2 feel free to keep my review tag :)
Maxime
>
> I didn't look, but there could be other places where this occurs.
> Tell me if you'd like me to send another patch that does this
> (here and in any other spots I find.)
>> However I don't see how jumbo would work on 64-bits anyways as des3 is the next
>> chunk of the jumbo frame...
>>
>> I think this is good as-is, so
>>
>> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>
> Thank you.
>
> -Alex
>
>> Maxime
>>
>>>
>>> Reported-by: Sashiko <sashiko-bot@kernel.org>
>>> Link: https://lore.kernel.org/linux-devicetree/20260606010122.21A211F00899@smtp.kernel.org/
>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>> ---
>>> drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 3 ++-
>>> drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 3 ++-
>>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
>>> index fc04a23342cfc..ec25193d287bb 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
>>> @@ -20,9 +20,10 @@ static int jumbo_frm(struct stmmac_tx_queue *tx_q, struct sk_buff *skb,
>>> unsigned int nopaged_len = skb_headlen(skb);
>>> struct stmmac_priv *priv = tx_q->priv_data;
>>> unsigned int entry = tx_q->cur_tx;
>>> - unsigned int bmax, buf_len, des2;
>>> + unsigned int bmax, buf_len;
>>> unsigned int i = 1, len;
>>> struct dma_desc *desc;
>>> + dma_addr_t des2;
>>> desc = tx_q->dma_tx + entry;
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
>>> index 78fc6aa5bbe95..664d8cfb58cdc 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
>>> @@ -20,8 +20,9 @@ static int jumbo_frm(struct stmmac_tx_queue *tx_q, struct sk_buff *skb,
>>> unsigned int nopaged_len = skb_headlen(skb);
>>> struct stmmac_priv *priv = tx_q->priv_data;
>>> unsigned int entry = tx_q->cur_tx;
>>> - unsigned int bmax, len, des2;
>>> + unsigned int bmax, len;
>>> struct dma_desc *desc;
>>> + dma_addr_t des2;
>>> if (priv->extend_desc)
>>> desc = (struct dma_desc *)(tx_q->dma_etx + entry);
>>>
>>> base-commit: 31397cf1819210bd63fa3d2c7d8c24f7c8667d99
>>
>
prev parent reply other threads:[~2026-08-12 12:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 19:27 [PATCH] net: stmmac: use dma_addr_t for DMA addresses Alex Elder
2026-08-12 7:23 ` Maxime Chevallier
2026-08-12 12:25 ` Alex Elder
2026-08-12 12:33 ` Maxime Chevallier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a15dda96-9a91-4055-b394-618ebd99b4df@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=elder@riscstar.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sashiko-bot@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.