Jonathan Cameron wrote: [..] > > > Maybe a guard() use case to allow early returns in error paths? > > > > I'm not seeing a good way to do it. pci_cfg_access_lock/unlock() isn't like your typical lock/unlock. It locks, changes some pci_dev internal stuff, and then unlocks in both functions. The pci_lock isn't being held after lock() call. > > > > You've lost me. > > Why does guard() care about the internals? > > All it does is stash a copy of the '_lock' - here the bridge struct > pci_dev then call the _unlock on it when the stashed copy of that > pointer when it goes out of scope. Agree, and I suggested offlist to just use pci_dev_lock() similar to pci_reset_function(). There is already a guard() for that, and pci_dev_lock() is amenable to lockdep.
