HC-SRO4 ultrasonic distance driver
Hi all, I wrote a driver for the popular HC-SRO4 ultrasonic distance sensor. It is beta and has been tested on the Raspberry PI by me and my brother: here is the stand-alone repo: https://github.com/johannesthoma/linux-hc-sro4 I would like to contribute it to the linux kernel, however I am a little bit nervous reading through the Documentation/Submitting[Patches][Drivers] documentation (in particular the How to piss off a kernel developer sections ;), so I wanted to ask if I could post the patch (it will be against the char/mics device kernel tree at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git , I think this is the correct location) on this list first, maybe someone can tell me if the formatting and the driver are correct.. I also have some driver specific questions: *) First, does it really belong to drivers/misc ? There are other sensors there as well, so I suppose this location is right. *) As of now, I've created a new device class "distance" where the sysfs control files live in (so the configuration file is /sys/class/distance/configure ), it works for me (tm) but I don't know if code that creates new device classes would be accepted. Is there another solution to put the control files in? Maybe under /sys/class/gpio? *) I've filled out the parent device field in device_create_with_groups() to NULL, I'm not sure if this is right. If I put a parent, should it be the GPIO device (the HC_SRO4 is attached to two GPIO pins)? *) When I submit the patch, I've read that one should cc the maintainers (that would be Arnd Bergmann <arnd@arndb.de> and Greg Kroah-Hartman <gregkh@linuxfoundation.org>) but on what list should I post the patch at all? Is it lkml.org? Please let me know if it ok to post the patch to this list first. Thanks a lot, - Johannes
On Thu, Mar 24, 2016 at 11:38:45AM +0100, Johannes Thoma wrote:
Hi all,
I wrote a driver for the popular HC-SRO4 ultrasonic distance sensor. It is beta and has been tested on the Raspberry PI by me and my brother: here is the stand-alone repo:
https://github.com/johannesthoma/linux-hc-sro4
I would like to contribute it to the linux kernel, however I am a little bit nervous reading through the Documentation/Submitting[Patches][Drivers] documentation (in particular the How to piss off a kernel developer sections ;)
Don't be scared, we don't bite :)
, so I wanted to ask if I could post the patch (it will be against the char/mics device kernel tree at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git , I think this is the correct location) on this list first, maybe someone can tell me if the formatting and the driver are correct..
Formatting of the code itself, or the patch?
I also have some driver specific questions:
*) First, does it really belong to drivers/misc ? There are other sensors there as well, so I suppose this location is right.
Probably not, if this is a sensor, it should be interacting with the IIO layer, and not just using "random" sysfs files.
*) As of now, I've created a new device class "distance" where the sysfs control files live in (so the configuration file is /sys/class/distance/configure ), it works for me (tm) but I don't know if code that creates new device classes would be accepted. Is there another solution to put the control files in? Maybe under /sys/class/gpio?
Look into the IIO api, it should fit into there somewhere. And if not, that api can easily be extended to do so.
*) I've filled out the parent device field in device_create_with_groups() to NULL, I'm not sure if this is right.
You are correct, it isn't :)
If I put a parent, should it be the GPIO device (the HC_SRO4 is attached to two GPIO pins)?
Yes, you want your device to show up properly in the device heiarachy for all of the suspend/resume and other good things that the driver core gives you for free.
*) When I submit the patch, I've read that one should cc the maintainers (that would be Arnd Bergmann <arnd@arndb.de> and Greg Kroah-Hartman <gregkh@linuxfoundation.org>) but on what list should I post the patch at all? Is it lkml.org?
Use scripts/get_maintainer.pl on your patch to determine this, it figures it out for you automagically.
Please let me know if it ok to post the patch to this list first.
Sure, feel free to, it's always good to see code on this list :) Hope this helps, greg k-h
Am 24.03.16 um 15:07 schrieb Greg KH: > On Thu, Mar 24, 2016 at 11:38:45AM +0100, Johannes Thoma wrote: >> Hi all, >> >> I wrote a driver for the popular HC-SRO4 ultrasonic distance sensor. It >> is beta and has been tested >> on the Raspberry PI by me and my brother: here is the stand-alone repo: >> >> https://github.com/johannesthoma/linux-hc-sro4 >> >> I would like to contribute it to the linux kernel, however I am a little >> bit nervous reading through >> the Documentation/Submitting[Patches][Drivers] documentation (in >> particular the How to piss off >> a kernel developer sections ;) > Don't be scared, we don't bite :) Good to know ;) >> , so I wanted to ask if I could post the >> patch (it will be against the >> char/mics device kernel tree at >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git >> , I think this is the correct location) on this list first, maybe >> someone can tell me if the formatting >> and the driver are correct.. > Formatting of the code itself, or the patch? The patch. I will do it with git-format-patch and then it should work .. >> I also have some driver specific questions: >> >> *) First, does it really belong to drivers/misc ? There are other >> sensors there as well, so I suppose >> this location is right. > Probably not, if this is a sensor, it should be interacting with the IIO > layer, and not just using "random" sysfs files. Oh that is a good hint, didn't know that.. >> *) As of now, I've created a new device class "distance" where the sysfs >> control files live in (so the configuration file is >> /sys/class/distance/configure ), it works for me (tm) but I don't know >> if code that creates new device classes would be accepted. Is there >> another solution to put the control files in? Maybe under >> /sys/class/gpio? > Look into the IIO api, it should fit into there somewhere. And if not, > that api can easily be extended to do so. I will do so. >> *) I've filled out the parent device field in >> device_create_with_groups() to NULL, I'm not sure if this >> is right. > You are correct, it isn't :) > >> If I put a parent, should it be the GPIO device (the HC_SRO4 is >> attached to two GPIO pins)? > Yes, you want your device to show up properly in the device heiarachy > for all of the suspend/resume and other good things that the driver core > gives you for free. So I will choose one of the GPIO pins as parent.. >> *) When I submit the patch, I've read that one should cc the maintainers >> (that would be Arnd Bergmann <arnd@arndb.de> and Greg Kroah-Hartman >> <gregkh@linuxfoundation.org>) but on what list should >> I post the patch at all? Is it lkml.org? > Use scripts/get_maintainer.pl on your patch to determine this, it > figures it out for you automagically. > >> Please let me know if it ok to post the patch to this list first. > Sure, feel free to, it's always good to see code on this list :) > > Hope this helps, Indeed it does. Thank you for your quick reply. I will post to this list what I have now, with the promise to fix it it the next few days. > greg k-h - johannes
participants (2)
-
Greg KH -
Johannes Thoma