From: Rob Herring <robh+dt@kernel.org>
To: John Stultz <john.stultz@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Bjorn Andersson <bjorn.andersson@sonymobile.com>,
lkml <linux-kernel@vger.kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Vinay Simha BN <simhavcs@gmail.com>,
Haojian Zhuang <haojian.zhuang@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Android Kernel Team <kernel-team@android.com>,
Andy Gross <agross@codeaurora.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [RFC][PATCH] misc: Introduce reboot_reason driver
Date: Thu, 10 Dec 2015 14:24:11 -0600 [thread overview]
Message-ID: <CAL_Jsq+s1Lk9s=dvSAe-rerSc1aUO39tkBnsrkoNqJoET3VNjw@mail.gmail.com> (raw)
In-Reply-To: <CALAqxLUKRFgg4pc-sJfOD_mDv8Afn-tzGuhNJzprheq4CEXUcw@mail.gmail.com>
On Thu, Dec 10, 2015 at 12:56 PM, John Stultz <john.stultz@linaro.org> wrote:
> On Thu, Dec 10, 2015 at 6:52 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday 09 December 2015 17:19:52 John Stultz wrote:
>>>
>>> If the concern is that since DT is basically ABI, one might not want
>>> to have such a wide interface that specifies all the different
>>> reasons, I can understand that. Though I'm really not sure how else we
>>> would be able to specify the device supported the reboot reason logic
>>> w/o having something in the DT (since some device may use the same soc
>>> w/ the same reboot logic may use a different bootloader which doesn't
>>> support the reason methods). At that point if we don't describe the
>>> method clearly, it ends up being something closer to just a quirks
>>> list which we'd have to map internally to behavior, which doesn't seem
>>> great.
>>>
>>> Should we run into hardware that the proposed driver doesn't handle,
>>> we can introduce a new driver for those specific semantics, but this
>>> way we can share at least most of the logic, no?
>>
>> I think we need a layered approach, with some high-level code to
>> store the boot reason, but then support firmware specific backends
>> to that. If we just need a phandle for an SRAM partition and an offset
>> within it, that can be done by the high-level driver, but not
>> any of the more sophisticated communication methods.
>
> Hrm. This feels to me like over-design, though. We already have the
> restart notifiers to hook into, which provide the command string. So
> its just a matter of parsing the string and writing the appropriate
> magic in the appropriate way (to memory, registers, efi, whatever).
> The amount of code we'd be dealing with to have a front end and 3-4
> back-ends, vs having 3-4 separate drivers seems like it would almost
> be the same. So why try to make a more complicated infrastructure?
The fact that we are using notifiers for reset reason and triggering
is probably some indication that some infrastructure is needed. But I
don't think you need to do that here as long as it is all kernel
internals. We'll make the 2nd guy do it. ;)
Rob
next prev parent reply other threads:[~2015-12-10 20:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-08 21:29 [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz
2015-12-08 21:52 ` Arnd Bergmann
2015-12-08 22:15 ` Bjorn Andersson
2015-12-08 22:43 ` Rob Herring
2015-12-09 0:13 ` John Stultz
[not found] ` <CALAqxLU4y6+AsKcZSPUaJQ2BgcAWoT8OPcYO6EYfOz+-7r8FTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-09 8:50 ` Sascha Hauer
2015-12-09 21:42 ` John Stultz
[not found] ` <1449610162-30543-1-git-send-email-john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-12-08 22:07 ` Bjorn Andersson
[not found] ` <20151208220722.GG4000-P9SbAA3LsXe39TS3lRcy0mP6iJigPa5YXqFh9Ls21Oc@public.gmane.org>
2015-12-09 0:22 ` John Stultz
2015-12-09 10:07 ` Arnd Bergmann
2015-12-10 1:19 ` John Stultz
2015-12-10 14:52 ` Arnd Bergmann
2015-12-10 18:56 ` John Stultz
2015-12-10 20:24 ` Rob Herring [this message]
2015-12-10 21:43 ` John Stultz
2015-12-10 22:11 ` Arnd Bergmann
2015-12-14 15:22 ` Rob Herring
2015-12-10 1:32 ` John Stultz
2015-12-10 9:05 ` Arnd Bergmann
2015-12-10 9:20 ` Tomas Winkler
2015-12-10 19:04 ` John Stultz
2015-12-10 19:57 ` One Thousand Gnomes
2015-12-10 20:03 ` John Stultz
2015-12-14 19:54 ` Bjorn Andersson
2015-12-08 22:26 ` Rob Herring
[not found] ` <CAL_JsqKMsG79TiB7nAOd8rB5m3VqwJYdQU0xiwvzvaqMyCk1BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-09 0:34 ` John Stultz
2015-12-09 8:53 ` Sascha Hauer
2015-12-09 8:59 ` Sascha Hauer
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='CAL_Jsq+s1Lk9s=dvSAe-rerSc1aUO39tkBnsrkoNqJoET3VNjw@mail.gmail.com' \
--to=robh+dt@kernel.org \
--cc=agross@codeaurora.org \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@sonymobile.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=haojian.zhuang@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=simhavcs@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).