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.
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
