Re: [Intel-wired-lan] [PATCH iwl-next v5 13/15] ixd: add reset checks and initialize the mailbox

[Larysa Zaremba]

On Mon, Nov 17, 2025 at 03:21:06PM +0100, Loktionov, Aleksandr wrote:
> 
> 
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf
> > Of Larysa Zaremba
> > Sent: Monday, November 17, 2025 2:49 PM
> > To: intel-wired-lan@xxxxxxxxxxxxxxxx; Nguyen, Anthony L
> > <anthony.l.nguyen@xxxxxxxxx>
> > Cc: Lobakin, Aleksander <aleksander.lobakin@xxxxxxxxx>; Samudrala,
> > Sridhar <sridhar.samudrala@xxxxxxxxx>; Singhai, Anjali
> > <anjali.singhai@xxxxxxxxx>; Michal Swiatkowski
> > <michal.swiatkowski@xxxxxxxxxxxxxxx>; Zaremba, Larysa
> > <larysa.zaremba@xxxxxxxxx>; Fijalkowski, Maciej
> > <maciej.fijalkowski@xxxxxxxxx>; Tantilov, Emil S
> > <emil.s.tantilov@xxxxxxxxx>; Chittim, Madhu <madhu.chittim@xxxxxxxxx>;
> > Hay, Joshua A <joshua.a.hay@xxxxxxxxx>; Keller, Jacob E
> > <jacob.e.keller@xxxxxxxxx>; Shanmugam, Jayaprakash
> > <jayaprakash.shanmugam@xxxxxxxxx>; Wochtman, Natalia
> > <natalia.wochtman@xxxxxxxxx>; Jiri Pirko <jiri@xxxxxxxxxxx>; David S.
> > Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet <edumazet@xxxxxxxxxx>;
> > Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>;
> > Simon Horman <horms@xxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>;
> > Richard Cochran <richardcochran@xxxxxxxxx>; Kitszel, Przemyslaw
> > <przemyslaw.kitszel@xxxxxxxxx>; Andrew Lunn <andrew+netdev@xxxxxxx>;
> > netdev@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; linux-
> > kernel@xxxxxxxxxxxxxxx
> > Subject: [Intel-wired-lan] [PATCH iwl-next v5 13/15] ixd: add reset
> > checks and initialize the mailbox
> > 
> > At the end of the probe, trigger hard reset, initialize and schedule
> > the after-reset task. If the reset is complete in a pre-determined
> > time, initialize the default mailbox, through which other resources
> > will be negotiated.
> > 
> > Co-developed-by: Amritha Nambiar <amritha.nambiar@xxxxxxxxx>
> > Signed-off-by: Amritha Nambiar <amritha.nambiar@xxxxxxxxx>
> > Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@xxxxxxxxx>
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@xxxxxxxxx>
> > ---
> >  drivers/net/ethernet/intel/ixd/Kconfig        |   1 +
> >  drivers/net/ethernet/intel/ixd/Makefile       |   2 +
> >  drivers/net/ethernet/intel/ixd/ixd.h          |  28 +++-
> >  drivers/net/ethernet/intel/ixd/ixd_dev.c      |  89 +++++++++++
> >  drivers/net/ethernet/intel/ixd/ixd_lan_regs.h |  40 +++++
> >  drivers/net/ethernet/intel/ixd/ixd_lib.c      | 143
> > ++++++++++++++++++
> >  drivers/net/ethernet/intel/ixd/ixd_main.c     |  32 +++-
> >  7 files changed, 326 insertions(+), 9 deletions(-)  create mode
> > 100644 drivers/net/ethernet/intel/ixd/ixd_dev.c
> >  create mode 100644 drivers/net/ethernet/intel/ixd/ixd_lib.c
> > 
> > diff --git a/drivers/net/ethernet/intel/ixd/Kconfig
> > b/drivers/net/ethernet/intel/ixd/Kconfig
> > index f5594efe292c..24510c50070e 100644
> > --- a/drivers/net/ethernet/intel/ixd/Kconfig
> > +++ b/drivers/net/ethernet/intel/ixd/Kconfig
> > @@ -5,6 +5,7 @@ config IXD
> >  	tristate "Intel(R) Control Plane Function Support"
> >  	depends on PCI_MSI
> >  	select LIBETH
> > +	select LIBIE_CP
> >  	select LIBIE_PCI
> >  	help
> >  	  This driver supports Intel(R) Control Plane PCI Function diff
> 
> ...
> 
> > +/**
> > + * ixd_check_reset_complete - Check if the PFR reset is completed
> > + * @adapter: CPF being reset
> > + *
> > + * Return: %true if the register read indicates reset has been
> > finished,
> > + *	   %false otherwise
> > + */
> > +bool ixd_check_reset_complete(struct ixd_adapter *adapter) {
> > +	u32 reg_val, reset_status;
> > +	void __iomem *addr;
> > +
> > +	addr = libie_pci_get_mmio_addr(&adapter->cp_ctx.mmio_info,
> > +				       ixd_reset_reg.rstat);
> > +	reg_val = readl(addr);
> > +	reset_status = reg_val & ixd_reset_reg.rstat_m;
> > +
> > +	/* 0xFFFFFFFF might be read if the other side hasn't cleared
> > +	 * the register for us yet.
> > +	 */
> > +	if (reg_val != 0xFFFFFFFF &&
> > +	    reset_status == ixd_reset_reg.rstat_ok_v)
> Magic number, I think 0xFFFFFFFF should be ~0U per kernel style.

I believe ~0U depends on the int size, but GENMASK() could work.

> 
> > +		return true;
> > +
> > +	return false;
> > +}
> 
> ...
> 
> > --
> > 2.47.0
>