linux-kernel - Re: [PATCH v3 fwctl 2/5] fwctl/bnxt_en: Refactor aux bus functions to be more generic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALs4sv3piP=PpcocBB0WTXLzE41dog-UtRZhGuSeXopkB0wC5w@mail.gmail.com>
Date: Thu, 5 Feb 2026 14:11:00 +0530
From: Pavan Chebbi <pavan.chebbi@...adcom.com>
To: Saeed Mahameed <saeedm@...dia.com>
Cc: jgg@...pe.ca, michael.chan@...adcom.com, linux-kernel@...r.kernel.org, 
	dave.jiang@...el.com, Jonathan.Cameron@...wei.com, gospo@...adcom.com, 
	selvin.xavier@...adcom.com, leon@...nel.org, 
	kalesh-anakkur.purayil@...adcom.com
Subject: Re: [PATCH v3 fwctl 2/5] fwctl/bnxt_en: Refactor aux bus functions to
 be more generic

On Thu, Feb 5, 2026 at 9:30 AM Pavan Chebbi <pavan.chebbi@...adcom.com> wrote:
>
> > >-void bnxt_rdma_aux_device_del(struct bnxt *bp)
> > >+void bnxt_aux_devices_del(struct bnxt *bp)
> > > {
> > >-      if (!bp->edev)
> > >-              return;
> > >+      int idx;
> > >
> > >-      auxiliary_device_delete(&bp->aux_priv->aux_dev);
> > >+      mutex_lock(&bp->auxdev_lock);
> > >+      for (idx = 0; idx < __BNXT_AUXDEV_MAX; idx++) {
> > >+              if (bnxt_auxdev_is_active(bp, idx)) {
> > >+                      auxiliary_device_delete(&bp->aux_priv[idx]->aux_dev);
> > >+                      bnxt_auxdev_set_state(bp, idx, BNXT_ADEV_STATE_INIT);
> >
> > I can't really follow why you need to maintain a dangling device state !
>
> This is so because the init-add and del-uninit function pair in bnxt
> are not tightly coupled, possibly for some historic reason.
> I see it produces regressions trying to club them together. As of now,
> these states are going to be in use only during probe/remove.
>
> >
> > Why not completely remove and free an aux dev and then on probe/add init
> > and add from scratch, simplified patch #3 which prompted me to come and
> > look back here.
>
> I see what you are saying. This is a design carried over from
> pre-auxbus time between bnxt_en and RoCE drivers and I need a buy-in
> from our RoCE driver folks to make this change.
> I am very certain I will endup touching RoCE driver code and it will
> increase the scope of the changes in this series. If not anything
> else, the regression tests will require a lot of time and effort.
> That said, it's a good change to make. Let me check with our RoCE team
> internally and get back.

I checked with our RoCE team. And yes, we feel time is ripe to move to
a complete aux bus dependent design.
We want to get rid of ulp_start/stop entirely and replace it with aux
device del/add. But this is going to need changes in the RoCE driver.
Looking at the changes and the testing involved, we feel it is best
suited to implement in our internal tree first.
RoCE team plans to start with this change and we anticipate it should
land upstream for review by 6.22 timeframe.

>
> >
> > >+              }
> > >+      }
> > >+      mutex_unlock(&bp->auxdev_lock);
> > > }
> > >

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5469 bytes)