lkml.org 
[lkml]   [2001]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectMII 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/

    \
     
     \ /
      Last update: 2005-03-22 12:54    [W:0.051 / U:34.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site