Page MenuHomeFreeBSD

regulator: don't use internal gpiobus function
ClosedPublic

Authored by vexeduxr on Jun 16 2025, 7:51 AM.
Tags
None
Referenced Files
F132135666: D50870.diff
Tue, Oct 14, 1:59 AM
Unknown Object (File)
Sun, Oct 12, 5:05 PM
Unknown Object (File)
Wed, Oct 8, 8:41 PM
Unknown Object (File)
Fri, Oct 3, 5:38 AM
Unknown Object (File)
Thu, Oct 2, 11:07 AM
Unknown Object (File)
Thu, Oct 2, 5:43 AM
Unknown Object (File)
Sun, Sep 28, 12:30 PM
Unknown Object (File)
Sun, Sep 28, 6:13 AM
Subscribers

Details

Summary

gpiobus_acquire_pin is only meant to be used internally by gpiobus. Use
gpio_pin_acquire instead.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 64946
Build 61829: arc lint + arc unit

Event Timeline

manu added a reviewer: mmel.

I think that it should be ok but let's wait for @mmel

This revision is now accepted and ready to land.Jun 17 2025, 7:59 AM

Why did you remove the comment? IMHO it is still a bit problematic (or not well defined) to hold the mutex across the GPIO infrastructure call.

I don't really see why it would cause problems. With the current implementation at least.
Thinking about this some more, it's very possible that a future change to gpiobus_acquire_pin or gpio_pin_acquire can break this though...

This revision now requires review to proceed.Jun 17 2025, 5:09 PM

Thanks.
The most problematic variant is GPIO over I2C bus (or other serial bus), where sleepable(SX) locks are required for basic operation. So I just was to be very careful and warn others of the problematic place.

This revision is now accepted and ready to land.Jun 17 2025, 6:21 PM

Looks good, but this is more 'permission to commit' rather than 'the change is good'. I trust the people that reviewed it and didn't see anything insane.