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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060730062942.29644.qmail@web36706.mail.mud.yahoo.com>
Date:	Sat, 29 Jul 2006 23:29:42 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash card readers

--- Pierre Ossman <drzeus-list@...eus.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/