UBI: optimize erase-header read checks

[Gupta, Pekon]

Hi Artem,

> 
> Hi Pekon,
> 
> thanks for the patch. Generally, I am fine to change the
> reading/scanning path, but carefully.
> 
[Pekon]: Yes I understand, that this patch should not break 
something already working. 
Though I have tested this with various scenarios mention in 
previous mail. But still I was waiting a 'Ack' from Brain.
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046738.html
But if others can test it also, It would be good.

> >
> > Signed-off-by: Gupta, Pekon <pekon at ti.com>
> 
> So the subject says this is an optimization, but I do not really see
> what did you optimize? Speed? If yes, some numbers?
> 
> Or this is about improving robustness? May be some clear explanations
> about that?
> 
> Or this is just simplifying the code and making it more clear?
> 
> I am fine with all of that, just want to clearly see this explained in
> the commit message.
> 
[Pekon]: Its more of simplifying code, I'll re-word the commit.
It should also improve some speed, in some scenarios, as I have 
removed all 0xFF header check. I'll try to get numbers for that.


> Also, the patch is a bit too big. Can you try to figure out smaller
> steps and split it on smaller pieces?
> 
[Pekon]: Yes, I tried this, but majority chunk of patch is change in
'ubi_io_read_ec_hdr()', which was completely re-written, in order to 
simplify code. I'll try to split the patch, but then it might not be logical split,
and there would be dependency between patches.

> There are also minor cosmetic things, but I do not want to touch them
> now.
> 
[Pekon]: I'll re-base them on 3.10-rcx. So its easy for you to check.
But right now I'm caught in other clean-up work, so re-submission would 
be bit delayed..

> Note: I am processing the mtd mailing list from oldest e-mails to
> newest, with few exceptions. But when I answer an e-mail, and the
> person
> re-sends patches, I usually jump to the new version right away. So if
> you resend, I should look at them with a lot smaller delay :-)
> 
[Pekon]: No issues for me..
I don't see these patches as emergency, but good to have from a 
long term prospective. And I'm more than happy to receive feedbacks.


with regards, pekon