On Fri Feb 20, 2026 at 9:04 AM CET, Leon Romanovsky wrote:

This init->add->remove->destroy pattern follows standard Linux kernel practice.
I expect all current review tools to flag any missing function call
among these three.

I'm not saying that the flow is not logical, goes against existing patterns,
etc., I'm saying that it is unnecessary to expose a new API to drivers, since
this is already handled internally.

I.e. we can easily fix the bug without increasing the API surface exposing a new
API to drivers.

It is not, atomic is not a replacement for locking and this hunk is
going to be racy as hell:

No, of course not, but it is sufficient to ensure that something runs only once.

However, you are still right, since sysfs_create_group() can still fail, we
still need the mutex, because we may need to unwind.

In the proposed patch, locking is handled by the driver, which understands the
flow far better than the driver core.

I don't think so, the driver core (or actually the auxiliary bus code) is
perfectly aware of the flow, i.e. create the attribute group once actually
needed by auxiliary_device_sysfs_irq_add(), remove it on driver unbind.