Greg,
when calling drivers/ata/pata_legacy.c, it grabs four irq's even
though those legacy device probes fail:
root@i486:~# cat /proc/interrupts
CPU0
0: 95630 XT-PIC timer
1: 1028 XT-PIC i8042
...
10: 0 XT-PIC platform[pata_legacy.3]
11: 0 XT-PIC platform[pata_legacy.2]
12: 0 XT-PIC platform[pata_legacy.5]
14: 66786 XT-PIC platform[pata_legacy.0]
15: 0 XT-PIC platform[pata_legacy.1]
Tejun believes that platform_device_unregister() should free the irqs:
>>
>> The thing I'm puzzled about and can't reproduce here is that the
>> platform_device_unregister() call on the fail path should release the
>> irq resources without the explicit devres group operations. I can
>> write up tracking each step but it'd probably be easier on your side
>> to track down why it's not getting called.
>>
>> So, pata_legacy doesn't need anything changed, but in the probe fail
>> path, platform_device_unregister() should trigger
>> driver/base/core.c::device_release() which calls devres_release_all()
>> and release the irqs.
>>
>
I ponder if the driver should instead release the irq's from the failed probe:
> It looks to me that when something is 'platform' it is not expected to
> ever go away, and that generally includes irqs. There are calls to
> platform_get_irq() but there isn't even a function called
> platform_put_irq() or platform_free_irq().
>
...
> I think this driver should either not be considered 'platform' or it
> should make a call to free_irq() on failures.
>
The question is: who is responsible to free an irq from a device
registered using platform_device_register_simple()? Is it the driver
or the platform code?
- Matthew
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
