Re: [PROPOSAL] ARM/FDT: passing multiple binaries to a kernel

On Tue, Sep 3, 2013 at 10:53 AM, Andre Przywara andre.przyw...@linaro.org wrote: Hi, a normal Linux kernel currently supports reading the start and end address of a single binary blob via the FDT's /chosen node. This will be interpreted as the location of an initial RAM disk. The Xen

Re: [PROPOSAL] ARM/FDT: passing multiple binaries to a kernel

On Fri, Sep 13, 2013 at 5:13 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Wed, Sep 4, 2013 at 5:41 PM, Rob Herring robherri...@gmail.com wrote: For u-boot Andre has proposed some syntactic sugar over the fdt command to make boot.scr more trivial to use. We would of course need

Re: [RFC PATCH] driver core: make deferring probe forever optional

On Mon, May 7, 2018 at 1:31 PM, Bjorn Andersson <bjorn.anders...@linaro.org> wrote: > On Tue 01 May 14:31 PDT 2018, Rob Herring wrote: > >> Deferred probe will currently wait forever on dependent devices to probe, >> but sometimes a driver will never exist. It's

Re: DT handling, [Ref Linux-Efi]

On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf wrote: > > > On 27.04.18 08:24, Udit Kumar wrote: >> Hi >> There is bit of discussion on linux-efi too , to handle DT update >> >> I guess some members of this forum are active there too. >> >>

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

On Mon, May 7, 2018 at 12:17 PM, William Mills <wmi...@ti.com> wrote: > > > On 05/07/2018 11:49 AM, Rob Herring wrote: >> On Fri, May 4, 2018 at 1:41 PM, William Mills <wmi...@ti.com> wrote: >>> >>> On 05/04/2018 01:03 PM, Andreas Färber wrote: >&

Re: [PATCH 2/2] Add PDF output

On Mon, May 14, 2018 at 6:34 PM, Grant Likely wrote: > Use Sphinx-doc to generate PDF output from the source text. With Sphinx > installed, a PDF version of the document can be generated by typing: > 'make latexpdf' > > Signed-off-by: Grant Likely >

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Fri, May 25, 2018 at 7:20 AM, Robin Murphy <robin.mur...@arm.com> wrote: > On 24/05/18 21:57, Rob Herring wrote: >> >> On Thu, May 24, 2018 at 2:00 PM, Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >>> >>> On Thu,

[PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE

rg Cc: linux-samsung-...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: devicet...@vger.kernel.org Signed-off-by: Rob Herring <r...@kernel.org> --- drivers/iommu/arm-smmu-v3.c| 2 -- drivers/iommu/arm-smmu.c | 7 --- drivers/iommu/exynos-iommu.c

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Thu, May 24, 2018 at 1:18 PM, Mark Brown <broo...@kernel.org> wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning &g

Re: Issue#9 Document hardware need (if any)

On Wed, May 30, 2018 at 2:07 AM, Udit Kumar wrote: > > >> -Original Message----- >> From: Rob Herring [mailto:robherri...@gmail.com] >> Sent: Tuesday, May 29, 2018 8:32 PM >> To: Udit Kumar >> Cc: Architecture Mailman List ; >> n...@arm.com; arm.eb

Re: Notes on "requiring" separate storage

On Thu, May 31, 2018 at 5:08 PM, William Mills wrote: > Hello, > > My notes on "requiring" (or strongly recommending) separate storage. > > A couple of times we have gone around the issue of "is it reasonable to > require new platforms have separate storage for firmware". > > Pros: > P1) No disk

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Tue, May 29, 2018 at 12:12 AM, Frank Rowand wrote: > On 05/24/18 11:18, Mark Brown wrote: >> On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: >> >>> Subsystems or drivers may opt-in to this behavior by calling >>> driver_deferred_probe_check_init

Re: [Arm.ebbr-discuss] [PATCH] Create a new chapter to discuss shared storage

On Fri, Jun 29, 2018 at 11:03 AM Grant Likely wrote: > > Special care is needed when storage is shared between firmware and the > OS. Add a chapter that discusses the issues and puts down the > requirements for using shared storage. > > Resolves: #19 > > Cc: Daniel Thompson > Signed-off-by:

Re: [RFC PATCH] driver core: make deferring probe forever optional

On Wed, May 2, 2018 at 6:40 AM, Robin Murphy <robin.mur...@arm.com> wrote: > On 01/05/18 22:31, Rob Herring wrote: >> >> Deferred probe will currently wait forever on dependent devices to probe, >> but sometimes a driver will never exist. It's also not always critic

Re: DT handling, [Ref Linux-Efi]

On Thu, May 3, 2018 at 11:11 AM, Rob Herring <r...@kernel.org> wrote: > On Thu, May 3, 2018 at 9:29 AM, Alexander Graf <ag...@suse.de> wrote: >> On 04/30/2018 08:36 PM, Rob Herring wrote: >>> >>> On Fri, Apr 27, 2018 at 4:39 PM, Alexander Graf

Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]

On Thu, May 3, 2018 at 5:13 AM, Daniel Thompson wrote: > On Wed, May 02, 2018 at 05:39:02PM -0400, Tom Rini wrote: >> On Wed, May 02, 2018 at 05:12:03AM +, Chang, Abner (HPS SW/FW >> Technologist) wrote: >> >> > > -Original Message- >> > > From: Udit Kumar

Re: DT handling, [Ref Linux-Efi]

On Thu, May 3, 2018 at 9:29 AM, Alexander Graf <ag...@suse.de> wrote: > On 04/30/2018 08:36 PM, Rob Herring wrote: >> >> On Fri, Apr 27, 2018 at 4:39 PM, Alexander Graf <ag...@suse.de> wrote: >>> >>> Hi Rob, >>> >>> On 27.04.18 18:4

Re: [Arm.ebbr-discuss] U-boot

On Mon, Jul 30, 2018 at 8:11 AM Alexander Graf wrote: > > On 07/30/2018 02:39 PM, Alexander Graf wrote: > > On 07/30/2018 02:16 PM, David Rusling wrote: > >> Success. I now have a u-boot built on Arm64 that works. Along the > >> way I learnt various things: > >> > >> [1] Raspberry Pi's first

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory wrote: > > On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > > > Hi Mark > > > > > -Original Message- > > > From: Mark Brown [mailto:broo...@kernel.org] > > > Sent: Thursday, July 12, 2018 8:20 PM > > > To: Udit Kumar > > > Cc: Ard

[PATCH v4 4/6] iommu: Stop deferring probe at end of initcalls

...@lists.linux-foundation.org Signed-off-by: Rob Herring --- drivers/iommu/of_iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b7656a..78ddf47dd67a 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu

[PATCH v4 2/6] dt-bindings: pinctrl: add a 'pinctrl-use-default' property

that the pin configuration is optional. Signed-off-by: Rob Herring --- .../devicetree/bindings/pinctrl/pinctrl-bindings.txt| 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl

[PATCH v4 3/6] pinctrl: Support stopping deferred probe after initcalls

can print deferred probe related messages if needed. Reviewed-by: Linus Walleij Signed-off-by: Rob Herring --- v4: - Add Linus' R-by. v3: - Drop pinctrl deferred probe msg in favor of driver core messages - Move the handling of "pinctrl-use-default" option out of driver core - Stop defer

[PATCH v4 5/6] iommu: Remove IOMMU_OF_DECLARE

: linux-samsung-...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: devicet...@vger.kernel.org Acked-by: Will Deacon Acked-by: Marek Szyprowski Acked-by: Joerg Roedel Signed-off-by: Rob Herring --- drivers/iommu/arm-smmu-v3.c | 2 -- drivers/iommu

[PATCH v4 0/6] Make deferring probe forever optional

-architecture/2018-April/000466.html [2] https://lore.kernel.org/patchwork/project/lkml/list/?series=347413 [3] https://lore.kernel.org/patchwork/project/lkml/list/?series=357344 Rob Herring (6): driver core: allow stopping deferred probe after init dt-bindings: pinctrl: add a 'pinctrl-use

[PATCH v4 1/6] driver core: allow stopping deferred probe after init

are resolved, then the kernel log will be printed (as opposed to no output). Cc: Alexander Graf Signed-off-by: Rob Herring --- v4: - Rebase on driver-core-next - Only allow base 10 for timeout v3: - Merged with timeout patch. - Clarify that deferred_probe_timeout is a debug option. - Drop

Re: [PATCH v4 1/6] driver core: allow stopping deferred probe after init

On Mon, Jul 9, 2018 at 9:52 AM Russell King - ARM Linux wrote: > > On Mon, Jul 09, 2018 at 09:41:48AM -0600, Rob Herring wrote: > > Deferred probe will currently wait forever on dependent devices to probe, > > but sometimes a driver will never exist. It's also not always critica

[PATCH v3 0/6] Make deferring probe forever optional

-architecture/2018-April/000466.html [2] https://lore.kernel.org/patchwork/project/lkml/list/?series=347413 Rob Herring (6): driver core: allow stopping deferred probe after init dt-bindings: pinctrl: add a 'pinctrl-use-default' property pinctrl: Support stopping deferred probe after initcalls iommu

[PATCH v3 2/6] dt-bindings: pinctrl: add a 'pinctrl-use-default' property

that the pin configuration is optional. Signed-off-by: Rob Herring --- .../devicetree/bindings/pinctrl/pinctrl-bindings.txt| 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl

[PATCH v3 3/6] pinctrl: Support stopping deferred probe after initcalls

can print deferred probe related messages if needed. Signed-off-by: Rob Herring --- v3: - Drop pinctrl deferred probe msg in favor of driver core messages - Move the handling of "pinctrl-use-default" option out of driver core - Stop deferring probe if modules are not enabled. Linus,

[PATCH v3 1/6] driver core: allow stopping deferred probe after init

are resolved, then the kernel log will be printed (as opposed to no output). Cc: Alexander Graf Signed-off-by: Rob Herring --- v3: - Merged with timeout patch. - Clarify that deferred_probe_timeout is a debug option. - Drop the 'optional' param. The only user was pinctrl, so it has to handle

[PATCH v3 4/6] iommu: Stop deferring probe at end of initcalls

...@lists.linux-foundation.org Signed-off-by: Rob Herring --- v3: - Update to new function name drivers/iommu/of_iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b7656a..78ddf47dd67a 100644 --- a/drivers

[PATCH v3 5/6] iommu: Remove IOMMU_OF_DECLARE

: linux-samsung-...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: devicet...@vger.kernel.org Acked-by: Will Deacon Acked-by: Marek Szyprowski Acked-by: Joerg Roedel Signed-off-by: Rob Herring --- v3: - Also remove linker sections from vmlinux.lds.h

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

" Cc: Kevin Hilman Cc: Ulf Hansson Cc: Pavel Machek Cc: Len Brown Cc: Greg Kroah-Hartman Cc: linux...@vger.kernel.org Signed-off-by: Rob Herring --- v3: - Update to new function name drivers/base/power/domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/

Re: Moving ARM dts files

On Fri, Dec 7, 2018 at 9:16 AM Mark Brown wrote: > > On Fri, Dec 07, 2018 at 08:57:06AM -0600, Rob Herring wrote: > > On Thu, Dec 6, 2018 at 2:07 PM Mark Brown wrote: > > > > The issues with the existing install_dtbs sounded unrelated to this. > > > Maybe, wha

Re: Moving ARM dts files

On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber wrote: > > Am 05.12.18 um 05:17 schrieb Rob Herring: > > On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber wrote: > >> > >> Rob, > >> > >> Am 04.12.18 um 19:36 schrieb Rob Herring: > >>>

Re: Moving ARM dts files

On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber wrote: > > Rob, > > Am 04.12.18 um 19:36 schrieb Rob Herring: > > I've put together a script to move the dts files and update the > > makefiles. It doesn't handle files not following a common prefix which > > isn't

Re: [RFC v9 2/5] dt-bindings: pstore-block: new support for blkoops

+boot-architecture list On Tue, Feb 19, 2019 at 07:52:47PM +0800, liaoweixiong wrote: > Create DT binding document for blkoops. > > Signed-off-by: liaoweixiong > --- > .../devicetree/bindings/pstore/blkoops.txt | 53 > ++ > MAINTAINERS

Re: [PATCH v2 1/2] fdt: add support for rng-seed

On Sun, May 12, 2019 at 7:39 PM Hsin-Yi Wang wrote: > > Introducing a chosen node, rng-seed, which is an entropy that can be > passed to kernel called very early to increase initial device > randomness. Bootloader should provide this entropy and the value is > read from /chosen/rng-seed in DT. >

Re: [PATCH] arm64: add support for rng-seed

+boot-architecture list as there was some discussion about this IIRC. On Mon, May 6, 2019 at 11:54 PM Hsin-Yi Wang wrote: > > Introducing a chosen node, rng-seed, which is an 64 bytes entropy > that can be passed to kernel called very early to increase device > randomness. Bootloader should

Re: [PATCH] arm64: add support for rng-seed

On Thu, May 9, 2019 at 11:27 PM Hsin-Yi Wang wrote: > > On Wed, May 8, 2019 at 3:47 AM Rob Herring wrote: > > > > Documentation/devicetree/bindings/chosen.txt | 14 + > > > > Actually, this file has been converted to json-schema and lives > > here[1].

Re: [PATCH] arm64: add support for rng-seed

On Wed, May 8, 2019 at 10:06 AM Hsin-Yi Wang wrote: > > On Wed, May 8, 2019 at 10:04 PM Rob Herring wrote: > > > > On Tue, May 7, 2019 at 11:08 PM Hsin-Yi Wang wrote: > > > > > > On Wed, May 8, 2019 at 3:47 AM Rob Herring wrote: > > > > &

Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper)

On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>> Am 11.11.19 um 07:40 schrieb Greg

Re: DT based PSA description of hardware partition

On Fri, Dec 18, 2020 at 9:43 PM François Ozog wrote: > > Hi > > I assume this needs to be analyzed from System Device Tree perspective: > https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manifest-binding.html That's not what we're reviewing upstream[1]. Rob [1]

Re: DT conformance and "reg" tuples

On Thu, Dec 24, 2020 at 3:09 AM François Ozog wrote: > > Hi, > > As I am thinking about conformance testing for SystemReady and Trusted > Substrate, I'd like to get your feedback on the following. > > There are 7 values in the reg entry of interrupt-controller@21 from the > below DT. This

Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region

On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE wrote: > > > > On 4/20/21 4:45 PM, Rob Herring wrote: > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE > > wrote: > >> > >> Hi, > > > > Greg or Sasha won't know what to do with this. No

Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region

On Tue, Apr 20, 2021 at 11:10 AM Ard Biesheuvel wrote: > > On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote: > > > > On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE > > wrote: > > > > > > > > > > > > On 4/20/21 4:45 PM, Rob Herr

Re: Device Tree call: Define Secure Data Path reserved memory

On Fri, Feb 11, 2022 at 8:21 AM Bill Mills wrote: > > Rob, > > Can you confirm for the DT call on Feb 21? I'm on holiday on the 21st. > > Oliver, > > On 2/11/22 4:54 AM, Olivier Masse wrote: > > Hi Bill, > > > > NXP had a discussion with Linaro about this optee os issue: > >

Re: [EXT] Re: Device Tree call: Define Secure Data Path reserved memory

r the node name > >> (after > >> you fix the node name to include @address)? > >> > >> You are defining a compatible string in the node. The current > >> suggestion is not in the spec. It could be "optee,sdp" if you get > >> optee > &g

Re: [DT] Chosen node documentation

devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml Link: https://lore.kernel.org/lkml/c8dddfe6-6385-ed34-e789-9f845c8a3...@linaro.org/ Link: https://lore.kernel.org/lkml/CAL_Jsq+uSdk9YNbUW35yjN3q8-3FDobrxHmBpy=4rkmcfnb...@mail.gmail.com/ Signed-off-by: Jason A. Donenfeld

Re: [RFC] Proposed location to host the firmware handoff specification.

On Thu, Jun 30, 2022 at 3:24 AM Simon Glass wrote: > > Hi Jose, > > I don't think this is correct. TF-A is a project that aims to replace > U-Boot SPL (and perhaps other components) with more closed firmware, > e.g. the permissive license. > > This spec needs to be in a neutral place, not captive

Re: [RFC] Proposed location to host the firmware handoff specification.

On Tue, Jul 5, 2022 at 10:37 AM Simon Glass wrote: > > Hi Rob, > > On Tue, 5 Jul 2022 at 09:24, Rob Herring wrote: > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass wrote: > > > > > > Hi Jose, > > > > > > I don't think this is corr

Re: [PATCH] schemas: Add schema for firmware logs

+boot-architecture On Mon, Feb 6, 2023 at 3:25 PM Simon Glass wrote: > > Hi Rob, > > On Mon, 6 Feb 2023 at 10:15, Rob Herring wrote: > > > > On Sat, Feb 4, 2023 at 6:04 AM Simon Glass wrote: > > > > > > Hi Peter, > > > >

Re: [PATCH 00/21] Qualcomm generic board support

On Mon, Dec 11, 2023 at 11:47 PM Sumit Garg wrote: > > Hi Tom, > > On Sun, 10 Dec 2023 at 03:33, Tom Rini wrote: > > > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > > > [snip] > > > But currently u-boot doesn't have a proper way to validate those DTS > > > against DT bindings

Re: [PATCH 00/21] Qualcomm generic board support

On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg wrote: > > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > > wrote: > > > > >

Re: [PATCH 00/21] Qualcomm generic board support

On Thu, Dec 7, 2023 at 2:08 AM ff wrote: > > > > > Le 6 déc. 2023 à 21:42, Rob Herring a écrit : > > > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg wrote: > >> > >>> On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > >>> wrote: &

Re: [PATCH 00/21] Qualcomm generic board support

On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg wrote: > > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > wrote: > > > > On 05/12/2023 10:45, Sumit Garg wrote: > > > + U-boot custodians list > > > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > > wrote: > > >> > > >> On 05/12/2023