Re: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash card readers

[Pierre Ossman <drzeus-list@drzeus.cx>]

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
formats.

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

Rgds
Pierre

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