W dniu 21 kwietnia 2011 07:11 użytkownik Arnd Bergmann a...@arndb.de napisał:
On Wednesday 20 April 2011 21:46:04 Michał Mirosław wrote:
2011/4/20 Arnd Bergmann a...@arndb.de:
No, please don't try to invent random new ways of doing this.
Your example relies on the assumption that the task is
On Wednesday 20 April 2011, Chris Ball wrote:
On Wed, Apr 20 2011, John Calixto wrote:
Have you had the chance to look at v6 of this patch? If so, what do you
think?
Looks good to me. Since Arnd's been reviewing, it'd be nice to get a
Reviewed-by: tag from him and acknowledgement that
On Thursday 21 April 2011, Michał Mirosław wrote:
Subject: Re: [PATCH v4] mmc: Add ioctl to let userspace apps send ACMDs
Date: Wed, 13 Apr 2011 01:00:39 +0200
Message-Id: 201104130100.39810.a...@arndb.de
Then I already provided an example of implementation that's
independent of endianness
W dniu 21 kwietnia 2011 13:15 użytkownik Arnd Bergmann a...@arndb.de napisał:
On Thursday 21 April 2011, Michał Mirosław wrote:
Subject: Re: [PATCH v4] mmc: Add ioctl to let userspace apps send ACMDs
Date: Wed, 13 Apr 2011 01:00:39 +0200
Message-Id: 201104130100.39810.a...@arndb.de
Then I
On Thursday 21 April 2011, Michał Mirosław wrote:
W dniu 21 kwietnia 2011 13:15 użytkownik Arnd Bergmann a...@arndb.de
napisał:
static int mmc_blk_compat_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct mmc_ioc_cmd blk;
if (cmd !=
W dniu 21 kwietnia 2011 14:39 użytkownik Arnd Bergmann a...@arndb.de napisał:
On Thursday 21 April 2011, Michał Mirosław wrote:
W dniu 21 kwietnia 2011 13:15 użytkownik Arnd Bergmann a...@arndb.de
napisał:
static int mmc_blk_compat_ioctl(struct block_device *bdev, fmode_t mode,
unsigned
Chris,
Have you had the chance to look at v6 of this patch? If so, what do you
think?
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 John,
On Wed, Apr 20 2011, John Calixto wrote:
Have you had the chance to look at v6 of this patch? If so, what do you
think?
Looks good to me. Since Arnd's been reviewing, it'd be nice to get a
Reviewed-by: tag from him and acknowledgement that his concerns are all
addressed, and then
2011/4/14 John Calixto john.cali...@modsystems.com:
[...]
+ /* DAT buffer */
+ __u32 data_ptr_size; /* size of the *pointer* */
+ __u64 data_ptr;
So... again... What's the problem with anonymous union of pointer and u64?
Example implementation:
struct mmc_ioc_cmd {
...
Hi Michal,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
So... again... What's the problem with anonymous union of pointer and u64?
As Arnd pointed out, this would not work for big endian machines.
John
W dniu 20 kwietnia 2011 19:38 użytkownik John Calixto
john.cali...@modsystems.com napisał:
Hi Michal,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
So... again... What's the problem with anonymous union of pointer and u64?
As Arnd pointed out, this would not work for big endian machines.
W dniu 20 kwietnia 2011 19:31 użytkownik Michał Mirosław
mir...@gmail.com napisał:
2011/4/14 John Calixto john.cali...@modsystems.com:
[...]
+ /* DAT buffer */
+ __u32 data_ptr_size; /* size of the *pointer* */
+ __u64 data_ptr;
So... again... What's the problem with
Hi Michał,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
Hmm. This might be even better:
static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct mmc_ioc_cmd blk;
if (cmd != MMC_IOC_CMD)
return -EINVAL;
On Wednesday 20 April 2011 21:06:49 John Calixto wrote:
On Wed, 20 Apr 2011, Michał Mirosław wrote:
Hmm. This might be even better:
static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct mmc_ioc_cmd blk;
if (cmd !=
Hi Arnd,
On Wed, 20 Apr 2011, Arnd Bergmann wrote:
No need for a union or a ptr_size member in the struct. Just use
a single __u64 and let the user cast the pointer to that. This
will work on all architectures.
However, I still think it should be implemented in compat_ioctl()
because
On Wednesday 20 April 2011 21:34:20 John Calixto wrote:
On Wed, 20 Apr 2011, Arnd Bergmann wrote:
No need for a union or a ptr_size member in the struct. Just use
a single __u64 and let the user cast the pointer to that. This
will work on all architectures.
However, I still think
2011/4/20 Arnd Bergmann a...@arndb.de:
On Wednesday 20 April 2011 21:06:49 John Calixto wrote:
On Wed, 20 Apr 2011, Michał Mirosław wrote:
Hmm. This might be even better:
static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct
On Wed, 20 Apr 2011, Michał Mirosław wrote:
I'm okay with the anon union + ``compat_ptr(*(u32 *))`` part of your
solution. If everyone else thinks it is reasonable, I'll submit a v7
with it.
No need for a union or a ptr_size member in the struct. Just use
a single __u64 and let the user
Hi John,
On Wed, Apr 20 2011, John Calixto wrote:
Do you have a preference here? I do not have a preference. On the one
hand, not having the union makes for a cleaner-to-read struct. On the
other hand, not having to cast the pointer in 32-bit userspace is nice
especially since I foresee
On Wednesday 20 April 2011 21:46:04 Michał Mirosław wrote:
2011/4/20 Arnd Bergmann a...@arndb.de:
No, please don't try to invent random new ways of doing this.
Your example relies on the assumption that the task is calling
the entry point for its native word size. Some architectures
Allows appropriately-privileged applications to send CMD (normal) and
ACMD (application-specific; preceded with CMD55) commands to
cards/devices on the mmc bus. This is primarily useful for enabling the
security functionality built in to every SD card.
It can also be used as a generic
21 matches
Mail list logo
