On Sun, Jul 27, 2025 at 11:07:05AM +0300, Leon Romanovsky wrote:

On Fri, Jul 25, 2025 at 07:02:24AM +0200, Greg Kroah-Hartman wrote:

quoted

On Thu, Jul 24, 2025 at 09:55:59AM -0400, Sean Anderson wrote:

quoted

On 7/23/25 04:13, Leon Romanovsky wrote:

quoted

On Mon, Jul 21, 2025 at 10:29:32AM -0400, Sean Anderson wrote:

quoted

On 7/20/25 04:17, Leon Romanovsky wrote:

quoted

On Thu, Jul 17, 2025 at 01:12:08PM -0400, Sean Anderson wrote:

quoted

On 7/17/25 12:33, Greg Kroah-Hartman wrote:

<...>

quoted

Anyway, if you really think ids should be random or whatever, why not
just ida_alloc one in axiliary_device_init and ignore whatever's
provided? I'd say around half the auxiliary drivers just use 0 (or some
other constant), which is just as deterministic as using the device
address.

I would say that auxiliary bus is not right fit for such devices. This
bus was introduced for more complex devices, like the one who has their
own ida_alloc logic.

I'd say that around 2/3 of the auxiliary drivers that have non-constant
ids use ida_alloc solely for the auxiliary bus and for no other purpose.
I don't think that's the kind of complexity you're referring to.

quoted

quoted

Another third use ida_alloc (or xa_alloc) so all that could be
removed.

These ID numbers need to be per-device.

Why? They are arbitrary with no semantic meaning, right?

Yes, officially there is no meaning, and this is how we would like to
keep it.

Right now, they are very correlated with with their respective PCI function number.
Is it important? No, however it doesn't mean that we should proactively harm user
experience just because we can do it.

[leonro@c ~]$ l /sys/bus/auxiliary/devices/
,,,
rwxrwxrwx 1 root root 0 Jul 21 15:25 mlx5_core.rdma.0 -> ../../../devices/pci0000:00/0000:00:02.7/0000:0
8:00.0/mlx5_core.rdma.0
lrwxrwxrwx 1 root root 0 Jul 21 15:25 mlx5_core.rdma.1 -> ../../../devices/pci0000:00/0000:00:02.7/0000:0
8:00.1/mlx5_core.rdma

Well, I would certainly like to have semantic meaning for ids. But apparently
that is only allowed if you can sneak it past the review process.

Do I need to dust off my "make all ids random" patch again and actually
merge it just to prevent this from happening?

After weekend thoughts on it. IDs need to be removed from the driver
access. Let's make them global at least.

Great, no objection from me, want to send a patch we can queue up for
6.18-rc1?