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