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@xxxxxxxx> and Greg Kroah-Hartman >> <gregkh@xxxxxxxxxxxxxxxxxxx>) 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
