On Tue, Apr 12, 2011 at 12:13 AM, Chris Ball c...@laptop.org wrote:
Hi Ameya,
On Tue, Apr 05 2011, Ameya Palande wrote:
This patch fixes 21 errors and 6 warnings reported by checkpatch.pl
Signed-off-by: Ameya Palande 2am...@gmail.com
Thanks, pushed to mmc-next for .40 with Wolfram's
-Original Message-
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Andrei Warkentin
Sent: Tuesday, April 12, 2011 5:14 AM
To: linux-mmc@vger.kernel.org
Cc: a...@arndb.de; c...@laptop.org; Andrei Warkentin
Subject: [patchv3 2/4] MMC:
2011/4/11 John Calixto john.cali...@modsystems.com:
[...]
--- /dev/null
+++ b/include/linux/mmc/ioctl.h
@@ -0,0 +1,32 @@
+#ifndef _MMC_IOCTL_H
+#define _MMC_IOCTL_H
+struct mmc_ioc_cmd {
+ /* implies direction of data. true = write, false = read */
+ int write_flag;
+
+
---
include/linux/mmc/card.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20110412.orig/include/linux/mmc/card.h
+++ linux-next-20110412/include/linux/mmc/card.h
@@ -180,7 +180,7 @@ struct mmc_fixup {
int data;
};
-#define CID_MANFID_ANY (-1ul)
+#define
Ball c...@laptop.org
Cc: linux-mmc@vger.kernel.org
---
include/linux/mmc/card.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20110412.orig/include/linux/mmc/card.h
+++ linux-next-20110412/include/linux/mmc/card.h
@@ -180,7 +180,7 @@ struct mmc_fixup {
int
Hi Mikko,
On Tue, Mar 29 2011, Mikko Vinni wrote:
Some SD host controllers (noticed on an integrated JMicron
SD reader on an HP Pavilion dv5-1250eo laptop) don't update
the dma address register before signaling a dma interrupt due
to a dma boundary. Update the register manually to the next
On Tue, Apr 12, 2011 at 4:06 AM, Dong, Chuanxiao
chuanxiao.d...@intel.com wrote:
-Original Message-
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Andrei Warkentin
Sent: Tuesday, April 12, 2011 5:14 AM
To: linux-mmc@vger.kernel.org
Cc:
On Tue, Apr 12, 2011 at 11:57 AM, Chris Ball c...@laptop.org wrote:
Hi Andrei,
On Mon, Apr 11 2011, Andrei Warkentin wrote:
This fixes the out-of-spec erase/trim support. CMD38 argument
is passed through an EXT_CSD byte instead of as the command
argument. This has the effect that trims act
Hi,
(Adding linux-mmc@.)
On Tue, Apr 12 2011, Cyril Hrubis wrote:
Hi!
When I insert the mmc card to zaurus, it gets properly detected and prints
some
info into console. Mounting reading/writing files works fine.
However when the card is removed (doesn't need to be mounted before), the
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 40 +++-
include/linux/mmc/card.h |1 +
2 files changed, 40 insertions(+), 1 deletions(-)
diff --git
On Tue, Apr 12, 2011 at 3:03 PM, Andrei Warkentin andr...@motorola.com wrote:
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
Wrong version again, sorry! :(
A
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 43 ++-
include/linux/mmc/card.h |1 +
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git
Hi Andrei,
On Tue, Apr 12 2011, Andrei Warkentin wrote:
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 40 +++-
include/linux/mmc/card.h |1 +
2 files changed, 40
On Tue, Apr 12, 2011 at 2:33 PM, Chris Ball c...@laptop.org wrote:
Hi Andrei,
On Tue, Apr 12 2011, Andrei Warkentin wrote:
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
You're still missing the final argument to mmc_switch(), no?
Hi Andrei,
On Tue, Apr 12 2011, Andrei Warkentin wrote:
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 43 ++-
include/linux/mmc/card.h |1 +
2 files changed,
Hi!
When I insert the mmc card to zaurus, it gets properly detected and prints
some
info into console. Mounting reading/writing files works fine.
However when the card is removed (doesn't need to be mounted before), the
removal is most likely not detected, so when I insert it again,
Hi,
On Tue, Apr 12 2011, Cyril Hrubis wrote:
Your symptoms match the bug that was fixed by:
bad3babace2ee4d (mmc: fix CONFIG_MMC_UNSAFE_RESUME regression)
but this fix made it into 2.6.38, so if you're using 2.6.38 final then
you shouldn't be seeing this. Could you confirm that you have
Hi!
Your symptoms match the bug that was fixed by:
bad3babace2ee4d (mmc: fix CONFIG_MMC_UNSAFE_RESUME regression)
but this fix made it into 2.6.38, so if you're using 2.6.38 final then
you shouldn't be seeing this. Could you confirm that you have this
patch?
It seems that the
Hi,
On Tue, Apr 12 2011, Cyril Hrubis wrote:
Tried 2.6.39-rc3 both with and without CONFIG_MMC_UNSAFE_RESUME and the
insert/remove detection works but both with and without unsafe resume, if the
card is removed for more than second or two it fails to recognize the card
after insertion failing
Hi,
On Tue, Apr 12 2011, Chris Ball wrote:
There aren't many -EOPNOTSUPP returns in the stack. I see:
card/block.c: mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq
card/core.c: mmc_erase
core/sd_ops.c: mmc_app_cmd
Mind doing some instrumentation to figure out which it is?
On Tue, 12 Apr 2011, Michał Mirosław wrote:
2011/4/11 John Calixto john.cali...@modsystems.com:
[...]
--- /dev/null
+++ b/include/linux/mmc/ioctl.h
@@ -0,0 +1,32 @@
+#ifndef _MMC_IOCTL_H
+#define _MMC_IOCTL_H
+struct mmc_ioc_cmd {
+ /* implies direction of data. true =
Hi!
Tried 2.6.39-rc3 both with and without CONFIG_MMC_UNSAFE_RESUME and the
insert/remove detection works but both with and without unsafe resume, if
the
card is removed for more than second or two it fails to recognize the card
after insertion failing with:
mmc0: error -95 whilst
A small fix for a compiler warning. Thanks to Michał Mirosław for
suggesting the solution!
Patch history below:
- v5
- fix 32-bit compiler warning about the 32+64 compat pointer
- v4
- replace postsleep udelay() with usleep_range()
- add cmd_timeout_ms field for R1B commands
- v3
Sending ACMDs from userspace is useful for such things as:
- The security application of an SD card (SD Specification, Part 3,
Security)
- SD passthrough for virtual machines
Tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC, TI OMAP3621
SoC, TI OMAP3630 SoC, Samsung S5PC110
On Tuesday 12 April 2011, Michał Mirosław wrote:
+ unsigned int cmd_timeout_ms;
+ __u64 data_ptr; /* DAT buffer */
This will be more natural if you have an anonymous union here:
union {
__u64 data_ptr_
void *data_ptr;
};
No, that really does not work. It's important for
On Wed, 13 Apr 2011, Arnd Bergmann wrote:
On Tuesday 12 April 2011, Michał Mirosław wrote:
+ unsigned int cmd_timeout_ms;
+ __u64 data_ptr; /* DAT buffer */
This will be more natural if you have an anonymous union here:
union {
__u64 data_ptr_
void *data_ptr;
};
On Monday 11 April 2011, John Calixto wrote:
Sending ACMDs from userspace is useful for such things as:
- The security application of an SD card (SD Specification, Part 3,
Security)
- SD passthrough for virtual machines
Tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652
Please ignore v5. The fix for the compiler warning is not appropriate
for all endians/archs.
John
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd,
On Wed, 13 Apr 2011, Arnd Bergmann wrote:
On Monday 11 April 2011, John Calixto wrote:
Sending ACMDs from userspace is useful for such things as:
- The security application of an SD card (SD Specification, Part 3,
Security)
- SD passthrough for virtual
-Original Message-
From: Andrei Warkentin [mailto:andr...@motorola.com]
Sent: Wednesday, April 13, 2011 2:05 AM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; a...@arndb.de; c...@laptop.org
Subject: Re: [patchv3 2/4] MMC: SDHCI R1B command handling +
MMC_CAP_ERASE.
On Tue,
On Tue, Apr 12, 2011 at 8:59 PM, Dong, Chuanxiao
chuanxiao.d...@intel.com wrote:
Yes, if all the consumers of mmc_command memset the structure to 0, there
will be no problem. But just reviewed the code, and found mmc_app_cmd() (in
sd_ops.c) didn't memset the command structure. So I think if
31 matches
Mail list logo
