On Thu, Dec 4, 2025 at 12:14 PM Krzysztof Kozlowski krzk@kernel.org wrote:
On 04/12/2025 10:44, Bartosz Golaszewski wrote:
This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between
Not forever. If every consumer is unloaded, this can be unloaded too, no?
it and the actual reset consumer. Suppress sysfs bind attributes so that
With that reasoning every reset consumer should have suppress binds. Devlink should be created by reset controller framework so it is not this driver's fault.
Here's my reasoning: I will add a devlink but Phillipp requested some changes so I still need to resend it. It will be a bigger change than this one-liner. The reset-gpio device was also converted to auxiliary bus for v6.19 and I will also convert reset core to using fwnodes for v6.20 so we'll significantly diverge in stable branches, while this issue is present ever since the reset-gpio driver exists. It's not the driver's fault but it's easier to fix it here and it very much is a special case - it's a software based device rammed in between two firmware-described devices.
user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle.
Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller")
Nothing to be fixed here, unless you claim that every reset provider is broken as well? What is exactly different in handling devlinks between this driver and every other reset provider?
I don't care if we keep the tag, it's just that this commit introduced a way for user-space to crash the system by simply unbinding reset-gpio and then its active consumers.
And the difference here is that there is no devlink between reset-gpio and its consumers. We need to first agree how to add it.
Bartosz