On Sat, 2004-11-06 at 03:59 +0000, Matthew Wilcox wrote:

> I think those devices need blacklisting.  Either that, or we need to do
> DV in non-approved ways.  Perhaps start with SDTR+WDTR.  If we get up
> to Fast-40, then try PPR.  I suspect James has Opinions on this though ;-)

Bleah.  I have opinions on this whether James does or not.  If you are
going to control device negotiation at the mid layer level, then you
need these things:

     1. Current bus state, as pointed out there are devices that reject
        PPR unless on an LVD bus, and whether or not you can get at the
        current bus mode and how is hardware dependent and changes from
        driver to driver, so now you have to add a new entry into the
        low level driver for all SPI class drivers hostt->bus_is_lvd()
        in order to be able to do proper checks at the mid layer level.
        This needs to be a call in function, not a static element.  Bus
        mode can change, especially from something as simple as hot
        plugging a new drive into an existing LVD JBOD, but the drive
        accidentally has the FORCE_SE jumper enabled.  This will force
        the whole bus to switch to SE instantly, and all drives will
        have to renegotiate.  So, given hotplug issues, the bus state
        needs to be checked at each negotiation, not based upon some
        previous state.
     2. Drivers *should*, when possible, honor user settings stored in
        NVRAM on the cards.  So, add another entry point so that the low
        level drivers with NVRAM can pass up the user specified max
        speed, width, cache settings, etc.  Oh, and if it isn't obvious,
        there are devices out there that reject attempted PPR messages
        if the speed/width/mode that you are requesting can be
        represented by a SDTR/WDTR pairs instead.  In other words, if
        you aren't requesting a DT + possible options settings, then
        don't use PPR.
     3. Recovery operations in the LLDD interrupt handler need to change
        the way commands are handled.  Given an attempt to send PPR
        messages, both BUSFREE and subsequent MSG_REJECT situations need
        to cancel the attempted and all future PPR messages, so now you
        need a hook in the scsi layer for the driver to tell the mid
        layer "Quit telling me to do PPR, it doesn't work you moron"
     4. In the event that a device doesn't advertise in any given way
        that it is capable of PPR, but does in fact send an unsolicited
        PPR message to the driver, we now need a hook in the mid layer
        so the driver can say "Well, would you look at that...it's a PPR
        device hiding in the corner"

That's the level of API you'll need to properly do this from the mid
level.

Of course, you could genericize this a bit.  You could have a callin for
current bus state in the LLDD.  Something like hostt->get_bus_type() and
have it return an or'ed bitmask of state bits, BUS_WIDE | BUS_SYNC |
BUS_{LVD,SE,HVD}, something like that, then it could possibly do more
than just PPR/LVD negotiation, but personally this is one of those
things that I think is card specific enough that it ought to just stay
in the LLDD.  My $.02.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606


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