[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141028141805.7b67bba29734be326354957f@linux-foundation.org>
Date: Tue, 28 Oct 2014 14:18:05 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Johan Hovold <johan@...nel.org>
Cc: Alessandro Zummo <a.zummo@...ertech.it>,
Tony Lindgren <tony@...mide.com>,
BenoƮt Cousson <bcousson@...libre.com>,
Felipe Balbi <balbi@...com>, Lokesh Vutla <lokeshvutla@...com>,
Guenter Roeck <linux@...ck-us.net>, nsekhar@...com,
t-kristo@...com, j-keerthy@...com, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] rtc: omap: add support for pmic_power_en
On Tue, 28 Oct 2014 09:36:33 +0100 Johan Hovold <johan@...nel.org> wrote:
> > But it doesn't explain *why* we want the alarm to trigger before
> > returning.
>
> Should we really require every power-off handler to document arch
> behaviour (even if its inconsistent and currently undocumented); in
> this case that some arches return to user-space where we may oops if
> called from process 0 (e.g. systemd, but not if using sysvinit)?
The kernel really doesn't have a problem related to excessive amounts
of useful code comments :(
The bottom line is: did I provide a reader with the ability to
understand why the code is this way? If "no" then improvements beckon.
This does look like one code site where an elaborate explanation is
warranted. There's no way in which a reader can get to your above
paragraph from the current rtc-omap.c.
--
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