From: Artem Bityutskiy <dedekind@infradead.org>
To: Kevin Cernekee <kpc.mtd@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [MTD] mtd-utils: Use new 64-bit ioctls to access >4GiB devices
Date: Wed, 18 Mar 2009 11:20:29 +0200 [thread overview]
Message-ID: <1237368029.3622.6.camel@localhost.localdomain> (raw)
In-Reply-To: <a95a62fe0903171813x404fcb4bsf29dc5ce9495dbb5@mail.gmail.com>
On Tue, 2009-03-17 at 18:13 -0700, Kevin Cernekee wrote:
> diff --git a/include/mtd/mtd-abi.h b/include/mtd/mtd-abi.h
> index 86defe1..10ebb7c 100644
> --- a/include/mtd/mtd-abi.h
> +++ b/include/mtd/mtd-abi.h
> @@ -1,6 +1,4 @@
> /*
> - * $Id: mtd-abi.h,v 1.13 2005/11/07 11:14:56 gleixner Exp $
> - *
> * Portions of MTD ABI definition which are shared by kernel and user space
> */
>
> @@ -12,10 +10,21 @@ struct erase_info_user {
> uint32_t length;
> };
>
> +struct erase_info_user64 {
> + uint64_t start;
> + uint64_t length;
> +};
> +
> struct mtd_oob_buf {
> uint32_t start;
> uint32_t length;
> - unsigned char *ptr;
> + unsigned char __user *ptr;
> +};
> +
> +struct mtd_oob_buf64 {
> + uint64_t start;
> + uint32_t length;
> + unsigned char __user *ptr;
> };
>
> #define MTD_ABSENT 0
> @@ -29,7 +38,7 @@ struct mtd_oob_buf {
> #define MTD_WRITEABLE 0x400 /* Device is writeable */
> #define MTD_BIT_WRITEABLE 0x800 /* Single bits can be flipped */
> #define MTD_NO_ERASE 0x1000 /* No erase necessary */
> -#define MTD_STUPID_LOCK 0x2000 /* Always locked after reset */
> +#define MTD_POWERUP_LOCK 0x2000 /* Always locked after reset */
>
> // Some common devices / combinations of capabilities
> #define MTD_CAP_ROM 0
> @@ -62,6 +71,15 @@ struct mtd_info_user {
> uint32_t eccsize;
> };
>
> +struct mtd_info_user64 {
> + uint32_t type;
> + uint32_t flags;
> + uint64_t size; // Total size of the MTD
> + uint32_t erasesize;
> + uint32_t writesize;
> + uint32_t oobsize; // Amount of OOB data per block (e.g. 16)
> +};
> +
> struct region_info_user {
> uint32_t offset; /* At which this region starts,
> * from the beginning of the MTD */
> @@ -70,6 +88,14 @@ struct region_info_user {
> uint32_t regionindex;
> };
>
> +struct region_info_user64 {
> + uint64_t offset; /* At which this region starts,
> + * from the beginning of the MTD */
> + uint32_t erasesize; /* For this region */
> + uint32_t numblocks; /* Number of blocks in this region */
> + uint32_t regionindex;
> +};
I think dwmw2 put it clearly that he will not accept new
_informational_ ioctls like MEMGETINFO64 and so on. This should
be exposed via sysfs instead.
Vs other inctl's, could you please reserve some space there for
possible future inmprovements by adding
uint8_t padding[128]; /* Unused, reserved for future, should be 0'd */
or something like this, please? We suffered from lack of fields like
this in the past.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2009-03-18 9:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 1:13 [PATCH] [MTD] mtd-utils: Use new 64-bit ioctls to access >4GiB devices Kevin Cernekee
2009-03-18 7:50 ` Ricard Wanderlof
2009-03-18 12:06 ` Josh Boyer
2009-03-18 12:16 ` Adrian Hunter
2009-03-18 12:26 ` Josh Boyer
2009-03-18 12:46 ` Adrian Hunter
2009-03-18 20:40 ` Kevin Cernekee
2009-03-18 9:20 ` Artem Bityutskiy [this message]
2009-03-18 20:21 ` Kevin Cernekee
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=1237368029.3622.6.camel@localhost.localdomain \
--to=dedekind@infradead.org \
--cc=kpc.mtd@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox