<div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername"></b> <span dir="ltr"><<a href="mailto:kernelnewbies-request@kernelnewbies.org">kernelnewbies-request@kernelnewbies.org</a>></span><br>Date: Mon, Mar 23, 2015 at 9:30 PM<br>Subject: Kernelnewbies Digest, Vol 52, Issue 41<br>To: <a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a><br><br><br>Send Kernelnewbies mailing list submissions to<br>
<a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:kernelnewbies-request@kernelnewbies.org">kernelnewbies-request@kernelnewbies.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:kernelnewbies-owner@kernelnewbies.org">kernelnewbies-owner@kernelnewbies.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Kernelnewbies digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Delaying an interrupt handler (Daniel Baluta)<br>
2. Re: Sysfs requirement for running generic_buffer.c<br>
application - IIO sensors (Daniel Baluta)<br>
3. Re: Delaying an interrupt handler (Milton Krutt)<br>
4. Re: Get Back Into Kernel Work (el_es)<br>
5. Re: Sysfs requirement for running generic_buffer.c<br>
application - IIO sensors (s.rawat)<br>
6. Re: Get Back Into Kernel Work (Nicholas Krause)<br>
7. Re: Writing driver for a net device which does not support<br>
interrupt (<a href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 23 Mar 2015 14:46:51 +0200<br>
From: Daniel Baluta <<a href="mailto:daniel.baluta@gmail.com">daniel.baluta@gmail.com</a>><br>
Subject: Re: Delaying an interrupt handler<br>
To: Milton Krutt <<a href="mailto:milton@krutt.org">milton@krutt.org</a>><br>
Cc: Kernelnewbies <<a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a>><br>
Message-ID:<br>
<CAEnQRZDQrnNjxKtDSqmmA+QFHYJbXoWWE=<a href="mailto:cHEPVE7LOLHA31Uw@mail.gmail.com">cHEPVE7LOLHA31Uw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <<a href="mailto:milton@krutt.org">milton@krutt.org</a>> wrote:<br>
> Hi.<br>
> It is known that no semaphore synchronization should be<br>
> used inside an interrupt handler.<br>
><br>
> Anyway, I am looking at a freeBSD device driver (written by<br>
> a profesionist) and there are semaphores inside an interrupt<br>
> handler's subroutine.<br>
><br>
> Since I should port to linux that driver, I ask you how can I<br>
> reach such synchronization under linux; I tried to use semaphores<br>
> inside my handler but I got complains, and I don't want to break<br>
> the law, so no semaphores for me.<br>
<br>
Perhaps spinlocks could be the solution :).<br>
<br>
2.6.10 please no - :), Linux kernel is now at 4.0.<br>
<br>
Daniel.<br>
</div><div class="gmail_quote"><br></div><div class="gmail_quote">Hi Daniel,</div><div class="gmail_quote"> Its us legitimate to use semaphore inside the interrupt handler but the only thing what should not be done is to _acquire_ it from within. Releasing is perfectly all right.</div><div class="gmail_quote">By the way what is done within the interrupt handler in the code written by professional? release ?? acquire??<br>
<br>
Vishwas<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 23 Mar 2015 15:40:39 +0200<br>
From: Daniel Baluta <<a href="mailto:daniel.baluta@gmail.com">daniel.baluta@gmail.com</a>><br>
Subject: Re: Sysfs requirement for running generic_buffer.c<br>
application - IIO sensors<br>
To: "s.rawat" <<a href="mailto:imsaurabhrawat@gmail.com">imsaurabhrawat@gmail.com</a>><br>
Cc: "<a href="mailto:linux-iio@vger.kernel.org">linux-iio@vger.kernel.org</a>" <<a href="mailto:linux-iio@vger.kernel.org">linux-iio@vger.kernel.org</a>>,<br>
kernelnewbies <<a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a>><br>
Message-ID:<br>
<CAEnQRZDmYTzZPyMiO=0SMo=<a href="mailto:d1k3s_Dj-T7u7Jw696dz1c5uRJA@mail.gmail.com">d1k3s_Dj-T7u7Jw696dz1c5uRJA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Mon, Mar 23, 2015 at 7:27 AM, s.rawat <<a href="mailto:imsaurabhrawat@gmail.com">imsaurabhrawat@gmail.com</a>> wrote:<br>
> I have two system having different kernel version and drivers(IIO) on which<br>
> i can run the generic_buffer.c application .On one system it works fine but<br>
> on the other it does not give the input reports data.<br>
<br>
What kernel versions are you using? Why are you using different drivers? :D<br>
<br>
thanks,<br>
Daniel.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 23 Mar 2015 06:46:23 -0700<br>
From: Milton Krutt <<a href="mailto:milton@krutt.org">milton@krutt.org</a>><br>
Subject: Re: Delaying an interrupt handler<br>
To: <a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a><br>
Message-ID: <20150323134622.GA4933@debian><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
> On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <<a href="mailto:milton@krutt.org">milton@krutt.org</a>> wrote:<br>
> > Hi.<br>
> > It is known that no semaphore synchronization should be<br>
> > used inside an interrupt handler.<br>
> ><br>
> > Anyway, I am looking at a freeBSD device driver (written by<br>
> > a profesionist) and there are semaphores inside an interrupt<br>
> > handler's subroutine.<br>
> ><br>
> > Since I should port to linux that driver, I ask you how can I<br>
> > reach such synchronization under linux; I tried to use semaphores<br>
> > inside my handler but I got complains, and I don't want to break<br>
> > the law, so no semaphores for me.<br>
><br>
> Perhaps spinlocks could be the solution :).<br>
><br>
> 2.6.10 please no - :), Linux kernel is now at 4.0.<br>
><br>
> Daniel.<br>
<br>
Yes and no. The routine the int. handler's delay depends on has to<br>
make some non atomic work. So if I lock a spinlock and then I do some<br>
"lengthy" (i.e. non atomic) job, then I get a warning message like<br>
"spinlock held while being preempted" (or similar). In symbols, you suggest<br>
something like<br>
<br>
process P{<br>
<br>
spin_lock(lock);<br>
non_atomic_function();<br>
spin_unlock(lock);<br>
<br>
}<br>
<br>
int. handler {<br>
<br>
spin_lock(lock);<br>
do_things(); /* preferably atomically */<br>
spin_unlock(lock);<br>
<br>
}<br>
<br>
My first attempt is still to avoid both semaphores and the above remedy,<br>
in order to delay the int. handler up to a desired point.<br>
<br>
Thanks!<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 23 Mar 2015 13:51:30 +0000 (UTC)<br>
From: el_es <<a href="mailto:el.es.cr@gmail.com">el.es.cr@gmail.com</a>><br>
Subject: Re: Get Back Into Kernel Work<br>
To: <a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a><br>
Message-ID: <<a href="mailto:loom.20150323T144133-770@post.gmane.org">loom.20150323T144133-770@post.gmane.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Nicholas Krause <xerofoify <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
<br>
><br>
> I have listened to peoples feedback. Am I still missing something<br>
> as I now do<br>
> 1. Build test all patches<br>
> 2. Reading the code properly<br>
> 3.Testing my patches<br>
> 4.Listening to feedback<br>
> Nick<br>
><br>
[trim]<br>
<br>
Insert this:<br>
<br>
X. Do My Own Research First, THEN ask questions<br>
<br>
preferably at X = 0, 2, 4, 6, 8 of the above list.<br>
<br>
Read a few netiquette/'how to write questions smart' manuals<br>
to learn how to let people /know/ you did your research.<br>
<br>
If your school work gets in the way though,<br>
it probably means it's much more important and you<br>
should not miss it.<br>
<br>
Cheers,<br>
<br>
CHSMBIDWT/MSPANC.<br>
<br>
el es<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 23 Mar 2015 20:22:30 +0530<br>
From: "s.rawat" <<a href="mailto:imsaurabhrawat@gmail.com">imsaurabhrawat@gmail.com</a>><br>
Subject: Re: Sysfs requirement for running generic_buffer.c<br>
application - IIO sensors<br>
To: Daniel Baluta <<a href="mailto:daniel.baluta@gmail.com">daniel.baluta@gmail.com</a>><br>
Cc: "<a href="mailto:linux-iio@vger.kernel.org">linux-iio@vger.kernel.org</a>" <<a href="mailto:linux-iio@vger.kernel.org">linux-iio@vger.kernel.org</a>>,<br>
kernelnewbies <<a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a>><br>
Message-ID:<br>
<CALwa49t7WB_KhE5o7d=B3vJXwd+=<a href="mailto:ctwU0_Rv6j93uHK5665F0A@mail.gmail.com">ctwU0_Rv6j93uHK5665F0A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
kernel version is 3.10.20 ,<br>
drivers are hid-sensor-* driver. (hid-accel-3d,hid-gyro-3d,etc.) for<br>
different sensors.I have two different devices having two different<br>
kernels,Just wanted to know the difference technically why one is not<br>
working.<br>
<br>
On Mon, Mar 23, 2015 at 7:10 PM, Daniel Baluta <<a href="mailto:daniel.baluta@gmail.com">daniel.baluta@gmail.com</a>><br>
wrote:<br>
<br>
> On Mon, Mar 23, 2015 at 7:27 AM, s.rawat <<a href="mailto:imsaurabhrawat@gmail.com">imsaurabhrawat@gmail.com</a>> wrote:<br>
> > I have two system having different kernel version and drivers(IIO) on<br>
> which<br>
> > i can run the generic_buffer.c application .On one system it works fine<br>
> but<br>
> > on the other it does not give the input reports data.<br>
><br>
> What kernel versions are you using? Why are you using different drivers? :D<br>
><br>
> thanks,<br>
> Daniel.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/13fdc553/attachment-0001.html" target="_blank">http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/13fdc553/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 23 Mar 2015 11:04:57 -0400<br>
From: Nicholas Krause <<a href="mailto:xerofoify@gmail.com">xerofoify@gmail.com</a>><br>
Subject: Re: Get Back Into Kernel Work<br>
To: el_es <<a href="mailto:el.es.cr@gmail.com">el.es.cr@gmail.com</a>>,<a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a><br>
Message-ID: <<a href="mailto:083A04E5-C995-425F-A4F8-ED164A87827A@gmail.com">083A04E5-C995-425F-A4F8-ED164A87827A@gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
<br>
On March 23, 2015 9:51:30 AM EDT, el_es <<a href="mailto:el.es.cr@gmail.com">el.es.cr@gmail.com</a>> wrote:<br>
>Nicholas Krause <xerofoify <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
><br>
>><br>
>> I have listened to peoples feedback. Am I still missing something<br>
>> as I now do<br>
>> 1. Build test all patches<br>
>> 2. Reading the code properly<br>
>> 3.Testing my patches<br>
>> 4.Listening to feedback<br>
>> Nick<br>
>><br>
>[trim]<br>
><br>
>Insert this:<br>
><br>
>X. Do My Own Research First, THEN ask questions<br>
><br>
>preferably at X = 0, 2, 4, 6, 8 of the above list.<br>
><br>
>Read a few netiquette/'how to write questions smart' manuals<br>
>to learn how to let people /know/ you did your research.<br>
><br>
>If your school work gets in the way though,<br>
>it probably means it's much more important and you<br>
>should not miss it.<br>
><br>
>Cheers,<br>
><br>
>CHSMBIDWT/MSPANC.<br>
><br>
>el es<br>
><br>
><br>
That makes sense and I am doing my own research now. Furthermore I am able to handle my school work in top of kernel programming.<br>
Nick<br>
>_______________________________________________<br>
>Kernelnewbies mailing list<br>
><a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
><a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br>
--<br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Mon, 23 Mar 2015 11:51:45 -0400<br>
From: <a href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a><br>
Subject: Re: Writing driver for a net device which does not support<br>
interrupt<br>
To: Freeman Zhang <<a href="mailto:freeman.zhang1992@gmail.com">freeman.zhang1992@gmail.com</a>><br>
Cc: Kernel Newbies <<a href="mailto:kernelnewbies@kernelnewbies.org">kernelnewbies@kernelnewbies.org</a>><br>
Message-ID: <<a href="mailto:53058.1427125905@turing-police.cc.vt.edu">53058.1427125905@turing-police.cc.vt.edu</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Mon, 23 Mar 2015 18:51:51 +0800, Freeman Zhang said:<br>
> I'm writing a net device driver for my final project in college. But the<br>
> half-finished device doesn't support interrupt yet(those hardware guys...)<br>
><br>
> So I'm wondering if there is some way to poll the device for its status<br>
> and events.<br>
<br>
As a realistic datapoint - if it still doesn't support interrupts, the *rest*<br>
of it is probably still so buggy that trying to write a driver isn't worth<br>
the effort.<br>
<br>
It's doable if you are working with a group of talented and experienced<br>
engineers - but if the hardware is also being done as a final project,<br>
you're in for naught but misery.<br>
<br>
You *could* do something like this:<br>
<br>
while (waiting) {<br>
status = read_status_bits(your_device);<br>
if (status & DATA_AVAIL_MASK) break;<br>
msleep(100);<br>
}<br>
<br>
But having seen enough student hardware design projects in my life, I estimate<br>
that if it still can't signal interrupts, the status bits probably aren't valid<br>
either. (Think about it - a bog-simple implementation of interrupts would be<br>
to just feed a transition-high on the appropriate status bit to the interrupt<br>
pin, and use a read from the chip to clear the pin).<br>
<br>
Good luck - I suspect you're going to need it....<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 848 bytes<br>
Desc: not available<br>
Url : <a href="http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/d9f1295d/attachment-0001.bin" target="_blank">http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/d9f1295d/attachment-0001.bin</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br>
<br>
End of Kernelnewbies Digest, Vol 52, Issue 41<br>
*********************************************<br>
</div><br></div>