Re: CMA question

[Johannes Thoma]

Hello,

Am 28.02.17 um 11:04 schrieb Thomas Petazzoni:
> Hello,
>
> On Sun, 26 Feb 2017 18:14:42 +0100, Johannes Thoma wrote:
>
>> As you pointed out the solution would be to allocate the memory earlier in 
>> the
>> boot process, by modifying the driver. I will try that in the next few days 
>> and
>> let you know the result.
>
> The whole point of CMA is that allocating earlier in the boot process
> should not be necessary. CMA guarantees that the memory reserved for
> the CMA pool is "movable", i.e it can be discarded when a CMA
> allocation is done.
>
Yes it is moveable, but it takes rather long until it is moved (up to
20 Seconds). To test this I've implemented a loop that restarts from
beginning of the CMA area as long as alloc_contig_range() returns
-EBUSY (something similar to
https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg16956.html
). The result (on my system, which is an ARM based IMX-6 SOC) is that
after some while it always succeeds but it takes some time.

> So if a CMA allocation fails, I would rather suggest that the size of
> your CMA pool is not large enough. Check your Device Tree and/or kernel
> command (you can specify the size of the CMA pool on both if I remember
> correctly).
>
We use kernel command line to set the CMA size, so I will try as you
suggested.

Thanks a lot,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: CMA question

[Johannes Thoma]

Dear Greg,

Thank you for your quick response.

Am 26.02.17 um 17:31 schrieb Greg KH:
> On Sun, Feb 26, 2017 at 05:29:05PM +0100, Johannes Thoma wrote:
>> Dear Kernel hackers,
>>
>> As far as I understood CMA (contiguous memory allocation) memory is used
>> for other purposes as long it isn't requested via cma_alloc() by a
>> driver. cma_alloc then tries to free the memory by relocating it and
>> returns the contiguous area.
>>
>> I have a case where cma_alloc() sometimes fails to relocate the memory
>> which causes my driver (a GPU driver) to fail starting up (the driver is
>> started when the system is running for a while). Is there a way to
>> prevent the CM allocator to use the memory for any other purpose? Or
>> should I better use another mechanism to allocate  contiguous memory at
>> boot time (is there a framework for doing so)?
>
> If at boot time you don't have enough memory, something is really wrong
> and your driver shouldn't work, that's to be expected.  Try starting it
> earlier in the boot process.
>
Maybe that is the problem. The call to cma_alloc() happens in a
driver-specific API function which is called when my application starts
(at uptime 30 seconds it always succeeded (at least I didn't observe any
failures), however when I restart the application later and call
cma_alloc() again (the memory was freed meanwhile) it sometimes fails).

> Do you have a pointer to your driver anywhere so we could see if you are
> doing something odd with the cma interface?
>

The driver is part of the imx kernel from boundary devices and can be found 
here:

https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_4.1.15_2.0.0_ga/drivers/mxc/gpu-viv

The call to dma_alloc_writecombine (which eventually calls cma_alloc() if I am 
not
completely wrong) can be found in this file:

https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_4.1.15_2.0.0_ga/drivers/mxc/gpu-viv/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c

Note that I didn't write the driver, I am just using it (it seems to be a port 
from
another OS to Linux to me).

As you pointed out the solution would be to allocate the memory earlier in the
boot process, by modifying the driver. I will try that in the next few days and
let you know the result.

Best,

- Johannes


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

CMA question

[Johannes Thoma]

Dear Kernel hackers,

As far as I understood CMA (contiguous memory allocation) memory is used 
for other purposes as long it isn't requested via cma_alloc() by a 
driver. cma_alloc then tries to free the memory by relocating it and 
returns the contiguous area.

I have a case where cma_alloc() sometimes fails to relocate the memory 
which causes my driver (a GPU driver) to fail starting up (the driver is 
started when the system is running for a while). Is there a way to 
prevent the CM allocator to use the memory for any other purpose? Or 
should I better use another mechanism to allocate  contiguous memory at 
boot time (is there a framework for doing so)?

PS: I once had a patch which tries harder to relocate the pages (I 
patched cma_alloc()), but it didn't really work well, blocking the 
allocation for seconds.

Thanks for your advice,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

AW:dma direction

[Johannes Thoma]

It might have to do something with CPU caching, we once had an issue with a USB driver where memory got overwritten. But I also might be wrong don't have the code at hand at the moment.Best,Johannes Originalnachricht Betreff: dma directionVon: Ran Shalit An: kernelnewbies Cc: Hello,I read the DMA-API-HOWTOhttps://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txtWhich mainly talks about dma mapping APIs.But I don't understand what's the meaning of DMA direction in contextof mapping.As I understand this documentation talks about mapping of dma buffers- NOT about triggering dma copy.In order to do a dma copy, we should use sometlink like dmaengine, Right ?So if dma mapping is not concerned with copying dma from cpu to device(or vice versa), why does it talks about dma direction ?Thanks,Ran___Kernelnewbies mailing listKernelnewbies@kernelnewbies.orghttps://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] mm: cma: Retry from the beginning of cma area if all blocks are busy

[Johannes Thoma]

Am 06.01.17 um 18:30 schrieb valdis.kletni...@vt.edu:
> On Fri, 06 Jan 2017 18:12:41 +0100, Johannes Thoma said:
>
>> Am 06.01.17 um 17:54 schrieb valdis.kletni...@vt.edu:
>>> On Fri, 06 Jan 2017 17:16:11 +0100, johan...@johannesthoma.com said:
>
>>>> +  if (start != 0 && retries--) {
>>>
>>> Do we have any guarantee, or even good reason to believe, that this
>>> will eventually make forward progress, or can the goto hang everything?
>>> I'm not thrilled by a potentially unbounded loop inside a mutex_lock(),
>>> especially when you holding the mutex may be preventing something else
>>> from changing things so forward progress can be made
>>>
>> Good point. That is what the retries variable is good for. To make this
>> more obvious, I should write:
>
> No, you missed my point.
>
> We're inside a mutex_lock() region.  We hit the goto, and drive
> bitmap_find_next_zero_are_off() again.  How do we know that we're not
> just going to spin our wheels 10 times and fall out?  What will change
> the bitmap_find_next_zero_area_offset() result?
>
Correct me if I am wrong but setting start from a high value where
no more memory is free back to zero should change the result. The
scenario I had is:

start is 0 -> bitmap_find_next_zero_off succeeds
alloc_contig_range fails with -EBUSY
start is incremented by the size of the requested block
start is near the end of the area, hence bitmap_find_next_zero_off fails
(new) now we set start again back to 0, so
bitmap_find_next_zero_off succeeds again (it might also fail
if someone else just allocated memory in which case we have
to (and do) fail).
alloc_contig_range succeeds.

> Remember - there's a mutex_lock() around that call for a *reason*.  And
> I suspect the reason is specifically so nobody else *can* monkey with
> the cma area.
>
> How is this better than just dropping the mutex, doing an mdelay(), and
> then re-taking it?
>
That would be probably the best way to do it. I suspect you mean
something like:

 if (start != 0) {
 retries--;
 if (retries > 0) {
 mutex_unlock(>lock);
 mdelay(1);
 start = 0;
 mutex_lock(>lock);
 goto scan_again;
 }
 }

Hmm..it seems that that would require more work. Thank you for your
input,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] mm: cma: Retry from the beginning of cma area if all blocks are busy

[Johannes Thoma]

Hi Vladis,

Thanks for your quick reply.

Am 06.01.17 um 17:54 schrieb valdis.kletni...@vt.edu:
> On Fri, 06 Jan 2017 17:16:11 +0100, johan...@johannesthoma.com said:
>> From: Johannes Thoma <johan...@johannesthoma.com>
>
>> This patch introduces a little extra loop that causes cma_alloc to
>> rescan from the beginning when all checked memory areas are busy.
>
>>  for (;;) {
>>  mutex_lock(>lock);
>> +scan_again:
>>  bitmap_no = bitmap_find_next_zero_area_off(cma->bitmap,
>>  bitmap_maxno, start, bitmap_count, mask,
>>  offset);
>>  if (bitmap_no >= bitmap_maxno) {
>
> It worries me that a few lines above, we have
>
> if (bitmap_count > bitmap_maxno)
>   return NULL;
>
> In this case, is >= correct rather than > ?
>
That might be the case, but would be an extra patch.

>> + * Restart from the beginning if all areas were busy.
>> + * This handles false failures when count is close
>> + * to overall CMA size and the checked areas were
>> + * busy temporarily.
>> + */
>> +if (start != 0 && retries--) {
>
> Do we have any guarantee, or even good reason to believe, that this
> will eventually make forward progress, or can the goto hang everything?
> I'm not thrilled by a potentially unbounded loop inside a mutex_lock(),
> especially when you holding the mutex may be preventing something else
> from changing things so forward progress can be made
>
Good point. That is what the retries variable is good for. To make this
more obvious, I should write:


 if (start != 0) {
 retries--;
 if (retries > 0) {
 start = 0;
 goto scan_again;
 }
 }

(with
 int retries = 10;
at the beginning of the function).

Agreed
if (start != 0 && retries--) {
isn't good coding style.

That should restrict it to a maximum of 10 iterations. This could be
lowered if the size requested is smaller.

Best,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

CMA patch

[Johannes Thoma]

Dear Kernel hackers,

I've just sent out a patch for a proposal of an improvement of the
cma allocator. Since I am not an experienced patch submitter, could
someone maybe have a look at it before I submit it to the maintainers?
I might have done formal errors (I've ran checkpatch and used git
send-email but maybe I forgot something).

Thanks a lot,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: linux-mm mailing list

[Johannes Thoma]

Hi Greg,

Thanks for the quick reply. If that is ok I will post the patch to
kernel newbies first once it is ready.

Am 06.01.17 um 16:30 schrieb Greg KH:
> $ ./scripts/get_maintainer.pl --file mm/cma.c

Best,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

linux-mm mailing list

[Johannes Thoma]

Hi Kernel hackers,

I have a proposal for an improvement of the CMA allocator (just about 5 
lines of code to make it more robust). I would like to send it to
the linux-mm mailing list (linux...@kvack.org according to MAINTAINERS),
but it seems to be inactive. What is the best way to reach the
maintainer of mm/cma.c ?

Thanks a lot,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

AW:insmod failing to insert a simple module

[Johannes Thoma]

Typeuname -aon the box where you try the insmod. If it says anything else than 4.0.5-rc7+ for the kernel version then this is the reason why insmod fails.BestJohannes___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Getting stacktrace for userspace applications on crash(SIGSEGV)

[Johannes Thoma]

Hi,

Am 10.09.16 um 05:18 schrieb Daniel.:
> Yeap it is. The protocol takes 4 threads the other are user's threads.
> Still, when getting some core dump and fatal error log I was expecting
> to get backtrace from the thread responsible for the segmentation
> fault? Am I wrong?
AFAIK a signal (like SIGSEGV) is always sent to the whole process not to
a specific thread. Therefore gdb cannot know which thread caused the
segfault (except if it would analyse the assembly which it doesn't). So,
unfortunately you'll have to find the misbehaving thread by yourself ..

Best,

- Johannes
> Thanks for the help and best regards!!!
;)


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

AW:Getting stacktrace for userspace applications on crash(SIGSEGV)

[Johannes Thoma]

Hi,Is it a multi threading application? Type info threads in gdb to find out. With thread threadnumyou can switch between threads and then display the other backtraces with btHope that helps.BestJohannes___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Minimum build config for boot messages

[Johannes Thoma]

Hi,

Am 19.08.16 um 16:17 schrieb Andre Schmidt:
 > Hello,
 >
 > what is the minimum config to build a linux kernel that just prints 
boot messages/errors?
 >
 > I was going through my old experiments/notes and found that we used 
to get kernel boot message with vanilla allnoconfig.
 >
 > make ARCH=x86_64 allnoconfig
 > make all
 > qemu-system-x86_64 -kernel arch/x86/boot/bzImage
 >
 > Those commands above used to be enough, but now the produced kernel 
doesn't print any messages on the qemu screen.
 >

Did you also disable CONFIG_PRINTK ? Without that kernel will not print 
anything, as far as I know.

HTH,

Best,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] HC-SR04 ultrasonic ranger IIO driver

[Johannes Thoma]

Dear List,

I've ported my hc-sr04 driver to IIO now and wanted to ask if it is ok 
to post it to the
main kernel list (or some other list?) like this (see original mail, 
sent with git send-mail).

Thanks a lot,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Finding GPIO names under Linux

[Johannes Thoma]

Dear list,

I am writing a driver which uses the "new" descriptor interface of the 
GPIO library. As far as I have understood it, gpiod_get(8) is the way to 
allocate (and also lock?) GPIOs pins for use. My question is how do I 
find what to pass as the con_id parameter (this should identify the pin 
but please correct me if I am wrong, in that case how to I tell 
gpiod_get which pin I want?). Is there a file somewhere where I can find 
the pin names of my hardware (which is a raspberry 1 for now), something 
like /sys/class/gpio/xxx/gpio_pin_names or so, or do I have to look them 
up in the device tree or somewhere else? Or do I have to
configure the pin somewhere in the device tree? What I would like to
do is offer an interface (via configfs) where the pins the sensor is
attached can be configured dynamically at run-time.

The driver itself is OpenSource (GPL) and can be obtained at

http://github.com/johannesthoma/linux-hc-sro4

(iio branch is currently the dev branch where this problem occurs).

Thanks a lot,

- Johannes



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] misc devices: HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

Dear Greg, dear Daniel,

Thank you for your suggestions,  I will port the driver to IIO layer as
you suggested and then get back (may take some days).  I will also use 
git-send-mail, since that seems to be the best way to do it.

Am 24.03.16 um 16:52 schrieb Daniel Baluta:
> On Thu, Mar 24, 2016 at 5:02 PM, Johannes Thoma
> <johan...@johannesthoma.com> wrote:
>>   From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001
>> From: Johannes Thoma <johan...@johannesthoma.com>
>> Date: Mon, 21 Mar 2016 22:11:01 +0100
>> Subject: [PATCH] HC-SRO4 ultrasonic distance sensor driver
>>
>> The HC-SRO4 is an ultrasonic distance sensor attached to two GPIO
>> pins. The driver is controlled via sysfs and supports an (in theory)
>> unlimited number of HC-SRO4 devices.
>>
>> Unlike user land solutions this driver produces precise results
>> even when there is high load on the system. It uses a non-blocking
>> interrupt triggered mechanism to record the length of the echo
>> signal.
>
> Add link to datasheet.

One location is:

http://www.micropik.com/PDF/HCSR04.pdf

>>
>> This patch is against the raspberry pi kernel from
>> https://github.com/raspberrypi/linux.git hash
>> e481b5ceae6c94c7e60f8bb8591cbb362806246e
>>
>> Note that this patch isn't meant for lkml (yet) see:
>> TODO's:
>>
>> .) Patch against mainline (or whatever kernel it belongs to)
>> .) Use IIO layer instead of creating random sysfs entries.
>
> So, why aren't you directly using IIO? :)
>
I will but I just got the hint from greg that I should do
so (didn't know about it ;).

all the best,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[PATCH] misc devices: HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

 From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001
From: Johannes Thoma <johan...@johannesthoma.com>
Date: Mon, 21 Mar 2016 22:11:01 +0100
Subject: [PATCH] HC-SRO4 ultrasonic distance sensor driver

The HC-SRO4 is an ultrasonic distance sensor attached to two GPIO
pins. The driver is controlled via sysfs and supports an (in theory)
unlimited number of HC-SRO4 devices.

Unlike user land solutions this driver produces precise results
even when there is high load on the system. It uses a non-blocking
interrupt triggered mechanism to record the length of the echo
signal.

This patch is against the raspberry pi kernel from
https://github.com/raspberrypi/linux.git hash
e481b5ceae6c94c7e60f8bb8591cbb362806246e

Note that this patch isn't meant for lkml (yet) see:
TODO's:

.) Patch against mainline (or whatever kernel it belongs to)
.) Use IIO layer instead of creating random sysfs entries.
.) Fill in GPIO device as parent to device_create_with_groups().
.) Test it with two or more HC-SRO4 devices.
.) Test it on other hardware than raspberry pi.
.) Test it with kernel debugging enabled.

Anyway, comments are highly appreciated.

Signed-off-by: Johannes Thoma <johan...@johannesthoma.com>
---
  MAINTAINERS|   5 +
  drivers/misc/Kconfig   |  11 ++
  drivers/misc/Makefile  |   1 +
  drivers/misc/hc-sro4.c | 360
+
  4 files changed, 377 insertions(+)
  create mode 100644 drivers/misc/hc-sro4.c

diff --git a/MAINTAINERS b/MAINTAINERS
index da3e4d8..f819d66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4910,6 +4910,11 @@ W:
http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
  S:Maintained
  F:drivers/platform/x86/hdaps.c

+HC-SRO4 ULTRASONIC DISTANCE SENSOR DRIVER
+M:     Johannes Thoma <johan...@johannesthoma.com>
+S: Maintained
+F: drivers/misc/hc-sro4.c
+
  HDPVR USB VIDEO ENCODER DRIVER
  M:Hans Verkuil <hverk...@xs4all.nl>
  L:linux-me...@vger.kernel.org
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4c499de..1be88ad 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -475,6 +475,17 @@ config BMP085_SPI
  To compile this driver as a module, choose M here: the
  module will be called bmp085-spi.

+config SENSORS_HC_SRO4
+   tristate "HC-SRO4 ultrasonic distance sensor on GPIO"
+   depends on GPIOLIB && SYSFS
+   help
+ Say Y here if you want to support the HC-SRO4
+ ultrasonic distance sensor to be hooked on two runtime-configurable
+ GPIO pins.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hc-sro4.
+
  config PCH_PHUB
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
select GENERIC_NET_UTILS
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 1acff5b..9a8e508 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_COINCELL)   += qcom-coincell.o
  obj-$(CONFIG_SENSORS_BH1780)  += bh1780gli.o
  obj-$(CONFIG_SENSORS_BH1770)  += bh1770glc.o
  obj-$(CONFIG_SENSORS_APDS990X)+= apds990x.o
+obj-$(CONFIG_SENSORS_HC_SRO4)  += hc-sro4.o
  obj-$(CONFIG_SGI_IOC4)+= ioc4.o
  obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
  obj-$(CONFIG_KGDB_TESTS)  += kgdbts.o
diff --git a/drivers/misc/hc-sro4.c b/drivers/misc/hc-sro4.c
new file mode 100644
index 000..9925b7e
--- /dev/null
+++ b/drivers/misc/hc-sro4.c
@@ -0,0 +1,360 @@
+/* Precise measurements of time delta between sending a trigger signal
+ * to the HC-SRO4 distance sensor and receiving the echo signal from
+ * the sensor back. This has to be precise in the usecs range. We
+ * use trigger interrupts to measure the signal, so no busy wait :)
+ *
+ * This supports an (in theory) unlimited number of HC-SRO4 devices.
+ * To add a device, do a (as root):
+ *
+ * # echo 23 24 1000 > /sys/class/distance-sensor/configure
+ *
+ * (23 is the trigger GPIO, 24 is the echo GPIO and 1000 is a timeout in
+ *  milliseconds)
+ *
+ * Then a directory appears with a file measure in it. To measure, do a
+ *
+ * # cat /sys/class/distance-sensor/distance_23_24/measure
+ *
+ * You'll receive the length of the echo signal in usecs. To convert
(roughly)
+ * to centimeters multiply by 17150 and divide by 1e6.
+ *
+ * To deconfigure the device, do a
+ *
+ * # echo -23 24 > /sys/class/distance-sensor/configure
+ *
+ * (normally not needed).
+ *
+ * DO NOT attach your HC-SRO4's echo pin directly to the raspberry, since
+ * it runs with 5V while raspberry expects 3V on the GPIO inputs.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct hc_sro4 {
+   int gpio_trig;
+   int gpio_echo;
+   struct gpio_desc *trig_desc;
+   struct g

Re: 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 <a...@arndb.de> and Greg Kroah-Hartman
>> <gre...@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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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  and Greg Kroah-Hartman 
) 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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies