linux-kernel - Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

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: <20141009164704.7286fc3f@free-electrons.com>
Date:	Thu, 9 Oct 2014 16:47:04 +0200
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc:	devicetree@...r.kernel.org,
	Florian Fainelli <f.fainelli@...il.com>,
	Eric Miao <eric.y.miao@...il.com>, netdev@...r.kernel.org,
	Antoine Ténart 
	<antoine.tenart@...e-electrons.com>, linux-kernel@...r.kernel.org,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin
 Ethernet

Dear Sebastian Hesselbarth,

On Thu, 09 Oct 2014 16:41:48 +0200, Sebastian Hesselbarth wrote:

> > Hum, in mvneta, we already disabled the automatic negotiation and use
> > libphy. What makes you think the current mvneta driver is wrong in this
> > respect?
> 
> I didn't check mvneta, but remember Ezequiel didn't clear all AN bits
> in the barebox driver (which is based on Linux mvneta). Just mentioned
> that I'll have a closer look at it.

Ah, ok.

> But I agree, regarding libphy support mvneta is probably the best
> already.

Well, I initially remember that the original driver coming from Marvell
was using the HW PHY stuff, and that I changed that because it would
not integrate well with the kernel libphy.

A drawback of this is that because the hardware has built-in PHY
polling which triggers a MAC interrupt when the PHY status changes, they
typically don't wire up the PHY interrupt. Therefore, since we're not
able to use the MAC interrupt for PHY event notifications, we rely on
software PHY polling, which means that link up / link down events take
a few seconds to be noticed by the kernel. Unfortunately, I don't think
the hardware allows to use the hardware PHY polling to get link changes
interrupt, but not let the hardware configure the PHY itself.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/