public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
	Kevin Cernekee <cernekee@gmail.com>,
	b35362@freescale.com, linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>,
	Matthew Creech <mlcreech@gmail.com>
Subject: Re: [RFC 5/5] mtd: add MEMWRITEDATAOOB ioctl
Date: Mon, 22 Aug 2011 11:56:18 +0300	[thread overview]
Message-ID: <1314003384.2644.85.camel@sauron> (raw)
In-Reply-To: <1313625029-19546-6-git-send-email-computersforpeace@gmail.com>

On Wed, 2011-08-17 at 16:50 -0700, Brian Norris wrote:
> Implement a new ioctl for writing both page data and OOB to flash at the
> same time.  This is especially useful for MLC NAND, which cannot be
> written twice (i.e., we cannot successfully write the page data and OOB
> in two separate operations).
> 
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Looks good except few nit-picks.

> +			ops.mode = buf.mode;
> +			ops.len = (size_t)buf.len;
> +			ops.ooblen = (size_t)buf.ooblen;
> +			ops.ooboffs = 0;
> +
> +			ops.datbuf = memdup_user(
> +					(void __user *)(uintptr_t)buf.usr_ptr,
> +					ops.len + ops.ooblen);

I'd introduced a local variable for buf.usr_ptr and made the formatting
nicer.

> +			if (IS_ERR(ops.datbuf))
> +				return PTR_ERR(ops.datbuf);
> +
> +			ops.oobbuf = ops.datbuf + ops.len;
> +
> +			ret = mtd->write_oob(mtd, (loff_t)buf.start, &ops);
> +			kfree(ops.datbuf);
> +		}
> +		break;
> +	}
> +
>  	case MEMLOCK:
>  	{
>  		struct erase_info_user einfo;
> diff --git a/include/mtd/mtd-abi.h b/include/mtd/mtd-abi.h
> index f850d9a..20df299 100644
> --- a/include/mtd/mtd-abi.h
> +++ b/include/mtd/mtd-abi.h
> @@ -59,6 +59,14 @@ typedef enum {
>  	MTD_OOB_RAW,
>  } mtd_oob_mode_t;
>  
> +struct mtd_data_oob_buf {
> +	__u64 start;
> +	__u32 len;
> +	__u32 ooblen;
> +	__u64 usr_ptr;
> +	mtd_oob_mode_t __user mode;
> +};

Let's add some reserved space for future improvements - I think it is
always a good idea to do for ioctls:

+ __u8 padding[8]

> +
>  #define MTD_ABSENT		0
>  #define MTD_RAM			1
>  #define MTD_ROM			2
> @@ -141,6 +149,7 @@ struct otp_info {
>  #define MEMWRITEOOB64		_IOWR('M', 21, struct mtd_oob_buf64)
>  #define MEMREADOOB64		_IOWR('M', 22, struct mtd_oob_buf64)
>  #define MEMISLOCKED		_IOR('M', 23, struct erase_info_user)
> +#define MEMWRITEDATAOOB		_IOWR('M', 24, struct mtd_data_oob_buf)

Would be greate to add a short comment about what this ioctl does. Of
course you can optionally do this for all of them, but at least for the
new one it does not hurt to have.

-- 
Best Regards,
Artem Bityutskiy

  reply	other threads:[~2011-08-22  8:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-17 23:50 [RFC 0/5] fix data+OOB writes, add ioctl Brian Norris
2011-08-17 23:50 ` [RFC 1/5] mtd: support MTD_MODE_RAW for writing OOB Brian Norris
2011-08-22  8:35   ` Artem Bityutskiy
2011-08-22 20:08     ` Brian Norris
2011-08-23  4:47       ` Artem Bityutskiy
2011-08-23  5:25   ` Jason Liu
2011-08-23 19:57     ` Brian Norris
2011-08-17 23:50 ` [RFC 2/5] mtd: support MTD_MODE_RAW for reading OOB Brian Norris
2011-08-22  8:38   ` Artem Bityutskiy
2011-08-17 23:50 ` [RFC 3/5] mtd: do not assume oobsize is power of 2 Brian Norris
2011-08-22  8:46   ` Artem Bityutskiy
2011-08-22 20:21     ` Brian Norris
2011-08-17 23:50 ` [RFC 4/5] mtd: move mtd_oob_mode_t to shared kernel/user space Brian Norris
2011-08-22  8:50   ` Artem Bityutskiy
2011-08-22 21:43     ` Brian Norris
2011-08-23  5:30       ` Artem Bityutskiy
2011-08-23 17:24         ` Brian Norris
2011-08-17 23:50 ` [RFC 5/5] mtd: add MEMWRITEDATAOOB ioctl Brian Norris
2011-08-22  8:56   ` Artem Bityutskiy [this message]
2011-08-23  0:04     ` Brian Norris
2011-08-23  6:05       ` Artem Bityutskiy
2011-08-23  6:06       ` Artem Bityutskiy
2011-08-23  6:11       ` Artem Bityutskiy
2011-08-22 10:02 ` [RFC 0/5] fix data+OOB writes, add ioctl Artem Bityutskiy
2011-08-22 12:04   ` Ivan Djelic
2011-08-22 12:16     ` Artem Bityutskiy
2011-08-23  6:48       ` Ricard Wanderlof
2011-08-23 16:47         ` Brian Norris
2011-08-24 15:36           ` Ricard Wanderlof
2011-08-24 18:01             ` Brian Norris
2011-08-25  7:21               ` Artem Bityutskiy
2011-08-25  9:33               ` Ricard Wanderlof
2011-08-25 17:54                 ` Brian Norris
2011-08-26 12:41                   ` Ricard Wanderlof
2011-08-22 23:42   ` Brian Norris
2011-08-23  6:01     ` Artem Bityutskiy

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=1314003384.2644.85.camel@sauron \
    --to=dedekind1@gmail.com \
    --cc=b35362@freescale.com \
    --cc=cernekee@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mlcreech@gmail.com \
    --cc=vapier.adi@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox