From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Paolo Abeni <pabeni@redhat.com>, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, thomas.petazzoni@bootlin.com,
"Andrew Lunn" <andrew@lunn.ch>,
"Jakub Kicinski" <kuba@kernel.org>,
"Eric Dumazet" <edumazet@google.com>,
"Russell King" <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Herve Codina" <herve.codina@bootlin.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Vladimir Oltean" <vladimir.oltean@nxp.com>,
"Köry Maincent" <kory.maincent@bootlin.com>,
"Marek Behún" <kabel@kernel.org>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Nicolò Veronese" <nicveronese@gmail.com>,
"Simon Horman" <horms@kernel.org>,
mwojtas@chromium.org, "Antoine Tenart" <atenart@kernel.org>,
devicetree@vger.kernel.org, "Conor Dooley" <conor+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Romain Gantois" <romain.gantois@bootlin.com>,
"Daniel Golle" <daniel@makrotopia.org>,
"Dimitri Fedrau" <dimitri.fedrau@liebherr.com>,
"Tariq Toukan" <tariqt@nvidia.com>
Subject: Re: [PATCH net-next v21 02/14] net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values
Date: Tue, 2 Dec 2025 16:48:39 +0100 [thread overview]
Message-ID: <49709595-5012-4fa3-9616-839dcdbf6b09@bootlin.com> (raw)
In-Reply-To: <298e982d-7796-4e46-ad1d-a7f57c573f35@redhat.com>
Hi Paolo
On 02/12/2025 14:03, Paolo Abeni wrote:
> On 11/29/25 9:22 AM, Maxime Chevallier wrote:
>> @@ -298,138 +321,149 @@ static_assert(ARRAY_SIZE(link_mode_names) == __ETHTOOL_LINK_MODE_MASK_NBITS);
>> .speed = SPEED_UNKNOWN, \
>> .lanes = 0, \
>> .duplex = DUPLEX_UNKNOWN, \
>> + .mediums = BIT(ETHTOOL_LINK_MEDIUM_NONE), \
>> }
>>
>> const struct link_mode_info link_mode_params[] = {
>> - __DEFINE_LINK_MODE_PARAMS(10, T, Half),
>> - __DEFINE_LINK_MODE_PARAMS(10, T, Full),
>> - __DEFINE_LINK_MODE_PARAMS(100, T, Half),
>> - __DEFINE_LINK_MODE_PARAMS(100, T, Full),
>> - __DEFINE_LINK_MODE_PARAMS(1000, T, Half),
>> - __DEFINE_LINK_MODE_PARAMS(1000, T, Full),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(10, T, 2, 4, Half, T),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(10, T, 2, 4, Full, T),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(100, T, 2, 4, Half, T),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(100, T, 2, 4, Full, T),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(1000, T, 4, 4, Half, T),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(1000, T, 4, 4, Full, T),
>> __DEFINE_SPECIAL_MODE_PARAMS(Autoneg),
>> __DEFINE_SPECIAL_MODE_PARAMS(TP),
>> __DEFINE_SPECIAL_MODE_PARAMS(AUI),
>> __DEFINE_SPECIAL_MODE_PARAMS(MII),
>> __DEFINE_SPECIAL_MODE_PARAMS(FIBRE),
>> __DEFINE_SPECIAL_MODE_PARAMS(BNC),
>> - __DEFINE_LINK_MODE_PARAMS(10000, T, Full),
>> + __DEFINE_LINK_MODE_PARAMS_PAIRS(10000, T, 4, 4, Full, T),
>> __DEFINE_SPECIAL_MODE_PARAMS(Pause),
>> __DEFINE_SPECIAL_MODE_PARAMS(Asym_Pause),
>> - __DEFINE_LINK_MODE_PARAMS(2500, X, Full),
>> + __DEFINE_LINK_MODE_PARAMS_MEDIUMS(2500, X, Full,
>> + __MED(C) | __MED(S) | __MED(L)),
>> __DEFINE_SPECIAL_MODE_PARAMS(Backplane),
>> - __DEFINE_LINK_MODE_PARAMS(1000, KX, Full),
>> - __DEFINE_LINK_MODE_PARAMS(10000, KX4, Full),
>> - __DEFINE_LINK_MODE_PARAMS(10000, KR, Full),
>> + __DEFINE_LINK_MODE_PARAMS(1000, KX, Full, K),
>> + __DEFINE_LINK_MODE_PARAMS(10000, KX4, Full, K),
>> + __DEFINE_LINK_MODE_PARAMS(10000, KR, Full, K),
>> [ETHTOOL_LINK_MODE_10000baseR_FEC_BIT] = {
>> .speed = SPEED_10000,
>> .lanes = 1,
>> .duplex = DUPLEX_FULL,
>
> The AI review points that medium is not initialized here:
>
> https://netdev-ai.bots.linux.dev/ai-review.html?id=437cd013-c6a6-49e1-bec1-de4869930c7a#patch-1
>
> Is that intentional? It should deserve at least an explanation in the
> commit message.
Yes it is OK, however I don't really know how to answer AI on that. I'm
sorry it's still a bit blurry to me what's the right way to proceed with
these reviews.
Should I paste the AI report, then reply to it ?
I'd rather add more comments to the code than say in my commit log "AI
says xxx, it's wrong because blabla" though.
>
> Somewhat related, AI raised on the first patch the same question raised
> on a previous iteration, and I assumed you considered that valid,
> according to:
>
> https://lore.kernel.org/netdev/f753719e-2370-401d-a001-821bdd5ee838@bootlin.com/
So I don't know either how to proceed with this. dt_binding_check is
fine with the current state, and Rob acked the patch. I am not sure how
it's going to be received if I reach out to DT maintainers saying "the
netdev LLM said XXX, is this correct or hallucination ?", but it may
very well have a good point. I did try to dive into the yaml and then
json schema specs, but I wasn't able to go far enough to reach a proper
conclusion on wether we must remove "contains" for scalar :(
All of that would be a bit clearer if the AI review was on the ML, but I
also understand the risk for pollution with that, especially at an early
stage of adoption.
>
> Otherwise I think some wording in the commit message explaining why the
> AI feedback is incorrect would be useful.
>
> /P
>
I'll update the commits and add comments anyways. I guess in a month
though, with net-next closed then the end of year.
Thanks,
Maxime
next prev parent reply other threads:[~2025-12-02 15:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-29 8:22 [PATCH net-next v21 00/14] net: phy: Introduce PHY ports representation Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 01/14] dt-bindings: net: Introduce the ethernet-connector description Maxime Chevallier
2025-11-29 9:21 ` Rob Herring (Arm)
2025-11-29 11:40 ` Christophe Leroy (CS GROUP)
2025-12-04 18:35 ` Rob Herring
2025-11-29 8:22 ` [PATCH net-next v21 02/14] net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values Maxime Chevallier
2025-12-02 13:03 ` Paolo Abeni
2025-12-02 15:48 ` Maxime Chevallier [this message]
2025-11-29 8:22 ` [PATCH net-next v21 03/14] net: phy: Introduce PHY ports representation Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 04/14] net: phy: dp83822: Add support for phy_port representation Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 05/14] dt-bindings: net: dp83822: Deprecate ti,fiber-mode Maxime Chevallier
2025-11-29 9:21 ` Rob Herring (Arm)
2025-11-29 11:42 ` Christophe Leroy (CS GROUP)
2025-11-29 8:22 ` [PATCH net-next v21 06/14] net: phy: Create a phy_port for PHY-driven SFPs Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 07/14] net: phy: Introduce generic SFP handling for PHY drivers Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 08/14] net: phy: marvell-88x2222: Support SFP through phy_port interface Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 09/14] net: phy: marvell: " Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 10/14] net: phy: marvell10g: Support SFP through phy_port Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 11/14] net: phy: at803x: Support SFP through phy_port interface Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 12/14] net: phy: qca807x: " Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 13/14] net: phy: Only rely on phy_port for PHY-driven SFP Maxime Chevallier
2025-11-29 8:22 ` [PATCH net-next v21 14/14] Documentation: networking: Document the phy_port infrastructure Maxime Chevallier
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=49709595-5012-4fa3-9616-839dcdbf6b09@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=andrew@lunn.ch \
--cc=atenart@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=conor+dt@kernel.org \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dimitri.fedrau@liebherr.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=herve.codina@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=kabel@kernel.org \
--cc=kory.maincent@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mwojtas@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=nicveronese@gmail.com \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=romain.gantois@bootlin.com \
--cc=tariqt@nvidia.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.oltean@nxp.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®