On Tue, Feb 3, 2026 at 8:46 AM Danilo Krummrich <[email protected]> wrote: > > On Tue Feb 3, 2026 at 5:40 PM CET, Greg Kroah-Hartman wrote: > > On Tue, Feb 03, 2026 at 05:29:16PM +0100, Danilo Krummrich wrote: > >> On Tue Feb 3, 2026 at 5:17 PM CET, Greg Kroah-Hartman wrote: > >> > And I don't see what patch in this series uses this, am I missing it? > >> > >> impl Smem { > >> pub(crate) fn access<'a>(&'a self, dev: &'a Device<Bound>) -> > >> Option<&'a Mmio> { > >> if *dev != *self.dev { > >> return None; > >> } > >> > >> // SAFETY: By our invariant, this was a subrange of what was > >> returned by smem_aux_get, for > >> // self.dev, and by our above check, that auxdev is still > >> available. > >> Some(unsafe { Mmio::from_raw(&self.raw) }) > >> } > >> } > >> > >> It's used to ensure that the Smem provided by the auxiliary parent can > >> only be > >> accessed as long as the auxiliary parent device is bound. > > > > But how can a parent device ever bevome "unbound"? > > It can't, that's why auxiliary::Device::parent() returns a &Device<Bound>, > i.e. > as long as the child is bound the parent is guaranteed to be bound as well. > > The point in this implementation is that we need to prove to the resource > container (Smem) that we are allowed to access the resource, since it is only > valid to access for the duration the parent is bound. > > In the end this is equivalent to Devres::access(), which bypasses the > Revocable > if we can prove that we are in a &Device<Bound> scope. > > Having that said, the code should probably just use Devres instead. :)
Not using Devres was intentional because: 1. Implementing `subrange` would require more unsafe / invariant logic with Devres. I would need to either wrap `MmioRaw` in a wrapper that maintained that it would always be inside a Devres that owned it, or wrap the Devres<MmioRaw> in a wrapper that encoded that invariant. Then, I would need to propagate the `dev` from the source `Devres` to the derived `Devres`. 2. Devres is PinInit, so I can't put it in a vector. 3. I don't need the destructor feature of Devres that necessitates the extra complexity, because this is morally a checked borrow, not an owned value. I considered adding a more lightweight `Devref` to the kernel crate which only supports types which do not implement `Drop` and access through `access`, and so does not need to be `PinInit`. However, since that would still require the manual dev propagation wrapper, it seemed like it might be overkill.
