From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: 'Simon Horman' <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2 3/5] ice: add correct handling of SMA/u.FL states
Date: Thu, 7 May 2026 12:45:11 +0100 [thread overview]
Message-ID: <20260507114507.910365-5-horms@kernel.org> (raw)
In-Reply-To: <20260504142451.4161845-4-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
Simon says:
I would also like to add that as a fix the patch description should
describe the user-visible effects of the bug, and how the fix addresses
them.
Thanks!
---
ice: add correct handling of SMA/u.FL states
This commit renames ICE_SMA2_UFL2_RX_DIS to ICE_SMA2_UFL2_RX_EN, stating that
the hardware bit is actually active high for enabling RX. It updates the uses
of the macro in ice_dpll.c to reflect the new name.
> The ICE_SMA2_UFL2_RX_DIS bit name is wrong: the bit is active high
> (setting it *enables* RX for u.FL2 / SMA2), not active low. Rename
> it to ICE_SMA2_UFL2_RX_EN and invert the use sites in ice_dpll.c so
> that enabling the u.FL2 pin clears the bit (as it used to do) and
> disabling sets it.
The commit message claims that setting the bit enables RX (active high), but
then states that enabling the pin clears the bit (active low). Could this
description be clarified to explain exactly whether the hardware uses active
high or active low logic?
> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
> index 62f75701d6520..7e8bb63b262a0 100644
> --- a/drivers/net/ethernet/intel/ice/ice_dpll.c
> +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
> @@ -672,7 +672,7 @@ ice_dpll_sw_pins_update(struct ice_pf *pf)
> p->active = false;
>
> p = &d->ufl[ICE_DPLL_PIN_SW_2_IDX];
> - p->active = (data & ICE_SMA2_DIR_EN) && !(data & ICE_SMA2_UFL2_RX_DIS);
> + p->active = (data & ICE_SMA2_DIR_EN) && !(data & ICE_SMA2_UFL2_RX_EN);
If the bit is renamed to an _EN suffix and is active high, should the logic be
inverted here? This code still treats the bit as active low by checking for it
being cleared (!(data & ICE_SMA2_UFL2_RX_EN)).
[ ... ]
> @@ -1264,10 +1264,10 @@ ice_dpll_ufl_pin_state_set(const struct dpll_pin *pin, void *pin_priv,
> case ICE_DPLL_PIN_SW_2_IDX:
> if (state == DPLL_PIN_STATE_SELECTABLE) {
> data |= ICE_SMA2_DIR_EN;
> - data &= ~ICE_SMA2_UFL2_RX_DIS;
> + data &= ~ICE_SMA2_UFL2_RX_EN;
> enable = true;
> } else if (state == DPLL_PIN_STATE_DISCONNECTED) {
> - data |= ICE_SMA2_UFL2_RX_DIS;
> + data |= ICE_SMA2_UFL2_RX_EN;
> enable = false;
> } else {
Similarly, does this code still apply active low logic by clearing the _EN bit
when enable is true, and setting it when enable is false?
If the bit is truly active high as the commit message suggests ("setting it
enables RX"), shouldn't the bitwise operations be inverted to match?
next prev parent reply other threads:[~2026-05-07 11:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 14:24 [Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: five small fixes and cleanups Aleksandr Loktionov
2026-05-04 14:24 ` [Intel-wired-lan] [PATCH iwl-next v2 1/5] ice: fix ETH56G Rx offset type description in kernel-doc comment Aleksandr Loktionov
2026-05-04 14:24 ` [Intel-wired-lan] [PATCH iwl-next v2 2/5] ice: remove unnecessary PF_SB_REM_DEV_CTL write for E82X Aleksandr Loktionov
2026-05-04 14:24 ` [Intel-wired-lan] [PATCH iwl-next v2 3/5] ice: add correct handling of SMA/u.FL states Aleksandr Loktionov
2026-05-07 11:45 ` Simon Horman [this message]
2026-05-04 14:24 ` [Intel-wired-lan] [PATCH iwl-next v2 4/5] ice: fix DPLL pin frequency range in CGU pin descriptors Aleksandr Loktionov
2026-05-04 14:24 ` [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: use element-by-element comparison for DCB config changes Aleksandr Loktionov
2026-05-07 11:46 ` Simon Horman
2026-05-06 22:53 ` [Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: five small fixes and cleanups Jacob Keller
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=20260507114507.910365-5-horms@kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox