Re: [PATCH] net: smc91x: propagate irq return code

Sergei Shtylyov [off-list ref] writes:

Hello.

On 2/1/2016 1:46 AM, Robert Jarzmik wrote:

quoted

The smc91x driver doesn't honor the probe deferral mechanism when the
interrupt source is not yet available, such as one provided by a gpio
controller not probed.

   What if 'ndev->irq' does equal 0?

That's not possible AFAIR.

There was a discussion where Linus had stated that the irq is a cookie, and a 0
value is "no interrupt", expcepting for the single case of a PC and its timer
interrupt.

As we're not in that case, and up to my understanding, platform_get_irq() cannot
return a 0 value, only a strictly negative or positive one.

And yet, that test now looks weird to me. I think I'll respin the patch with a
"if (ndev->irq < 0) {" instead of the "if (ndev->irq <= 0) {".

Cheers.

-- 
Robert

On 02/01/2016 11:41 PM, Robert Jarzmik wrote:

quoted

quoted

The smc91x driver doesn't honor the probe deferral mechanism when the
interrupt source is not yet available, such as one provided by a gpio
controller not probed.

quoted

    What if 'ndev->irq' does equal 0?

That's not possible AFAIR.

    Possible if of_irq_get() returns 0 (and it will on failure!).

There was a discussion where Linus had stated that the irq is a cookie, and a 0
value is "no interrupt", expcepting for the single case of a PC and its timer
interrupt.

    I know, I know... and even on x86 it was never passed to request_irq(), 
only to setup_irq()...

As we're not in that case, and up to my understanding, platform_get_irq() cannot
return a 0 value, only a strictly negative or positive one.

    Wishful thinking...

And yet, that test now looks weird to me. I think I'll respin the patch with a
"if (ndev->irq < 0) {" instead of the "if (ndev->irq <= 0) {".

    Defeating Linus' PoV as a result... ;-)

Cheers.

MBR, Sergei