Re: [net PATCH 6/6] fbnic: Pull fbnic_fw_xmit_cap_msg use out of interrupt context

[Simon Horman <horms@kernel.org>]

On Sun, May 04, 2025 at 07:53:09AM -0700, Alexander Duyck wrote:
> On Fri, May 2, 2025 at 9:54 AM Simon Horman <horms@kernel.org> wrote:
> >
> > On Thu, May 01, 2025 at 04:30:30PM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexanderduyck@fb.com>
> > >
> > > This change pulls the call to fbnic_fw_xmit_cap_msg out of
> > > fbnic_mbx_init_desc_ring and instead places it in the polling function for
> > > getting the Tx ready. Doing that we can avoid the potential issue with an
> > > interrupt coming in later from the firmware that causes it to get fired in
> > > interrupt context.
> > >
> > > In addition we can add additional verification to the poll_tx_ready
> > > function to make sure that the mailbox is actually ready by verifying that
> > > it has populated the capabilities from the firmware. This is important as
> > > the link config relies on this and we were currently delaying this until
> > > the open call was made which would force the capbabilities message to be
> > > processed then. This resolves potential issues with the link state being
> > > inconsistent between the netdev being registered and the open call being
> > > made.
> > >
> > > Lastly we can make the overall mailbox poll-to-ready more
> > > reliable/responsive by reducing the overall sleep time and using a jiffies
> > > based timeout method instead of relying on X number of sleeps/"attempts".
> >
> > This patch really feels like it ought to be three patches.
> > Perhaps that comment applies to other patches in this series,
> > but this one seems to somehow stand out in that regard.
> 
> Yeah, part of the issue is that these patches all became an exercise
> in "flipping rocks". Every time I touched one thing it exposed a bunch
> more bugs. I'll try to split this one up a bit more. I should be able
> to defer the need for the management version until net-next which will
> cut down on the noise.

Thanks. I could see that you were working your way through some sort of
rabbit hole situation. And while I certainly don't want to be unreasonable.
If would be nice if you could split this one up a bit. And it would
be a bonus in my view if some bits could be deferred to net-next.