ARM64: Add support for FSL's LS2085A SoC
Subsystems (4)
v3 cover ARM64: Add support for FSL's LS2085A SoC
This patchset adds the support for FSL's LS2085A SoC which is based on ARMv8 architecture.
This patchset also has patches which addresses DT compatible strings for nodes which appear un-documented.
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2 CPU_ON method (and corresponding secondary boot) using the following ARMv8 u-boot patches:
http://patchwork.ozlabs.org/patch/383556/
http://patchwork.ozlabs.org/patch/383555/
http://patchwork.ozlabs.org/patch/383557/
http://patchwork.ozlabs.org/patch/383558/
http://patchwork.ozlabs.org/patch/383559/
http://patchwork.ozlabs.org/patch/383560/
http://patchwork.ozlabs.org/patch/383561/
http://patchwork.ozlabs.org/patch/383562/
Rebased against v3.17-rc3
Changes from v2:
----------------
* Addressed review comments:
- Minor nit-picks.
- Removed the #address-cells, #size-cells, and ranges properties in the gic node.
Bhupesh Sharma (6):
Documentation: DT: Add bindings for FSL NS16550A UART
Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model
Documentation: DT: Add entry for FSL Management Complex
arm64: Add DTS support for FSL's LS2085A SoC
arm64: dts/Makefile: Add support for FSL's LS2085A simulator model
arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig
Documentation/devicetree/bindings/arm/fsl.txt | 8 ++ .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 40 +++++++ .../devicetree/bindings/serial/of-serial.txt | 12 ++ arch/arm64/Kconfig | 5 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 26 +++++ arch/arm64/boot/dts/fsl-ls2085a.dtsi | 117 ++++++++++++++++++++ arch/arm64/configs/defconfig | 1 + 8 files changed, 210 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi
Signature · 1 line
1.7.9.5
PATCH v3 1/6 Documentation: DT: Add bindings for FSL NS16550A UART
This patch addss the device-tree documentation for Freescale's NS16550 UART (also called DUART).
There is a specific errata fix required in FSL NS16550 UART which ensures that an random interrupt storm is not observed when a break is provided as an input to the UART.
--- .../devicetree/bindings/serial/of-serial.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Documentation/devicetree/bindings/serial/of-serial.txt +12 -0
@@ -14,6 +14,7 @@ Required properties: - "altr,16550-FIFO32" - "altr,16550-FIFO64" - "altr,16550-FIFO128" + - "fsl,ns16550" - "serial" if the port type is unknown. - reg : offset and length of the register set for the device. - interrupts : should contain uart interrupt.
@@ -39,6 +40,17 @@ Optional properties: property. - has-hw-flow-control: the hardware has flow control capability. +Note: +* fsl,ns16550: + ------------ + Freescale DUART is very similar to the PC16552D (and to a + pair of NS16550A), albeit with some nonstandard behavior such as + erratum A-004737 (relating to incorrect BRK handling). + + Represents a single port that is compatible with the DUART found + on many Freescale chips (examples include mpc8349, mpc8548, + mpc8641d, p4080 and ls2085a). + Example: uart at 80230000 {
Signature · 1 line
1.7.9.5
PATCH v3 2/6 Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model
In reply to Bhupesh SharmaThis patch adds a devicetree binding documentation for FSL's LS2085A SoC and Simulator model.
--- Documentation/devicetree/bindings/arm/fsl.txt | 8 ++++++++ 1 file changed, 8 insertions(+)
Documentation/devicetree/bindings/arm/fsl.txt +8 -0
@@ -74,3 +74,11 @@ Required root node properties: i.MX6q generic board Required root node properties: - compatible = "fsl,imx6q"; + +Freescale LS2085A SoC Device Tree Bindings +------------------------------------------ + +LS2085A ARMv8 based Simulator model +Required root node properties: + - compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; +
Signature · 1 line
1.7.9.5
PATCH v3 3/6 Documentation: DT: Add entry for FSL Management Complex
In reply to Bhupesh SharmaThis patch adds a devicetree binding documentation for FSL's Management Complex.
Management Complex is a hardware resource manager that manages specialized hardware objects used in network-oriented packet processing applications
--- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 40 ++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt new file +40 -0
@@ -0,0 +1,40 @@ +* Freescale Management Complex + +The Freescale Management Complex (fsl-mc) is a hardware resource +manager that manages specialized hardware objects used in +network-oriented packet processing applications. After the fsl-mc +block is enabled, pools of hardware resources are available, such as +queues, buffer pools, I/O interfaces. These resources are building +blocks that can be used to create functional hardware objects/devices +such as network interfaces, crypto accelerator instances, L2 switches, +etc. + +Required properties: + + - compatible + Value type: <string> + Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex + compatible with this binding must have Block Revision + Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in + the MC control register region. + + - reg + Value type: <prop-encoded-array> + Definition: A standard property. Specifies one or two regions + defining the MC's registers: + + -the first region is the command portal for the + this machine and must always be present + + -the second region is the MC control registers. This + region may not be present in some scenarios, such + as in the device tree presented to a virtual machine. + +Example: + + fsl_mc: fsl-mc at 80c000000 { + compatible = "fsl,qoriq-mc"; + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ + }; +
Signature · 1 line
1.7.9.5
PATCH v3 4/6 arm64: Add DTS support for FSL's LS2085A SoC
In reply to Bhupesh SharmaThis patch adds the device tree support for FSL LS2085A SoC based on ARMv8 architecture.
Following levels of DTSI/DTS files have been created for the LS2085A SoC family:
- fsl-ls2085a.dtsi:
DTS-Include file for FSL LS2085A SoC.
- fsl-ls2085a-simu.dts:
DTS file for FSL LS2085a software simulator model.
--- arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 26 +++++++ arch/arm64/boot/dts/fsl-ls2085a.dtsi | 117 ++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+) create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +26 -0
@@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/dts-v1/; + +/include/ "fsl-ls2085a.dtsi" + +/ { + model = "Freescale Layerscape 2085a software Simulator model"; + compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; + + ethernet at 2210000 { + compatible = "smsc,lan91c111"; + reg = <0x0 0x2210000 0x0 0x100>; + interrupts = <0 58 0x1>; + }; +};
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +117 -0
117 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Arnd Bergmann
maintainerPATCH v3 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Quoted 8 lines · On Wednesday 03 September 2014 20:43:12 Bhupesh Sharma wrote:
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +1
-0@@ -0,0 +1,26 @@ +/*
arch/arm64/boot/dts/fsl-ls2085a-simu.dts line 11
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +10
-0+ * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */
One more thing, same comment as for the respective Exynos7 patch:
can this please be a permissive license, like GPLv2+MIT dual license?
Arnd
PATCH v3 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Hi Arnd,
Quoted 24 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 12:05 AM
To: linux-arm-kernel at lists.infradead.org
Cc: Sharma Bhupesh-B45370; Catalin.Marinas at arm.com; mark.rutland at arm.com; rob.herring at linaro.org; marc.zyngier at arm.com; Will.Deacon at arm.com; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-B45036
Subject: Re: [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoCQuoted 14 lines · On Wednesday 03 September 2014 20:43:12 Bhupesh Sharma wrote:
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +7
-0@@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + *
Quoted 9 lines
arch/arm64/boot/dts/fsl-ls2085a-simu.dts line 11
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +4
-0+ * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */One more thing, same comment as for the respective Exynos7 patch:
can this please be a permissive license, like GPLv2+MIT dual license?
Yes. I saw Russell's email in which he mentions that Linus is ok with using the MIT X11 licenses ([1]). However, I am not sure I understand the GPLv2+MIT dual license. Is it listed separately on [2], or is it a sum of the X11 + GPLv2 clauses mentioned in [2].
[1] http://www.spinics.net/lists/arm-kernel/msg358782.html
[2] http://www.gnu.org/licenses/license-list.html
Regards,
Bhupesh
PATCH v3 4/6 arm64: Add DTS support for FSL's LS2085A SoC
In reply to Arnd BergmannPing?
Quoted 59 lines
-----Original Message-----
From: Sharma Bhupesh-B45370
Sent: Thursday, September 04, 2014 1:25 PM
To: 'Arnd Bergmann'; linux-arm-kernel at lists.infradead.org
Cc: Catalin.Marinas at arm.com; mark.rutland at arm.com;
rob.herring at linaro.org; marc.zyngier at arm.com; Will.Deacon at arm.com; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-B45036
Subject: RE: [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoCHi Arnd,
Quoted 26 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 12:05 AM
To: linux-arm-kernel at lists.infradead.org
Cc: Sharma Bhupesh-B45370; Catalin.Marinas at arm.com; mark.rutland at arm.com; rob.herring at linaro.org; marc.zyngier at arm.com; Will.Deacon at arm.com; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-B45036
Subject: Re: [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoCQuoted 14 lines · On Wednesday 03 September 2014 20:43:12 Bhupesh Sharma wrote:
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +7
-0@@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + *Quoted 9 lines
arch/arm64/boot/dts/fsl-ls2085a-simu.dts line 11
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +4
-0+ * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */One more thing, same comment as for the respective Exynos7 patch:
can this please be a permissive license, like GPLv2+MIT dual license?Yes. I saw Russell's email in which he mentions that Linus is ok with using the MIT
X11 licenses ([1]). However, I am not sure I understand the GPLv2+MIT dual license.
Is it listed separately on [2], or is it a sum of the X11 + GPLv2 clauses mentioned in [2].[1] http://www.spinics.net/lists/arm-kernel/msg358782.html
[2] http://www.gnu.org/licenses/license-list.htmlRegards,
Bhupesh
PATCH v3 5/6 arm64: dts/Makefile: Add support for FSL's LS2085A simulator model
In reply to Bhupesh SharmaThis patch adds build support for FSL's LS2085A simulator model in arm64 dts Makefile.
--- arch/arm64/boot/dts/Makefile | 1 + 1 file changed, 1 insertion(+)
arch/arm64/boot/dts/Makefile +1 -0
@@ -1,5 +1,6 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb +dtb-$(CONFIG_ARCH_FSL_LS2085A) += fsl-ls2085a-simu.dtb targets += dtbs targets += $(dtb-y)
Signature · 1 line
1.7.9.5
PATCH v3 6/6 arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig
In reply to Bhupesh SharmaThis patch adds support for FSL's LS2085A SoC in the arm64 Kconfig and defconfig files.
--- arch/arm64/Kconfig | 5 +++++ arch/arm64/configs/defconfig | 1 + 2 files changed, 6 insertions(+)
arch/arm64/Kconfig +5 -0
@@ -149,6 +149,11 @@ config ARCH_XGENE help This enables support for AppliedMicro X-Gene SOC Family +config ARCH_FSL_LS2085A + bool "Freescale LS2085A SOC" + help + This enables support for Freescale LS2085A SOC. + endmenu menu "Bus support"
arch/arm64/configs/defconfig +1 -0
@@ -34,6 +34,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y +CONFIG_ARCH_FSL_LS2085A=y CONFIG_SMP=y CONFIG_PREEMPT=y CONFIG_KSM=y
Signature · 1 line
1.7.9.5
Arnd Bergmann
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Bhupesh SharmaQuoted 5 lines · On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2
CPU_ONmethod (and corresponding secondary boot) using the following ARMv8 u-boot patches:
What would be a reason for using something other than PSCI?
Arnd
v3 cover ARM64: Add support for FSL's LS2085A SoC
Hi Arnd,
Quoted 10 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Wednesday, September 03, 2014 9:00 PM
To: Sharma Bhupesh-B45370
Cc: Catalin.Marinas at arm.com; Will.Deacon at arm.com; grant.likely at secretlab.ca; mark.rutland at arm.com; marc.zyngier at arm.com; rob.herring at linaro.org; linux-arm-kernel at lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
Quoted 9 lines
Quoted 5 lines · On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2
CPU_ONmethod (and corresponding secondary boot) using the following ARMv8 u-boot patches:What would be a reason for using something other than PSCI?
We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot (see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3 of the DTS patchset have been tested with both the spin-table and PSCI approaches.
[1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
Regards,
Bhupesh
Arnd Bergmann
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 10 lines · On Wednesday 03 September 2014 15:36:44 bhupesh.sharma at freescale.com wrote:
Quoted 9 lines · On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
Quoted 5 lines
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2
CPU_ONmethod (and corresponding secondary boot) using the following ARMv8 u-boot patches:What would be a reason for using something other than PSCI?
Quoted 7 lines
We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot (see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3 of the DTS patchset have been tested with both the spin-table and PSCI approaches.
[1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
Would it be possible then to just mandate PSCI for the upstream-supported version?
Arnd
v3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 26 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Wednesday, September 03, 2014 9:09 PM
To: Sharma Bhupesh-B45370
Cc: Catalin.Marinas at arm.com; Will.Deacon at arm.com; grant.likely at secretlab.ca; mark.rutland at arm.com; marc.zyngier at arm.com; rob.herring at linaro.org; linux-arm-kernel at lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCQuoted 7 lines · On Wednesday 03 September 2014 15:36:44 bhupesh.sharma at freescale.com wrote:
Quoted 7 lines · On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
Quoted 5 lines
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2
CPU_ONmethod (and corresponding secondary boot) using the following ARMv8 u-boot patches:Quoted 7 lines
Quoted 2 lines
What would be a reason for using something other than PSCI?
We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot (see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3 of the DTS
Quoted 7 lines
patchset have been tested with both the spin-table and PSCI approaches.
Quoted 3 lines
[1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
Would it be possible then to just mandate PSCI for the upstream-supported version?
Yes. The upstream DTS is going to use PSCI as the default cpu release method for the secondary's. Later as we add more richness to the PSCI v0.2 layer in the ARMv8 u-boot, we will look to check features such as Hotplug etc.
Regards,
Bhupesh
Mark Rutland
reviewerv3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Arnd BergmannHi Arnd,
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Wednesday 03 September 2014 15:36:44 bhupesh.sharma at freescale.com wrote:
Quoted 9 lines · On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
Quoted 5 lines
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2
CPU_ONmethod (and corresponding secondary boot) using the following ARMv8 u-boot patches:What would be a reason for using something other than PSCI?
We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot (see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3 of the DTS patchset have been tested with both the spin-table and PSCI approaches.
Quoted 5 lines
Quoted 2 lines
[1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
Would it be possible then to just mandate PSCI for the upstream-supported version?
I had asked for the FW to patch up the enable-method (and omit this in the in-kernel dts) as this is something that may vary over the lifetime of the SoC independently from the fixed HW properties (it's a firmware property really).
Personally I'd like to see such things patched by the firmware/loader where possible (ideally with some way of switching said patching off if we really know better). We already expect the loader to patch memory nodes where memory can be dynamically populated.
I don't see why we should tie the in-kernel dts to a particular firmware revision. Having such properties in the in-kernel dts is only going to mislead. The arm64 boot-wrapper patches dts for PSCI, but for compatibility with old wrappers the in-kernel dts must forever say spin-table is used to bring up secondaries.
Mark.
Arnd Bergmann
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 4 lines · On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
I had asked for the FW to patch up the enable-method (and omit this in the in-kernel dts) as this is something that may vary over the lifetime of the SoC independently from the fixed HW properties (it's a firmware property really).
I agree in principle.
Quoted 10 lines
Personally I'd like to see such things patched by the
firmware/loaderwhere possible (ideally with some way of switching said patching off if we really know better). We already expect the loader to patch memory nodes where memory can be dynamically populated.I don't see why we should tie the in-kernel dts to a particular firmware revision. Having such properties in the in-kernel dts is only going to mislead. The arm64 boot-wrapper patches dts for PSCI, but for compatibility with old wrappers the in-kernel dts must forever say spin-table is used to bring up secondaries.
But the kernel has never supported this platform with a non-PSCI enable method, why should we provide compatibility for something we never had upstream?
ARnd
Mark Rutland
reviewerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 7 lines · Arnd Bergmann
Quoted 4 lines · On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
I had asked for the FW to patch up the enable-method (and omit this in the in-kernel dts) as this is something that may vary over the lifetime of the SoC independently from the fixed HW properties (it's a firmware property really).
I agree in principle.
Ok.
Quoted 11 lines
Quoted 10 lines
Personally I'd like to see such things patched by the
firmware/loaderwhere possible (ideally with some way of switching said patching off if we really know better). We already expect the loader to patch memory nodes where memory can be dynamically populated.I don't see why we should tie the in-kernel dts to a particular firmware revision. Having such properties in the in-kernel dts is only going to mislead. The arm64 boot-wrapper patches dts for PSCI, but for compatibility with old wrappers the in-kernel dts must forever say spin-table is used to bring up secondaries.
Quoted 3 lines
But the kernel has never supported this platform with a non-PSCI enable method, why should we provide compatibility for something we never had upstream?
I'm not arguing we should.
What I'm suggesting is there wouldn't be an enable-method at all (so we won't bring up secondaries at all unless that's patched).
I didn't spot an enable-method in skimming this series, but I've not yet looked at this posting in-depth. Assuming there isn't one I don't see that we're providing compatibility with anything.
Mark.
v3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 38 lines
-----Original Message-----
From: Mark Rutland [mailto:mark.rutland at arm.com]
Sent: Wednesday, September 03, 2014 9:40 PM
To: Arnd Bergmann
Cc: Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; grant.likely at secretlab.ca; Marc Zyngier; rob.herring at linaro.org; linux- arm-kernel at lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCQuoted 7 lines · Arnd Bergmann
Quoted 4 lines · On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
I had asked for the FW to patch up the enable-method (and omit this in the in-kernel dts) as this is something that may vary over the lifetime of the SoC independently from the fixed HW properties (it's a firmware property really).
I agree in principle.
Ok.
Quoted 4 lines
Quoted 4 lines
Personally I'd like to see such things patched by the
firmware/loaderwhere possible (ideally with some way of switching said patching off if we really know better). We already expect the loader to patch memory nodes where memory can be dynamicallypopulated.
Quoted 10 lines
Quoted 6 lines
I don't see why we should tie the in-kernel dts to a particular firmware revision. Having such properties in the in-kernel dts is only going to mislead. The arm64 boot-wrapper patches dts for PSCI, but for compatibility with old wrappers the in-kernel dts must forever say spin-table is used to bring up secondaries.
But the kernel has never supported this platform with a non-PSCI enable method, why should we provide compatibility for something we never had upstream?
Quoted 8 lines
I'm not arguing we should.
What I'm suggesting is there wouldn't be an enable-method at all (so we won't bring up secondaries at all unless that's patched).
I didn't spot an enable-method in skimming this series, but I've not yet looked at this posting in-depth. Assuming there isn't one I don't see that we're providing compatibility with anything.
'enable-method' has been removed from this DTS since v2.
Regards,
Bhupesh
Arnd Bergmann
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Mark RutlandQuoted 13 lines · On Wednesday 03 September 2014 17:09:36 Mark Rutland wrote:
Quoted 12 lines · Arnd Bergmann
Quoted 10 lines · On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
Personally I'd like to see such things patched by the
firmware/loaderwhere possible (ideally with some way of switching said patching off if we really know better). We already expect the loader to patch memory nodes where memory can be dynamically populated.I don't see why we should tie the in-kernel dts to a particular firmware revision. Having such properties in the in-kernel dts is only going to mislead. The arm64 boot-wrapper patches dts for PSCI, but for compatibility with old wrappers the in-kernel dts must forever say spin-table is used to bring up secondaries.
Quoted 8 lines
Quoted 3 lines
But the kernel has never supported this platform with a non-PSCI enable method, why should we provide compatibility for something we never had upstream?
I'm not arguing we should.
What I'm suggesting is there wouldn't be an enable-method at all (so we won't bring up secondaries at all unless that's patched).
Ok, I see the appeal in forcing boot loaders to put some patch up the dtbs with whatever software interfaces they provide. What I'm interested in however is making it harder for the boot loader to use something other than psci.
How about setting enable-method=psci but not providing a psci node? That way the boot loader still has to patch up the psci node but not necessarily each CPU node, unless they want to use the spin table, which they should not.
Arnd
Mark Rutland
reviewerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 20 lines · Arnd Bergmann
Quoted 19 lines · On Wednesday 03 September 2014 17:09:36 Mark Rutland wrote:
Quoted 12 lines · Arnd Bergmann
Quoted 10 lines · On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
Personally I'd like to see such things patched by the
firmware/loaderwhere possible (ideally with some way of switching said patching off if we really know better). We already expect the loader to patch memory nodes where memory can be dynamically populated.I don't see why we should tie the in-kernel dts to a particular firmware revision. Having such properties in the in-kernel dts is only going to mislead. The arm64 boot-wrapper patches dts for PSCI, but for compatibility with old wrappers the in-kernel dts must forever say spin-table is used to bring up secondaries.
Quoted 3 lines
But the kernel has never supported this platform with a non-PSCI enable method, why should we provide compatibility for something we never had upstream?
I'm not arguing we should.
Quoted 7 lines
Quoted 2 lines
What I'm suggesting is there wouldn't be an enable-method at all (so we won't bring up secondaries at all unless that's patched).
Ok, I see the appeal in forcing boot loaders to put some patch up the dtbs with whatever software interfaces they provide. What I'm interested in however is making it harder for the boot loader to use something other than psci.
I see.
I agree that we presently want systems to implement PSCI (0.2+), and we certainly do not want anything that's platform-specific.
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Mark.
Arnd Bergmann
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
I just saw that Geoff had a related comment, and documenting this would make it clearer to other reviewers, as well as people that happen to look at this file as a base for new platforms.
Arnd
Mark Rutland
reviewerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
Quoted 3 lines
I just saw that Geoff had a related comment, and documenting this would make it clearer to other reviewers, as well as people that happen to look at this file as a base for new platforms.
I agree that having something to point people in the right direction is a good idea. The only point I disagree with is putitng something in the DT that can be trivially made false (and possibly with good reason).
I'm happy with having comments.
Mark.
Arnd Bergmann
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 15 lines · On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
Quoted 6 lines
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/
I was thinking of leaving the enable-method in the cpus node, but having an empty psci node with a similar comment.
Quoted 2 lines
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
Quoted 9 lines
Quoted 3 lines
I just saw that Geoff had a related comment, and documenting this would make it clearer to other reviewers, as well as people that happen to look at this file as a base for new platforms.
I agree that having something to point people in the right direction is a good idea. The only point I disagree with is putitng something in the DT that can be trivially made false (and possibly with good reason).
I'm happy with having comments.
Right, but I see no good reason for having something else in the enable-method, the only way I can see why that would be done is for the boot loader or firmware implementer to be misinformed.
Arnd
v3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 33 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 4:39 AM
To: Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCQuoted 15 lines · On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
Quoted 6 lines
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/
Quoted 7 lines
I was thinking of leaving the enable-method in the cpus node, but having an empty psci node with a similar comment.
Quoted 2 lines
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
If any documentation updates are to be made I think they belong in Documentation/arm64/booting.txt.
There is currently the following:
[cut]
- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr' property in their cpu node. This property identifies a naturally-aligned 64-bit zero-initalised memory location.
These CPUs should spin outside of the kernel in a reserved area of memory (communicated to the kernel by a /memreserve/ region in the device tree) polling their cpu-release-addr location, which must be contained in the reserved region. A wfe instruction may be inserted to reduce the overhead of the busy-loop and a sev will be issued by the primary CPU. When a read of the location pointed to by the cpu-release-addr returns a non-zero value, the CPU must jump to this value. The value will be written as a single 64-bit little-endian value, so CPUs must convert the read value to their native endianness before jumping to it.
- CPUs with a "psci" enable method should remain outside of the kernel (i.e. outside of the regions of memory described to the kernel in the memory node, or in a reserved area of memory described to the kernel by a /memreserve/ region in the device tree). The kernel will issue CPU_ON calls as described in ARM document number ARM DEN 0022A ("Power State Coordination Interface System Software on ARM processors") to bring CPUs into the kernel.
The device tree should contain a 'psci' node, as described in Documentation/devicetree/bindings/arm/psci.txt.
[cut]
Whatever the requirements are-- enable-method present, psci node (empty or otherwise), plus anything about other initialization like CNTVOFF/CNTFREQ. Having all boot time requirements in one place would be good.
Also, if psci 2.0 is a requirement that should be specified in there as well.
Thanks,
Stuart
v3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Arnd BergmannHi Mark, Arnd
Quoted 32 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 3:09 PM
To: Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCQuoted 15 lines · On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
Quoted 6 lines
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/
Quoted 7 lines
I was thinking of leaving the enable-method in the cpus node, but having an empty psci node with a similar comment.
Quoted 2 lines
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
Is this documentation planned (already being worked upon), or should I try to spin-out a RFC patch which tries to add this guidance documentation.
Regards,
Bhupesh
Quoted 17 lines
Quoted 8 lines
Quoted 4 lines
I just saw that Geoff had a related comment, and documenting this would make it clearer to other reviewers, as well as people that happen to look at this file as a base for new platforms.
I agree that having something to point people in the right direction is a good idea. The only point I disagree with is putitng something in the DT that can be trivially made false (and possibly with good
reason).
Quoted 2 lines
I'm happy with having comments.
Right, but I see no good reason for having something else in the enable- method, the only way I can see why that would be done is for the boot loader or firmware implementer to be misinformed.
Arnd
Catalin Marinas
maintainerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 26 lines · bhupesh.sharma at freescale.com
Quoted 26 lines · On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
Quoted 15 lines · Arnd Bergmann
Quoted 8 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
Quoted 6 lines
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
Quoted 6 lines
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/I was thinking of leaving the enable-method in the cpus node, but having an empty psci node with a similar comment.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
Is this documentation planned (already being worked upon), or should I try to spin-out a RFC patch which tries to add this guidance documentation.
RFCs are welcome. We had such thing on the random to-do list of the day but never got to write anything down. As Stuart mentioned, it would be better to add it as part of the booting.txt document. A potential soc.txt is more for DT, code structuring (spreading) throughout drivers/ etc. If you have time, that would be good as well ;).
Signature · 1 line
Catalin
v3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Arnd BergmannPing?
Quoted 77 lines
-----Original Message-----
From: Sharma Bhupesh-B45370
Sent: Tuesday, September 09, 2014 5:16 PM
To: 'Arnd Bergmann'; Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Catalin Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: RE: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCHi Mark, Arnd
Quoted 34 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 3:09 PM
To: Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCQuoted 15 lines · On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
Quoted 7 lines
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent
on
* the FW, which will fill this in.
*/Quoted 7 lines
I was thinking of leaving the enable-method in the cpus node, but having an empty psci node with a similar comment.
Quoted 2 lines
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
Is this documentation planned (already being worked upon), or should I try to spin-out a RFC patch which tries to add this guidance documentation.
Regards,
BhupeshQuoted 17 lines
Quoted 8 lines
Quoted 4 lines
I just saw that Geoff had a related comment, and documenting this would make it clearer to other reviewers, as well as people that happen to look at this file as a base for new platforms.
I agree that having something to point people in the right direction is a good idea. The only point I disagree with is putitng something in the DT that can be trivially made false (and possibly with good
reason).
Quoted 2 lines
I'm happy with having comments.
Right, but I see no good reason for having something else in the enable- method, the only way I can see why that would be done is for the boot loader or firmware implementer to be misinformed.
Arnd
Mark Rutland
reviewerv3 cover ARM64: Add support for FSL's LS2085A SoC
Quoted 1 line · bhupesh.sharma at freescale.com
Ping?
Hi Bhupesh,
Quoted 48 lines
Quoted 48 lines
-----Original Message-----
From: Sharma Bhupesh-B45370
Sent: Tuesday, September 09, 2014 5:16 PM
To: 'Arnd Bergmann'; Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Catalin Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: RE: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCHi Mark, Arnd
Quoted 37 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 3:09 PM
To: Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoCQuoted 15 lines · On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
However, I'm not sure I follow the reasoning for making this significantly harder, and even ignoring that I don't think this does make things significantly harder. Especially so if we have a PSCI node but not an enable method -- in that case its trivial to patch in an unrelated enable-method anyhow.
Quoted 5 lines
Right, it's not actually much harder. A better way to look at it is probably that we document what which parts we expect to stay constant and which parts are to be filled out by the boot loader. Independent of what PSCI implementation the boot loader provides, we would like to see enable-method="psci".
Quoted 7 lines
So in the /cpus node, have a comment like:
/*
* We expect the enable-method to be "psci", but this is dependent
on
* the FW, which will fill this in.
*/I was thinking of leaving the enable-method in the cpus node, but having an empty psci node with a similar comment.
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Or, should we put together a soc-guidance.txt with that, ensuring things are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
Is this documentation planned (already being worked upon), or should I try to spin-out a RFC patch which tries to add this guidance documentation.
If you'd be willing to put together an RFC, that would be welcomed. It has so far been a TODO item that no-one has had the time for.
Mark.
v3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Arnd BergmannSo there is still an open issue that has not been closed related to what device trees should have with respect to enable-method. There are 2 proposals from Mark and Arnd--
1. Put comment in /cpus node in dts (Mark)
...
cpus {
#address-cells = <2>;
#size-cells = <0>;
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/
cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
};
...2. Put explicit psci enable-method in cpu nodes, to make it clear that psci
is expected. Plus include empty psci node with a comment. (Arnd)
...
/*
* We expect the enable-method to be "psci", but this is dependent on
* the FW, which will fill this in.
*/
psci {
}
...
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "psci";
};
...I would prefer #1. I think putting "hints" like the psci node and the enable-method are weak at best. I think the comment in #1 is enough to make the preferred approach clear. In the end firmware will override the nodes and properties if it wants or needs to.
Thanks,
Stuart
v3 cover ARM64: Add support for FSL's LS2085A SoC
In reply to Mark RutlandHi Mark.
Quoted 3 lines · Mark Rutland
Personally I'd like to see such things patched by the
firmware/loaderwhere possible (ideally with some way of switching said patching off if we really know better).
I think this makes sense for the enable method at least, since the enable method is a service the firmware provides, and what the firmware provides may vary over firmware revisions or even a single revision configured differently.
-Geoff