Accessing rpmsg_device in sysfs attribute functions

[Pelle Windestam]

> To: Pelle Windestam <Pelle.Windestam at tagmaster.com>
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: Accessing rpmsg_device in sysfs attribute functions
> 
> On Tue, Mar 24, 2020 at 01:05:48PM +0000, Pelle Windestam wrote:
> > > From: Greg KH <greg at kroah.com>
> > > Sent: Tuesday, 24 March 2020 13:31
> > > To: Pelle Windestam <Pelle.Windestam at tagmaster.com>
> > > Cc: kernelnewbies at kernelnewbies.org
> > > Subject: Re: Accessing rpmsg_device in sysfs attribute functions
> > >
> > > On Tue, Mar 24, 2020 at 12:02:15PM +0000, Pelle Windestam wrote:
> > > > > On Tue, Mar 24, 2020 at 05:34:44AM +0000, Pelle Windestam wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am trying to develop a simple driver for the rpmsg bus, in
> > > > > > order to send
> > > > > various commands from user space in Linux to a secondary CPU (A
> > > > > Cortex
> > > M4).
> > > > > I'm trying to keep things as simple as possible, so my idea was
> > > > > to create a driver that just has a few attributes which can be
> > > > > set in /sys which would trigger commands to be sent to the M4
> > > > > CPU. I have the communication between the CPU:s up and running,
> > > > > but where I'm having trouble moving forward is how to access the
> > > > > "struct rpmsg_device *" that I need in order to communicate with
> > > > > the endpoint for the M4 CPU from the store/show function of the
> > > > > sysfs attributes. What my driver does is to register a
> > > > > rpmsg_driver in the init
> > > > > function:
> > > > > >
> > > > > > register_rpmsg_driver(&pwm_rpmsg_driver);
> > > > > >
> > > > > > the device_driver member of my rpmsg_driver struct has its
> > > > > > groups member
> > > > > set to my driver attribute groups array:
> > > > > > static struct rpmsg_driver pwm_rpmsg_driver = {
> > > > > > 	.probe = pwm_rpmsg_probe,
> > > > > > 	.remove = pwm_rpmsg_remove,
> > > > > > 	.callback = pwm_rpmsg_cb,
> > > > > > 	.id_table = pwm_rpmsg_device_id_table,
> > > > > > 	.drv = {
> > > > > > 		.groups = driver_pwm_groups,
> > > > > > 		.name = "pwm_rpmsg",
> > > > > > 	},
> > > > > > };
> > > > > >
> > > > > > My issue is that that I am not sure how to access the struct
> > > > > > "rpmsg_device
> > > > > *" (i.e. from the probe() function) in the show/store functions
> > > > > for the sysfs attributes, which have a "struct device_driver *"
> argument:
> > > > >
> > > > > That is because you have created a driver attribute, not a
> > > > > device
> > > attribute.
> > > > > Create device attributes and you should be fine, they bind to
> > > > > the device your driver is passed.
> > > >
> > > > Thanks! Changing them to device attributes was a breeze. Now I am
> > > > slightly confused about the "struct device *" argument to the
> > > > store/show functions. I was under the impression that this would
> > > > be the "struct device" in the struct rpmsg_device, (which would
> > > > let me get the struct rpmsg_device using container_of()?), but it
> > > > appears to be some completely other device (by looking at the
> > > > pointer address). I have tried searching the kernel code for
> > > > similar example, but I have not found anything so far. It feels
> > > > like I am stumbling a bit in the dark here, looking for my
> rpmsg_device.
> > >
> > > It's a bit hard to figure out what exactly you are doing here
> > > without a pointer to the code itself :)
> > >
> > > Are you sure you aren't pointing the platform device accidentally?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I suppose anything is possible 😊 Here is the actual code if you want to
> have a look:
> > https://gist.github.com/iceaway/9900a9c2dd221eb836c5acda49f5d688
> 
> Odd, that "should" work.  But the pwm core is strange, I suggest posting it
> to the pwm driver mailing list and asking for help there, as there might be
> some odd "wrapper" structures involved here as can be seen by the pwm core
> sysfs file accesses.
> 
> good luck!
> 

I do no think that the PWM subsystem actually has anything to do with it, I only have "pwm" in the name because it will control a PWM signal via the M4 CPU. Otherwise it's all via the rpmsg driver. Rpmsg does not seem to have a mailing list of its own.

I will do some more digging. Thanks for the help!

//Pelle