From: Pierre Ossman <drzeus-list@drzeus.cx>
To: philipl@overt.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.18 1/1] mmc: Add support for mmc v4 high speed mode
Date: Wed, 11 Oct 2006 07:58:19 +0200 [thread overview]
Message-ID: <452C87FB.6080302@drzeus.cx> (raw)
In-Reply-To: <11208.67.169.45.37.1160545100.squirrel@overt.org>
philipl@overt.org wrote:
>> Pierre Ossman wrote:
>>
>>> + cmd.arg = 0x03B90100;
>>>
>>>
>> I'd prefer some defines and shifts here. Also, this should be done at
>> init, not at select. The reason SD does it is that the spec says it
>> drops out of wide mode when it gets unselected.
>>
>
> I have done this, but your suggestion somewhat contradicts your original
> suggestion to remove the defines. Essentially, my updated change restores
> the relevant definitions from my very first diff. I hope this is what you
> wanted. I prefer to have the #defines, so I'm not complaining.
>
I know I can be a bit unclear some times, so feel free to be utterly
confused. :)
What I don't like is defines used for structure offsets where those
fields will be transformed into a normal C structure. I.e. the defines
will only be used once.
In this case, it's protocol opcodes, which are far more vital to have
readable. Currently we only use this in one place, but this will
probably grow. If I understand things correctly, switching to 4-bit and
8-bit bus also uses the SWITCH command?
> I also moved the explaination of the MMC_SWITCH argument to protocol.h I
> think it's worth documenting somewhere.
>
A variant of this would be to do a macro. But this is fine as well.
> I have moved this work into the read_ext_csd function and renamed it
> process_ext_csd.
>
>
Looks good.
>> A "max_dtr" int the mmc_ext_csd structure would be nicer here. And you
>> cannot do a kernel BUG because the card is broken. You should mark it as
>> dead.
>>
>
> I have replaced storing the CARD_TYPE value with storing a dtr based on
> the CARD_TYPE which should achieve what you wanted. I've replaced the
> BUG with marking the card as bad.
>
>
Very nice. This is a lot less confusing when someone else will be
mucking about with the clock selection routines (e.g. adding SDIO support).
> Finally, as pointed out by Jarkko, I added the missing MMC_CMD flags to
> the calls to MMC_SWITCH and MMC_SEND_EXT_CSD;
>
Rgds
Pierre
next prev parent reply other threads:[~2006-10-11 5:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 5:41 [PATCH 2.6.18 1/1] mmc: Add support for mmc v4 high speed mode philipl
2006-10-07 5:58 ` Pierre Ossman
2006-10-10 6:17 ` Pierre Ossman
2006-10-11 5:38 ` philipl
2006-10-11 5:58 ` Pierre Ossman [this message]
2006-10-11 6:59 ` Philip Langdale
2006-10-15 19:49 ` Pierre Ossman
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=452C87FB.6080302@drzeus.cx \
--to=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=philipl@overt.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