Hi Greg KH and all,
I found how to find the irq number in my case! (char driver kernel module)
I want to share it for reference to others.
add these two header files for this.
#include <linux/irq.h>
#include <linux/irqdesc.h>
extern struct irq_desc *irq_to_desc(unsigned int irq);
struct irq_desc *desc;
in the module _init function :
// find my irq number
for(i=0;i<NR_IRQS;i++){
desc = irq_to_desc(i);
if (desc) {
//printk("irq_desc(%d)->irq_data.hwirq = %ld\n", i,
desc->irq_data.hwirq);
if (desc->irq_data.hwirq == 47) break; // 47 is the hwirq
number, (SPI 15)
}
}
if (i == NR_IRQS) {
printk("couldn't find irq number..\n");
goto r_device;
}
ret = request_irq(i, axpu_irq_handler, IRQF_SHARED, "axpu_irq",
&axpu_cdev);
This way I could find the correct irq number on ubuntu and vanilla linux.
Hope this is helpful to someone. (anyway you know the hardware connection so
you can use it)
Thank you!
Chan Kim
> -----Original Message-----
> From: Chan Kim <ckim@xxxxxxxxxx>
> Sent: Tuesday, April 12, 2022 1:55 PM
> To: 'Greg KH' <greg@xxxxxxxxx>
> Cc: kernelnewbies@xxxxxxxxxxxxxxxxx; 'qemu-discuss' <qemu-
> discuss@xxxxxxxxxx>
> Subject: RE: Can't understand /proc/interrupts output for GICv3 case
>
> Hi Greg KH,
> I see, I understand what the proper method should be for this.
> I'll take it as an almost official answer from the linux people :) Thank
> you.
> Chan Kim
>
> > -----Original Message-----
> > From: 'Greg KH' <greg@xxxxxxxxx>
> > Sent: Tuesday, April 12, 2022 1:50 PM
> > To: Chan Kim <ckim@xxxxxxxxxx>
> > Cc: 'qemu-discuss' <qemu-discuss@xxxxxxxxxx>;
> > kernelnewbies@xxxxxxxxxxxxxxxxx
> > Subject: Re: Can't understand /proc/interrupts output for GICv3 case
> >
> > On Tue, Apr 12, 2022 at 11:18:03AM +0900, Chan Kim wrote:
> > > > You can replace all of the above code by just using the miscdevice
> > > > interface instead. Please use that, it ensures that you do
> > > > everything properly and simplifies it all.
> >
> > Again, use the misc device api please.
> >
> > > > > vaddr = ioremap(AXPU_BASE, 0x80000);
> > > >
> > > > Wait, where are you picking those random values from?
> > >
> > > Yes, it now looks weird to me. I have passed the register address
> > > information in the device tree and the kernel already knows my
> > > device's address range. Then, how should I get this virtual io
> > > address in this driver? I need it to access some registers. How can
> > > I ask the
> > system bus?
> >
> > Use a platform driver and bind your driver to that device based on
> > that api.
> >
> > > And my driver is a kernel module because I want to use it in
> > > ubuntu-20.04 on a virtual machine, I want it to be a kernel module
> > > that I can insmod or rmmod.(actually my job is to provide this
> > > virtual
> > machine to some folks).
> > > And I cannot build the ubuntu image even if I change it to a
> > > platform device driver and add it in the kernel tree.
> >
> > This all does not matter, just write a proper platform driver and all
> > will be fine.
> >
> > > > > ret = request_irq(6, axpu_irq_handler, IRQF_SHARED,
> "axpu_irq",
> > > > > &axpu_cdev);
> > > >
> > > > Same for that, just picking 6 will not work, sorry.
> > > >
> > >
> > > Yes, that was my original question. How can I get my irq number (I
> > > know it's hwirq 47) and I peeked into kernel that irq 6 was assigned
> > > for
> > the irq_desc.
> > > So I changed my driver to request irq 6 for my device and I found at
> > > least it works for now, all the register access and interrupts. I
> > > know this is not the solution and I'm curious how I should get the
> > > irq number of io virtual address in this situation.
> >
> > Again, the platform driver interface will provide you with the needed
> > information. We have thousands of working examples in the kernel tree.
> >
> > >
> > > > Perhaps take a look at the book, Linux Device Drivers, 3rd edition.
> > > > It's free online and should help you out a lot.
> > > >
> > > > > printk("request_irq returned %d\n", ret); // -EINVAL
> > > > > printk(KERN_INFO "Device driver inserted ..done
> properly..\n");
> > > > > return 0;
> > > > >
> > > > > r_device :
> > > > > class_destroy(dev_class);
> > > > >
> > > > > r_class :
> > > > > unregister_chrdev_region(dev,1);
> > > > > return -1;
> > > >
> > > > One final comment, don't make up error values like this, use real
> > > > ERROR codes.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > Yes, I've read the book sometimes (not the whole part) but if I read
> > > it now, I'll be able to more understand it. It's a bit outdated
> > > though. Why don't you update your book? :)
> >
> > Because the publisher does not want to publish a new version.
> >
> > thanks,
> >
> > greg k-h
>
>
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
