| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <45683C45.8020904@f2s.com> Date: Sat, 25 Nov 2006 12:51:17 +0000 From: Ian Molton <spyro@....com> To: Ian Molton <spyro@....com>, linux-kernel@...r.kernel.org Subject: Re: [Kernel-discuss] RFC - platform device, IRQs and SoC devices Russell King wrote: > > It's quite possible to have: > > IRQ chip > 0 irqchip_0 > 1 irqchip_0 > 2 irqchip_1 > 3 irqchip_0 > 4 irqchip_0 > 5 irqchip_1 > 6 irqchip_2 > 7 irqchip_2 > 8 irqchip_2 > 9 irqchip_1 > > Where do you start '0' for each irqchip? How do you split the irq_desc > array between the irqchips? I see no reason why this couldnt continue to work 'as is' with the new behaviour only applying to irqchips with their own non-NULL irq_desc array. The other problem is integration with /proc, specifically the irq usage counter. The irq numbers in /proc wouldnt have to be 'real' they can be synthesized from a base starting after the main system IRQs. Im not sure how fixed the format of /proc/interrupts is, wether the IRQ numbers are required to be sequential or not (some arent even numbers like NMI on x86). if they dont have to be sequential then its simply a matter of keeping a counter starting from BOARD_IRQ_END+1 and for each IRQchip adding its individual irq numbers to it as they are displayed, then incrementing the counter by the size of the irqdesc array for that chip. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists