--- Pierre Ossman <[email protected]> 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
switches).
>
> 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
http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
