From: "Jörn Engel" <joern@logfs.org>
To: Nicolas Pitre <nico@cam.org>
Cc: David Woodhouse <dwmw2@infradead.org>, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [MTD] orion_nand: add chip_delay parameter
Date: Fri, 27 Jun 2008 09:23:54 +0200 [thread overview]
Message-ID: <20080627072354.GA30174@logfs.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0806261319340.2979@xanadu.home>
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.
> > 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.
Jörn
--
There is no worse hell than that provided by the regrets
for wasted opportunities.
-- Andre-Louis Moreau in Scarabouche
next prev parent reply other threads:[~2008-06-27 7:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 13:55 [PATCH] [MTD] orion_nand: add chip_delay parameter Nicolas Pitre
2008-06-26 17:24 ` Nicolas Pitre
2008-06-27 7:23 ` Jörn Engel [this message]
2008-06-28 1:18 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080627072354.GA30174@logfs.org \
--to=joern@logfs.org \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.