linux-kernel - Re: [PATCH] reset: gpio: suppress bind attributes in sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cfe3ac14-829a-4ef3-927a-bff031574a9c@kernel.org>
Date: Mon, 8 Dec 2025 08:15:12 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH] reset: gpio: suppress bind attributes in sysfs

On 06/12/2025 09:45, Bartosz Golaszewski wrote:
>>> 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.
>>
>> So you mean that between every other reset consumer and reset provider
>> there is a devlink? And here there is no devlink?
>>
> 
> Effectively: yes, but only because reset is OF-only (as of commit
> 8bffbfdc01df ("reset: remove legacy reset lookup code")) so device
> links are created from device-tree. If you look at any device using
> reset-gpio in sysfs, you'll see a supplier:gpiochipX entry but no
> entry for the reset. So the answer is: yes, there's no devlink between
> the reset-gpio provider and its consumers unless we create them
> explicitly, which we should eventually do but I need to rethink the
> patch because we should possibly also remove the devlink between the
> gpiochip and the reset consumer as well.
> 
> Of course, here we could mention a different story: reset seems like
> one of these subsystems suffering from object lifetime issues: if you
> remove the supplier and the consumer tries to use the reset, you'll
> crash because of the dangling rstc->rcdev pointer. That should be
> addressed as well eventually.
> 

Yeah, I get it. We talked in person, so unless you plan to rework the
patch to fix it differently:


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>

Best regards,
Krzysztof