netdev - Re: ravb: Possible Regression In "net: phy: Avoid polling PHY with PHY_IGNORE

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] [day] [month] [year] [list]

Date:	Tue, 16 Feb 2016 22:35:03 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Simon Horman <horms@...ge.net.au>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	linux-renesas-soc@...r.kernel.org,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: ravb: Possible Regression In "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"

On February 16, 2016 3:06:55 AM PST, Sergei Shtylyov <sergei.shtylyov@...entembedded.com> wrote:
>Hello.
>
>On 2/16/2016 10:42 AM, Geert Uytterhoeven wrote:
>
>>> I have observed what appears to be a regression in the ravb ethernet
>driver
>>> caused by d5c3d84657db ("net: phy: Avoid polling PHY with
>>> PHY_IGNORE_INTERRUPTS").
>>>
>>> When booting net-next configured with the ARM64 defconfig on the
>Renesas
>>> r8a7795/salvator-x I see the following and the ravb is unable to
>access the
>>> network. With the above mentioned patch reverted I am able to boot
>to
>>> user-space using nfsroot.
>>
>> The ravb interrupt is connected to a GPIO controller, which is
>> runtime-suspended and thus not serving the interrupt.

OK that makes complete sense then, is your patch going to make it into an upcoming v4.5-rc pull request or should we think about having the ravb driver re-assign its phydev->irq to PHY_POLL for the time being?

>>
>> Cfr. "[PATCH/RFC] gpio: rcar: Add Runtime PM handling for interrupts"
>> (http://www.spinics.net/lists/linux-renesas-soc/msg00532.html).
>>
>> I assume it worked before as the PHY driver polled the PHY instead of
>relying
>> solely on the interrupt.
>
>   Correct. BTW, I'm going to look at handling AVB_PHY_INT in the ravb 
>driver, thus removing the need for routing it to the GPIO controller
>now that 
>phylib allows this again...

That sounds like a better solution if the PHY interrupt is consistently and uniformly available on these boards. 

-- 
Florian