From: Arnd Bergmann <arnd@arndb.de>
To: J Freyensee <james_p_freyensee@linux.intel.com>
Cc: Shashidhar Hiremath <shashidharh@vayavyalabs.com>,
Chris Ball <cjb@laptop.org>,
John Calixto <john.calixto@modsystems.com>,
linux-mmc@vger.kernel.org
Subject: Re: A question on IOCTL interface for MMC
Date: Thu, 17 Nov 2011 15:46:10 +0000 [thread overview]
Message-ID: <201111171546.10214.arnd@arndb.de> (raw)
In-Reply-To: <4EA5AE64.2030106@linux.intel.com>
On Monday 24 October 2011, J Freyensee wrote:
> On 10/24/2011 05:32 AM, Shashidhar Hiremath wrote:
> > Hi Arnd,
> > As explained in previous mail, the IOCTL is actually an inteface to
> > block layer and it is only expecting read/write commands to be sent
> > through the interface.The prrof of it can be seen in write_flag
> > present in the IOCTL structure which indicates the either the command
> > can be read or a write command.
> >
> > So, can I submit a linux module to the kernel which uses the same
> > mmc_ioc_cmd structure and do all the required processing in my module.
> >
> > To be clear on my requirement:
> > it is To test ALL SD/MMC Commands and NOT just the Read/Write Commands.
> > or should I extend the mmc_test module present in kernel to support
> > testing of individual commands as well ?
>
> I would think the mmc_test module would be a good vehicle to extend to
> have it test individual commands.
>
> Of course if there is no documentation or HOWTO use mmc_test module to
> test an individual MMC command then the work is kind-of for naught.
I'm still catching up on my email after travelling. I'm sorry I did not
catch this earlier, because this seems to be the source of the confusion
that lead to the suboptimal implementation of test code in the kernel
driver.
I believe the correct answer to the original question would have been
that any command that does not take an argument should just pass
a length of zero on the ioctl interface. If I read the code correctly,
this needs at least a change to mmc_blk_ioctl_copy_from_user to
handle zero-length arguments, and there are possibly some other
issues, but I think that should let you do everything you need.
Arnd
next prev parent reply other threads:[~2011-11-17 15:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-20 5:09 A question on IOCTL interface for MMC Shashidhar Hiremath
2011-10-20 7:18 ` Arnd Bergmann
2011-10-24 12:32 ` Shashidhar Hiremath
2011-10-24 16:39 ` Chris Ball
2011-10-24 18:28 ` J Freyensee
2011-11-17 15:46 ` Arnd Bergmann [this message]
2011-10-20 14:55 ` Andrei Warkentin
2011-10-21 4:34 ` Shashidhar Hiremath
2011-10-21 15:10 ` Shashidhar Hiremath
2011-10-21 15:01 ` OMAP HSMMC data timeout calculation Hebbar, Gururaja
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=201111171546.10214.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=cjb@laptop.org \
--cc=james_p_freyensee@linux.intel.com \
--cc=john.calixto@modsystems.com \
--cc=linux-mmc@vger.kernel.org \
--cc=shashidharh@vayavyalabs.com \
/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.