This set is based on Greg's driver-core-next tree.

Currently there is no good way to pass arbitrary data from the driver to
a miscdevice or to share data between individual handles to a miscdevice in rust.

This series adds additional (generic) data to the MiscDeviceRegistration
for this purpose.

The first patch add the Aliased type.

The second patch implements the changes and fixes the build of the sample.

The third patch changes the rust_misc_device sample to use this to 
share the same data between multiple handles to the miscdevice.

Some discussion on Zulip about the motivation and approach
(Thanks a lot to everyone helping me out with this):
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Passing.20a.20DevRes.20to.20a.20miscdev/near/494553814

Signed-off-by: Christian Schrefl <chrisi.schrefl@gmail.com>
---
Christian Schrefl (3):
      rust: add Aliased type
      rust: miscdevice: Add additional data to MiscDeviceRegistration
      rust: miscdevice: adjust the rust_misc_device sample to use RegistrationData.

 rust/kernel/miscdevice.rs        | 37 ++++++++++++++++++++++++++++++-------
 rust/kernel/types.rs             | 40 ++++++++++++++++++++++++++++++++++++++++
 samples/rust/rust_misc_device.rs | 22 ++++++++++++----------
 3 files changed, 82 insertions(+), 17 deletions(-)
---
base-commit: 01b3cb620815fc3feb90ee117d9445a5b608a9f7
change-id: 20250119-b4-rust_miscdevice_registrationdata-a11d88dcb284

Best regards,
-- 
Christian Schrefl <chrisi.schrefl@gmail.com>

On Sun, Jan 19, 2025 at 11:11:12PM +0100, Christian Schrefl wrote:
> This set is based on Greg's driver-core-next tree.
> 
> Currently there is no good way to pass arbitrary data from the driver to
> a miscdevice or to share data between individual handles to a miscdevice in rust.

Why would you want to do this?  A misc device instance should be "self
contained" with the needed stuff to make it work.

Do you have an example of where this is needed as I can't figure out the
goal here, sorry.

thanks,

greg k-h

On 20.01.25 6:46 AM, Greg Kroah-Hartman wrote:
> On Sun, Jan 19, 2025 at 11:11:12PM +0100, Christian Schrefl wrote:
>> This set is based on Greg's driver-core-next tree.
>>
>> Currently there is no good way to pass arbitrary data from the driver to
>> a miscdevice or to share data between individual handles to a miscdevice in rust.
> 
> Why would you want to do this?  A misc device instance should be "self
> contained" with the needed stuff to make it work.
> 
> Do you have an example of where this is needed as I can't figure out the
> goal here, sorry.

The main reason for needing this was that I could not figure out how to otherwise
use a Devres from the platfrom driver probe in the implementation of the miscdevice.
The reason to add this to MiscDeviceRegistration is to avoid race-conditions between
the fops and driver registration/deregistration.
(See the commit description of patch 2/3)

If there is a better or more intended way to achieve that please let me know.

> 
> thanks,
> 
> greg k-h

On Tue, Jan 21, 2025 at 11:29:40AM +0100, Christian Schrefl wrote:
> 
> On 20.01.25 6:46 AM, Greg Kroah-Hartman wrote:
> > On Sun, Jan 19, 2025 at 11:11:12PM +0100, Christian Schrefl wrote:
> >> This set is based on Greg's driver-core-next tree.
> >>
> >> Currently there is no good way to pass arbitrary data from the driver to
> >> a miscdevice or to share data between individual handles to a miscdevice in rust.
> > 
> > Why would you want to do this?  A misc device instance should be "self
> > contained" with the needed stuff to make it work.
> > 
> > Do you have an example of where this is needed as I can't figure out the
> > goal here, sorry.
> 
> The main reason for needing this was that I could not figure out how to otherwise
> use a Devres from the platfrom driver probe in the implementation of the miscdevice.

A platform device has nothing to do with a misc device.  They should be
separate as they have totally different lifecycles.

> The reason to add this to MiscDeviceRegistration is to avoid race-conditions between
> the fops and driver registration/deregistration.
> (See the commit description of patch 2/3)
> 
> If there is a better or more intended way to achieve that please let me know.

I think you need an object that contains both of these, the driver_data
pointer field for the misc device should be able to be used for this,
right?

thanks,

greg k-h