[PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Thomas Walsh]

In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to
enable PCIe TPH when setting up interrupts.

If the NIC hardware or firmware capabilities do not support queue ops,
attempting to enable TPH during bnxt_request_irq() is unnecessary.

As a result a flood of "RX queue restart failed: err=-95"  messages is
seen upon boot.

Gate the call to pcie_enable_tph() and setting of bp->tph_mode
behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized
on devices capable of supporting queue ops. This prevents a guaranteed
-EOPNOTSUPP error from occurring due to NULL operations.

Fixes: 1410c7416dc3 ("eth: bnxt: always set the queue mgmt ops")
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Thomas Walsh <thwalsh@redhat.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 1e4944f3e606..9a2bbfa38f76 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -11920,9 +11920,11 @@ static int bnxt_request_irq(struct bnxt *bp)
 #endif
 
 	/* Enable TPH support as part of IRQ request */
-	rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
-	if (!rc)
-		bp->tph_mode = PCI_TPH_ST_IV_MODE;
+	if (BNXT_SUPPORTS_QUEUE_API(bp)) {
+		rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
+		if (!rc)
+			bp->tph_mode = PCI_TPH_ST_IV_MODE;
+	}
 
 	for (i = 0, j = 0; i < bp->cp_nr_rings; i++) {
 		int map_idx = bnxt_cp_num_to_irq_num(bp, i);
-- 
2.55.0

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Pavan Chebbi]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

On Tue, Aug 18, 2026 at 7:46 PM Thomas Walsh <thwalsh@redhat.com> wrote:
>
> In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to
> enable PCIe TPH when setting up interrupts.
>
> If the NIC hardware or firmware capabilities do not support queue ops,
> attempting to enable TPH during bnxt_request_irq() is unnecessary.
>
> As a result a flood of "RX queue restart failed: err=-95"  messages is
> seen upon boot.
>
> Gate the call to pcie_enable_tph() and setting of bp->tph_mode
> behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized
> on devices capable of supporting queue ops. This prevents a guaranteed
> -EOPNOTSUPP error from occurring due to NULL operations.
>
> Fixes: 1410c7416dc3 ("eth: bnxt: always set the queue mgmt ops")
> Suggested-by: Michal Schmidt <mschmidt@redhat.com>
> Signed-off-by: Thomas Walsh <thwalsh@redhat.com>
> ---
>  drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 1e4944f3e606..9a2bbfa38f76 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -11920,9 +11920,11 @@ static int bnxt_request_irq(struct bnxt *bp)
>  #endif
>
>         /* Enable TPH support as part of IRQ request */
> -       rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
> -       if (!rc)
> -               bp->tph_mode = PCI_TPH_ST_IV_MODE;
> +       if (BNXT_SUPPORTS_QUEUE_API(bp)) {

IMO we should not gate pcie_enable_tph() on BNXT_SUPPORTS_QUEUE_API,
since TPH's initial steering-tag placement is valid on its own and
re-steering may never be needed in some cases?
So in these cases it simply disables the feature.

The TPH code has changed recently. You will need to rebase so see if
you can bail out from the newly introduced bnxt_tph_update() function
if queue management is not supported.
I feel that may be a better solution..

> +               rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
> +               if (!rc)
> +                       bp->tph_mode = PCI_TPH_ST_IV_MODE;
> +       }
>
>         for (i = 0, j = 0; i < bp->cp_nr_rings; i++) {
>                 int map_idx = bnxt_cp_num_to_irq_num(bp, i);
> --
> 2.55.0
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Jakub Kicinski]

On Wed, 19 Aug 2026 15:18:49 +0530 Pavan Chebbi wrote:
> >         /* Enable TPH support as part of IRQ request */
> > -       rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
> > -       if (!rc)
> > -               bp->tph_mode = PCI_TPH_ST_IV_MODE;
> > +       if (BNXT_SUPPORTS_QUEUE_API(bp)) {  
> 
> IMO we should not gate pcie_enable_tph() on BNXT_SUPPORTS_QUEUE_API,
> since TPH's initial steering-tag placement is valid on its own and
> re-steering may never be needed in some cases?
> So in these cases it simply disables the feature.

Since irqs are requested at open wouldn't this mean that users who
program affinity (all serious users?) will have the wrong TPH? Which
is presumably worse than no TPH at all?

IMHO the simplicity and consistency is good. AFAIU queue API is
supported on fairly old bnxt NICs so the combination of CPU needing
TPH and NIC design being 15(?) years old is rather unlikely in the 
first place. The real scenario where users may run into no queue API
support is FW being old, in which case FW should be updated?

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Thomas Walsh]

On Thu, Aug 20, 2026 at 1:40 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 19 Aug 2026 15:18:49 +0530 Pavan Chebbi wrote:
> > >         /* Enable TPH support as part of IRQ request */
> > > -       rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
> > > -       if (!rc)
> > > -               bp->tph_mode = PCI_TPH_ST_IV_MODE;
> > > +       if (BNXT_SUPPORTS_QUEUE_API(bp)) {
> >
> > IMO we should not gate pcie_enable_tph() on BNXT_SUPPORTS_QUEUE_API,
> > since TPH's initial steering-tag placement is valid on its own and
> > re-steering may never be needed in some cases?
> > So in these cases it simply disables the feature.
>
> Since irqs are requested at open wouldn't this mean that users who
> program affinity (all serious users?) will have the wrong TPH? Which
> is presumably worse than no TPH at all?
>
> IMHO the simplicity and consistency is good. AFAIU queue API is
> supported on fairly old bnxt NICs so the combination of CPU needing
> TPH and NIC design being 15(?) years old is rather unlikely in the
> first place. The real scenario where users may run into no queue API
> support is FW being old, in which case FW should be updated?
>
Thank you both for taking a look, I appreciate it.

In this particular situation, the customer had very recently upgraded their
firmware. "RX queue restart failed: err=-95" messages were still observed.

I should note that this was prior to the addition of bnxt_tph_update().

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Jakub Kicinski]

On Thu, 20 Aug 2026 13:55:57 -0400 Thomas Walsh wrote:
> In this particular situation, the customer had very recently upgraded their
> firmware. "RX queue restart failed: err=-95" messages were still observed.

Would you be able to share the NIC and the FW version?
Could it be that they upgraded to a version which has TPH but not queue
resets yet?  I _think_ queue resets came in 232.x but maybe there were
bugs which delayed it later.

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Thomas Walsh]

On Thu, Aug 20, 2026 at 2:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 20 Aug 2026 13:55:57 -0400 Thomas Walsh wrote:
> > In this particular situation, the customer had very recently upgraded their
> > firmware. "RX queue restart failed: err=-95" messages were still observed.
>
> Would you be able to share the NIC and the FW version?

NIC is BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
[14e4:16d7]
FW version shared with us was 238.1.138.6 upgraded from 236.1.167.0

> Could it be that they upgraded to a version which has TPH but not queue
> resets yet?  I _think_ queue resets came in 232.x but maybe there were
> bugs which delayed it later.

I suspected something similar initially, but both of the versions are
_relatively_ recent AFAICT.  Which lead us to graceful handling of
pcie_enable_tph()

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Michael Chan]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Thu, Aug 20, 2026 at 11:30 AM Thomas Walsh <thwalsh@redhat.com> wrote:
>
> On Thu, Aug 20, 2026 at 2:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Thu, 20 Aug 2026 13:55:57 -0400 Thomas Walsh wrote:
> > > In this particular situation, the customer had very recently upgraded their
> > > firmware. "RX queue restart failed: err=-95" messages were still observed.
> >
> > Would you be able to share the NIC and the FW version?
>
> NIC is BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
> [14e4:16d7]
> FW version shared with us was 238.1.138.6 upgraded from 236.1.167.0

This NIC does not support queue management.  I think it also doesn't
support TPH, but I need to check and confirm.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Jakub Kicinski]

On Thu, 20 Aug 2026 14:29:55 -0400 Thomas Walsh wrote:
> On Thu, Aug 20, 2026 at 2:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Thu, 20 Aug 2026 13:55:57 -0400 Thomas Walsh wrote:  
> > > In this particular situation, the customer had very recently upgraded their
> > > firmware. "RX queue restart failed: err=-95" messages were still observed.  
> >
> > Would you be able to share the NIC and the FW version?  
> 
> NIC is BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
> [14e4:16d7]
> FW version shared with us was 238.1.138.6 upgraded from 236.1.167.0
> 
> > Could it be that they upgraded to a version which has TPH but not queue
> > resets yet?  I _think_ queue resets came in 232.x but maybe there were
> > bugs which delayed it later.  
> 
> I suspected something similar initially, but both of the versions are
> _relatively_ recent AFAICT.  

Ugh, apparently :( I would have thought nobody is buying BCM574xx

> Which lead us to graceful handling of pcie_enable_tph()

Either way, I still agree with your approach.
Let's see if Pavan and Michael feel strongly.

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Michael Chan]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On Thu, Aug 20, 2026 at 11:59 AM Michael Chan <michael.chan@broadcom.com> wrote:
>
> On Thu, Aug 20, 2026 at 11:30 AM Thomas Walsh <thwalsh@redhat.com> wrote:
> > NIC is BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
> > [14e4:16d7]
> > FW version shared with us was 238.1.138.6 upgraded from 236.1.167.0
>
> This NIC does not support queue management.  I think it also doesn't
> support TPH, but I need to check and confirm.

Confirmed.  Only Thor and newer (P5_PLUS) supports TPH.

So the patch looks fine to me.  TPH requires queue management to
restart the queue.  And NICs that support queue management (with
updated FW) all support TPH.  Thanks.

Reviewed-by: Michael Chan <michael.chan@broadcom.com>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Jakub Kicinski]

On Thu, 20 Aug 2026 12:16:07 -0700 Michael Chan wrote:
> On Thu, Aug 20, 2026 at 11:59 AM Michael Chan <michael.chan@broadcom.com> wrote:
> >
> > On Thu, Aug 20, 2026 at 11:30 AM Thomas Walsh <thwalsh@redhat.com> wrote:  
> > > NIC is BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
> > > [14e4:16d7]
> > > FW version shared with us was 238.1.138.6 upgraded from 236.1.167.0  
> >
> > This NIC does not support queue management.  I think it also doesn't
> > support TPH, but I need to check and confirm.  
> 
> Confirmed.  Only Thor and newer (P5_PLUS) supports TPH.
> 
> So the patch looks fine to me.  TPH requires queue management to
> restart the queue.  And NICs that support queue management (with
> updated FW) all support TPH.  Thanks.
> 
> Reviewed-by: Michael Chan <michael.chan@broadcom.com>

Thanks! 

Thomas, please update commit msg with the info from Michael, rebase on
up-to-date net/main and repost.
-- 
pw-bot: cr

Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check

[Thomas Walsh]

On Thu, Aug 20, 2026 at 5:15 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 20 Aug 2026 12:16:07 -0700 Michael Chan wrote:
> > On Thu, Aug 20, 2026 at 11:59 AM Michael Chan <michael.chan@broadcom.com> wrote:
> > >
> > > On Thu, Aug 20, 2026 at 11:30 AM Thomas Walsh <thwalsh@redhat.com> wrote:
> > > > NIC is BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
> > > > [14e4:16d7]
> > > > FW version shared with us was 238.1.138.6 upgraded from 236.1.167.0
> > >
> > > This NIC does not support queue management.  I think it also doesn't
> > > support TPH, but I need to check and confirm.
> >
> > Confirmed.  Only Thor and newer (P5_PLUS) supports TPH.
> >
> > So the patch looks fine to me.  TPH requires queue management to
> > restart the queue.  And NICs that support queue management (with
> > updated FW) all support TPH.  Thanks.
> >
> > Reviewed-by: Michael Chan <michael.chan@broadcom.com>
>
> Thanks!
>
> Thomas, please update commit msg with the info from Michael, rebase on
> up-to-date net/main and repost.
> --
> pw-bot: cr
>

Thank you both!

I'll get the v2 out shortly.