From: Richard Weinberger <richard@nod.at>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
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:22:53 +0200 [thread overview]
Message-ID: <578E53DD.806@nod.at> (raw)
In-Reply-To: <20160719181248.2a71b5a7@bbrezillon>
Am 19.07.2016 um 18:12 schrieb Boris Brezillon:
>>> 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).
I've been told that new code (except core code) should not BUG()/_ON().
> 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.
Yes, definitely.
Thanks,
//richard
next prev parent reply other threads:[~2016-07-19 16:23 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
2016-07-19 16:22 ` Richard Weinberger [this message]
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=578E53DD.806@nod.at \
--to=richard@nod.at \
--cc=andrew.smirnov@gmail.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.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.