[lkml]   [2006]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash card readers
    Alex Dubov wrote:
    > They are magic numbers. I have only the vague idea on
    > what most of these numbers mean. I digged them out
    > from TI's/everest's binary driver.

    Then try to make qualified guesses. Even if the constants are
    TIFM_INTFLAG_2, that still makes the code more readable as you see which
    values are the same constant.

    By "magic", in the valid sense, I do not mean "unknown". What I mean is
    "purposely random", as in values used to identify file systems and file

    > I already have "socket". "card" is something that is
    > plugged into the "socket". It's hard to think about
    > short name that fits here nicely.

    I assume "socket" is a structure for one of the card type subfunctions
    of the controller and that "card" is something you create once that
    subfunction is activated by a card insertion. Why can't you have the
    "card" portions allocated at all times as part of the "socket"
    structure? Is it possible for a "socket" to have multiple "card":s
    associated with it? Otherwise I see little need for the dynamic behaviour.

    > Unfortunately, hardware does care. Output of
    > tifm_sd_op_flag is set into upper half of command
    > register.

    Sorry, I was a bit unclear. Of course hardware cares about what kind of
    response it will get. What I meant was that hardware shouldn't care if
    it's R1, R2 or R666. What it should care about is if it's "Short
    response with CRC and embedded opcode" or something similar. If you look
    at the meaning of the response types and try to compare the different
    bit combinations, you can usually see patterns. Just remember that most
    controllers do not usually support checking every little aspect.

    > The fall-back is 0 (implied default for both
    > switches).

    And you are sure this will be valid for response type RFooBar,
    consisting of only a new combination of the existing response
    attributes, that I will come up with tomorrow?

    > The TI binary drivers tests for the command type
    > before setting the appropriate bit in command register
    > (similar to tifm_sd_op_flags).

    Please do a BUG_ON() or fail the request or something similar. If you
    would happen to get a request where cmd->data is set, but type isn't
    ADTC, then I assume all hell will break loose.

    > In general: while I'm using code flow different from
    > this used in TI's binary drivers, I tried very hard to
    > preserve register access semantics.

    Careful. People get a bit edgy with such reasoning around reverse
    engineering. ;)

    > When I failed to
    > do so, very bad things happened - sporadic and brutal
    > kernel crashes and run-aways. I think they were caused
    > by device writing random junk to some memory address
    > at arbitrary times.

    Baby steps. If you test carefully enough (and do some qualified
    guessing), you usually can figure out what most bits of a register are for.

    Great work figuring out the hardware as much as you have though. This
    driver will be a nice addition.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-07-30 12:15    [W:0.022 / U:1.828 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site