Messages in this thread | | | Date | Sat, 2 Jun 2001 21:10:44 +0200 (CEST) | From | Bogdan Costescu <> | Subject | MII access (was [PATCH] support for Cobalt Networks (x86 only) systems) |
| |
[ As this is becoming more and more MII specific, I changed the subject ]
On Sat, 2 Jun 2001, Alan Cox wrote:
> > This only answered the first part of the question: when. How do you pass > > the "how long" info ? > > Does the same applies for the MII ioctl case ? > > The mtime tells you exactly that.
Alan, please consider this situation:
One application needs to poll link status with 1 second resolution. On a system where caching is done with an unknown cache expiring time, this application is sometimes fed incorrect data. So, you need a way to tell for how long this situation lasts. If you have a proc/ioctl interface for setting cache expiring time, this same interface can then be used for reading back this info. This application can then check that this value is lower than 1 second and if not, notify the user that it cannot run.
As this thread started as a general hardware access problem, would only _one_ value for all these cases be sufficient ? Or each case should have its own timeout ? Anyway, for MII, accessing the status at sub-second intervals might be a legit one, so what measuring units should be used?
> I disagree. A non priviledged app should not be able to poke around in MII > registers anyway. So you only have to cache the generic state of the link.
At the beginning of this thread, Jeff said "calling the ioctls without priveleges is quite useful". Now if you say that there is no such case, the whole problem could simply be solved by checking for the appropriate priviledges.
I just realized another thing, important (IMHO) if a normal user is still allowed to access MII: the drivers (checked for 3c59x, eepro100, tulip) do not verify that the value passed for register number is within the allowed range and use it as:
int read_cmd = (0xf6 << 10) | ((phy_id & 0x1f) << 5) | location;
(phy_id is the MII address and location is the register number).
There is also no check that the MII address specified is actually in use by the driver, but this is used with mii-diag to query a MII which was not correctly identified (maybe this should be allowed for CAP_NET_ADMIN only ?)
From one of Don Becker pages: "MII transceivers have 32 management registers. The first 16 are reserved for standard-defined uses, and the remaining one are available for chip-specific features. Only the first seven registers are currently defined."
Usually, the transceivers return garbage if you read from locations you are not supposed to (overwritting phy_ad). But if you begin overwritting the READ command (0xf6 above)... Something like this should do:
int read_cmd = (0xf6 << 10) | ((phy_id & 0x1f) << 5) | (location & 0x1f);
> You don't need timers.
Too tired to think straight yesterday... You're right. And if you alloc 32*sizeof(int) (you want to keep jiffies, right ?) per netdevice, I think that it could even be done outside the driver. Hmm, most of my previous arguments are no longer valid 8-(
-- Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |