[PATCH] of: Export of_irq_count for using in modules

[Michal Simek]

On 06/06/2013 10:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:45 Fri 31 May     , Michal Simek wrote:
>> On 05/31/2013 05:16 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 15:57 Fri 31 May     , Michal Simek wrote:
>>>> On 05/31/2013 01:00 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 10:14 Fri 31 May     , Michal Simek wrote:
>>>>>> Hi Jean-Christophe,
>>>>>>
>>>>>> On 05/30/2013 10:17 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> On 15:49 Thu 30 May     , Michal Simek wrote:
>>>>>>>> Export of_irq_count for modules.
>>>>>>>
>>>>>>> can you explain why do you need to call of_irq_count
>>>>>>
>>>>>> I need to count number of irq written in the DTS node.
>>>>>> It is not fixed size that's why I need to proper way how to
>>>>>> find it out.
>>>>>>
>>>>>> I am using this loop.
>>>>>> 	count = of_irq_count(pdev->dev.of_node);
>>>>>> 	/* Alloc IRQ based on DTS to be sure that no other driver will use it */
>>>>>> 	while (count--) {
>>>>>> 		tmp->irq = irq_of_parse_and_map(pdev->dev.of_node, count);
>>>>>> 		dev_info(&pdev->dev, "%d: Alloc irq: %d\n", count, tmp->irq);
>>>>>> 		ret = request_irq(tmp->irq, zynq_remoteproc_interrupt, 0,
>>>>>> 					dev_name(&pdev->dev), &pdev->dev);
>>>>>> 		if (ret) {
>>>>>> 			...
>>>>>> 		}
>>>>>> 	}
>>>>>>
>>>>>> But of course if you think that this is incorrect to export it
>>>>>> I can use what it is in of_irq_count body
>>>>>> 368 int of_irq_count(struct device_node *dev)
>>>>>> 369 {
>>>>>> 370         int nr = 0;
>>>>>> 371
>>>>>> 372         while (of_irq_to_resource(dev, nr, NULL))
>>>>>> 373                 nr++;
>>>>>> 374
>>>>>> 375         return nr;
>>>>>> 376 }
>>>>>>
>>>>>> Because of_irq_to_resource is exported for modules.
>>>>>> Or is there any better way how to loop over all interrupts in DT node?
>>>>>
>>>>> can just explain me why you need to call irq_of_parse_and_map in your driver?
>>>>>
>>>>> as the irq will be provided in the resources normally
>>>>
>>>> It is quite a long time I have written this driver on v3.1 or 3.3.
>>>> But is this better?
>>>>
>>>> 	struct resource *res;
>>>> 	int i = 0;
>>>> 	do {
>>>> 		res = platform_get_resource(pdev, IORESOURCE_IRQ, i++);
>>>> 		if (res)
>>>> 			do something
>>>> 	} while(res);
>>>>
>>>> Also what about of_irq_to_resource()? Is it deprecated and all drivers
>>>> shouldn't use it?
>>>>
>>>> I have no problem to rewrite the driver to use platform_get_resource.
>>> yeah it's better but be aware there is a but in DT that I'm working on to fix
>>> if you use irq that are registered by a pdev this will not work
>>>
>>> I hope to fix it for 3.11
>>> and already send an RFC that fix it
>>
>> ok. good to know. Btw: Let's return to my origin point why not to
>> export of_irq_count for modules?
>> Or opposite question if platform_get_resource is correct way
>> why to export of_irq_to_resource for modules?
> 
> for old ppc drivers that are not converted yet to pdev
> 
> if you can do so just use pdev resource I should have fix the pb or irq_domain
> hopefully for 3.11

ok. It means it is currently deprecated.
I just wanted to be sure that I understand it correctly.

I have changed my drivers not to use this function and using resources as
we discussed.

btw: I have sent one email to device-tree ML about describing missing
connection between cpu and the first interrupt controller.
Can you please look at it and comment it?
https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-May/033955.html

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130606/bb9449c1/attachment.sig>