> Subject: [EXTERNAL] Re: [Patch net-next v2] net: mana: Handle hardware
> recovery events when probing the device
>
> On 11/18/25 2:52 AM, [email protected] wrote:
> > From: Long Li <[email protected]>
> >
> > When MANA is being probed, it's possible that hardware is in recovery
> > mode and the device may get GDMA_EQE_HWC_RESET_REQUEST over HWC
> in the
> > middle of the probe. Detect such condition and go through the recovery
> > service procedure.
> >
> > Fixes: fbe346ce9d62 ("net: mana: Handle Reset Request from MANA NIC")
> > Signed-off-by: Long Li <[email protected]>
>
> Does not apply cleanly anymore due to commit
> 934fa943b53795339486cc0026b3ab7ad39dc600, please rebase and repost.
I will rebase and repost v3.
>
> > +static void mana_recovery_delayed_func(struct work_struct *w) {
> > + struct mana_dev_recovery_work *work;
> > + struct mana_dev_recovery *dev, *tmp;
> > + unsigned long flags;
> > +
> > + work = container_of(w, struct mana_dev_recovery_work, work.work);
> > +
> > + spin_lock_irqsave(&work->lock, flags);
> > +
> > + list_for_each_entry_safe(dev, tmp, &work->dev_list, list) {
> > + list_del(&dev->list);
>
> Minor nit: here and in similar code below I find sligly more readable
> something
> alike:
>
> while (!list_empty(&work->dev_list)) {
> dev = list_first_entry(&work->dev_list);
> list_del(dev);
> //...
>
> as it's more clear that releasing the lock will not causes races, but no
> strong
> opinion against the current style.
>
> /P
>
> /P
This is better, will change to use while(!list_empty()) as you suggested.
Thank you,
Long
