devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).