[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170828182723.iav5lgucnuhd646f@pd.tnic>
Date: Mon, 28 Aug 2017 20:27:23 +0200
From: Borislav Petkov <bp@...e.de>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Tyler Baicar <tbaicar@...eaurora.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>, Will Deacon <will.deacon@....com>,
james.morse@....com, shiju.jose@...wei.com,
Geliang Tang <geliangtang@...il.com>,
Tony Luck <tony.luck@...el.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3] acpi: apei: clear error status before acknowledging
the error
On Mon, Aug 28, 2017 at 08:44:21PM +0300, Andy Shevchenko wrote:
> For my opinion, since you asked, the either case needs a comment on
> top of that additional check.
That's because the comment belongs to the v2 part of the check.
> Separate conditionals in independent cases are, of course, better.
Yes, and separate are easier to read if you read them like this:
+ if (rc == -ENOENT)
+ return rc;
<--- Ok, we got the missing entry out of the way, now, here, we have a
valid entry. Now we can concentrate on processing it further.
... other check and ack and ...
And this becomes a lot more natural when you're staring at a big function
which does a lot of things and you concentrate only on the main path.
Oh, and this is how those checks get translated to asm as there you
don't really have compound if-statements. So if you switch your mind to
reading such checks separately, you're practically ready to read their
asm translation too...
Anyway, this is how I see it.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists