Tejun, > > 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. > 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 do see some driver calls to failure conditions or 'remove' functions where it calls: free_irq(platform_get_irq(pdev, 0), var) See: drivers/mmc/host/atmel-mci.c drivers/usb/gadget/udc/fotg210-udc.c drivers/usb/gadget/udc/fusb300_udc.c drivers/usb/gadget/udc/m66592-udc.c drivers/video/fbdev/au1200fb.c drivers/virtio/virtio_mmio.c drivers/dma/at_hdmac.c drivers/input/keyboard/pxa930_rotary.c drivers/input/keyboard/sh_keysc.c I think this driver should either not be considered 'platform' or it should make a call to free_irq() on failures. - 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
