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

From: Alex Dubov
Date: Sun Jul 30 2006 - 02:28:30 EST

--- Pierre Ossman <drzeus-list@xxxxxxxxx> wrote:

> Some comments from a MMC/SD perspective.
> On a general note, please replace all your constants
> with defines. Magic
> values are no fun (unless they are in fact a magic
> number ;)).
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.

Luckily, Vayo's linux binary had every register
accessed from separate function, so, at least,
register names are known with certain confidence.

> Also, calling the struct "card" might be a bit
> misleading as it might be
> a bus in the MMC case.
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.

> In tifm_sd_o_flags(), try not to case on response
> types as the hardware
> shouldn't have to care about this. If you really,
> really, _really_ must
> do this, then make sure you have a default that
> prints something nasty
> and fails the request with an error.

Unfortunately, hardware does care. Output of
tifm_sd_op_flag is set into upper half of command
register. The fall-back is 0 (implied default for both

> A default is also needed for cmd_flags in the same
> function.
> In tifm_sd_exec(), you should only need to test for
> the presence of
> cmd->data, not that the command is of ADTC type.

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

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

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at