From: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>,
Wolfram Sang <w.sang@pengutronix.de>,
Eric Benard <eric@eukrea.com>,
kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
patches@linaro.org
Subject: Re: [PATCH 4/4] mmc: sdhci-esdhc-imx: extend card_detect and write_protect support
Date: Sat, 11 Jun 2011 11:30:42 +0200 [thread overview]
Message-ID: <87boy4lnp9.fsf@lebrac.rtp-net.org> (raw)
In-Reply-To: <1307702572-22066-5-git-send-email-shawn.guo@linaro.org> (Shawn Guo's message of "Fri, 10 Jun 2011 18:42:52 +0800")
Shawn Guo <shawn.guo@linaro.org> writes:
Hi,
> The patch extends card_detect and write_protect support to get mx5
> family and more scenarios supported. The changes include:
>
> * Turn platform_data from optional to mandatory
> * Add cd_types and wp_types into platform_data to cover more use
> cases
> * Remove the use of flag ESDHC_FLAG_GPIO_FOR_CD
> * Adjust machine codes to adopt the platform_data changes
Before I go and test theses patches, I'd like to get some
clarification. From what I see, you've modified all over the place the
code to provide a platform_data, setting wp/cd type to type "NONE", as
if it was the default you choose. Why this default and not considerer
the "SIGNAL" type being the default ? Is this choice the safest one when
one doesn't know what type to choose or can it have some bad side
effects ?
Also, why didn't you modify the imx*_add_sdhci_esdhc_imx() functions to
provide the default platform_data by themselves that if the 2nd argument
was NULL instead of modifying all theses machines files ?
Last comment: How did you choose the platform_data values ? I mean, for
that the cases I'm mainly take care of (efika mx and sb platforms), you
choose NONE type, while the code has :
MX51_PAD_GPIO1_0__SD1_CD,
MX51_PAD_GPIO1_1__SD1_WP,
MX51_PAD_GPIO1_7__SD2_WP,
MX51_PAD_GPIO1_8__SD2_CD,
which means that it would rather be the SIGNAL type if I got it
right. Does this mean that you've set the type to NONE for all platforms
you didn't know what the answer was ? (I guess/hope that theses 2
questions will be answered by your answers to my previous questions tbh).
Thanks,
Arnaud
WARNING: multiple messages have this Message-ID (diff)
From: arnaud.patard@rtp-net.org (Arnaud Patard (Rtp))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] mmc: sdhci-esdhc-imx: extend card_detect and write_protect support
Date: Sat, 11 Jun 2011 11:30:42 +0200 [thread overview]
Message-ID: <87boy4lnp9.fsf@lebrac.rtp-net.org> (raw)
In-Reply-To: <1307702572-22066-5-git-send-email-shawn.guo@linaro.org> (Shawn Guo's message of "Fri, 10 Jun 2011 18:42:52 +0800")
Shawn Guo <shawn.guo@linaro.org> writes:
Hi,
> The patch extends card_detect and write_protect support to get mx5
> family and more scenarios supported. The changes include:
>
> * Turn platform_data from optional to mandatory
> * Add cd_types and wp_types into platform_data to cover more use
> cases
> * Remove the use of flag ESDHC_FLAG_GPIO_FOR_CD
> * Adjust machine codes to adopt the platform_data changes
Before I go and test theses patches, I'd like to get some
clarification. From what I see, you've modified all over the place the
code to provide a platform_data, setting wp/cd type to type "NONE", as
if it was the default you choose. Why this default and not considerer
the "SIGNAL" type being the default ? Is this choice the safest one when
one doesn't know what type to choose or can it have some bad side
effects ?
Also, why didn't you modify the imx*_add_sdhci_esdhc_imx() functions to
provide the default platform_data by themselves that if the 2nd argument
was NULL instead of modifying all theses machines files ?
Last comment: How did you choose the platform_data values ? I mean, for
that the cases I'm mainly take care of (efika mx and sb platforms), you
choose NONE type, while the code has :
MX51_PAD_GPIO1_0__SD1_CD,
MX51_PAD_GPIO1_1__SD1_WP,
MX51_PAD_GPIO1_7__SD2_WP,
MX51_PAD_GPIO1_8__SD2_CD,
which means that it would rather be the SIGNAL type if I got it
right. Does this mean that you've set the type to NONE for all platforms
you didn't know what the answer was ? (I guess/hope that theses 2
questions will be answered by your answers to my previous questions tbh).
Thanks,
Arnaud
next prev parent reply other threads:[~2011-06-11 9:36 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-10 10:42 [PATCH 0/4] Extend sdhci-esdhc-imx card_detect and write_protect support for mx5 Shawn Guo
2011-06-10 10:42 ` Shawn Guo
2011-06-10 10:42 ` [PATCH 1/4] mmc: sdhci: fix interrupt storm from card detection Shawn Guo
2011-06-10 10:42 ` Shawn Guo
2011-06-14 9:24 ` Wolfram Sang
2011-06-14 9:24 ` Wolfram Sang
2011-06-14 11:55 ` Shawn Guo
2011-06-14 11:55 ` Shawn Guo
2011-06-14 12:02 ` Wolfram Sang
2011-06-14 12:02 ` Wolfram Sang
2011-06-14 12:24 ` Shawn Guo
2011-06-14 12:24 ` Shawn Guo
2011-06-10 10:42 ` [PATCH 2/4] mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared Shawn Guo
2011-06-10 10:42 ` Shawn Guo
2011-06-14 9:22 ` Wolfram Sang
2011-06-14 9:22 ` Wolfram Sang
2011-06-10 10:42 ` [PATCH 3/4] mmc: sdhci-esdhc-imx: remove "WP" from flag ESDHC_FLAG_GPIO_FOR_CD_WP Shawn Guo
2011-06-10 10:42 ` Shawn Guo
2011-06-14 9:28 ` Wolfram Sang
2011-06-14 9:28 ` Wolfram Sang
2011-06-14 11:51 ` Shawn Guo
2011-06-14 11:51 ` Shawn Guo
2011-06-10 10:42 ` [PATCH 4/4] mmc: sdhci-esdhc-imx: extend card_detect and write_protect support Shawn Guo
2011-06-10 10:42 ` Shawn Guo
2011-06-11 9:30 ` Arnaud Patard [this message]
2011-06-11 9:30 ` Arnaud Patard (Rtp)
2011-06-11 11:50 ` Shawn Guo
2011-06-11 11:50 ` Shawn Guo
2011-06-11 11:59 ` Arnaud Patard
2011-06-11 11:59 ` Arnaud Patard (Rtp)
2011-06-11 13:16 ` Shawn Guo
2011-06-11 13:16 ` Shawn Guo
2011-06-11 19:21 ` Arnaud Patard
2011-06-11 19:21 ` Arnaud Patard (Rtp)
2011-06-14 6:47 ` [PATCH v2 4/4] mmc: sdhci-esdhc-imx: extend card_detect and write_protect support for mx5 Shawn Guo
2011-06-14 6:47 ` Shawn Guo
2011-06-14 9:51 ` Wolfram Sang
2011-06-14 9:51 ` Wolfram Sang
2011-06-14 13:06 ` Shawn Guo
2011-06-14 13:06 ` Shawn Guo
2011-06-14 13:55 ` Wolfram Sang
2011-06-14 13:55 ` Wolfram Sang
2011-06-15 3:10 ` Shawn Guo
2011-06-15 3:10 ` Shawn Guo
2011-06-15 10:33 ` Shawn Guo
2011-06-15 10:33 ` Shawn Guo
2011-06-15 10:44 ` Wolfram Sang
2011-06-15 10:44 ` Wolfram Sang
2011-06-14 6:48 ` [PATCH 0/4] Extend sdhci-esdhc-imx " Shawn Guo
2011-06-14 6:48 ` Shawn Guo
2011-06-14 11:13 ` Arnaud Patard
2011-06-14 11:13 ` Arnaud Patard (Rtp)
2011-06-14 11:39 ` Shawn Guo
2011-06-14 11:39 ` Shawn Guo
2011-06-14 13:12 ` Shawn Guo
2011-06-14 13:12 ` Shawn Guo
2011-06-14 14:29 ` Arnaud Patard
2011-06-14 14:29 ` Arnaud Patard (Rtp)
2011-06-15 3:13 ` Shawn Guo
2011-06-15 3:13 ` Shawn Guo
2011-06-16 18:32 ` Arnaud Patard
2011-06-16 18:32 ` Arnaud Patard (Rtp)
2011-06-20 10:41 ` Shawn Guo
2011-06-20 10:41 ` Shawn Guo
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=87boy4lnp9.fsf@lebrac.rtp-net.org \
--to=arnaud.patard@rtp-net.org \
--cc=cjb@laptop.org \
--cc=eric@eukrea.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=patches@linaro.org \
--cc=shawn.guo@linaro.org \
--cc=w.sang@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.