[U-Boot] [PATCH] eeprom: fix eeprom write procedure

[Alexey Brodkin]

Hi Marek,

On Tue, 2015-12-15 at 12:47 +0100, Marek Vasut wrote:
> On Tuesday, December 15, 2015 at 09:07:01 AM, Alexey Brodkin wrote:
> > Hi Marek,
> > 
> > On Tue, 2015-12-15 at 01:27 +0100, Marek Vasut wrote:
> > > On Monday, December 14, 2015 at 04:45:34 PM, Alexey Brodkin wrote:
> > > > This fixes commit 1a37889b0ad084a740b4f785031d7ae9955d947b:
> > > > ----------------------->8--------------------
> > > > eeprom: Pull out the RW loop
> > > > 
> > > > Unify the code for doing read/write into single function, since the
> > > > code for both the read and write is almost identical. This again
> > > > trims down the code duplication.
> > > > ----------------------->8--------------------
> > > > 
> > > > where the same one routine is utilized for both EEPROM writing and
> > > > reading. The only difference was supposed to be a "read" flag which
> > > > in both cases was set with 1 somehow.
> > > > 
> > > > That lead to a missing delay in case of writing which lead to write
> > > > failure (in my case no data was written).
> > > > 
> > > > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> > > > Cc: Marek Vasut <marex at denx.de>
> > > > Cc: Simon Glass <sjg at chromium.org>
> > > > Cc: Tom Rini <trini at konsulko.com>
> > > > Cc: Heiko Schocher <hs at denx.de>
> > > 
> > > Obviously correct,
> > > 
> > > Acked-by: Marek Vasut <marex at denx.de>
> > > 
> > > Thanks for spotting this, nice!
> > 
> > That was a nice exercise for me.
> > From the first glance DW SPI and ARC-specific changes
> > were not guilty so I tried some previous RC-s and found that
> > v2016.01-rc1 is good while rc2 is not.
> > 
> > So I recalled articles and talks about git bisect.
> > And literally in few next minutes I knew commit that introduced
> > that breakage. At that point problem became really obvious.
> 
> ... and then you cursed at me, yeah, I did not sleep very well last night ;-)

Well 1 beer may definitely help to improve our relationships indeed :)

But jokes aside I'm a bit confused with development cycle of U-Boot.
I mean here we're free to push quite important changes at any point
even if tomorrow Tom is cutting the next release. RCs are out of the
question at all.

I have to confess I do it myself from time to time just because it's
so easy and nobody cares. But that really makes me worry because I cannot
afford running U-Boot on every board I support on each and every commit.
Which in turn means there's a possibility in final release some of my boards
will be broken to some extent.

That said I really like Linux development procedure when merge window is
open just for a week or so and then only regression fixes are accepted
during RC cycles.

Still that very-very formal approach could be a bit of overkill for us here.
But there's another good example - Buildroot.

In the same way as we do it they accept patches right in master branch
but only until the first RC. From RC1 on only fixes go in master,
everything else goes to "next" branch. And "next" gets merged in master
right after release.

Again I'm not following U-boot mailing list closely so I might be missing
similar ongoing discussion so please be lenient to that my rant :)

-Alexey