Re: Should I return NOTIFY_DONE always from restart handler?
Hello, I believe you'll break the "chain" if you return an error. You might have registered as the last one so probably nothing would break but if someone registers on the notifier after your module did then that won't receive the notification if you throw an error and break the chain. Regards, On Tue, Mar 24, 2020 at 9:37 PM Tomek The Messenger wrote: > > Hi > There is such struct as 'notifier_block'. It has member 'notifier_call' where > You assign pointer to your function (handler) and priority. Then You register > such notifier block to restart handler list. > Then when You type in linux reboot Your function might be invoked (depends on > priority you set and if You don't have registered arm_pm_restart function > which is typically done through device tree) . > My question is should I always return NOTIFY_DONE from my restart handler? Or > can I return some error code? In fact this doesn't make sense to return any > other code value as Your restart handler has to succeed always in order not > to halt system and not to do manually recovery by power off/on. > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- ---P.K.S ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Should I return NOTIFY_DONE always from restart handler?
Hi There is such struct as 'notifier_block'. It has member 'notifier_call' where You assign pointer to your function (handler) and priority. Then You register such notifier block to restart handler list. Then when You type in linux reboot Your function might be invoked (depends on priority you set and if You don't have registered arm_pm_restart function which is typically done through device tree) . My question is should I always return NOTIFY_DONE from my restart handler? Or can I return some error code? In fact this doesn't make sense to return any other code value as Your restart handler has to succeed always in order not to halt system and not to do manually recovery by power off/on. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Accessing rpmsg_device in sysfs attribute functions
> To: Pelle Windestam > Cc: kernelnewbies@kernelnewbies.org > Subject: Re: Accessing rpmsg_device in sysfs attribute functions > > On Tue, Mar 24, 2020 at 01:05:48PM +, Pelle Windestam wrote: > > > From: Greg KH > > > Sent: Tuesday, 24 March 2020 13:31 > > > To: Pelle Windestam > > > Cc: kernelnewbies@kernelnewbies.org > > > Subject: Re: Accessing rpmsg_device in sysfs attribute functions > > > > > > On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote: > > > > > On Tue, Mar 24, 2020 at 05:34:44AM +, 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Accessing rpmsg_device in sysfs attribute functions
On Tue, Mar 24, 2020 at 01:05:48PM +, Pelle Windestam wrote: > > From: Greg KH > > Sent: Tuesday, 24 March 2020 13:31 > > To: Pelle Windestam > > Cc: kernelnewbies@kernelnewbies.org > > Subject: Re: Accessing rpmsg_device in sysfs attribute functions > > > > On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote: > > > > On Tue, Mar 24, 2020 at 05:34:44AM +, 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! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Accessing rpmsg_device in sysfs attribute functions
> From: Greg KH > Sent: Tuesday, 24 March 2020 13:31 > To: Pelle Windestam > Cc: kernelnewbies@kernelnewbies.org > Subject: Re: Accessing rpmsg_device in sysfs attribute functions > > On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote: > > > On Tue, Mar 24, 2020 at 05:34:44AM +, 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 //Pelle ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Finding bugs/issues to work on
On Tue, Mar 24, 2020 at 04:49:29PM +0530, Suraj Upadhyay wrote: > Hii newbies, > I just started studying for linux-kernel development although I am > not completely new to open source technologies. I wanted to clarify my > doubts in the following things > 1. Where can I find issues/tickets regarding linux-kernel, to work on ? It depends on the part of the kernel you are interested in, what part is that? > 2. What's the best resource to get started on linux-kernel development ? > I started reading kernel-newbies guides, though. That's a great start, what is wrong with that? good luck, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Accessing rpmsg_device in sysfs attribute functions
On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote: > > On Tue, Mar 24, 2020 at 05:34:44AM +, 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Accessing rpmsg_device in sysfs attribute functions
> On Tue, Mar 24, 2020 at 05:34:44AM +, 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. //Pelle ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Finding bugs/issues to work on
On Tue, 24 Mar 2020, Suraj Upadhyay wrote: > Hii newbies, > Â Â Â I just started studying for linux-kernel development although I am not > completely new to open source technologies. I wanted to clarify my doubts in > the > following things > 1. Where can I find issues/tickets regarding linux-kernel, to work on ? > 2. What's the best resource to get started on linux-kernel development ? > I started reading kernel-newbies guides, though. i make this suggestion on a semi-regular basis ... if you want something that desperately needs doing, work on improving the documentation. there is never a lack of docs that need improving, and it gives you a chance to *safely* learn a lot of new stuff. rday___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Finding bugs/issues to work on
Hii newbies, I just started studying for linux-kernel development although I am not completely new to open source technologies. I wanted to clarify my doubts in the following things 1. Where can I find issues/tickets regarding linux-kernel, to work on ? 2. What's the best resource to get started on linux-kernel development ? I started reading kernel-newbies guides, though. Grateful for your time and responses, Yours sincerely, A Kernel-Newbie. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Accessing rpmsg_device in sysfs attribute functions
On Tue, Mar 24, 2020 at 10:49:46AM +0100, Martin Kaiser wrote: > Hi Greg, > > Thus wrote Greg KH (g...@kroah.com): > > > 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. > > could you point me to an example in the kernel tree where this is done > correctly for a platform device? > > I had a look at > > http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ > > but I couldn't figure out how to create device attributes in a simple > platform driver that binds to a platform device. Look at commit d5a4f0f1 ("Input: axp20x-pek - convert driver to use dev_groups") in the 5.4 kernel as an example of how to use the correct api here. Hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Accessing rpmsg_device in sysfs attribute functions
Hi Greg, Thus wrote Greg KH (g...@kroah.com): > 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. could you point me to an example in the kernel tree where this is done correctly for a platform device? I had a look at http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ but I couldn't figure out how to create device attributes in a simple platform driver that binds to a platform device. Thanks a lot for your help, Martin ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies