[ 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 CostescuIWR - 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/
This archive was generated by hypermail 2b29 : Thu Jun 07 2001 - 21:00:22 EST