From: Jacob Keller <jacob.e.keller@intel.com>
To: Petr Oros <poros@redhat.com>,
"Rinitha, SX" <sx.rinitha@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "Vecera, Ivan" <ivecera@redhat.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
Eric Dumazet <edumazet@google.com>,
"Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
Simon Horman <horms@kernel.org>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
Jakub Kicinski <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
Date: Tue, 14 Apr 2026 13:13:04 -0700 [thread overview]
Message-ID: <73a48032-e891-47ff-a0b7-22e3810d47f8@intel.com> (raw)
In-Reply-To: <d74a9071-336d-4fec-a061-bf9a3a444678@redhat.com>
On 4/8/2026 1:54 AM, Petr Oros wrote:
>
> On 4/1/26 18:29, Rinitha, SX wrote:
>>> -----Original Message-----
>>> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
>>> Of Petr Oros
>>> Sent: 13 February 2026 19:47
>>> To: netdev@vger.kernel.org
>>> Cc: Vecera, Ivan <ivecera@redhat.com>; Kitszel, Przemyslaw
>>> <przemyslaw.kitszel@intel.com>; Eric Dumazet <edumazet@google.com>;
>>> Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Andrew Lunn
>>> <andrew+netdev@lunn.ch>; Nguyen, Anthony L
>>> <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-
>>> wired-lan@lists.osuosl.org; Jakub Kicinski <kuba@kernel.org>; Paolo
>>> Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>;
>>> linux-kernel@vger.kernel.org
>>> Subject: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin
>>> initialization in DPLL subsystem
>>>
>>> The DPLL SMA/U.FL pin redesign introduced
>>> ice_dpll_sw_pin_frequency_get() which gates frequency reporting on
>>> the pin's active flag. This flag is determined by
>>> ice_dpll_sw_pins_update() from the PCA9575 GPIO expander state.
>>> Before the redesign, SMA pins were exposed as direct HW input/output
>>> pins and ice_dpll_frequency_get() returned the CGU frequency
>>> unconditionally — the PCA9575 state was never consulted.
>>>
>>> The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN,
>>> ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the
>>> driver writes the register during initialization, so
>>> ice_dpll_sw_pins_update() sees all pins as inactive and
>>> ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every SW
>>> pin.
>>>
>>> Fix this by writing a default SMA configuration in
>>> ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and
>>> SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input
>>> disabled. Each SMA/U.FL pair shares a physical signal path so only
>>> one pin per pair can be active at a time. U.FL pins still report
>>> frequency 0 after this fix: U.FL1 (output-only) is disabled by
>>> ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2
>>> (input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be
>>> activated by changing the corresponding SMA pin direction via dpll
>>> netlink.
>>>
>>> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
>>> Signed-off-by: Petr Oros <poros@redhat.com>
>>> ---
>>> drivers/net/ethernet/intel/ice/ice_dpll.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>> When SMA1 is changed from output to input , U.FL1 (input) is expected
>> to get connected but is still disconnected
>> Similary, when SMA2 is changed from input to output , U.FL2 (output)
>> is still disconnected
>
> Hi Rinitha,
>
> Thanks for testing this.
> The initialization patch itself is correct. After boot, the PCA9575
> register is written to a known-good default state and SMA1/SMA2
> properly report as active inputs with the expected frequency.
>
> The behavior you describe (U.FL1/U.FL2 staying disconnected after
> SMA direction change) is a pre-existing issue in
> ice_dpll_sma_direction_set(), not in the initialization path.
>
> I am addressing this in v2 of "[PATCH iwl-net] ice: fix U.FL pin
> state set affecting paired SMA pin" with an expanded scope that
> covers both directions of the SMA/U.FL pairing.
>
> Is it OK like this?
>
@Rinitha,
I agree with Petr's assessment here, that the SMA issue is pre-existing
and shouldn't block sending this patch. Could you please let me know if
you agree and we can resolve the issue you reported within Petr's other
patch? I'm hoping to put together a net series with several fixes that
have been waiting for some time.
Thanks,
Jake
> Regards,
> Petr
>
prev parent reply other threads:[~2026-04-14 20:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 14:16 [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem Petr Oros
2026-02-13 14:33 ` Ivan Vecera
2026-02-26 13:48 ` Kubalewski, Arkadiusz
2026-04-01 16:29 ` [Intel-wired-lan] " Rinitha, SX
2026-04-08 8:54 ` Petr Oros
2026-04-14 20:13 ` Jacob Keller [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=73a48032-e891-47ff-a0b7-22e3810d47f8@intel.com \
--to=jacob.e.keller@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=ivecera@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=poros@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=sx.rinitha@intel.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