Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1422366 > unrolled thread

Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings

Started byRob Herring <robh@kernel.org>
First post2016-06-15 00:00 +0200
Last post2016-06-21 22:50 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings Rob Herring <robh@kernel.org> - 2016-06-15 00:00 +0200
    Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings Kees Cook <keescook@chromium.org> - 2016-06-15 06:50 +0200
      Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings Rob Herring <robh@kernel.org> - 2016-06-21 22:50 +0200

#1422366 — Re: [PATCH v4 0/1] pstore/ram: add Device Tree bindings

FromRob Herring <robh@kernel.org>
Date2016-06-15 00:00 +0200
SubjectRe: [PATCH v4 0/1] pstore/ram: add Device Tree bindings
Message-ID<rK4xo-23y-7@gated-at.bofh.it>
On Fri, Jun 10, 2016 at 03:50:58PM -0700, Kees Cook wrote:
> This is a "v4" of Greg Hackmann's DT bindings for ramoops. This is
> what I'm going to land in the pstore tree unless there are strong and
> convincing arguments against it. :)
> 
> I made a number of changes based people's feedback, and I want to get
> it unblocked. This patch is already carried by Android, and it doesn't
> need to be out of tree.
> 
> To respond to Arnd's comment: I like this as the ramoops node, not the
> pstore node, since it describes the ramoops backend, not the pstore
> subsystem, which has different controls, and can only have one backend
> at a time. So it doesn't make sense to me to have this have a redundant
> extra pstore node, since the very presence of ramoops implies pstore.

Either I don't follow or you don't get Arnd's comment...

IIRC, his suggestion which I agree with was to remove the memory-region 
phandle and just move all the properties into the reserved memory node 
directly. This simplifies things such that we are just describing 
properties of a chunk of memory rather than a Linux specific node for 
virtual driver.

Rob

[toc] | [next] | [standalone]


#1422590

FromKees Cook <keescook@chromium.org>
Date2016-06-15 06:50 +0200
Message-ID<rKaW5-6gR-1@gated-at.bofh.it>
In reply to#1422366
On Tue, Jun 14, 2016 at 2:59 PM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Jun 10, 2016 at 03:50:58PM -0700, Kees Cook wrote:
>> This is a "v4" of Greg Hackmann's DT bindings for ramoops. This is
>> what I'm going to land in the pstore tree unless there are strong and
>> convincing arguments against it. :)
>>
>> I made a number of changes based people's feedback, and I want to get
>> it unblocked. This patch is already carried by Android, and it doesn't
>> need to be out of tree.
>>
>> To respond to Arnd's comment: I like this as the ramoops node, not the
>> pstore node, since it describes the ramoops backend, not the pstore
>> subsystem, which has different controls, and can only have one backend
>> at a time. So it doesn't make sense to me to have this have a redundant
>> extra pstore node, since the very presence of ramoops implies pstore.
>
> Either I don't follow or you don't get Arnd's comment...
>
> IIRC, his suggestion which I agree with was to remove the memory-region
> phandle and just move all the properties into the reserved memory node
> directly. This simplifies things such that we are just describing
> properties of a chunk of memory rather than a Linux specific node for
> virtual driver.

Ah! Okay, I'm a DT newbie, so I think I misunderstood Arnd. :) If it's
easy, can you create a patch for that against the v4 I sent of Greg's
patch? I'm not sure how to do what you're suggesting. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]


#1428150

FromRob Herring <robh@kernel.org>
Date2016-06-21 22:50 +0200
Message-ID<rMAMq-2gO-27@gated-at.bofh.it>
In reply to#1422590
On Tue, Jun 14, 2016 at 09:40:47PM -0700, Kees Cook wrote:
> On Tue, Jun 14, 2016 at 2:59 PM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Jun 10, 2016 at 03:50:58PM -0700, Kees Cook wrote:
> >> This is a "v4" of Greg Hackmann's DT bindings for ramoops. This is
> >> what I'm going to land in the pstore tree unless there are strong and
> >> convincing arguments against it. :)
> >>
> >> I made a number of changes based people's feedback, and I want to get
> >> it unblocked. This patch is already carried by Android, and it doesn't
> >> need to be out of tree.
> >>
> >> To respond to Arnd's comment: I like this as the ramoops node, not the
> >> pstore node, since it describes the ramoops backend, not the pstore
> >> subsystem, which has different controls, and can only have one backend
> >> at a time. So it doesn't make sense to me to have this have a redundant
> >> extra pstore node, since the very presence of ramoops implies pstore.
> >
> > Either I don't follow or you don't get Arnd's comment...
> >
> > IIRC, his suggestion which I agree with was to remove the memory-region
> > phandle and just move all the properties into the reserved memory node
> > directly. This simplifies things such that we are just describing
> > properties of a chunk of memory rather than a Linux specific node for
> > virtual driver.
> 
> Ah! Okay, I'm a DT newbie, so I think I misunderstood Arnd. :) If it's
> easy, can you create a patch for that against the v4 I sent of Greg's
> patch? I'm not sure how to do what you're suggesting. :)

While I want to see this merged, I'm not going to get to anything soon. 
So here's a DT example of what I mean. This will in addition need an 
of_platform_populate call on the /reserved-memory node to get the 
platform device created.

{/
        reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		/* global autoconfigured region for contiguous allocations */
		linux,cma {
			compatible = "shared-dma-pool";
			reusable;
			size = <0x4000000>;
			alignment = <0x2000>;
			linux,cma-default;
		};

		ramoops@78000000 {
			compatible = "ramoops";
			reg = <0x78000000 0x8000>;
			record-size = <0x4000>;
			console-size = <0x4000>
		};
	};
};

Rob

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web