From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Huacai Chen <chenhuacai@kernel.org>, Andrew Lunn <andrew@lunn.ch>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 0/3] net: stmmac: Fix usage of maximum queue number macros
Date: Tue, 28 Jan 2025 11:42:19 +0900 [thread overview]
Message-ID: <336580ad-e8f6-436a-bf62-adcd348c553b@socionext.com> (raw)
In-Reply-To: <CAAhV-H73FNTzhjwkZwO4RAZFF1Ri6EzpJL3jnWW4rPRFZQRZZA@mail.gmail.com>
Hi Huacai, Andrew,
On 2025/01/27 22:47, Huacai Chen wrote:
> Hi, Andrew,
>
> On Mon, Jan 27, 2025 at 9:21 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>> I'm not very familiar with the difference between net and net-next,
>>> but I think this series should be backported to stable branches.
>>
>> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> According to the rules a "bug" should break build or break runtime or
> a security issue, but shouldn't be spelling fixes.
>
> But from my point of view, this series is not just "spelling fixes",
> and not "trivial fixes without benefit for users". It is obviously a
> copy-paste error and may confuse developers, so I think the patches
> really have "benefits".
>
>>
>>
>> It must either fix a real bug that bothers people or just add a
>> device ID.
>>
>> Does this really bother people? Have we seen bug reports?
> No bug report is because MTL_MAX_RX_QUEUES is accidentally equal to
> MTL_MAX_TX_QUEUES and it just works, not because the logic is correct.
> And Kunihiko's patch can also be treated as a report.
>
>>
>> There is another aspect to this. We are adding warnings saying that
>> the device tree blob is broken. That should encourage users to upgrade
>> their device tree blob. But most won't find any newer version. If this
>> goes into net-next, the roll out will be a lot slower, developers on
>> the leading edge will find the DT issue and submit a DT patch. By the
>> time this is in a distro kernel, maybe most of the DT issues will
>> already be fixed?
> Goto net or goto net-next are both fine to me, I just think this
> series should be backported to stable branches. There are lots of
> patches backported even though they are less important than this
> series (maybe not in the network subsystem).
Currently both macros define the same value and there is no critical
break for previous kernels.
When different values are defined for these macros, this can cause
problems, however, I don't think that these different values are
adopted (backported) in the current stable kernels.
So I think it's reasonable to repost this series to net-next.
Thank you,
---
Best Regards
Kunihiko Hayashi
next prev parent reply other threads:[~2025-01-28 2:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 9:24 Kunihiko Hayashi
2025-01-27 9:24 ` [PATCH net 1/3] net: stmmac: Fix use of queue max macros for Rx interrupt name Kunihiko Hayashi
2025-01-27 9:24 ` [PATCH net 2/3] net: stmmac: Fix use of queue max macros for Rx coalesce Kunihiko Hayashi
2025-01-27 9:24 ` [PATCH net 3/3] net: stmmac: Fix use of queue max macros for irq statistics Kunihiko Hayashi
2025-01-27 9:51 ` [PATCH net 0/3] net: stmmac: Fix usage of maximum queue number macros Russell King (Oracle)
2025-01-27 11:11 ` Huacai Chen
2025-01-27 13:21 ` Andrew Lunn
2025-01-27 13:47 ` Huacai Chen
2025-01-27 21:03 ` Jakub Kicinski
2025-01-28 2:42 ` Kunihiko Hayashi [this message]
2025-01-28 2:41 ` Kunihiko Hayashi
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=336580ad-e8f6-436a-bf62-adcd348c553b@socionext.com \
--to=hayashi.kunihiko@socionext.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=chenhuacai@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®