DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Malov <ivan.malov@arknetworks.am>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, Andy Moreton <andy.moreton@amd.com>,
	 Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am>,
	 Roman Zhukov <Roman.Zhukov@arknetworks.am>,
	 Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>,
	 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	stable@dpdk.org
Subject: Re: [PATCH v2 3/3] common/sfc_efx/base: fix reading advertised autoneg ability
Date: Thu, 13 Aug 2026 08:10:34 +0400 (+04)	[thread overview]
Message-ID: <fdfecacc-d2cc-8f91-59db-d18ba9af548d@arknetworks.am> (raw)
In-Reply-To: <20260812194414.55bf706e@phoenix.local>

Dear Stephen,

If I may, I should like to address the following:

- Backport conflict and 'Depends-on:':
   The stable team operates independently of the upstream review process; should the patch not apply cleanly, the stable maintainers will contact me directly (a well-established practice) and I am entirely willing to provide all the assistance at the appropriate juncture. In other words, the 'Cc: stable@dpdk.org' signals that a backport is desirable, not that it must apply without manual resolution. Upstream acceptance is not contingent on the mechanics of a stable backport, which falls outside the scope of this review.

   As to 'Depends-on:': the dependency here is purely contextual. It is one of hunk context, not of function; the fix is semantically correct regardless of whether the block precedes or follows the conversion call.

- Local variable ('port'): I am entirely mindful of the desire to keep code laconic, yet, high-quality future-proof code benefits from such local declarations as they make the actual usage sites easier on the eyes and can be re-used by later additions to the logic.

On these premises, I respectfully suggest that the series be put forward for reconsideration and integration.

Thank you.

On Wed, 12 Aug 2026, Stephen Hemminger wrote:

> On Wed, 12 Aug 2026 21:10:17 +0400
> Ivan Malov <ivan.malov@arknetworks.am> wrote:
>
>> The issue is that when the user disables auto-negotiation by removing
>> the capability bit from the 'advertised mask' (set method) and then
>> reads the resulting capabilities, which involves querying MCDI, the
>> bit reappears in the mask irrespective of the user's intent.
>>
>> Fix this by remembering the user's intent before any link-state queries.
>>
>> Fixes: 2a5cf77e6de8 ("common/sfc_efx/base: provide PHY link get method on Medford4")
>> Fixes: 06f569de6c06 ("common/sfc_efx/base: decode netport link state on probe path")
>> Cc: stable@dpdk.org
>>
>> Suggested-by: Andy Moreton <andy.moreton@amd.com>
>> Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
>> Reviewed-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am>
>> Reviewed-by: Andy Moreton <andy.moreton@amd.com>
>
> This patch depends on the previous common series and therefore can
> not be easily backported to stable.
>
> There is a way to mark patch dependencies using Depends-on:
> please use that instead of instructions to AI.
>
> AI says that in its usual over the top wordy way...
>
> Patch 3/3 - common/sfc_efx/base: fix reading advertised autoneg ability
>
>  Warning: this patch depends on the pending common/sfc series for its
>  diff context only, and that dependency creates a backport conflict.
>
>  The efx_np.c hunk removes
>
>      if (lsp->enls_an_supported != B_FALSE)
>              lsp->enls_adv_cap_mask |= 1U << EFX_PHY_CAP_AN;
>
>  from a position after the LINK_STATE_OUT_ADVERTISED_ABILITIES
>  conversion.  On main and on every stable branch the block is still
>  before that conversion, where 06f569de6c06 originally put it.  Since
>  efx_np_cap_mask_hw_to_sw() ORs into *sw_cap_maskp (efx_np.c:197)
>  rather than assigning, the block's position has no effect on the
>  resulting mask - the pending series is only moving text.
>
>  Both Fixes: commits first appear in v25.07, so this needs to reach
>  25.11 LTS and 25.07, neither of which has the move.  Stable will hit
>  a conflict on a hunk whose resolution is not obvious from the diff.
>
>  Suggest sending this fix ahead of the series that moves the block,
>  or as a standalone patch against main.  It then applies unchanged
>  everywhere, and the other series absorbs a zero-cost rebase.  If the
>  current ordering has to stand, please post an explicit backport to
>  stable@dpdk.org rather than leaving the resolution to the stable
>  maintainer.
>
>  Info: the added local
>
>      const efx_port_t *port = &enp->en_port;
>
>  is used once, and the file otherwise reaches through enp->en_port
>  directly (line 33) or names the local "epp" (medford4_phy_reconfigure,
>  medford4_mac_poll).  Suggest:
>
>      preserve_an = enp->en_port.ep_adv_cap_mask &
>                    (1U << EFX_PHY_CAP_AN);
>

      reply	other threads:[~2026-08-13  4:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 17:49 [PATCH 0/3] net/sfc: miscellaneous bug fixes Ivan Malov
2026-08-11 17:49 ` [PATCH 1/3] net/sfc: set Rx queue type flags from scratch on queue setup Ivan Malov
2026-08-11 17:49 ` [PATCH 2/3] net/sfc: drop wrong static qualifier from iterator variable Ivan Malov
2026-08-11 17:49 ` [PATCH 3/3] common/sfc_efx/base: fix reading advertised autoneg ability Ivan Malov
2026-08-11 20:24 ` [PATCH 0/3] net/sfc: miscellaneous bug fixes Stephen Hemminger
2026-08-12 17:10 ` [PATCH v2 " Ivan Malov
2026-08-12 17:10   ` [PATCH v2 1/3] net/sfc: set Rx queue type flags from scratch on queue setup Ivan Malov
2026-08-12 17:10   ` [PATCH v2 2/3] net/sfc: drop wrong static qualifier from iterator variable Ivan Malov
2026-08-12 17:10   ` [PATCH v2 3/3] common/sfc_efx/base: fix reading advertised autoneg ability Ivan Malov
2026-08-13  2:44     ` Stephen Hemminger
2026-08-13  4:10       ` Ivan Malov [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=fdfecacc-d2cc-8f91-59db-d18ba9af548d@arknetworks.am \
    --to=ivan.malov@arknetworks.am \
    --cc=Roman.Zhukov@arknetworks.am \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=andy.moreton@amd.com \
    --cc=dev@dpdk.org \
    --cc=pieter.jansen-van-vuuren@amd.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=viacheslav.galaktionov@arknetworks.am \
    /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