Re: Kernelnewbies Digest, Vol 15, Issue 12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I want to contribute to camera drivers in linux kernel.Please guide me the procedure of doing that.

Regards,
Mayank

On Tue, Feb 7, 2012 at 10:30 PM, <kernelnewbies-request@xxxxxxxxxxxxxxxxx> wrote:
Send Kernelnewbies mailing list submissions to
       kernelnewbies@xxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
or, via email, send a message with subject or body 'help' to
       kernelnewbies-request@xxxxxxxxxxxxxxxxx

You can reach the person managing the list at
       kernelnewbies-owner@xxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kernelnewbies digest..."


Today's Topics:

  1. Re: "Trying to free already-free IRQ 9", but it wasn't freed
     by me (mayur nande)
  2. Re: request_firmware question (Greg KH)
  3. Re: fork() and exec() (Bernd Petrovitsch)
  4. Re: make config errors while building kernel on Fedora 16
     (Kartik Singhal)


----------------------------------------------------------------------

Message: 1
Date: Tue, 7 Feb 2012 20:33:31 +0530
From: mayur nande <mayur.nan@xxxxxxxxx>
Subject: Re: "Trying to free already-free IRQ 9", but it wasn't freed
       by me
To: "nils.stec" <nils.stec@xxxxxxxxxxxxxx>
Cc: kernelnewbies <Kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
       <CA+fM3Xy2QALrjbTYJxW0yKn-Q-Y99Wi8xUyyWtKEzYDTByTkjQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Hi Nils,

>>void cleanup_module(void) {
 >>   ...
 >>  free_irq(ADC_IRQ, NULL);        /* remove interrupt handler */
 >>  ...
 >>   return;
>>}

You should not pass NULL here. It should be the unique cookie that you
passed in request_irq (adc_irq_handler in your case) since you have used
IRQF_SHARED which means you want to share your interrupt line. Also check
whether you really want to share your interrupt line and also if you want
to use "(void *)(adc_irq_handler)" as the unique identification.

HTH!

Regards
Mayur

On Tue, Feb 7, 2012 at 7:45 PM, nils.stec <nils.stec@xxxxxxxxxxxxxx> wrote:

>  Hi,
>
> atm I'm writing a kernel module for an embedded ARM device.
> This module uses IRQ9.
>
> If i remove the module, the kernel tells me that:
>
> ------------[ cut here ]------------
> WARNING: at kernel/irq/manage.c:858 __free_irq+0x84/0x154()
> Trying to free already-free IRQ 9
> Modules linked in: adc_demo_irq(P-) g_ether pegasus mii
> [<c0028794>] (unwind_backtrace+0x0/0xd0) from [<c003b504>]
> (warn_slowpath_common+0x48/0x60)
> [<c003b504>] (warn_slowpath_common+0x48/0x60) from [<c003b554>]
> (warn_slowpath_fmt+0x24/0x30)
> [<c003b554>] (warn_slowpath_fmt+0x24/0x30) from [<c005fa00>]
> (__free_irq+0x84/0x154)
> [<c005fa00>] (__free_irq+0x84/0x154) from [<c005fb0c>]
> (free_irq+0x3c/0x5c)
> [<c005fb0c>] (free_irq+0x3c/0x5c) from [<bf01e18c>]
> (cleanup_module+0x4c/0x60 [adc_demo_irq])
> [<bf01e18c>] (cleanup_module+0x4c/0x60 [adc_demo_irq]) from [<c005b898>]
> (sys_delete_module+0x1c4/0x238)
> [<c005b898>] (sys_delete_module+0x1c4/0x238) from [<c0022dc0>]
> (ret_fast_syscall+0x0/0x28)
> ---[ end trace 60d7a16d878ac0b3 ]---
> adc testing module removed
> ------------[ cut here ]------------
>
> The message "adc testing module removed" comes from my module **after**free_irq() via printk, so the module exit routine works till the end.
>
> This is my code (only the IRQ related part):
>
> irqreturn_t adc_irq_handler(int irq, void *dev_id) {
>
>     ... do someting ...
>
>     return IRQ_HANDLED;
> }
>
> int init_module(void) {
>     int32_t retval;
>     ...
>     retval = request_irq(ADC_IRQ, adc_irq_handler, IRQF_SHARED, "lpc313x
> adc irq", (void *)(adc_irq_handler));
>     ...
>     return retval;
> }
>
> void cleanup_module(void) {
>     ...
>     free_irq(ADC_IRQ, NULL);        /* remove interrupt handler */
>     ...
>     return;
> }
>
>
> I hope anyone of you can help me with that problem. If you need more
> information, i'll send it
>
> Greetings,
> Nils
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120207/79cf9412/attachment-0001.html

------------------------------

Message: 2
Date: Tue, 7 Feb 2012 07:07:50 -0800
From: Greg KH <greg@xxxxxxxxx>
Subject: Re: request_firmware question
To: anish kumar <anish198519851985@xxxxxxxxx>
Cc: Kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID: <20120207150750.GA7583@xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Tue, Feb 07, 2012 at 12:51:42AM -0800, anish kumar wrote:
> Hi,
>
> Now I have switched to using request_firmware api
> and after using firmware, memory is being released.
> Does it save kernel memory compare to case when
> I am having a having a local static firmware buffer(very big)
> from which I used to get the firmware and write it
> to the chip?
>
> As I know request_firmware api has several advantages
> but what I want to know is the advantages related
> to kernel memory footprint.

Yes it is, as well as using the "proper" api for firmware loading, which
means it fits into the rest of the kernel correctly.

Also, no new drivers will be accepted that have static firmware blobs.

greg k-h



------------------------------

Message: 3
Date: Tue, 07 Feb 2012 16:40:13 +0100
From: Bernd Petrovitsch <bernd@xxxxxxxxxxxxxxxxxxx>
Subject: Re: fork() and exec()
To: Vijay Chauhan <kernel.vijay@xxxxxxxxx>
Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID: <1328629213.25984.123.camel@thorin>
Content-Type: text/plain; charset="UTF-8"

On Die, 2012-02-07 at 00:38 +0530, Vijay Chauhan wrote:
> Hi List,
>
> I am learning Linux and trying to understand exec and fork function.
> execl says that it overlays the running address space. What does it mean?
>
> I created the following program and used top command with
> intentionally wrong arguments:
>
> #include<stdio.h>
> #include<unistd.h>
> #include<sys/types.h>
> #include<stdlib.h>
>
> int main(){
>       int a = -1;
>       if(fork()==0){
>               printf("Inside child\n");
>               printf("child pid=%d, parentid=%d\n", getpid(), getppid());
>               execl("/usr/bin/top", "/usr/bin/top", ">/dev/null" ,(char*)0 );

You get here only if the execl() as such fails.

>               scanf("inside child provide a %d", &a);

You should check the return value here if you actually got a matching
parameter.
scanf() is actually a function to be avoided.

>               printf("Inside child a=%d\n", a);
>               exit(1);
>       } else {
>               printf("Inside parent, going to wait\n");
>               printf("my pid=%d, parentid=%d\n", getpid(), getppid());
>               scanf("input parent %d\n", &a);

You should check the return value here if you actually got a matching
parameter.
scanf() is actually a function to be avoided.

>               wait(NULL);

You should check the return value here to know why "wait()" returns.

>               printf("Wait over\n");
>               printf("Inside parent a=%d\n", a);
>       }
>       return 0;
> }

       Bernd
--
Bernd Petrovitsch                  Email : bernd@xxxxxxxxxxxxxxxxxxx
                    LUGA : http://www.luga.at




------------------------------

Message: 4
Date: Tue, 7 Feb 2012 22:10:46 +0530
From: Kartik Singhal <kartiksinghal@xxxxxxxxx>
Subject: Re: make config errors while building kernel on Fedora 16
To: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>
Cc: Kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID:
       <CAAY3Td5UJYmtqM5mzkBHug5bfMx0q5CoBd5CowtDNTdVrTORTQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

On Mon, Feb 6, 2012 at 1:05 PM, Mulyadi Santosa
<mulyadi.santosa@xxxxxxxxx>wrote:

> have you check their checksums?


Is there a way to verify the checksums for git clones as in my case?

--
Kartik
http://k4rtik.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120207/3ff99cbf/attachment-0001.html

------------------------------

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


End of Kernelnewbies Digest, Vol 15, Issue 12
*********************************************

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

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux