From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Richard Weinberger <richard@nod.at>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>,
linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mtd: nand: BUG_ON in case of no select_chip and cmd_ctrl
Date: Tue, 19 Jul 2016 18:12:48 +0200 [thread overview]
Message-ID: <20160719181248.2a71b5a7@bbrezillon> (raw)
In-Reply-To: <578E4F13.1070100@nod.at>
On Tue, 19 Jul 2016 18:02:27 +0200
Richard Weinberger <richard@nod.at> wrote:
> Am 19.07.2016 um 17:59 schrieb Boris Brezillon:
> > On Tue, 19 Jul 2016 17:44:48 +0200
> > Richard Weinberger <richard@nod.at> wrote:
> >
> >> Am 19.07.2016 um 17:41 schrieb Andrey Smirnov:
> >>> If no user specified chip->select_chip() function is provided, code in
> >>> nand_base.c will automatically set this hook to nand_select_chip(),
> >>> which in turn depends on chip->cmd_ctrl() hook being valid. Not
> >>> providing both of those functions in NAND controller driver (for example
> >>> by mistake) will result in a bit cryptic segfault. Replace it with
> >>> explicit BUG_ON statement so it would be obvious what went wrong.
> >>>
> >>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> >>> ---
> >>> drivers/mtd/nand/nand_base.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> >>> index ce7b2ca..57043a6 100644
> >>> --- a/drivers/mtd/nand/nand_base.c
> >>> +++ b/drivers/mtd/nand/nand_base.c
> >>> @@ -3128,8 +3128,10 @@ static void nand_set_defaults(struct nand_chip *chip, int busw)
> >>> if (chip->waitfunc == NULL)
> >>> chip->waitfunc = nand_wait;
> >>>
> >>> - if (!chip->select_chip)
> >>> + if (!chip->select_chip) {
> >>> + BUG_ON(!chip->cmd_ctrl);
> >>
> >> Please don't add new BUG_ON() calls. WARN_ON() is good enough to raise the driver developer's
> >> attention and won't kill the machine.
> >
> > Not sure a BUG_ON() is worst than a NULL-pointer exception ;-).
>
> When this really just triggers a NULL-pointer exception, we don't need a BUG_ON or WARN_ON at
> all since the kernel can tell anyway what went wrong.
Hm, that's not entirely true, depending on your debug options you don't
have all the information to guess which line triggered the NULL pointer
exception, and this makes it harder to debug.
And I agree with Andrey here, it's better to complain at registration
time than letting the controller register all its NAND devices and
generate exceptions when the NAND is really used.
BTW, I don't quite understand the rational behind BUG_ON() eradication.
I agree that they should not be used when the driver can recover from a
specific failure, but that's not really the case here (some NAND
controller drivers don't check nand_scan_tail() or nand_scan() return
code).
The best solution would probably be to patch all those drivers and then
return an error when one of the mandatory hooks is missing, but in the
meantime I don't see any problem in adding BUG_ON() calls.
next prev parent reply other threads:[~2016-07-19 16:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 15:41 [PATCH 1/2] mtd: nand: BUG_ON in case of no select_chip and cmd_ctrl Andrey Smirnov
2016-07-19 15:41 ` [PATCH 2/2] mtd: nand: Get rid of needless 'goto' Andrey Smirnov
2016-07-19 18:30 ` Brian Norris
2016-07-19 18:48 ` Andrey Smirnov
2016-07-19 18:55 ` Boris Brezillon
2016-07-19 19:43 ` Brian Norris
2016-07-19 15:44 ` [PATCH 1/2] mtd: nand: BUG_ON in case of no select_chip and cmd_ctrl Richard Weinberger
2016-07-19 15:59 ` Boris Brezillon
2016-07-19 16:02 ` Richard Weinberger
2016-07-19 16:12 ` Boris Brezillon [this message]
2016-07-19 16:22 ` Richard Weinberger
2016-07-19 18:11 ` Andrey Smirnov
2016-07-19 18:16 ` Boris Brezillon
2016-07-19 18:23 ` Brian Norris
2016-07-19 18:36 ` Andrey Smirnov
2016-07-19 18:19 ` Brian Norris
2016-07-19 18:47 ` Boris Brezillon
2016-07-19 19:39 ` Brian Norris
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=20160719181248.2a71b5a7@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=andrew.smirnov@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).