From: David Daney <ddaney@caviumnetworks•com>
To: Grant Edwards <grant.b.edwards@gmail•com>
Cc: netdev@vger•kernel.org
Subject: Re: Question about PHY-less board and "fixed_phy"
Date: Wed, 13 Oct 2010 12:06:18 -0700 [thread overview]
Message-ID: <4CB6032A.8020908@caviumnetworks.com> (raw)
In-Reply-To: <i94oag$epv$1@dough.gmane.org>
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...
>
next prev parent reply other threads:[~2010-10-13 19:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-13 16:55 Question about PHY-less board and "fixed_phy" Grant Edwards
2010-10-13 19:06 ` David Daney [this message]
2010-10-13 19:21 ` Grant Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CB6032A.8020908@caviumnetworks.com \
--to=ddaney@caviumnetworks$(echo .)com \
--cc=grant.b.edwards@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox