> On 13 Jul 2025, at 11:27, Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>
> On Sun Jul 13, 2025 at 4:19 PM CEST, Danilo Krummrich wrote:
>> On Sun Jul 13, 2025 at 4:09 PM CEST, Daniel Almeida wrote:
>>> On a second look, I wonder how useful this will be.
>>>
>>> fn handle(&self, dev: &Device<Bound>) -> IrqReturn
>>>
>>> Sorry for borrowing this terminology, but here we offer Device<Bound>, while I
>>> suspect that most drivers will be looking for the most derived Device type
>>> instead. So for drm drivers this will be drm::Device, for example, not the base
>>> dev::Device type. I assume that this pattern will hold for other subsystems as
>>> well.
>>>
>>> Which brings me to my second point: drivers can store an ARef<drm::Device> on
>>> the handler itself, and I assume that the same will be possible in other
>>> subsystems.
>>
>> Well, the whole point is that you can use a &Device<Bound> to directly access
>> device resources without any overhead, i.e.
>>
>> fn handle(&self, dev: &Device<Bound>) -> IrqReturn {
>> let io = self.iomem.access(dev);
>>
>> io.write32(...);
>> }
>
> So, yes, you can store anything in your handler, but the &Device<Bound> is a
> cookie for the scope.
Fine, but can’t you get a &Device<Bound> from a ARef<drm::Device>, for example?
Perhaps a nicer solution would be to offer this capability instead?
