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
signature.asc
Description: This is a digitally signed message part
