On Mon, Nov 11, 2013 at 7:44 PM, Fabio Estevam <festevam@xxxxxxxxx> wrote: > On Tue, Nov 12, 2013 at 12:47 AM, Huang Shijie <b32955@xxxxxxxxxxxxx> wrote: >> 于 2013年11月12日 02:23, Brian Norris 写道: > >> For imx23, the work flow is like this: >> [1] first check the fingerprint, if we can find it, we will return >> immediately. >> [2] if [1] failed, such as you erase all the partitions, the gpmi will call >> mx23_write_transcription_stamp() to write the fingerprint. >> >> So the @chip->buffer is not only used by the >> mx23_check_transcription_stamp(), >> but _also_ used by the mx23_write_transcription_stamp() when the gpmi >> can not find any >> fingerprint in the NAND page. >> >> >> That's why i use the NAND_OWN_BUFFERS, the buffer can be used by both >> the mx23_check_transcription_stamp() >> and mx23_write_transcription_stamp(). > > Understood. > > What if we just allocate the 4-byte buffer once on probe? > > Like this: > > diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c > b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c > index a9830ff..647da1b 100644 > --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c > +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c ... > @@ -1728,6 +1726,10 @@ static int gpmi_nand_probe(struct platform_device *pdev) > return -ENOMEM; > } > > + this->buffer = devm_kzalloc(&pdev->dev, strlen(fingerprint), GFP_KERNEL); > + if (!this->buffer) > + return -ENOMEM; > + > platform_set_drvdata(pdev, this); > this->pdev = pdev; > this->dev = &pdev->dev; ... As Huang noted, this approach is still very fragile. I think it's best if we rework GPMI's init sequence so that we don't have to do these kind of fragile dodges any more; just do all the BBT scanning after nand_scan_tail(). Let's wait for Huang's version of my suggestion. Brian -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html