On Wed, Jan 31, 2024 at 2:32 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 31/01/2024 14:17, Linus Walleij wrote: > > On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > >> [Me] > >>> reset -> virtual "gpio" -> many physical gpios[0..n] > >> > >> This is a different problem: it supports many users enabling the same > >> GPIO (in Krzysztof's patch it's one but could be more if needed) but - > >> unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number > >> of users and doesn't disable the GPIO for as long as there's at least > >> one. > > > > I don't know if the NONEXCLUSIVE stuff is broken, if you mean reference > > counting isn't working on them, then that is by design because they were > > invented for regulators and such use cases that do their own reference > > counting. It's also used for hacks where people need to look up a desc in > > a second spot, (perhaps we can fix those better). > > > > As I say in commit b0ce7b29bfcd090ddba476f45a75ec0a797b048a > > "This solution with a special flag is not entirely elegant and should ideally > > be replaced by something more careful as this makes it possible for > > several consumers to enable/disable the same GPIO line to the left > > and right without any consistency." > > > > I think for regulators (which is the vast majority using it) it isn't broken > > because the regulator reference counting is working. > > > > So if we solve that problem for reset, we probably should put it in > > drivers/gpio/* somewhere so we can reuse the same solution for > > regulators and get rid of NONEXCLUSIVE altogether I think? > > > > The NONEXCLUSIVE stuff was prompted by converting regulators to > > gpio descriptors, so it was for the greater good one can say. Or the > > lesser evil :( my judgement can be questioned here. > > I discussed the non-exclusive GPIOs with Bartosz quite a lot, who was > Cced since beginning of this patchset, because that was my first > approach, which was rejected: > > https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@xxxxxxxxxxxxx/ > > The non-exclusive GPIO was made explicitly for regulators, so it is > working fine there, but it is broken everywhere else, where the drivers > do not handle it in sane way as regulator core does. > > To make it working, either GPIO should be enable-count-aware, to which > Bartosz was opposing with talks with me, or the subsystem should mimic For the record: I'm not 100% opposed to the enable-count-awarness of GPIOs but don't want it to be the standard. I'm open for introducing a wrapper built around the core, low-level GPIO API but I've just dropped a big patchset addressing the access control and serialization issues for the GPIO consumer API and I would rather work towards making it at least more-or-less correct in the first place before we start overcomplicating it again. Bartosz > regulators approach. In some way, my patchset is the second way here - > reset framework subsystem being aware of shared GPIO and handles the > enable-count, even though it is not using non-exclusive flag. > > Best regards, > Krzysztof >
