On Fri, 2013-10-25 at 13:03 +0100, David Woodhouse wrote:
>
> So... what if someone has already shipped the new chips that require
> stronger ECC, without realising that legacy_set_geometry() is
> insufficient? (And is legacy_set_geometry *actually* doing precisely the
> same as 3.10/3.11?)
Answering my own question: If the required ECC strength is known and the
legacy ECC layout is insufficient, that's caused a failure since commit
92d0e09abeebd ("mtd: gpmi: add sanity check for the ECC") in 3.9, so I'm
not worried about supporting that.
And legacy_set_geometry() *is* doing what 3.11 did, verbatim.
So the question is whether we want this "if legacy is sufficient then
use it else use the new method" that you offer in v2 of the patch, or if
a device-tree property is the better way to do it.
I'm actually slightly in favour of the device-tree property. But since
3.12 is imminent I think the *best* option is just to do this to
preserve the 3.11 behaviour, and worry about getting it right for 3.13:
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 59ab069..a9830ff 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -349,7 +349,7 @@ static int legacy_set_geometry(struct gpmi_nand_data *this)
int common_nfc_set_geometry(struct gpmi_nand_data *this)
{
- return set_geometry_by_ecc_info(this) ? 0 : legacy_set_geometry(this);
+ return legacy_set_geometry(this);
}
struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
--
dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature