From: Donald Becker <firstname.lastname@example.org> To: Jeff Garzik <email@example.com> Cc: Bogdan Costescu <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, firstname.lastname@example.org, "David S. Miller" <email@example.com>, Linus Torvalds <firstname.lastname@example.org> Subject: Re: PATCH: ethtool MII helpers Date: Wed, 13 Jun 2001 12:56:57 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.email@example.com> (raw) In-Reply-To: <3B265416.58941C3C@mandrakesoft.com> I was on vacation, and thus didn't have the opportunity to comment earlier. This message covers Why caching MII values doesn't work. Why extended MII values are useful. On Tue, 12 Jun 2001, Jeff Garzik wrote: > > - You are proposing some caching for the MII registers. I suppose that you > > would like to have this code also working with whatever caching will be > > done for MII access that was recently discussed. Wouldn't this produce > > double caching under some circumstances ? > > You misunderstood the code. The "caching" here is whatever is -already- > being done by the driver. Many Becker-style drivers cache the > advertising value. If such a driver uses the ethtool MII code, that is > one less MII read that needs to occur. That's not the way I read the code. It appears to cache various MII management registers. Caching almost any MII register, except the ID registers, may be invalid. My drivers record values written to MII registers (note 1), but always does an actual read. Here is a quick summary of the basic mode registers MII Reg Function When it changes 0 Control register -- May return the current autonegotiated status. 1 Status register -- Changes with link status and other events. 2&3 ID registers -- Should never change 4 Advertised value -- may change with a transceiver reset 5 Link partner -- changes with negotiation, and "next page" feature (1) The drivers record the autonegotiation advertised value, and recently have been updated to allow writes to the control register to force the speed and duplex. Caching and ioctl() rate-limiting are both a problem for a program I use frequently. It monitors the transceiver to report the timing and state transitions of autonegotiation. It internally handles polling rate limiting by backing off the poll rate when nothing is happening. But when something happens, it polls every timer tick for the next 30 ticks. > Bogdan Costescu wrote: > > On Sun, 10 Jun 2001, Jeff Garzik wrote: > > - I don't know what the long-term plan is about ethtool vs. MII ioctl's. > > If you do plan to replace completely the MII ioctl's, there should be a > > way to access _all_ MII registers provided by the PHY, even if you do this > > in a restricted way (i.e. for CAP_NET_ADMIN only). There is also useful > > info in other registers than the 4 you have in your implementation. > > What are you doing that you need to access all registers from userspace? That's an easy one: "next page" information, diagnostics, status reports, and extended configuration. Much useful information is reported by certain MII transceivers. People that care select transceivers that provide the extended information. Diagnostic reports The approximate distance to the first major impedence mismatch on the cable. Signal status reports. Signal level -- estimate if the cable is to long or flawed. Signal to noise -- estimate the reliability of the link. Near-end cross-talk level. Reversed receive polarity. Operational errors Symbol coding error count Symbol sequence error count Decoder/PLL slip indication. Some examples of extended configuration are Increasing or decreasing the transmit level. Setting a lowered recieve threshold to allow marginal non-noisy links to work. Using symbol coding over fiber. Changing the information reported on the LED outputs > Becker's argument is that each driver should provide a set of MII > ioctls, emulating behavior when hardware isn't exactly per spec. (yes, > right now they are SIOCDEVPRIVATE, but that can be easily changed to > SIOCDEVMIIxxx) My driver sources converted to using specific names, which are currently mapped as follows #ifndef SIOCGMIIPHY #define SIOCGMIIPHY (SIOCDEVPRIVATE) /* Get the PHY in use. */ #define SIOCGMIIREG (SIOCDEVPRIVATE+1) /* Read a PHY register. */ #define SIOCSMIIREG (SIOCDEVPRIVATE+2) /* Write a PHY register. */ #define SIOCGPARAMS (SIOCDEVPRIVATE+3) /* Read operational parameters. */ #define SIOCSPARAMS (SIOCDEVPRIVATE+4) /* Set operational parameters. */ > David's argument is for ethtool, which originally comes out of the sparc > port (see include/asm-sparc/ethtool.h in older trees), and has been > around for a while, but doesn't enjoy the massive deployment that the > MII ioctls enjoy. We have control over the ethtool API, and we can > correct its deficiencies, whereas any MII spec deficiencies must be > worked out inside the driver. You should first understand what MII management registers provide before deciding that you can do better. There are some design uglinesses, but it was put together by people that lived and breathed transceivers. It has been proven over six or seven years or use with no incompatible changes to the original software interface definition. >... > the chip is designed. There are completeness flaws in more than one MII > ioctl implementation. Several drivers will return zeroes for the MII id > registers, for example. The ethtool API doesn't have that problem. Returning zeros for the MII ID registers is accepted industry practice for integrated transceivers. We could have the driver substitute a specific ID, but this isn't an actual problem. > Further, for the userland ethtool program, support for MII ioctls will > be added soon, so that there will be no need for additional mii-tool or > mii-diag tools. This could be easily reversed: the additional ethtool program was not needed in the first place. > > This is nice, but I would like to able to restart autonegotiation even > > without changing any of the advertised capabilities. If I missed this > > possibility, please point me to it... > > no, that is a capability which needs to be added to ethtool. > ETHTOOL_RENEG or ETHTOOL_ANRESTART or something. Basically kick the > link state machine, whether such a state machine is in the driver or in > the MII phy. That's the one big thing that mii-tool can do that ethtool > cannot, AFAICS. An additional capability of the MII ioctl() is that it permits sending "next page" extended information to the link partner. Donald Becker firstname.lastname@example.org Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993
next prev parent reply other threads:[~2001-06-13 16:49 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-06-10 17:34 Jeff Garzik 2001-06-11 5:59 ` Pekka Savola 2001-06-11 6:10 ` Keith Owens 2001-06-12 17:09 ` Bogdan Costescu 2001-06-12 17:40 ` Jeff Garzik 2001-06-12 18:40 ` PATCH: ethtool MII helpers (vers 2) Jeff Garzik 2001-06-13 15:29 ` PATCH: ethtool MII helpers Bogdan Costescu 2001-06-13 16:56 ` Donald Becker [this message] 2001-06-13 20:24 ` Jeff Garzik 2001-06-15 17:22 ` Bogdan Costescu 2001-06-22 5:10 ` Chris Wedgwood 2001-06-22 5:24 ` Jeff Garzik 2001-06-22 5:34 ` Chris Wedgwood 2001-06-22 5:58 ` Jeff Garzik
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=Pine.LNX.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: PATCH: ethtool MII helpers' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).