[PATCH net] octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler

Ratheesh Kannoth posted 1 patch 1 week, 2 days ago
drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 1 +
1 file changed, 1 insertion(+)
[PATCH net] octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler
Posted by Ratheesh Kannoth 1 week, 2 days ago
From: Subbaraya Sundeep <sbhatta@marvell.com>

rvu_mbox_handler_nix_cn10k_aq_enq() is used by out-of-tree CN10K
modules but was not exported, causing unresolved symbol failures at
module load time.

Fixes: 30077d210c83 ("octeontx2-af: cn10k: Update NIX/NPA context structure")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
index 153eb57bad06..95776ab924e5 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
@@ -1501,6 +1501,7 @@ int rvu_mbox_handler_nix_cn10k_aq_enq(struct rvu *rvu,
 	return rvu_nix_aq_enq_inst(rvu, (struct nix_aq_enq_req *)req,
 				  (struct nix_aq_enq_rsp *)rsp);
 }
+EXPORT_SYMBOL(rvu_mbox_handler_nix_cn10k_aq_enq);
 
 int rvu_mbox_handler_nix_hwctx_disable(struct rvu *rvu,
 				       struct hwctx_disable_req *req,
-- 
2.43.0
Re: [PATCH net] octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler
Posted by netdev-bot+sashiko@kernel.org 6 days, 23 hours ago
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 1 · Medium: 0 · Low: 0

- [High] New EXPORT_SYMBOL() with no in-tree consumer:
  `EXPORT_SYMBOL(rvu_mbox_handler_nix_cn10k_aq_enq)` is added in…

--

octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler

This adds EXPORT_SYMBOL() for rvu_mbox_handler_nix_cn10k_aq_enq() in the
octeontx2 AF driver, with the stated motivation that out-of-tree CN10K
modules fail to load with an unresolved symbol.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
> index 153eb57bad067..95776ab924e57 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
> @@ -1501,6 +1501,7 @@ int rvu_mbox_handler_nix_cn10k_aq_enq(struct rvu *rvu,
>  	return rvu_nix_aq_enq_inst(rvu, (struct nix_aq_enq_req *)req,
>  				  (struct nix_aq_enq_rsp *)rsp);
>  }
> +EXPORT_SYMBOL(rvu_mbox_handler_nix_cn10k_aq_enq);

[Severity: High]
Is there an in-tree user for this new export?

Grepping under drivers/net/ethernet/marvell/octeontx2/ shows
rvu_mbox_handler_nix_cn10k_aq_enq is referenced only by its own definition
in rvu_nix.c and by the mailbox dispatch that the MBOX_MESSAGES M() list in
af/mbox.h expands inside rvu_process_mbox_msg() in af/rvu.c.

That dispatch lives in the same module as the handler, per af/Makefile:

    rvu_af-y := cgx.o rvu.o rvu_cgx.o rvu_npa.o rvu_nix.o \
		  rvu_reg.o rvu_npc.o rvu_debugfs.o ptp.o rvu_npc_fs.o \
		  ...

So how can the commit message's "causing unresolved symbol failures at
module load time" be reproduced with an in-tree configuration?  With
rvu_nix.o and the dispatch both linked into rvu_af, there does not appear to
be any mainline module that has to resolve this symbol at load time.

The commit message says the caller is out-of-tree:

    "rvu_mbox_handler_nix_cn10k_aq_enq() is used by out-of-tree CN10K
     modules but was not exported"

Would it make more sense to drop this hunk, or to post it together with the
in-tree driver that consumes it?  As it stands the export widens the AF
module ABI to include direct NIX admin-queue context programming, struct rvu
internals and the mailbox request layout struct nix_cn10k_aq_enq_req, with
nothing in the tree using it.

A related question on consistency: the sibling handler
rvu_mbox_handler_nix_cn20k_aq_enq() in af/cn20k/nix.c is not exported, while
rvu_mbox_handler_npa_cn20k_aq_enq() in af/cn20k/npa.c is.  Is the CN20K NIX
handler needed by the same out-of-tree modules, or is the intent to export
only this one?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260915072357.980485-1-rkannoth%40marvell.com
Re: [PATCH net] octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler
Posted by Ratheesh Kannoth 6 days, 23 hours ago
On 2026-09-18 at 12:56:23, netdev-bot+sashiko@kernel.org (netdev-bot+sashiko@kernel.org) wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
>
> Critical: 0 · High: 1 · Medium: 0 · Low: 0
>
> - [High] New EXPORT_SYMBOL() with no in-tree consumer:
>   `EXPORT_SYMBOL(rvu_mbox_handler_nix_cn10k_aq_enq)` is added in…
Can i post this patch to net-next as consumer is out of tree ?
Re: [PATCH net] octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler
Posted by Jakub Kicinski 3 days, 9 hours ago
On Fri, 18 Sep 2026 13:03:10 +0530 Ratheesh Kannoth wrote:
> > - [High] New EXPORT_SYMBOL() with no in-tree consumer:
> >   `EXPORT_SYMBOL(rvu_mbox_handler_nix_cn10k_aq_enq)` is added in…  
> Can i post this patch to net-next as consumer is out of tree ?

No, we don't carry exports for OOT code upstream.
-- 
pw-bot: reject
Re: [PATCH net] octeontx2-af: nix: Export CN10K admin queue enqueue mbox handler
Posted by Christoph Hellwig 37 minutes ago
On Mon, Sep 21, 2026 at 03:02:41PM -0700, Jakub Kicinski wrote:
> On Fri, 18 Sep 2026 13:03:10 +0530 Ratheesh Kannoth wrote:
> > > - [High] New EXPORT_SYMBOL() with no in-tree consumer:
> > >   `EXPORT_SYMBOL(rvu_mbox_handler_nix_cn10k_aq_enq)` is added in…  
> > Can i post this patch to net-next as consumer is out of tree ?
> 
> No, we don't carry exports for OOT code upstream.

Btw, someone really should do an audit of all the octeontx2
exports.  There is a lot of them, they are non-GPL and non-namespaces
which is a bit of a red flag.

Similar the drivers/net/ethernet/marvell/prestera is really weirdly
split into two drivers for no reason at all.