![]() | |||||||||||||
Messages in this thread |
--- Pierre Ossman <drzeus-list@drzeus.cx> 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 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/ | ||||||||||||
| Last update: 2006-07-30 08:33 [from the cache] ©2003-2008 | |||||||||||||