[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151008230353.GM14464@wotan.suse.de>
Date: Fri, 9 Oct 2015 01:03:53 +0200
From: "Luis R. Rodriguez" <mcgrof@...e.com>
To: Josh Boyer <jwboyer@...oraproject.org>
Cc: "Luis R. Rodriguez" <mcgrof@...not-panic.com>,
Greg KH <gregkh@...uxfoundation.org>,
Ming Lei <ming.lei@...onical.com>,
Jonathan Corbet <corbet@....net>,
"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
linux-doc@...r.kernel.org, David Woodhouse <dwmw2@...radead.org>,
David Howells <dhowells@...hat.com>,
Seth Forshee <seth.forshee@...onical.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Michal Marek <mmarek@...e.cz>,
Matthew Garrett <mjg59@...f.ucam.org>, kyle@...nel.org,
linux-security-module <linux-security-module@...r.kernel.org>,
keyrings@...ux-nfs.org, Tom Gundersen <teg@...m.no>
Subject: Re: [PATCH v2 5/5] firmware: add an extensible system data helpers
On Thu, Oct 08, 2015 at 01:59:11PM -0400, Josh Boyer wrote:
> On Thu, Oct 1, 2015 at 1:44 PM, Luis R. Rodriguez
> > +static inline int desc_sync_found_call_cb(const struct sysdata_file_desc *desc,
> > + const struct sysdata_file *sysdata)
> > +{
> > + BUG_ON(desc->sync_reqs.mode != SYNCDATA_SYNC);
>
> ngh... Why do these inline functions all have BUG_ONs in them? If it
> is to catch a programming error, why can't you just return EINVAL like
> you do in the async function case? (Even that WARN_ON seems
> excessive).
Sure, I've replaced the pesky BUG_ON() with returning -EINVAL's.
Let me know if there is anything else.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists