From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
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 20:16:11 +0200 [thread overview]
Message-ID: <20160719201611.277dfbff@bbrezillon> (raw)
In-Reply-To: <CAHQ1cqGN6fbbXoqZaFpDG856EsHAve-Or0M_HT8Zpb-BodC3sA@mail.gmail.com>
On Tue, 19 Jul 2016 11:11:54 -0700
Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
> On Tue, Jul 19, 2016 at 9:22 AM, Richard Weinberger <richard@nod.at> wrote:
> > 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.
>
> I don't have any preferences as far BUG_ON/WARN_ON are concerned and
> am more than happy to change one for another.
>
> The reason I came up with that patch is that I stumbled on that
> segfault (by not providing custom select_chip() and not setting up
> cmd_ctrl()) and it took me good 20 minutes to figure out the nature of
> the problem, whereas, IMHO, having a BUG/WARN statement at the would
> have been more self-documenting/explanatory.
>
> What if I modify the patch to change nand_set_default's signature to
> return a error code, add corresponding checking in
> nand_get_flash_type()/nand_scan_ident() and replace BUG_ON with
> WARN_ON? Would it be more agreeable solution?
Agreed.
next prev parent reply other threads:[~2016-07-19 18:16 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
2016-07-19 18:11 ` Andrey Smirnov
2016-07-19 18:16 ` Boris Brezillon [this message]
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=20160719201611.277dfbff@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 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.