On Fri, 2026-03-20 at 20:59 +0100, Danilo Krummrich wrote: > On 3/20/26 6:13 PM, Markus Probst wrote: > > This is unique for a bus device. > > > > A class device has its own Data (e. g. PwmOps), i. e. it will only be > > registered after this Data has been initialized by the driver. > > > > The receive_buf callback on the serdev device on the other hand must > > happen on the drvdata, as there is no place to store its own Data. > > > > The drvdata is only available at the end of the probe in Rust. > > In other words, devm_serdev_device_open() relies on the driver having its > private data set before this is called, since once devm_serdev_device_open() > has > been called, the driver's receive_buf() callback may be called. > > So, in C it is the driver's responsibility to do things in the correct order, > in > Rust we want to make sure the driver can't do it out of order in the first > place. > > I'm still not sure whether the current approach is the best option. For > instance, we could also solve this with a separate callback. >
> Wasn't this even > what you had in a previous version? Yes, but Kari pointed out that changing the ops while it is in use is unsafe [1]. Thanks - Markus Probst [1] https://lore.kernel.org/rust-for-linux/CAC=evgr2wyddtw3koeemyqpp-h0aausrzn5gk5zce2hqeb7...@mail.gmail.com/
signature.asc
Description: This is a digitally signed message part
