[PATCH] [MTD] orion_nand: add chip_delay parameter

Nicolas Pitre nico at cam.org
Fri Jun 27 21:18:31 EDT 2008


On Fri, 27 Jun 2008, Jörn Engel wrote:

> On Thu, 26 June 2008 13:24:14 -0400, Nicolas Pitre wrote:
> > 
> > I posted this patch on Monday for inclusion in 2.6.27.  However we have 
> > additional patches meant to be pushed through the ARM tree that depend 
> > on this one.  So to simplify dependency issues, I would like for this 
> > patch to be acked and then we'll simply push it along with the others 
> > through the ARM path.
> > 
> > Any objections??
> 
> While I don't really understand what this patch does, it seems harmless
> enough and I generally trust your judgement.  Good enough for me.

OK thanks.

> > > diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> > > index 59e05a1..ee2ac39 100644
> > > --- a/drivers/mtd/nand/orion_nand.c
> > > +++ b/drivers/mtd/nand/orion_nand.c
> > > @@ -85,6 +85,9 @@ static int __init orion_nand_probe(struct platform_device *pdev)
> > >  	nc->cmd_ctrl = orion_nand_cmd_ctrl;
> > >  	nc->ecc.mode = NAND_ECC_SOFT;
> > >  
> > > +	if (board->chip_delay)
> > > +		nc->chip_delay = board->chip_delay;
> > > +
> 
> What I'm wondering about is whether the assignment should be made
> unconditional.  After all, if board->chip_delay is zero, the assignment
> should simply write zero to a variable that already is zero.  Or if it
> isn't, the driver is missing a memset() somewhere.

There is the case that a default could be set by the driver and having 
board->chip_delay == 0 should mean the driver default is fine.


Nicolas


More information about the linux-mtd mailing list