There are discrepancies with regards to how MMC capabilities
are carried throughout the subsystem. Let's standardise them
to elevate any confusion.
Cc: Chris Ball <[email protected]>
Cc: [email protected]
Signed-off-by: Lee Jones <[email protected]>
---
drivers/mmc/core/mmc.c | 2 +-
include/linux/mmc/dw_mmc.h | 4 ++--
include/linux/mmc/host.h | 4 ++--
include/linux/mmc/sdhci.h | 4 ++--
include/linux/platform_data/pxa_sdhci.h | 4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 7cc4638..8c2fa80 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -239,7 +239,7 @@ static void mmc_select_card_type(struct mmc_card *card)
{
struct mmc_host *host = card->host;
u8 card_type = card->ext_csd.raw_card_type & EXT_CSD_CARD_TYPE_MASK;
- unsigned int caps = host->caps, caps2 = host->caps2;
+ u32 caps = host->caps, caps2 = host->caps2;
unsigned int hs_max_dtr = 0;
if (card_type & EXT_CSD_CARD_TYPE_26)
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 7c6a113..f825379 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -229,8 +229,8 @@ struct dw_mci_board {
u32 quirks; /* Workaround / Quirk flags */
unsigned int bus_hz; /* Clock speed at the cclk_in pad */
- unsigned int caps; /* Capabilities */
- unsigned int caps2; /* More capabilities */
+ u32 caps; /* Capabilities */
+ u32 caps2; /* More capabilities */
/*
* Override fifo depth. If 0, autodetect it from the FIFOTH register,
* but note that this may not be reliable after a bootloader has used
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7abb0e1..37442b2 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -211,7 +211,7 @@ struct mmc_host {
#define MMC_VDD_34_35 0x00400000 /* VDD voltage 3.4 ~ 3.5 */
#define MMC_VDD_35_36 0x00800000 /* VDD voltage 3.5 ~ 3.6 */
- unsigned long caps; /* Host capabilities */
+ u32 caps; /* Host capabilities */
#define MMC_CAP_4_BIT_DATA (1 << 0) /* Can the host do 4 bit transfers */
#define MMC_CAP_MMC_HIGHSPEED (1 << 1) /* Can do MMC high-speed timing */
@@ -241,7 +241,7 @@ struct mmc_host {
#define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */
#define MMC_CAP_HW_RESET (1 << 31) /* Hardware reset */
- unsigned int caps2; /* More host capabilities */
+ u32 caps2; /* More host capabilities */
#define MMC_CAP2_BOOTPART_NOACC (1 << 0) /* Boot partition no access */
#define MMC_CAP2_CACHE_CTRL (1 << 1) /* Allow cache control */
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index fa8529a..c76b4a3 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -157,8 +157,8 @@ struct sdhci_host {
struct timer_list timer; /* Timer for timeouts */
- unsigned int caps; /* Alternative CAPABILITY_0 */
- unsigned int caps1; /* Alternative CAPABILITY_1 */
+ u32 caps; /* Alternative CAPABILITY_0 */
+ u32 caps1; /* Alternative CAPABILITY_1 */
unsigned int ocr_avail_sdio; /* OCR bit masks */
unsigned int ocr_avail_sd;
diff --git a/include/linux/platform_data/pxa_sdhci.h b/include/linux/platform_data/pxa_sdhci.h
index 59acd98..0d75008 100644
--- a/include/linux/platform_data/pxa_sdhci.h
+++ b/include/linux/platform_data/pxa_sdhci.h
@@ -48,8 +48,8 @@ struct sdhci_pxa_platdata {
unsigned int ext_cd_gpio;
bool ext_cd_gpio_invert;
unsigned int max_speed;
- unsigned int host_caps;
- unsigned int host_caps2;
+ u32 host_caps;
+ u32 host_caps2;
unsigned int quirks;
unsigned int pm_caps;
};
--
1.7.9.5
On Wed, Nov 14, 2012 at 1:35 PM, Lee Jones <[email protected]> wrote:
> There are discrepancies with regards to how MMC capabilities
> are carried throughout the subsystem. Let's standardise them
> to elevate any confusion.
>
> Cc: Chris Ball <[email protected]>
> Cc: [email protected]
> Signed-off-by: Lee Jones <[email protected]>
Looks good to me, and these are obviously
u32 bitfields by design, so:
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
On Thursday 15 November 2012, Linus Walleij wrote:
>
> On Wed, Nov 14, 2012 at 1:35 PM, Lee Jones <[email protected]> wrote:
>
> > There are discrepancies with regards to how MMC capabilities
> > are carried throughout the subsystem. Let's standardise them
> > to elevate any confusion.
> >
> > Cc: Chris Ball <[email protected]>
> > Cc: [email protected]
> > Signed-off-by: Lee Jones <[email protected]>
>
> Looks good to me, and these are obviously
> u32 bitfields by design, so:
> Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Hi Lee,
Pushed to mmc-next for 3.8 with a minor change:
On Wed, Nov 14 2012, Lee Jones wrote:
> There are discrepancies with regards to how MMC capabilities
> are carried throughout the subsystem. Let's standardise them
> to elevate any confusion.
I think you meant "eliminate" here. :) Thanks,
- Chris.
--
Chris Ball <[email protected]> <http://printf.net/>
One Laptop Per Child
On Sat, 17 Nov 2012, Chris Ball wrote:
> Hi Lee,
>
> Pushed to mmc-next for 3.8 with a minor change:
>
> On Wed, Nov 14 2012, Lee Jones wrote:
> > There are discrepancies with regards to how MMC capabilities
> > are carried throughout the subsystem. Let's standardise them
> > to elevate any confusion.
>
> I think you meant "eliminate" here. :) Thanks,
No, I meant alleviate. :)
Do you want me to re-submit, or have you fixed up?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
On Mon, Nov 19 2012, Lee Jones wrote:
>> > There are discrepancies with regards to how MMC capabilities
>> > are carried throughout the subsystem. Let's standardise them
>> > to elevate any confusion.
>>
>> I think you meant "eliminate" here. :) Thanks,
>
> No, I meant alleviate. :)
>
> Do you want me to re-submit, or have you fixed up?
I already pushed with a change to "eliminate" -- I'll leave it like
that if that's okay.
Thanks,
- Chris.
--
Chris Ball <[email protected]> <http://printf.net/>
One Laptop Per Child
On Mon, 19 Nov 2012, Chris Ball wrote:
> Hi,
>
> On Mon, Nov 19 2012, Lee Jones wrote:
> >> > There are discrepancies with regards to how MMC capabilities
> >> > are carried throughout the subsystem. Let's standardise them
> >> > to elevate any confusion.
> >>
> >> I think you meant "eliminate" here. :) Thanks,
> >
> > No, I meant alleviate. :)
> >
> > Do you want me to re-submit, or have you fixed up?
>
> I already pushed with a change to "eliminate" -- I'll leave it like
> that if that's okay.
No problem.
Thanks Chris.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog