[PATCH] mtd: unify initialization of erase_info->fail_addr

[Shmulik Ladkani]

On Mon, 13 Feb 2012 16:03:16 +0200 Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Mon, 2012-02-13 at 16:02 +0200, Artem Bityutskiy wrote:
> > On Thu, 2012-02-09 at 15:36 +0200, Shmulik Ladkani wrote:
> > > From: Shmulik Ladkani <shmulik.ladkani at gmail.com>
> > > 
> > > Initialization of 'erase_info->fail_addr' to MTD_FAIL_ADDR_UNKNOWN prior
> > > erase operation is duplicated accross several MTD drivers, and also taken
> > > care of by some MTD users as well.
> > > 
> > > Harmonize it: initialize 'fail_addr' within 'mtd_erase()' interface.
> > > 
> > > Signed-off-by: Shmulik Ladkani <shmulik.ladkani at gmail.com>
> > 
> > Could you please re-send this one and
> > 
> > [PATCH] sfc: mtd: Use MTD_FAIL_ADDR_UNKNOWN instead of 0xffffffff
> > 
> > as a single patch or a series of 2 patches?
> 
> I mean this patch should also patch 'sfc' or just contain that change,
> right?
> 

No, these are independent patches.

'mtd: unify initialization of erase_info->fail_addr' deals with the
duplication of 'fail_addr' initialization accross mtd users and drivers.

'sfc: mtd: Use MTD_FAIL_ADDR_UNKNOWN instead of 0xffffffff' is a bug fix
which I accidentally encountered when grepping 'fail_addr' during the
work on the former patch.
Here we're dealing with an 'erase()' implementation, in the case were
the erase has actually failed, however the 'sfc' driver seems not
capable of stating the location of the failure.
In this case 'fail_addr' should be set to MTD_FAIL_ADDR_UNKNOWN
(which was 0xffffffff ages ago).
Note today 'fail_addr' is a uint64_t, and MTD_FAIL_ADDR_UNKNOWN is -1LL,
meaning 'efx_mtd_erase()' was not adhering to the interface.

Regards
Shmulik