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
| ||
|
Message-ID: <c695af6a-c3c3-752c-0f98-e43fe460d1f6@phrozen.org> 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
Powered by blists - more mailing lists