RE: [PATCH] v0.6-pre1 draft comments responses

2018-07-11 Thread Udit Kumar
Thanks Grant > -Original Message- > From: Grant Likely [mailto:grant.lik...@arm.com] > Sent: Thursday, July 12, 2018 1:44 AM > To: boot-architecture@lists.linaro.org; arm.ebbr-disc...@arm.com > Cc: Udit Kumar ; Grant Likely > Subject: [PATCH] v0.6-pre1 draft comments responses > > Edits

RE: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released

2018-07-11 Thread Udit Kumar
> -Original Message- > From: Grant Likely [mailto:grant.lik...@arm.com] > Sent: Thursday, July 12, 2018 1:33 AM > To: Udit Kumar ; boot-architecture@lists.linaro.org; > arm.ebbr-discuss > Cc: Ben Eckermann ; Varun Sethi > > Subject: Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released > > On

Re: [PATCH] Update manifesto from comments on mailing list

2018-07-11 Thread Alexander Graf
On 11.07.18 22:15, Grant Likely wrote: > On 11/07/2018 21:13, Simon Glass wrote: >> Hi Grant, >> >> On 9 July 2018 at 06:17, Grant Likely wrote: >>> Editing in response to comments from Bill Mills, Daniel Thompson, and >>> Alex Graf. Mostly trivial editorial, but did flush out the discussion of

Re: [PATCH] Update manifesto from comments on mailing list

2018-07-11 Thread Grant Likely
On 11/07/2018 21:13, Simon Glass wrote: Hi Grant, On 9 July 2018 at 06:17, Grant Likely wrote: Editing in response to comments from Bill Mills, Daniel Thompson, and Alex Graf. Mostly trivial editorial, but did flush out the discussion of how future updates to the specification would be handled

[PATCH] v0.6-pre1 draft comments responses

2018-07-11 Thread Grant Likely
Edits responding to comments from Udit Kumar Suggested-by: Udit Kumar Signed-off-by: Grant Likely --- source/chapter1-about.rst | 16 +--- source/chapter4-firmware-media.rst | 3 ++- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/source/chapter1-about.rst

Re: [PATCH] Update manifesto from comments on mailing list

2018-07-11 Thread Simon Glass
Hi Grant, On 9 July 2018 at 06:17, Grant Likely wrote: > Editing in response to comments from Bill Mills, Daniel Thompson, and > Alex Graf. Mostly trivial editorial, but did flush out the discussion of > how future updates to the specification would be handled, and added a > note about DT platfor

Re: [PATCH] Update manifesto from comments on mailing list

2018-07-11 Thread Grant Likely
On 09/07/2018 13:39, Mark Brown wrote: On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: - While ACPI provides more standardization, Devicetree is preferred in may embedded - platforms for its flexibility. + While ACPI provides more standardization, Devicetree is preferred in ma

Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released

2018-07-11 Thread Grant Likely
On 11/07/2018 06:33, Udit Kumar wrote: Hi Grant Few comments 1/ 1.1 Introduction For example, an Arm A-class embedded networking platform to For example, an Arm A-class embedded platform done 2/ 1.2 Guiding Principals EBBR as a specification defines requirements to EBBR as a specif

Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released

2018-07-11 Thread Grant Likely
On 09/07/2018 19:47, Dong Wei wrote: Grant, We don't need to change anything in the UEFI Spec. All we need to do is to request the addition of /Firmware directory in the registry. You can send the request to the USWG chair. There is a link on that page to send the request. Okay, I'll do that

Re: [PATCH v4 6/6] PM / Domains: Stop deferring probe at the end of initcall

2018-07-11 Thread Ulf Hansson
On 9 July 2018 at 17:41, Rob Herring wrote: > All PM domain drivers must be built-in (at least those using DT), so > there is no point deferring probe after initcalls are done. Continuing > to defer probe may prevent booting successfully even if managing PM > domains is not required. This can happ

Re: [PATCH v4 6/6] PM / Domains: Stop deferring probe at the end of initcall

2018-07-11 Thread Ulf Hansson
On 10 July 2018 at 16:25, Rob Herring wrote: > On Mon, Jul 9, 2018 at 4:49 PM Ulf Hansson wrote: >> >> On 9 July 2018 at 17:41, Rob Herring wrote: >> > All PM domain drivers must be built-in (at least those using DT), so >> > there is no point deferring probe after initcalls are done. Continuing