All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vipin Kumar <vipin.kumar@st.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] imls: Add support to list images in NAND device
Date: Tue, 18 Dec 2012 10:34:16 +0530	[thread overview]
Message-ID: <50CFF950.7050205@st.com> (raw)
In-Reply-To: <1355789112.18495.7@snotra>

On 12/18/2012 5:35 AM, Scott Wood wrote:
> On 12/17/2012 02:22:40 AM, Vipin Kumar wrote:
>> On 12/14/2012 11:40 PM, Scott Wood wrote:
>>> On 12/14/2012 03:32:04 AM, Vipin Kumar wrote:
>>>>>> +
>>>>>> + switch (genimg_get_format(buffer)) {
>>>>>> + case IMAGE_FORMAT_LEGACY:
>>>>>> + header = (const image_header_t *)buffer;
>>>>>> + len = image_get_image_size(header);
>>>>>> +
>>>>>> + ret = nand_imls_legacyimage(nand,
>>>>>> nand_dev,
>>>>>> + off, len);
>>>>>> + if (ret< 0&& ret != -ENOMEM)
>>>>>> + return ret;
>>>>>> + break;
>>>>>> +#if defined(CONFIG_FIT)
>>>>>> + case IMAGE_FORMAT_FIT:
>>>>>> + len = fit_get_size(buffer);
>>>>>> + ret = nand_imls_fitimage(nand, nand_dev,
>>>>>> + off, len);
>>>>>> + if (ret< 0&& ret != -ENOMEM)
>>>>>> + return ret;
>>>>>> + break;
>>>>>> +#endif
>>>>>> + }
>>>>>
>>>>> Do you really mean to return from the main imls function just because
>>>>> one image has an error? By "use return" I meant return from the
>>>>> subfunction.
>>>>>
>>>>
>>>> This return only corresponds to the situation when there is an error
>>>> returned from nand read routine. In that case, I don't think there is
>>>> any use reading the NAND any further.
>>>
>>> Just because one page has an uncorrectable error doesn't mean the
>>> entire NAND is bad. Note that this is different from what you
>>> currently do if you get an error on the initial read where you look for
>>> a header.
>>>
>>
>> Yes, I got your point.
>>
>> I would now not announce the uncorrectable errors as they may hog the
>> whole stdout and still continue to work for the whole NAND device.
>> Please check the implementation in v4
>
> I'd rather see errors be announced, with some reasonable limit on how
> many (and a message indicating if further errors exist that were
> suppressed).
>

Hmm, OK. I would do it this way in v5

> -Scott
>

  reply	other threads:[~2012-12-18  5:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <50CED650.3090000@st.com>
2012-12-18  0:05 ` [U-Boot] [PATCH v3] imls: Add support to list images in NAND device Scott Wood
2012-12-18  5:04   ` Vipin Kumar [this message]
2012-12-13 10:38 Vipin Kumar
2012-12-13 21:59 ` Scott Wood
2012-12-14  8:57   ` Vipin Kumar
2012-12-14  9:32   ` Vipin Kumar
2012-12-14 18:10     ` Scott Wood

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=50CFF950.7050205@st.com \
    --to=vipin.kumar@st.com \
    --cc=u-boot@lists.denx.de \
    /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.