Message-ID: <i94oag$epv$1@dough.gmane.org>
Date:	Wed, 13 Oct 2010 16:55:44 +0000 (UTC)
From:	Grant Edwards <grant.b.edwards@...il.com>
To:	netdev@...r.kernel.org
Subject: Question about PHY-less board and "fixed_phy"


I'm working with an Atmel ARM9 board (macb driver), that doesn't have
a PHY.

The MAC is connected to a switch via MII.  That MII link is hard-wired
to be 100M full-duplex.

>From what I've been able to google, the "fixed_phy" driver is intended
for this situation.  But from looking at the fixed.c source code it
appears to provide an emulated MDIO bus.

I don't want an emulated MDIO bus.

I have a real, working MDIO bus.

What I don't have is a PHY.

The switch presents a bunch of logical slave devices (23, IIRC)
attached to the MDIO bus, and I need use the MDIO bus to access those
"devices" (mainly from user-space via ioctl() calls).  If I use the
fixed_phy driver, it appears that it will hide the real MDIO bus and
replace it with a fake one that's connected to a fake set of PHY
registers.  That means I won't be able to access the the registers in
the switch to which my MAC is connected.

The ethernet/phy architecture seems to be based on several assumptions
that aren't true in my case:

 1) Every MAC is connected to a PHY.

 2) An MDIO bus is a point-to-point link between the MAC and the PHY.

 3) The MDIO bus belongs to the PHY.

 4) It's OK to go out and read arbitrary registers from every device
    on the MDIO bus when that bus is registered using mdiobus_register().
 
[Hmm, #4 may be true in my case, but it seems like a dangerous assumption.]
    
Anyway, I'm confused on how the MAC/PHY architecture is meant to deal
with the case where there is no PHY, but there are real devices
attached to a real MDIO bus which needs to be accessed both from the
Ethernet driver and from userspace using the normal user-space ioctl()
call.  

Do I need to write my own "fixed_phy" driver that presents a virtual
PHY without putting a fake MDIO bus in place?  

How _do_ you present a virtual PHY without faking an MDIO bus?

Do I need _two_ MDIO buses, the real one that is used to communicate
with the switch chip and a fake one that's used to talk to a fake PHY?
If so, how do I associate two MDIO buses with a single Ethernet
interface?

How do you register an mdio bus without having every device on the bus
accessed?

Can anybody loan me a clue?

Another thing I don't understand is that it looks to me like the
ioctl() to access devices on the mdio bus is handled by the PHY driver
when it should be handled by the Ethernet driver: the MDIO bus belongs
to the MAC, not the PHY.

The PHY driver apparently ignores the device ID specified by the user
and forces the device ID to that of the PHY, thus cutting of access to
any other devices on the bus.  [I've worked around that by kludging
the Ethernet driver's mdio_read/write routines so that I can specify
the device ID by placing it in the upper 8 bits of the 16-bit register
number (which is left unchanged as it passes through the PHY driver).]

This doesn't make sense to me.  Why provide a device ID in the ioctl()
API, and then overwrite it as the request passes through the PHY
driver to the Ethernet driver.  Why are ioctl() MDIO register
read/write requests that are done on an Ethernet interface passed
through the PHY driver?

I've read and re-read the phy.txt file under Documentation, and I've
looked at the fixed_phy source and sources of drivers where it is
used, but I'm still in the dark...

-- 
Grant Edwards               grant.b.edwards        Yow! Somewhere in Tenafly,
                                  at               New Jersey, a chiropractor
                              gmail.com            is viewing "Leave it to
                                                   Beaver"!

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists