All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Vitaly Wool <vwool@ru.mvista.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH/RFC] remove len/ooblen confusion in MTD/NAND code: respin
Date: Fri, 03 Nov 2006 11:16:17 +0200	[thread overview]
Message-ID: <1162545377.15435.35.camel@sauron> (raw)
In-Reply-To: <20061102100659.f223d094.vwool@ru.mvista.com>

On Thu, 2006-11-02 at 10:06 +0300, Vitaly Wool wrote:
> Hello folks,

snip

> ===================================================================
> --- linux-2.6.orig/drivers/mtd/mtdconcat.c
> +++ linux-2.6/drivers/mtd/mtdconcat.c
> @@ -278,14 +278,14 @@ concat_read_oob(struct mtd_info *mtd, lo
>  				return err;
>  		}
>  
> -		devops.len = ops->len - ops->retlen;
> -		if (!devops.len)
> +		devops.ooblen = ops->ooblen - ops->retlen;
> +		if (!devops.ooblen)
>  			return ret;

May you please explain this code. If ops->databuf != NULL,
mtd->read_oob() stores the number of read _data_ bytes. Then we
substract number of _data_ bytes from number of _OOB_ bytes
(devops.ooblen)? Looks confusing.

'struct mtd_oob_ops' is still a bit confusing. This is how it looks
after your patch:


/**
 * struct mtd_oob_ops - oob operation operands
 * @mode:       operation mode
 *
 * @len:        number of data bytes to write/read
 *
 * @retlen:     number of bytes written/read. When a data buffer is
given
 *              (datbuf != NULL) this is the number of data bytes. When
 *              no data buffer is available this is the number of oob
bytes.
 *
 * @ooblen:     number of oob bytes to write/read
 * @ooboffs:    offset of oob data in the oob area (only relevant when
 *              mode = MTD_OOB_PLACE)
 * @datbuf:     data buffer - if NULL only oob data are read/written
 * @oobbuf:     oob data buffer
 */

struct mtd_oob_ops {
        mtd_oob_mode_t  mode;
        size_t          len;
        size_t          retlen;
        size_t          ooblen;
        uint32_t        ooboffs;
        uint8_t         *datbuf;
        uint8_t         *oobbuf;
};

The fact that retlen depends on whether datbuf is NULL is not nice. I
would prefer go further and make it like this:

/**
 * struct mtd_oob_ops - OOB operation operands
 * @mode:       operation mode
 * @len:        number of data bytes to write/read
 * @ooblen:     number of OOB bytes to write/read
 * @retlen:     number of data bytes written/read
 * @oobretlen:  number of OOB bytes written/read
 * @ooboffs:    offset of OOB data in the OOB area (only relevant when
 *              mode = MTD_OOB_PLACE)
 * @datbuf:     data buffer - if NULL only OOB data are read/written
 * @oobbuf:     OOB data buffer - cnnot not be NULL
 */
struct mtd_oob_ops {
        mtd_oob_mode_t  mode;
        size_t          len;
        size_t          ooblen;
        size_t          retlen;
        size_t          oobretlen;
        uint32_t        ooboffs;
        uint8_t         *datbuf;
        uint8_t         *oobbuf;
};

If we say "A" why not to say "B"?

Comments?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2006-11-03  9:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02  7:06 [PATCH/RFC] remove len/ooblen confusion in MTD/NAND code: respin Vitaly Wool
2006-11-03  9:16 ` Artem Bityutskiy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-11-03 15:20 Vitaly Wool
2006-11-07 16:20 ` Artem Bityutskiy
2006-11-08 11:33   ` Vitaly Wool
2006-11-10 14:28   ` Vitaly Wool
2006-11-09 15:26 Vitaly Wool
2006-11-10  8:23 ` Artem Bityutskiy
2006-11-10 12:46   ` Vitaly Wool

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=1162545377.15435.35.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vwool@ru.mvista.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.