Am 24.03.16 um 15:07 schrieb Greg KH:

On Thu, Mar 24, 2016 at 11:38:45AM +0100, Johannes Thoma wrote:

quoted

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 ;)

quoted

, 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 ..

quoted

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..

quoted

*) 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.

quoted

*) 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 :)

quoted

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..

quoted

*) When I submit the patch, I've read that one should cc the maintainers
(that would be Arnd Bergmann [off-list ref] and Greg Kroah-Hartman
[off-list ref]) 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.

quoted

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