HC-SRO4 ultrasonic distance driver

HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

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

HC-SRO4 ultrasonic distance driver

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

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

HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

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