netdev - Re: [RFC v3 1/3] NET: PHY: adds driver for Intel XWAY PHY

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 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]

Date:	Sat, 4 Jun 2016 16:55:30 +0200
From:	John Crispin <john@...ozen.org>
To:	"Langer, Thomas" <thomas.langer@...el.com>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>
Cc:	"alexander.stein@...tec-electronic.com" 
	<alexander.stein@...tec-electronic.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"andrew@...n.ch" <andrew@...n.ch>,
	"openwrt@...sin.me" <openwrt@...sin.me>,
	"Mehrtens, Hauke" <hauke.mehrtens@...el.com>,
	"daniel.schwierzeck@...il.com" <daniel.schwierzeck@...il.com>,
	"eckert.florian@...glemail.com" <eckert.florian@...glemail.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC v3 1/3] NET: PHY: adds driver for Intel XWAY PHY

Hi Thomas
Hi Hauke

On 04/06/2016 16:43, Langer, Thomas wrote:
>> +		 /* there is an errata regarding irqs in this rev */
> And then this is comment is also now valid.
> What about a system with a single external phy connected,
> on a non-Lantiq/Intel SoC?
> 
> I think the feasibility of using interrupts is not related to the phy version,
> but indirectly by the version of the SoC it is integrated.
> 
> So maybe he use of interrupts (on these SoCs) should be controlled by devicetree or
> network driver, where the SoC type and version can be handled?
> 

IIRC the 2 irq lines are broken on xrx200 v1.1 SoC silicon. irqs were
unreliable and sometimes fired on the wrong phy or not at all. maybe
this was fixed on v1.2 silicon ? this is not related to the phy per-se
but the SoC silicon it is integrated into.

the PHY driver should be agnostic of the SoC having a functional IRQ
block i think. devictrees for v1.1 SoC silicon should simply not define
an IRQ inside the devicetree and rely on the phy polling done by the
mdio/phy layer.

	John