Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
Hi Arnd, thanks for the reply. On Tue, Nov 22, 2011 at 9:34 PM, Arnd Bergmann wrote: > On Friday 18 November 2011, Shashidhar Hiremath wrote: >> Hi Arnd, >> Please forgive me for a lengthy mail. >> >> firstly, the Patch has not added testcases in kernel, but has added >> support infrastructure for handling different commands. Function >> names are misnomers and “.test_CMD0” should have instead been >> “send_CMD0”. >> >> I have tried to express my views in 2 questions: >> >> Q1 : What all Commands can be sent using MMC block layer IOCTL ? >> >> Currently it be used for sending only read/write commands. >> Should it also not support non-data (read/write) commands ? >> If Yes, then the “block.c” must be modified with few changes to >> handle non-data commands by making the read/write code conditional. >> >> Ex: Code snippet below has to be made conditional i.e. execute only >> for read/write commands >> >> data.sg = &sg; >> data.sg_len = 1; >> data.blksz = idata->ic.blksz; >> data.blocks = idata->ic.blocks; >> >> sg_init_one(data.sg, idata->buf, idata->buf_bytes); >> >> if (idata->ic.write_flag) >> data.flags = MMC_DATA_WRITE; >> else >> data.flags = MMC_DATA_READ; > > This is all fine, I don't object at all to changing the code so it > supports non-data commands. It should be easy enough to make the above > code get executed only if idata->buf_bytes is positive. > >> Q2 : Can I send CMD 9 (or any non-data command) via the mmc blk layer >> IOCTL ? If not what are the issues ? >> >> As of now non-data commands are not supported. So in order to send CMD >> 9, the card has to be brought to a certain known state by sending the >> pre CMD 9 sequence. > > The command interface we have is for very low-level commands, and the > kernel should not try to intercept these. > >> As per the Specification, before sending CMD 9, the following commands >> have to be sent >> Pre-CMD 9 Sequence >> CMD0 : Reset >> CMD8 : Get ocr >> CMD55 : App command >> CMD41 : >> CMD2 : >> CMD3 : >> >> ... >> >> From user space, in order to send CMD9, the above code snippet should >> be available as a single stand alone function. As of now the mmc core >> state machine has a single flow which is card enumeration. But if we >> want to send stand alone commands from user space, the enumeration >> flow has to be broken into single standalone functions specific to the >> commands that is they have to send the pre command sequence and get >> the card to the proper state to send the user specified command. > > I think it is reasonable to require user space to know that it needs to > send all the other commands before it can send CMD9. However, if you > need the mmc_block driver to perform any other operations besides > sending commands to the card, you can add new ioctl commands for > this, e.g. you can have one ioctl to tell the block driver to > get out of the way and not accept any requests from the block layer > while you are sending low-level commands, and another ioctl to > tell the block layer to rescan the card in order to get it into > a known working state again after you are done with the tests. Would > that work for you? Yes, extra ioctl's can help me bringing the card to defined state. I will try implementing with this approach. > >> The command sent should also work in following scenarios:- >> CASE 1 : Card enumerated, and ready for transfer >> CASE 2 : Card is reset >> CASE 3 : CMD 9 has been sent, now can I send CMD 8 > > Why is that a requirement? I would argue that the user application > already does things that are outside of the scope of normal > operation, so it should know what it is doing and cannot expect > the kernel to perform extra magic behind its back. I Agree, Kernel need not worry about these scenarios.. > > Arnd > -- regards, Shashidhar Hiremath -- 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
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
On Friday 18 November 2011, Shashidhar Hiremath wrote: > Hi Arnd, > Please forgive me for a lengthy mail. > > firstly, the Patch has not added testcases in kernel, but has added > support infrastructure for handling different commands. Function > names are misnomers and “.test_CMD0” should have instead been > “send_CMD0”. > > I have tried to express my views in 2 questions: > > Q1 : What all Commands can be sent using MMC block layer IOCTL ? > >Currently it be used for sending only read/write commands. >Should it also not support non-data (read/write) commands ? >If Yes, then the “block.c” must be modified with few changes to > handle non-data commands by making the read/write code conditional. > > Ex: Code snippet below has to be made conditional i.e. execute only > for read/write commands > > data.sg = &sg; > data.sg_len = 1; > data.blksz = idata->ic.blksz; > data.blocks = idata->ic.blocks; > > sg_init_one(data.sg, idata->buf, idata->buf_bytes); > > if (idata->ic.write_flag) > data.flags = MMC_DATA_WRITE; > else > data.flags = MMC_DATA_READ; This is all fine, I don't object at all to changing the code so it supports non-data commands. It should be easy enough to make the above code get executed only if idata->buf_bytes is positive. > Q2 : Can I send CMD 9 (or any non-data command) via the mmc blk layer > IOCTL ? If not what are the issues ? > > As of now non-data commands are not supported. So in order to send CMD > 9, the card has to be brought to a certain known state by sending the > pre CMD 9 sequence. The command interface we have is for very low-level commands, and the kernel should not try to intercept these. > As per the Specification, before sending CMD 9, the following commands > have to be sent > Pre-CMD 9 Sequence > CMD0 : Reset > CMD8 : Get ocr > CMD55 : App command > CMD41 : > CMD2 : > CMD3 : > > ... > > From user space, in order to send CMD9, the above code snippet should > be available as a single stand alone function. As of now the mmc core > state machine has a single flow which is card enumeration. But if we > want to send stand alone commands from user space, the enumeration > flow has to be broken into single standalone functions specific to the > commands that is they have to send the pre command sequence and get > the card to the proper state to send the user specified command. I think it is reasonable to require user space to know that it needs to send all the other commands before it can send CMD9. However, if you need the mmc_block driver to perform any other operations besides sending commands to the card, you can add new ioctl commands for this, e.g. you can have one ioctl to tell the block driver to get out of the way and not accept any requests from the block layer while you are sending low-level commands, and another ioctl to tell the block layer to rescan the card in order to get it into a known working state again after you are done with the tests. Would that work for you? > The command sent should also work in following scenarios:- >CASE 1 : Card enumerated, and ready for transfer >CASE 2 : Card is reset >CASE 3 : CMD 9 has been sent, now can I send CMD 8 Why is that a requirement? I would argue that the user application already does things that are outside of the scope of normal operation, so it should know what it is doing and cannot expect the kernel to perform extra magic behind its back. Arnd -- 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
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
Hi Arnd,
Please forgive me for a lengthy mail.
firstly, the Patch has not added testcases in kernel, but has added
support infrastructure for handling different commands. Function
names are misnomers and “.test_CMD0” should have instead been
“send_CMD0”.
I have tried to express my views in 2 questions:
Q1 : What all Commands can be sent using MMC block layer IOCTL ?
Currently it be used for sending only read/write commands.
Should it also not support non-data (read/write) commands ?
If Yes, then the “block.c” must be modified with few changes to
handle non-data commands by making the read/write code conditional.
Ex: Code snippet below has to be made conditional i.e. execute only
for read/write commands
data.sg = &sg;
data.sg_len = 1;
data.blksz = idata->ic.blksz;
data.blocks = idata->ic.blocks;
sg_init_one(data.sg, idata->buf, idata->buf_bytes);
if (idata->ic.write_flag)
data.flags = MMC_DATA_WRITE;
else
data.flags = MMC_DATA_READ;
Q2 : Can I send CMD 9 (or any non-data command) via the mmc blk layer
IOCTL ? If not what are the issues ?
As of now non-data commands are not supported. So in order to send CMD
9, the card has to be brought to a certain known state by sending the
pre CMD 9 sequence.
As per the Specification, before sending CMD 9, the following commands
have to be sent
Pre-CMD 9 Sequence
CMD0 : Reset
CMD8 : Get ocr
CMD55 : App command
CMD41 :
CMD2 :
CMD3 :
The implementation for the above can be seen mmc.c file snippet shown below
CODE SNIPPET : linux/driver/core/mmc.c
/*
* Since we're changing the OCR value, we seem to
* need to tell some cards to go back to the idle
* state. We wait 1ms to give cards time to
* respond.
* mmc_go_idle is needed for eMMC that are asleep
*/
mmc_go_idle(host);
/* The extra bit indicates that we support high capacity */
err = mmc_send_op_cond(host, ocr | (1 << 30), &rocr);
if (err)
goto err;
/*
* For SPI, enable CRC as appropriate.
*/
if (mmc_host_is_spi(host)) {
err = mmc_spi_set_crc(host, use_spi_crc);
if (err)
goto err;
}
/*
* Fetch CID from card.
*/
if (mmc_host_is_spi(host))
err = mmc_send_cid(host, cid);
else
err = mmc_all_send_cid(host, cid);
if (err)
goto err;
if (oldcard) {
if (memcmp(cid, oldcard->raw_cid, sizeof(cid)) != 0) {
err = -ENOENT;
goto err;
}
card = oldcard;
} else {
/*
* Allocate card structure.
*/
card = mmc_alloc_card(host, &mmc_type);
if (IS_ERR(card)) {
err = PTR_ERR(card);
goto err;
}
card->type = MMC_TYPE_MMC;
card->rca = 1;
memcpy(card->raw_cid, cid, sizeof(card->raw_cid));
}
/*
* For native busses: set card RCA and quit open drain mode.
*/
if (!mmc_host_is_spi(host)) {
err = mmc_set_relative_addr(card);
if (err)
goto free_card;
mmc_set_bus_mode(host, MMC_BUSMODE_PUSHPULL);
}
if (!oldcard) {
/*
* Fetch CSD from card.
*/
err = mmc_send_csd(card, card->raw_csd);
if (err)
goto free_card;
err = mmc_decode_csd(card);
if (err)
goto free_card;
err = mmc_decode_cid(card); //send CMD9
if (err)
goto free_card;
}
From user space, in order to send CMD9, the above code snippet should
be available as a single stand alone function. As of now the mmc core
state machine has a single flow which is card enumeration. But if we
want to send stand alone commands from user space, the enumeration
flow has to be broken into single standalone functions specific to the
commands that is they have to send the pre command sequence and get
the card to the proper state to send the user specified command.
The command sent should also work in following scenarios:-
CASE 1 : Card enumerated, and ready for transfer
CASE 2 : Card is reset
CASE 3 : CMD 9 has been sent, now can I send CMD 8
On Thu, Nov 17, 2011 at 8:11 PM, Arnd Bergmann wrote:
> On Wednesday 16 November 2011, Shashidhar Hiremath wrote:
>> The patch provides An infrastructure to test commands other than Read/Write
>> commands using the IOCTL interface.The Patch can be u
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
On Wednesday 16 November 2011, Shashidhar Hiremath wrote: > The patch provides An infrastructure to test commands other than Read/Write > commands using the IOCTL interface.The Patch can be useful incase of > validating the device to verify whether device support a given command or > not. The result of the sent command will be written to the result element of > the mmc_ioc_cmd structure passed through IOCTL interface. > > Signed-off-by: Shashidhar Hiremath Hi Shashidhar, Unfortunately, I have to tell you that an implementation like this is inappropriate for a number of reasons. My feeling is that most importantly you should instead have the test logic entirely in user space and only call the existing ioctl in the kernel. This would make the entire patch obsolete, so I'm not commenting on the other problems. What has lead you to implementing the individual test cases in the kernel? Arnd -- 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
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
Yes,
Please find the attachment for the user space application.
On Thu, Nov 17, 2011 at 5:50 PM, S, Venkatraman wrote:
> On Thu, Nov 17, 2011 at 4:48 PM, Shashidhar Hiremath
> wrote:
>> Hi Venkatraman,
>> If I understand correctly, You want the test_cmds.c file to be
>> compiled conditionally based on the menuconfig option for
>> CONFIG_MMC_TEST right ?
>
> Yes.
> BTW, do you have any user space utilities for testing this ?
> I'd be inclined to give it a run.
>
>>
>> On Thu, Nov 17, 2011 at 4:04 PM, S, Venkatraman wrote:
>>> On Wed, Nov 16, 2011 at 4:38 PM, Shashidhar Hiremath
>>> wrote:
The patch provides An infrastructure to test commands other than
Read/Write commands using the IOCTL interface.The Patch can be useful
incase of validating the device to verify whether device support a given
command or not. The result of the sent command will be written to the
result element of the mmc_ioc_cmd structure passed through IOCTL interface.
Signed-off-by: Shashidhar Hiremath
---
drivers/mmc/card/Makefile | 2 +-
drivers/mmc/card/block.c | 28 ++
drivers/mmc/card/test_cmds.c | 743
++
drivers/mmc/card/test_cmds.h | 53 +++
drivers/mmc/core/core.c | 4 +
drivers/mmc/core/mmc.c | 4 +
drivers/mmc/core/mmc_ops.c | 1 +
drivers/mmc/core/sd.c | 2 +
include/linux/mmc/ioctl.h | 1 +
9 files changed, 837 insertions(+), 1 deletions(-)
create mode 100644 drivers/mmc/card/test_cmds.c
create mode 100644 drivers/mmc/card/test_cmds.h
diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile
index c73b406..ea52ee1 100644
--- a/drivers/mmc/card/Makefile
+++ b/drivers/mmc/card/Makefile
@@ -3,7 +3,7 @@
#
obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
-mmc_block-objs := block.o queue.o
+mmc_block-objs := block.o queue.o test_cmds.o
>>>
>>> Why should it be included by default ?
>>> I think it belongs under CONFIG_MMC_TEST
>>>
obj-$(CONFIG_MMC_TEST) += mmc_test.o
>>>
>>
>>
>>
>> --
>> regards,
>> Shashidhar Hiremath
>>
>
--
regards,
Shashidhar Hiremath
#include
#include
#include
#include
#include
#define DEV_NAME "/dev/mmcblk0"
#define MMC_BLOCK_MAJOR 179
static struct mmc_ioc_cmd mmc_local_cmd;
int main(void)
{
int fd, ret_val,opcode;
printf("Please Enter the Command Index to be tested \n");
scanf("%d",&opcode);
mmc_local_cmd.opcode = opcode,
mmc_local_cmd.write_flag = 2,
mmc_local_cmd.data_ptr = (int)NULL,
fd = open(DEV_NAME, O_RDWR);
if (fd < 0) {
printf("cannot open device file: %s\n", DEV_NAME);
return -1;
}
ioctl(fd,MMC_IOC_CMD,&mmc_local_cmd);
if(mmc_local_cmd.result == 0)
printf("\nResult: OK\nTest Passed");
else if(mmc_local_cmd.result == 1)
printf("\nResult: Failed");
else if(mmc_local_cmd.result == 2)
printf("\nResult: Command Not Supported");
else if(mmc_local_cmd.result == 3)
printf("\nResult: Card Not Supported");
else {
printf("\nResult:ERROR %d Occured",mmc_local_cmd.result);
printf("\nResult: Please see Kernel log messages for detail");
}
close(fd);
return 0;
}
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
On Thu, Nov 17, 2011 at 4:48 PM, Shashidhar Hiremath wrote: > Hi Venkatraman, > If I understand correctly, You want the test_cmds.c file to be > compiled conditionally based on the menuconfig option for > CONFIG_MMC_TEST right ? Yes. BTW, do you have any user space utilities for testing this ? I'd be inclined to give it a run. > > On Thu, Nov 17, 2011 at 4:04 PM, S, Venkatraman wrote: >> On Wed, Nov 16, 2011 at 4:38 PM, Shashidhar Hiremath >> wrote: >>> The patch provides An infrastructure to test commands other than Read/Write >>> commands using the IOCTL interface.The Patch can be useful incase of >>> validating the device to verify whether device support a given command or >>> not. The result of the sent command will be written to the result element >>> of the mmc_ioc_cmd structure passed through IOCTL interface. >>> >>> Signed-off-by: Shashidhar Hiremath >>> --- >>> drivers/mmc/card/Makefile | 2 +- >>> drivers/mmc/card/block.c | 28 ++ >>> drivers/mmc/card/test_cmds.c | 743 >>> ++ >>> drivers/mmc/card/test_cmds.h | 53 +++ >>> drivers/mmc/core/core.c | 4 + >>> drivers/mmc/core/mmc.c | 4 + >>> drivers/mmc/core/mmc_ops.c | 1 + >>> drivers/mmc/core/sd.c | 2 + >>> include/linux/mmc/ioctl.h | 1 + >>> 9 files changed, 837 insertions(+), 1 deletions(-) >>> create mode 100644 drivers/mmc/card/test_cmds.c >>> create mode 100644 drivers/mmc/card/test_cmds.h >>> >>> diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile >>> index c73b406..ea52ee1 100644 >>> --- a/drivers/mmc/card/Makefile >>> +++ b/drivers/mmc/card/Makefile >>> @@ -3,7 +3,7 @@ >>> # >>> >>> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o >>> -mmc_block-objs := block.o queue.o >>> +mmc_block-objs := block.o queue.o test_cmds.o >> >> Why should it be included by default ? >> I think it belongs under CONFIG_MMC_TEST >> >>> obj-$(CONFIG_MMC_TEST) += mmc_test.o >>> >> > > > > -- > regards, > Shashidhar Hiremath > -- 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
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
Hi Venkatraman, If I understand correctly, You want the test_cmds.c file to be compiled conditionally based on the menuconfig option for CONFIG_MMC_TEST right ? On Thu, Nov 17, 2011 at 4:04 PM, S, Venkatraman wrote: > On Wed, Nov 16, 2011 at 4:38 PM, Shashidhar Hiremath > wrote: >> The patch provides An infrastructure to test commands other than Read/Write >> commands using the IOCTL interface.The Patch can be useful incase of >> validating the device to verify whether device support a given command or >> not. The result of the sent command will be written to the result element >> of the mmc_ioc_cmd structure passed through IOCTL interface. >> >> Signed-off-by: Shashidhar Hiremath >> --- >> drivers/mmc/card/Makefile | 2 +- >> drivers/mmc/card/block.c | 28 ++ >> drivers/mmc/card/test_cmds.c | 743 >> ++ >> drivers/mmc/card/test_cmds.h | 53 +++ >> drivers/mmc/core/core.c | 4 + >> drivers/mmc/core/mmc.c | 4 + >> drivers/mmc/core/mmc_ops.c | 1 + >> drivers/mmc/core/sd.c | 2 + >> include/linux/mmc/ioctl.h | 1 + >> 9 files changed, 837 insertions(+), 1 deletions(-) >> create mode 100644 drivers/mmc/card/test_cmds.c >> create mode 100644 drivers/mmc/card/test_cmds.h >> >> diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile >> index c73b406..ea52ee1 100644 >> --- a/drivers/mmc/card/Makefile >> +++ b/drivers/mmc/card/Makefile >> @@ -3,7 +3,7 @@ >> # >> >> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o >> -mmc_block-objs := block.o queue.o >> +mmc_block-objs := block.o queue.o test_cmds.o > > Why should it be included by default ? > I think it belongs under CONFIG_MMC_TEST > >> obj-$(CONFIG_MMC_TEST) += mmc_test.o >> > -- regards, Shashidhar Hiremath -- 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
Re: [PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
On Wed, Nov 16, 2011 at 4:38 PM, Shashidhar Hiremath wrote: > The patch provides An infrastructure to test commands other than Read/Write > commands using the IOCTL interface.The Patch can be useful incase of > validating the device to verify whether device support a given command or > not. The result of the sent command will be written to the result element of > the mmc_ioc_cmd structure passed through IOCTL interface. > > Signed-off-by: Shashidhar Hiremath > --- > drivers/mmc/card/Makefile | 2 +- > drivers/mmc/card/block.c | 28 ++ > drivers/mmc/card/test_cmds.c | 743 > ++ > drivers/mmc/card/test_cmds.h | 53 +++ > drivers/mmc/core/core.c | 4 + > drivers/mmc/core/mmc.c | 4 + > drivers/mmc/core/mmc_ops.c | 1 + > drivers/mmc/core/sd.c | 2 + > include/linux/mmc/ioctl.h | 1 + > 9 files changed, 837 insertions(+), 1 deletions(-) > create mode 100644 drivers/mmc/card/test_cmds.c > create mode 100644 drivers/mmc/card/test_cmds.h > > diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile > index c73b406..ea52ee1 100644 > --- a/drivers/mmc/card/Makefile > +++ b/drivers/mmc/card/Makefile > @@ -3,7 +3,7 @@ > # > > obj-$(CONFIG_MMC_BLOCK) += mmc_block.o > -mmc_block-objs := block.o queue.o > +mmc_block-objs := block.o queue.o test_cmds.o Why should it be included by default ? I think it belongs under CONFIG_MMC_TEST > obj-$(CONFIG_MMC_TEST) += mmc_test.o > -- 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
[PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
The patch provides An infrastructure to test commands other than Read/Write
commands using the IOCTL interface.The Patch can be useful incase of validating
the device to verify whether device support a given command or not. The result
of the sent command will be written to the result element of the mmc_ioc_cmd
structure passed through IOCTL interface.
Signed-off-by: Shashidhar Hiremath
---
drivers/mmc/card/Makefile|2 +-
drivers/mmc/card/block.c | 28 ++
drivers/mmc/card/test_cmds.c | 743 ++
drivers/mmc/card/test_cmds.h | 53 +++
drivers/mmc/core/core.c |4 +
drivers/mmc/core/mmc.c |4 +
drivers/mmc/core/mmc_ops.c |1 +
drivers/mmc/core/sd.c|2 +
include/linux/mmc/ioctl.h|1 +
9 files changed, 837 insertions(+), 1 deletions(-)
create mode 100644 drivers/mmc/card/test_cmds.c
create mode 100644 drivers/mmc/card/test_cmds.h
diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile
index c73b406..ea52ee1 100644
--- a/drivers/mmc/card/Makefile
+++ b/drivers/mmc/card/Makefile
@@ -3,7 +3,7 @@
#
obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
-mmc_block-objs := block.o queue.o
+mmc_block-objs := block.o queue.o test_cmds.o
obj-$(CONFIG_MMC_TEST) += mmc_test.o
obj-$(CONFIG_SDIO_UART)+= sdio_uart.o
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c80bb6d..c55d564 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -58,6 +58,7 @@ MODULE_ALIAS("mmc:block");
#define INAND_CMD38_ARG_SECERASE 0x80
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
+#define NON_DATA_CMD 2
static DEFINE_MUTEX(block_mutex);
@@ -77,6 +78,11 @@ static int max_devices;
static DECLARE_BITMAP(dev_use, 256);
static DECLARE_BITMAP(name_use, 256);
+/* prototype of function called for testing
+ * non-read-write commands
+ */
+void test_command(struct mmc_card *card, struct mmc_ioc_cmd *cmd);
+
/*
* There is one mmc_blk_data per slot.
*/
@@ -345,6 +351,28 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
mmc_claim_host(card->host);
+ /* Calling API for testing the non-read/write commands */
+ if (idata->ic.write_flag == NON_DATA_CMD) {
+ test_command(card, &(idata->ic));
+ err = 0;
+ if (copy_to_user(&(ic_ptr->response), cmd.resp
+, sizeof(cmd.resp))) {
+ err = -EFAULT;
+ goto cmd_rel_host;
+ }
+ /* The result of the state of the tested command is returned
+* to user space RESULT OK - 0, RESULT_FAIL - 1
+* RESUL_UNSUP_CMD - 2, RESULT_UNSUP_CARD - 3
+* Other Failures - any other integer.
+*/
+ if (copy_to_user(&(ic_ptr->result), &(idata->ic.result)
+, sizeof(idata->ic.result))) {
+ err = -EFAULT;
+ goto cmd_rel_host;
+ }
+ goto cmd_rel_host;
+ }
+
if (idata->ic.is_acmd) {
err = mmc_app_cmd(card->host, card);
if (err)
diff --git a/drivers/mmc/card/test_cmds.c b/drivers/mmc/card/test_cmds.c
new file mode 100644
index 000..dd9671f
--- /dev/null
+++ b/drivers/mmc/card/test_cmds.c
@@ -0,0 +1,743 @@
+/*
+ * linux/drivers/mmc/card/test_cmds.c
+ *
+ * This File implements functions for testing non-data commands
+ * through IOCTL interface.
+ *
+ * Copyright (C) 2011 Vayavya Labs Pvt. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../core/sd_ops.h"
+#include "../core/mmc_ops.h"
+#include "../core/sdio_ops.h"
+#include "test_cmds.h"
+
+static int mmc_test_CMD0(struct mmc_card *card)
+{
+ int ret;
+ struct mmc_host *host = card->host;
+
+ mmc_power_off(host);
+ mmc_power_up(host);
+
+ ret = mmc_go_idle(card->host);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int mmc_test_CMD1(struct mmc_card *card)
+{
+ int err = 0;
+ struct mmc_host *host = card->host;
+ u32 ocr;
+
+ if (card->type == MMC_TYPE_MMC) {
+ mmc_test_CMD0(card);
+
+ err = mmc_send_op_cond(card->host, 0, &ocr);
+ if (err)
+ return err;
+
+ /*
+* Sanity check the voltages that the card claims to
+* support.
+*/
+ if (ocr & 0x7F) {
+ printk(KERN_WARNING
+ "%s: card claims to support voltages
