Thank you for your feedback. You might have misunderstood me.
Our difficulties lie in the following:
1. Assuming only the mainline version changes the name (Assume name "nbl"),
   and our regularly released driver doesn't change its name, then when
   customers upgrade to a new kernel (containing the "nbl" driver),
   and then want to update our regularly released driver (named "nbl_core"),
   the module (ko) conflict will occur.
2. If both our mainline and regularly released drivers change their names,
   then customers who are already using the "nbl_core" driver will also
   encounter conflict issues when updating to the new driver "nbl".

Is it possible to do this: our net driver is also modified to be a driver based
on the auxiliary bus, while the PCIe driver only handles PCIe-related processing,
and these two drivers share a single kernel module (ko), namely "nbl_core"?
------------------------------------------------------------------
发件人：Andrew Lunn [off-list ref]
发送时间：2026年1月30日(周五) 11:04
收件人：Sam[off-list ref]
抄　送：Illusion Wang[off-list ref]; Dimon[off-list ref]; Alvin[off-list ref]; netdev[off-list ref]; "andrew+netdev"[off-list ref]; corbet[off-list ref]; kuba[off-list ref]; "linux-doc"[off-list ref]; lorenzo[off-list ref]; pabeni[off-list ref]; horms[off-list ref]; "vadim.fedorenko"[off-list ref]; "lukas.bulwahn"[off-list ref]; hawk[off-list ref]; ast[off-list ref]; bpf[off-list ref]; sdf[off-list ref]; daniel[off-list ref]; "john.fastabend"[off-list ref]; edumazet[off-list ref]; open list[off-list ref]
主　题：Re: 回复：回复：[PATCH v3 net-next 01/15] net/nebula-matrix: add minimum nbl build framework


On Fri, Jan 30, 2026 at 10:23:50AM +0800, Sam wrote:

Thank you for your feedback. I understand what you mean.The reasons why
we cannot change the module name now are as follows:
Our driver has already been integrated into multiple communities, and
the module name is nbl_core. Many customers have already deployed it. If
we change the name, there will be a critical problem of conflict between
the two modules during subsequent online driver upgrades.

To a large extent, mainline does not care about your vendor driver,
and it does not care about any compatibility issues between your
vendor driver and mainline.

I've not looked at your driver in detail yet so i cannot comment on
your driver in particular. But we often see vendor drivers do things
mainline does not allow. Custom ioctl handlers, files in /sys, write
APIs in debugfs, statistic counters wrongly grouped, etc. In a vendor
driver this is O.K, this is all open source, you are free to do what
you want. But when it comes to mainline, you have to keep to the
mainline rules. Such code will need to be removed, or reworked,
breaking compatibility with your vendor driver.

So it can be advantages to have different names, it then become clear
if a customer is using the vendor driver, or is using mainline.

   Andrew