On Fri, Mar 20, 2026 at 03:05:24PM -0700, Tony Nguyen wrote:
> 
> 
> On 3/20/2026 12:33 PM, Simon Horman wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > 
> > For local reproduction steps see 
> > https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > ice: do not carry link status over to link event data
> > 
> > This patch removes code that updated the link_up parameter with the
> > current firmware state after calling ice_update_link_info().
> > 
> > > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c 
> > > b/drivers/net/ethernet/intel/ice/ice_main.c
> > > index e7308e381e2f..348c86b7328d 100644
> > > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > > @@ -1127,12 +1127,6 @@ ice_link_event(struct ice_pf *pf, struct 
> > > ice_port_info *pi, bool link_up,
> > > 
> > >           ice_check_link_cfg_err(pf, pi->phy.link_info.link_cfg_err);
> > > 
> > > - /* Check if the link state is up after updating link info, and treat
> > > -  * this event as an UP event since the link is actually UP now.
> > > -  */
> > > - if (phy_info->link_info.link_info & ICE_AQ_LINK_UP)
> > > -         link_up = true;
> > > -
> > 
> > Could removing this check create a race condition with stale link events?
> 
> This was a part of other changes that allows this to happen. By itself, as
> evidenced here, it does not.

Thanks for the clarification, much appreciated.

Reply via email to