mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Dubov <oakad@yahoo.com>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash card readers
Date: Sat, 29 Jul 2006 23:29:42 -0700 (PDT)	[thread overview]
Message-ID: <20060730062942.29644.qmail@web36706.mail.mud.yahoo.com> (raw)
In-Reply-To: <44CBBEC5.7090908@drzeus.cx>

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

  reply	other threads:[~2006-07-30  6:29 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28  3:34 Alex Dubov
2006-07-28  4:04 ` Alexey Dobriyan
2006-07-29 15:11   ` Alex Dubov
2006-07-28 11:46 ` Andrey Panin
2006-07-28 13:02   ` Alex Dubov
2006-07-29 20:02 ` Pierre Ossman
2006-07-30  6:29   ` Alex Dubov [this message]
2006-07-30 10:12     ` Pierre Ossman
2006-07-31 15:11       ` Alex Dubov
2006-07-31 17:37         ` Pierre Ossman
2006-08-02  2:12           ` Alex Dubov
2006-08-02  9:31             ` Pierre Ossman
2006-09-02  8:53               ` Alex Dubov
2006-09-02 11:15                 ` Pierre Ossman
2006-09-02 16:48                   ` Andrew Morton
2006-09-02 20:50                     ` Pierre Ossman
2006-09-03  3:48                       ` Greg KH
2006-09-03  9:53                         ` Pierre Ossman
2006-09-05 19:12                           ` Greg KH
2006-09-05 20:08                             ` Pierre Ossman
2006-09-06  3:33                               ` Greg KH
2006-09-06  5:02                                 ` Pierre Ossman
2006-09-07  3:00                                   ` Alex Dubov
2006-09-15  2:17                                   ` Alex Dubov
2006-09-15  6:43                                     ` Pierre Ossman
2006-09-19  3:20                                       ` Alex Dubov
2006-09-19  6:03                                         ` Pierre Ossman
2006-09-03  7:41                   ` Alex Dubov
2006-09-03 10:03                     ` Pierre Ossman
2006-09-04 14:12                       ` Alex Dubov
2006-09-04 14:49                         ` Pierre Ossman
2006-09-03 10:20                     ` Russell King
2006-09-03 10:32                       ` Pierre Ossman
2006-09-04 14:28                         ` Alex Dubov
2006-09-04 14:41                           ` Pierre Ossman
2006-09-05  2:18                             ` Alex Dubov
2006-09-05  5:35                               ` Pierre Ossman
2006-07-28 16:04 Mikael Pettersson
2006-07-29  6:43 ` Alex Dubov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060730062942.29644.qmail@web36706.mail.mud.yahoo.com \
    --to=oakad@yahoo.com \
    --cc=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®