netdev - Re: [PATCH] phy: IRQ cannot be shared

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52BDDAC4.2050100@cogentembedded.com>
Date:	Fri, 27 Dec 2013 22:53:40 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	David Miller <davem@...emloft.net>, f.fainelli@...il.com
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH] phy: IRQ cannot be shared

On 12/27/2013 09:43 PM, David Miller wrote:

>>> With the way PHY IRQ handler is implemented (all real handling being pushed to
>>> the workqueue and returning IRQ_HANDLED all the time PHY is active), we cannot
>>> really claim that PHY IRQ can be shared when calling request_irq().

>> Looks good, in the future we might want to be able to let the Ethernet
>> MAC driver specify the flags to pass down to request_irq()

    I don't think this is such a good idea now since the way to pass those 
flags would be quite clumsy (like it is for IRQs, via array of 32 entries).
I'd prefer irq_set_irq_type() if there'd be no objections.

>> but this is
>> good enough for me for the time being.

>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>

>> Acked-by: Florian Fainelli <f.fainelli@...il.com>

> I really worry that putting this new restriction in place is going to
> break a bunch of drivers.

> Arguably they are broken,

    Yes, they already are.

> but they are least mostly working right now
> and probes will completely fail after this change.

    I don't see how the probes will fail. Have you seen the surrounding code? 
It should just switch to PHY polling if request_irq() fails and return 0. Am I 
missing something?

> Feel free to allay my concerns, but tossing this into 'net' and
> -stable with such a possible risk really concerns me.

    Up to you, of course.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html