1. sdhci_prepare_data: fix shadowing of count variable
u8 count
int count -> sg_cnt;
2. sdhci_add_host: assignment of integer to pointer
dma_mask = 0 -> dma_mask = NULL;
Signed-off-by: Tomas Winkler <[email protected]>
---
drivers/mmc/host/sdhci.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2eabfac..59db3de 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -672,14 +672,14 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
host->ioaddr + SDHCI_ADMA_ADDRESS);
}
} else {
- int count;
+ int sg_cnt;
- count = dma_map_sg(mmc_dev(host->mmc),
+ sg_cnt = dma_map_sg(mmc_dev(host->mmc),
data->sg, data->sg_len,
(data->flags & MMC_DATA_READ) ?
DMA_FROM_DEVICE :
DMA_TO_DEVICE);
- if (count == 0) {
+ if (sg_cnt == 0) {
/*
* This only happens when someone fed
* us an invalid request.
@@ -1583,7 +1583,7 @@ int sdhci_add_host(struct sdhci_host *host)
/* XXX: Hack to get MMC layer to avoid highmem */
if (!(host->flags & SDHCI_USE_DMA))
- mmc_dev(host->mmc)->dma_mask = 0;
+ mmc_dev(host->mmc)->dma_mask = NULL;
host->max_clk =
(caps & SDHCI_CLOCK_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
--
1.5.4.1
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
This patch cleans up endianity conversions im mmc core
and style errors in the 'for' statements
Signed-off-by: Tomas Winkler <[email protected]>
---
drivers/mmc/card/block.c | 5 ++---
drivers/mmc/core/mmc_ops.c | 15 ++++++++-------
drivers/mmc/core/sd_ops.c | 7 ++++---
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 4b0f822..fbee07f 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -144,7 +144,7 @@ struct mmc_blk_request {
static u32 mmc_sd_num_wr_blocks(struct mmc_card *card)
{
int err;
- u32 blocks;
+ __be32 blocks;
struct mmc_request mrq;
struct mmc_command cmd;
@@ -203,9 +203,8 @@ static u32 mmc_sd_num_wr_blocks(struct mmc_card *card)
if (cmd.error || data.error)
return (u32)-1;
- blocks = ntohl(blocks);
- return blocks;
+ return be32_to_cpu(blocks);
}
static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 64b05c6..8187aea 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -267,17 +267,18 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
int mmc_send_csd(struct mmc_card *card, u32 *csd)
{
int ret, i;
+ __be32 csd_buf[4];
if (!mmc_host_is_spi(card->host))
return mmc_send_cxd_native(card->host, card->rca << 16,
csd, MMC_SEND_CSD);
- ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd, 16);
+ ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd_buf, 16);
if (ret)
return ret;
- for (i = 0;i < 4;i++)
- csd[i] = be32_to_cpu(csd[i]);
+ for (i = 0; i < 4; i++)
+ csd[i] = be32_to_cpu(csd_buf[i]);
return 0;
}
@@ -285,7 +286,7 @@ int mmc_send_csd(struct mmc_card *card, u32 *csd)
int mmc_send_cid(struct mmc_host *host, u32 *cid)
{
int ret, i;
-
+ __be32 cid_buf[4];
if (!mmc_host_is_spi(host)) {
if (!host->card)
return -EINVAL;
@@ -293,12 +294,12 @@ int mmc_send_cid(struct mmc_host *host, u32 *cid)
cid, MMC_SEND_CID);
}
- ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid, 16);
+ ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid_buf, 16);
if (ret)
return ret;
- for (i = 0;i < 4;i++)
- cid[i] = be32_to_cpu(cid[i]);
+ for (i = 0; i < 4; i++)
+ cid[i] = be32_to_cpu(cid_buf[i]);
return 0;
}
diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
index 0d96080..7ef7b6c 100644
--- a/drivers/mmc/core/sd_ops.c
+++ b/drivers/mmc/core/sd_ops.c
@@ -254,6 +254,7 @@ int mmc_app_send_scr(struct mmc_card *card, u32 *scr)
struct mmc_command cmd;
struct mmc_data data;
struct scatterlist sg;
+ __be32 scr_buf[2];
BUG_ON(!card);
BUG_ON(!card->host);
@@ -282,7 +283,7 @@ int mmc_app_send_scr(struct mmc_card *card, u32 *scr)
data.sg = &sg;
data.sg_len = 1;
- sg_init_one(&sg, scr, 8);
+ sg_init_one(&sg, scr_buf, 8);
mmc_set_data_timeout(&data, card);
@@ -293,8 +294,8 @@ int mmc_app_send_scr(struct mmc_card *card, u32 *scr)
if (data.error)
return data.error;
- scr[0] = be32_to_cpu(scr[0]);
- scr[1] = be32_to_cpu(scr[1]);
+ scr[0] = be32_to_cpu(scr_buf[0]);
+ scr[1] = be32_to_cpu(scr_buf[1]);
return 0;
}
--
1.5.4.1
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Sat, 5 Jul 2008 19:52:05 +0300
Tomas Winkler <[email protected]> wrote:
> This patch cleans up endianity conversions im mmc core
> and style errors in the 'for' statements
>
> Signed-off-by: Tomas Winkler <[email protected]>
> ---
NAK in its current form. The data needs to be DMA:able, which means
that the stack cannot be used.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Sat, 5 Jul 2008 19:52:04 +0300
Tomas Winkler <[email protected]> wrote:
> 1. sdhci_prepare_data: fix shadowing of count variable
> u8 count
> int count -> sg_cnt;
> 2. sdhci_add_host: assignment of integer to pointer
> dma_mask = 0 -> dma_mask = NULL;
>
> Signed-off-by: Tomas Winkler <[email protected]>
> ---
Applied, thanks.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
>-----Original Message-----
>From: Pierre Ossman [mailto:[email protected]]
>Sent: Sunday, July 06, 2008 2:27 AM
>To: Winkler, Tomas
>Cc: [email protected]; [email protected]; Winkler, Tomas
>Subject: Re: [PATCH 2/2 V2] MMC: cleanup endianity conversions and
style
>problems
>
>On Sat, 5 Jul 2008 19:52:05 +0300
>Tomas Winkler <[email protected]> wrote:
>
>> This patch cleans up endianity conversions im mmc core
>> and style errors in the 'for' statements
>>
>> Signed-off-by: Tomas Winkler <[email protected]>
>> ---
>
>NAK in its current form. The data needs to be DMA:able, which means
>that the stack cannot be used.
>
I see, anyway only the last hunk is problematic in this matter.
So we need to define raw_src as __be32 and translate it in
mmc_decode_src
I will get to the MMC spec only tomorrow but it sound strange that SDIO
registers are in little endian and these are in big.
Thanks
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Sun, 6 Jul 2008 02:54:56 +0300
"Winkler, Tomas" <[email protected]> wrote:
> >
> >NAK in its current form. The data needs to be DMA:able, which means
> >that the stack cannot be used.
> >
> I see, anyway only the last hunk is problematic in this matter.
>
All of them actually. The other registers are possible DMA victims when
on an SPI host (which is also the only code path your patch modifies).
> So we need to define raw_src as __be32 and translate it in
> mmc_decode_src
I'd prefer if raw_scr is in native endian. The conversions should be
done at the entry/exit points IMO.
> I will get to the MMC spec only tomorrow but it sound strange that SDIO
> registers are in little endian and these are in big.
I'd say that it's SDIO that's the odd man. Protocols tend to use big
endian after all. A reason for the difference is probably that SDIO
should be regarded as a register interface, not as a bus protocol.
Different worlds, different norms...
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.