Re: [PATCH v8 3/5] rust: add basic serial device bus abstractions

[Markus Probst]

On Sat, 2026-05-30 at 18:27 +0200, Danilo Krummrich wrote:
> On Sat May 30, 2026 at 6:23 PM CEST, Markus Probst wrote:
> > On Sat, 2026-05-30 at 18:14 +0200, Danilo Krummrich wrote:
> > > On Sat May 30, 2026 at 4:51 PM CEST, Markus Probst wrote:
> > > > On Sat, 2026-05-30 at 16:35 +0200, Danilo Krummrich wrote:
> > > > > On Sat May 30, 2026 at 4:27 PM CEST, Markus Probst wrote:
> > > > > > This would work, but I don't see how it would get rid of rust_private_data in
> > > > > > this way. The device private data will but the private bus abstraction data
> > > > > > needs to outlive the devres callbacks (which is done by rust_private_data).
> > > > > 
> > > > > Why? You only ever use it in the receive callback, which won't be called after
> > > > > device unbind anymore.
> > > > Because the possibility exists that some classdev ops or Drop calls
> > > > e.g. sdev.set_baudrate. This is a null pointer dereference after
> > > > serdev_device_close has been called. I interpreted it to add a state to
> > > > the abstraction private data which would prevent those calls (early
> > > > return with error) after serdev_device_close has been called, but this
> > > > would only work if it outlives these calls.
> > > > 
> > > > But it seems you were refering to something else with the state?
> > > 
> > > Yes, but I just notice that I'm a step ahead. With the lifetime model class
> > > device registrations shouldn't be guarded with Devres anymore, but with a
> > > lifetime.
> > > 
> > > (This also entirely eliminates the need for having different devres stages to
> > > prevent drivers from smuggling a newly created Devres object into an existing
> > > Devres<Registration<T>>'s data, which would be unsound for obvious reasons.)
> > > 
> > > With this there is no way there are still class device callbacks after the bus
> > > device private data has been dropped in the first place.
> > There would still be Drop, which can access the device.
> > Drop happens after remove_callback.
> 
> But you control drop(), so can order it such that first the driver's bus device
> private data drops and after this the private data of the bus wrapping it (which
> will also call serdev_device_close()).
Yes.

It seems I also have to rebase led then, as it currently uses Devres.

Thanks
- Markus Probst

> 
> > Might be simpler for now: I can use a mutex to prevent calls in
> > receive_buf after remove_callback has been called.
> > 
> > Thanks
> > - Markus Probst

Attachment: signature.asc
Description: This is a digitally signed message part