netdev - RE: [PATCH net-next,V2] Add LAN9352 Ethernet Driver

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: <90A7E81AE28BAE4CBDDB3B35F187D264402EFAF5@CHN-SV-EXMX02.mchp-main.com>
Date:	Tue, 16 Feb 2016 19:34:26 +0000
From:	<Bryan.Whitehead@...rochip.com>
To:	<andrew@...n.ch>
CC:	<davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next,V2] Add LAN9352 Ethernet Driver

Hi Andrew,

You can find my comments below wrapped in <BW> ... </BW>

-----Original Message-----
From: Andrew Lunn [mailto:andrew@...n.ch] 
Sent: Friday, February 12, 2016 12:11 PM
To: Bryan Whitehead - C21958
Cc: davem@...emloft.net; netdev@...r.kernel.org
Subject: Re: [PATCH net-next,V2] Add LAN9352 Ethernet Driver

On Fri, Feb 12, 2016 at 04:51:49PM +0000, Bryan.Whitehead@...rochip.com wrote:
> Hi Andrew,
> 
> Sorry I still did not make this clear. And I'm not sure I understand your question so I'll try to explain again, but please give me feedback if it's still not clear.
> 
> Also you can reference Figure 2-1 for an Internal Block Diagram on 
> page 9 of 
> http://ww1.microchip.com/downloads/en/DeviceDoc/00001923A.pdf
> 
> Conceptually I think it's easier to ignore the switch all together, since the driver really doesn't touch it.
> 
> Imagine we have two separate components
> 	1) LAN9218 (which is a 10/100 Ethernet Controller)
> 	2) An external 3 port switch (which is actually embedded)
> 
> This driver only operates on the Ethernet Controller, whose phy is in reality just a virtual phy.

> That virtual phy is connected directly to the embedded switch fabric, 
> which has the two physical phys that you are asking about. Since this 
> driver only operates on the Ethernet controller and its virtual phy. I 
> makes no sense to talk about phy-modes for the physical phys on the 
> switch.

So the code implements an MDIO bus and registers it with the MDIO framework. 
<BW> Yes </BW>

It then finds the first phy and connects it to the netdev.
<BW> Yes </BW>

When doing this, it passes the phy-mode.
<BW> Yes </BW>

My assumption is, the first PHY on the MDIO bus is the PHY connected to port 0 of the switch. 
<BW> Yes, that is the correct assumption </BW>

So you are setting the phy-mode of this port.
<BW> Yes </BW>

This is a real phy, not a virtual phy.
<BW> 
>From the software point of view it is a real phy, in that there is a real phy register set that can be read and written. But from the hardware point of view, it is virtual because it does not control a physical phy. 

The following is a clip from the spec.
"The Virtual PHY provides a basic MII management interface (MDIO) per EEE 802.3 (clause 22) so
that a MAC with an unmodified driver can be supported as if it was attached to a single port PHY. This
functionality is designed to allow easy and quick integration of the device into designs with minimal
driver modifications. The Virtual PHY provides a full bank of registers which comply with the IEEE
802.3 specification. This enables the Virtual PHY to provide various status and control bits similar to
those provided by a real PHY. These include the output of speed selection, duplex, loopback, isolate,
collision test, and Auto-Negotiation status."
</BW>

     Andrew