From: Moritz Fischer <moritz.fischer@ettus.com>
To: Rob Herring <robh@kernel.org>
Cc: Andy Yan <andy.yan@rock-chips.com>,
heiko@sntech.de, Arnd Bergmann <arnd@arndb.de>,
john.stultz@linaro.org, sjg@chromium.org,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
treding@nvidia.com, Kumar Gala <galak@codeaurora.org>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
wxt@rock-chips.com, Catalin Marinas <catalin.marinas@arm.com>,
olof@lixom.net, geert+renesas@glider.be,
linux-rockchip@lists.infradead.org,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
Sebastian Reichel <sre@kernel.org>,
jun.nie@linaro.org, "pawel.moll@arm.com" <pawel.moll@arm.com>,
Will Deacon <will.deacon@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Devicetree List <devicetree@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>,
Greg KH <gregkh@linuxfoundation.org>,
joel@jms.id.au,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
lorenzo.pieralisi@arm.com, khilman@linaro.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v1 1/6] dt-bindings: misc: add document for reboot-mode driver
Date: Wed, 23 Dec 2015 00:37:22 -0800 [thread overview]
Message-ID: <CAAtXAHfkfqELHamMVK3-6UE+LtVwimA7oe=QEzfF2WyrHXxcaQ@mail.gmail.com> (raw)
In-Reply-To: <20151223003217.GA18700@rob-hp-laptop>
Rob,
On Tue, Dec 22, 2015 at 4:32 PM, Rob Herring <robh@kernel.org> wrote:
> I would like to see the property names here standardized as much as
> possible. I'm not sure if we can define the properties as a u32 or need
> some flexibility here.
Quick question, semi on topic. I have a similar case (and a driver in
the pipeline),
however all I got is a (persistent over reboot) hardware register to
which I can write whatever.
On the other side I'd have u-boot pull out the value, but as it's up
to u-boot to
implement whatever it does with this info I'm kinda struggling with the idea
of a standardized binding. In my case I'd like it to go into 'safe
mode' or 'firmware update'.
With loader = <0xace0ba5e>, <0xdeadbeef> ... and loader-names <> I
could have u-boot read the values
from fdt at boot. Then again I'm not describing hardware, but specific
settings ...
Would that be acceptable?
Cheers,
Moritz
WARNING: multiple messages have this Message-ID (diff)
From: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Dmitry Eremin-Solenikov
<dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
"pawel.moll-5wv7dgnIgG8@public.gmane.org"
<pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Devicetree List
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Greg KH
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, khilm
Subject: Re: [PATCH v1 1/6] dt-bindings: misc: add document for reboot-mode driver
Date: Wed, 23 Dec 2015 00:37:22 -0800 [thread overview]
Message-ID: <CAAtXAHfkfqELHamMVK3-6UE+LtVwimA7oe=QEzfF2WyrHXxcaQ@mail.gmail.com> (raw)
In-Reply-To: <20151223003217.GA18700@rob-hp-laptop>
Rob,
On Tue, Dec 22, 2015 at 4:32 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> I would like to see the property names here standardized as much as
> possible. I'm not sure if we can define the properties as a u32 or need
> some flexibility here.
Quick question, semi on topic. I have a similar case (and a driver in
the pipeline),
however all I got is a (persistent over reboot) hardware register to
which I can write whatever.
On the other side I'd have u-boot pull out the value, but as it's up
to u-boot to
implement whatever it does with this info I'm kinda struggling with the idea
of a standardized binding. In my case I'd like it to go into 'safe
mode' or 'firmware update'.
With loader = <0xace0ba5e>, <0xdeadbeef> ... and loader-names <> I
could have u-boot read the values
from fdt at boot. Then again I'm not describing hardware, but specific
settings ...
Would that be acceptable?
Cheers,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: moritz.fischer@ettus.com (Moritz Fischer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 1/6] dt-bindings: misc: add document for reboot-mode driver
Date: Wed, 23 Dec 2015 00:37:22 -0800 [thread overview]
Message-ID: <CAAtXAHfkfqELHamMVK3-6UE+LtVwimA7oe=QEzfF2WyrHXxcaQ@mail.gmail.com> (raw)
In-Reply-To: <20151223003217.GA18700@rob-hp-laptop>
Rob,
On Tue, Dec 22, 2015 at 4:32 PM, Rob Herring <robh@kernel.org> wrote:
> I would like to see the property names here standardized as much as
> possible. I'm not sure if we can define the properties as a u32 or need
> some flexibility here.
Quick question, semi on topic. I have a similar case (and a driver in
the pipeline),
however all I got is a (persistent over reboot) hardware register to
which I can write whatever.
On the other side I'd have u-boot pull out the value, but as it's up
to u-boot to
implement whatever it does with this info I'm kinda struggling with the idea
of a standardized binding. In my case I'd like it to go into 'safe
mode' or 'firmware update'.
With loader = <0xace0ba5e>, <0xdeadbeef> ... and loader-names <> I
could have u-boot read the values
from fdt at boot. Then again I'm not describing hardware, but specific
settings ...
Would that be acceptable?
Cheers,
Moritz
next prev parent reply other threads:[~2015-12-23 8:37 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 9:02 [PATCH v1 0/6] misc: add reboot mode driver Andy Yan
2015-12-22 9:02 ` Andy Yan
2015-12-22 9:05 ` [PATCH v1 1/6] dt-bindings: misc: add document for reboot-mode driver Andy Yan
2015-12-22 9:05 ` Andy Yan
2015-12-23 0:32 ` Rob Herring
2015-12-23 0:32 ` Rob Herring
2015-12-23 0:32 ` Rob Herring
2015-12-23 8:37 ` Moritz Fischer [this message]
2015-12-23 8:37 ` Moritz Fischer
2015-12-23 8:37 ` Moritz Fischer
2015-12-23 9:01 ` Andy Yan
2015-12-23 9:01 ` Andy Yan
2015-12-23 9:01 ` Andy Yan
2015-12-22 9:08 ` [PATCH v1 2/6] dt-bindings: soc: add document for rockchip " Andy Yan
2015-12-22 9:08 ` Andy Yan
2015-12-22 9:10 ` [PATCH v1 3/6] misc: add reboot mode driver Andy Yan
2015-12-22 9:10 ` Andy Yan
2015-12-22 9:13 ` [PATCH v1 4/6] soc: rockchip: " Andy Yan
2015-12-22 9:13 ` Andy Yan
2015-12-22 9:16 ` [PATCH v1 5/6] ARM: dts: rockchip: add reboot-mode node Andy Yan
2015-12-22 9:16 ` Andy Yan
2015-12-22 11:23 ` Heiko Stübner
2015-12-22 11:23 ` Heiko Stübner
2015-12-22 11:23 ` Heiko Stübner
2015-12-22 13:37 ` Andy Yan
2015-12-22 9:19 ` [PATCH v1 6/6] ARM64: " Andy Yan
2015-12-22 9:19 ` Andy Yan
2015-12-22 16:47 ` [PATCH v1 0/6] misc: add reboot mode driver Alexandre Belloni
2015-12-22 16:47 ` Alexandre Belloni
2015-12-22 16:47 ` Alexandre Belloni
2015-12-23 9:31 ` Andy Yan
2015-12-23 9:31 ` Andy Yan
2015-12-23 9:31 ` Andy Yan
2015-12-28 15:28 ` Arnd Bergmann
2015-12-28 15:28 ` Arnd Bergmann
2015-12-28 15:28 ` Arnd Bergmann
2015-12-28 15:56 ` Heiko Stübner
2015-12-28 15:56 ` Heiko Stübner
2015-12-28 16:09 ` Arnd Bergmann
2015-12-28 16:09 ` Arnd Bergmann
2015-12-28 16:09 ` Arnd Bergmann
2015-12-29 7:55 ` Andy Yan
2015-12-29 7:55 ` Andy Yan
2015-12-29 7:55 ` Andy Yan
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='CAAtXAHfkfqELHamMVK3-6UE+LtVwimA7oe=QEzfF2WyrHXxcaQ@mail.gmail.com' \
--to=moritz.fischer@ettus.com \
--cc=akpm@linux-foundation.org \
--cc=alexandre.belloni@free-electrons.com \
--cc=andy.yan@rock-chips.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=joel@jms.id.au \
--cc=john.stultz@linaro.org \
--cc=jun.nie@linaro.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=olof@lixom.net \
--cc=pawel.moll@arm.com \
--cc=robh@kernel.org \
--cc=sjg@chromium.org \
--cc=sre@kernel.org \
--cc=treding@nvidia.com \
--cc=will.deacon@arm.com \
--cc=wxt@rock-chips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.