Question about PHY-less board and "fixed_phy"

Question about PHY-less board and "fixed_phy"

[Grant Edwards]

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"!

Re: Question about PHY-less board and "fixed_phy"

[David Daney]

On 10/13/2010 09:55 AM, Grant Edwards wrote:
>
> 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.

As long as you handle calling netif_carrier_{on,off}() and some of the 
ndo_do_ioctl commands, I don't think you need a PHY.

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

This I don't think is the case.  See phy_connect() for example.  It 
certianly allows for multiple PHYs per bus.

We have a SOC device (Octeon) that has many PHYs on a single MDIO bus, 
and have a separate MDIO bus driver (mdio-octeon.c) that is shared 
between all the Ethernet devices/drivers.

>
>   3) The MDIO bus belongs to the PHY.
>

??, The mdio bus lock is taken for some operations, but how does it 
'belong 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().
>

You can set the struct mii_bus phy_mask element to prevent probing of 
specific addresses.



> [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...
>

Re: Question about PHY-less board and "fixed_phy"

[Grant Edwards]

On 2010-10-13, David Daney <ddaney@caviumnetworks.com> wrote:
> On 10/13/2010 09:55 AM, Grant Edwards wrote:
>
>> 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.
>
> As long as you handle calling netif_carrier_{on,off}() and some of
> the ndo_do_ioctl commands, I don't think you need a PHY.

Thanks.  I'll look into that.

>>   2) An MDIO bus is a point-to-point link between the MAC and the PHY.
>
> This I don't think is the case.  See phy_connect() for example.  It 
> certianly allows for multiple PHYs per bus.
>
> We have a SOC device (Octeon) that has many PHYs on a single MDIO
> bus, and have a separate MDIO bus driver (mdio-octeon.c) that is
> shared between all the Ethernet devices/drivers.

Do you bypass the ioctl code in phy.c that ignores the device id in
the request and instead routes all read/write operations to the PHY's
id?

>>   3) The MDIO bus belongs to the PHY.
>
> ??, The mdio bus lock is taken for some operations, but how does it 
> 'belong to' the PHY?

I said that because the ioctl() to do read/write operations on the
mdio bus is a "phy" ioctl() that is handled by phy.c code (in the
drivers I've looked at), and it overwrites any user-provided device ID
with that of the PHY, thus turning the mdio bus into a point-to-point
link to the PHY whose use is controlled by the PHY driver.  In my mind
I guess that equates to the mdio bus "belonging to" the PHY.

It looks like I need to change the macb driver to handle those ioctl
requests directly instead of having the phy.c code handle them.

>>   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().
>
> You can set the struct mii_bus phy_mask element to prevent probing of
> specific addresses.

Ah, I hadn't figured that out yet.

Thanks for the hints!

-- 
Grant Edwards               grant.b.edwards        Yow! I know things about
                                  at               TROY DONAHUE that can't
                              gmail.com            even be PRINTED!!