Re: [PATCH net-next] octeontx2-af: consolidate RVU AFVF device id definitions

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

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

- [Medium] Incomplete consolidation: the patch's stated goal
  ("octeontx2-af: consolidate RVU AFVF device id definitions") is only…

--

octeontx2-af: consolidate RVU AFVF device id definitions

This moves the local PCI_DEVID_OCTEONTX2_RVU_AFVF define from af/rvu.c into
the "PCI device IDs" block in af/rvu.h, and renames RVU_LBK_VF_DEVID to the
same name so both users share one definition.  The change is documented as
having no functional impact.

[Severity: Medium]
Is the consolidation complete here?  There is still a third definition of
the same macro in nic/otx2_common.h:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h:
    #include <rvu.h>
    ...
    #define PCI_DEVID_OCTEONTX2_RVU_AFVF		0xA0F8

Since nic/Makefile adds:

    ccflags-y += -I$(srctree)/drivers/net/ethernet/marvell/octeontx2/af

the <rvu.h> included by nic/otx2_common.h is the header modified by this
patch, so after this change every object built from nic/ (otx2_pf.o,
otx2_common.o, otx2_vf.o, rep.o) sees PCI_DEVID_OCTEONTX2_RVU_AFVF defined
twice within one translation unit.

Both replacement lists are the identical token 0xA0F8, so this is a benign
redefinition and no warning or build failure results.  Would it make sense
to also drop the copy in nic/otx2_common.h, so that its users
(is_..._vf() in nic/otx2_common.h and the PCI id table in nic/otx2_vf.c)
pick up the definition through the included af/rvu.h?

As it stands, does the commit message claim more than the diff does when it
says the goal is to "consolidate RVU AFVF device id definitions" and
"drop the local define", given that two live definitions remain?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260908094051.666769-1-yijiangshan%40kylinos.cn