January 2018 - U-Boot

[U-Boot] Pull request v2: u-boot-spi/master
by Jagan Teki 26 Jan '18

26 Jan '18

Hi Tom, Please pull this PR. Changes for v2: - Fixed patches on wait_bit - Collected new patches. thanks! Jagan. The following changes since commit 98691a60abffb44303d7dae6e9e699d0daded930: Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 58c125b9e2b232ce73ed7b24ba7b1ca5ff41c5bd: DW SPI: Get clock value from Device Tree (2018-01-26 11:26:16 +0530) ---------------------------------------------------------------- Chris Packham (1): spi: kirkwood_spi: implement workaround for FE-9144572 Eugeniy Paltsev (2): SOCFPGA: clock manager: implement dw_spi_get_clk function DW SPI: Get clock value from Device Tree Goldschmidt Simon (1): Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" Jason Rush (4): spi: cadence_spi: Sync DT bindings with Linux dts: cadence_spi: Sync DT bindings with Linux config: cadence_spi: Remove defines read from DT dts: cadence_spi: Update documentation for DT bindings Mario Six (8): spi: Fix style violation and improve code spi: Remove obsolete spi_base_setup_slave_fdt spi: Remove spi_flash_probe_fdt spi: Remove spi_setup_slave_fdt spi: Remove CONFIG_OF_SPI_FLASH spi: sf_probe: Fix style violations spi: spi-uclass: Fix style violations sf_probe: Merge spi_flash_probe_tail into spi_flash_probe Miquel Raynal (1): doc: bindings: soft-spi: update documentation to match the code Vignesh R (2): Revert "spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible" spi: cadence_qspi_apb: Make flash writes 32 bit aligned Álvaro Fernández Rojas (16): wait_bit: add 8/16/32 BE/LE versions of wait_for_bit wait_bit: use wait_for_bit_le32 and remove wait_for_bit drivers: spi: allow limiting reads drivers: spi: consider command bytes when sending transfers dm: spi: add BCM63xx SPI driver mips: bmips: add bcm63xx-spi driver support for BCM6338 mips: bmips: add bcm63xx-spi driver support for BCM6348 mips: bmips: add bcm63xx-spi driver support for BCM6358 mips: bmips: add bcm63xx-spi driver support for BCM3380 mips: bmips: add bcm63xx-spi driver support for BCM63268 mips: bmips: enable the SPI flash on the Sagem F@ST1704 mips: bmips: enable the SPI flash on the Netgear CG3100D dm: spi: add BCM63xx HSSPI driver mips: bmips: add bcm63xx-hsspi driver support for BCM6328 mips: bmips: add bcm63xx-hsspi driver support for BCM63268 mips: bmips: enable the SPI flash on the Comtrend AR-5387un arch/arm/dts/keystone-k2g-evm.dts | 75 +++-- arch/arm/dts/keystone-k2g.dtsi | 5 +- arch/arm/dts/socfpga.dtsi | 5 +- arch/arm/dts/socfpga_arria10.dtsi | 4 +- arch/arm/dts/socfpga_arria5_socdk.dts | 9 +- arch/arm/dts/socfpga_cyclone5_is1.dts | 9 +- arch/arm/dts/socfpga_cyclone5_socdk.dts | 9 +- arch/arm/dts/socfpga_cyclone5_sockit.dts | 9 +- arch/arm/dts/socfpga_cyclone5_socrates.dts | 9 +- arch/arm/dts/socfpga_cyclone5_sr1500.dts | 9 +- arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 18 +- arch/arm/dts/stv0991.dts | 12 +- arch/arm/include/asm/arch-mvebu/spi.h | 6 + arch/arm/mach-imx/mx6/ddr.c | 22 +- arch/arm/mach-socfpga/clock_manager.c | 4 +- arch/arm/mach-socfpga/clock_manager_arria10.c | 9 + arch/arm/mach-socfpga/clock_manager_gen5.c | 15 +- arch/arm/mach-socfpga/reset_manager_arria10.c | 36 +-- arch/mips/dts/brcm,bcm3380.dtsi | 17 + arch/mips/dts/brcm,bcm63268.dtsi | 38 +++ arch/mips/dts/brcm,bcm6328.dtsi | 24 ++ arch/mips/dts/brcm,bcm6338.dtsi | 17 + arch/mips/dts/brcm,bcm6348.dtsi | 17 + arch/mips/dts/brcm,bcm6358.dtsi | 17 + arch/mips/dts/comtrend,ar-5387un.dts | 12 + arch/mips/dts/netgear,cg3100d.dts | 12 + arch/mips/dts/sagem,f(a)st1704.dts | 12 + arch/mips/mach-ath79/ar934x/clk.c | 2 +- board/samtec/vining_2000/vining_2000.c | 4 +- configs/comtrend_ar5387un_ram_defconfig | 8 + configs/netgear_cg3100d_ram_defconfig | 8 + configs/sagem_f@st1704_ram_defconfig | 8 + doc/device-tree-bindings/spi/soft-spi.txt | 24 +- doc/device-tree-bindings/spi/spi-cadence.txt | 13 +- drivers/clk/clk_pic32.c | 12 +- drivers/clk/renesas/clk-rcar-gen3.c | 4 +- drivers/ddr/microchip/ddr2.c | 8 +- drivers/fpga/socfpga_arria10.c | 17 +- drivers/mmc/msm_sdhci.c | 8 +- drivers/mtd/pic32_flash.c | 4 +- drivers/mtd/spi/sf_probe.c | 34 +- drivers/mtd/spi/spi_flash.c | 5 +- drivers/net/ag7xxx.c | 16 +- drivers/net/dwc_eth_qos.c | 17 +- drivers/net/ethoc.c | 8 +- drivers/net/pic32_eth.c | 12 +- drivers/net/pic32_mdio.c | 28 +- drivers/net/ravb.c | 4 +- drivers/net/xilinx_axi_emac.c | 4 +- drivers/net/zynq_gem.c | 12 +- drivers/reset/sti-reset.c | 4 +- drivers/serial/serial_pic32.c | 4 +- drivers/spi/Kconfig | 16 + drivers/spi/Makefile | 2 + drivers/spi/atmel_spi.c | 4 +- drivers/spi/bcm63xx_hsspi.c | 414 ++++++++++++++++++++++++ drivers/spi/bcm63xx_spi.c | 433 ++++++++++++++++++++++++++ drivers/spi/cadence_qspi.c | 20 +- drivers/spi/cadence_qspi.h | 6 +- drivers/spi/cadence_qspi_apb.c | 82 +++-- drivers/spi/designware_spi.c | 45 ++- drivers/spi/fsl_qspi.c | 20 +- drivers/spi/kirkwood_spi.c | 69 +++- drivers/spi/mvebu_a3700_spi.c | 20 +- drivers/spi/spi-uclass.c | 21 +- drivers/spi/spi.c | 27 +- drivers/usb/host/dwc2.c | 24 +- drivers/usb/host/ehci-msm.c | 3 +- drivers/usb/host/ehci-mx6.c | 5 +- drivers/usb/host/ohci-lpc32xx.c | 12 +- drivers/usb/host/xhci-rcar.c | 12 +- drivers/video/atmel_hlcdfb.c | 64 ++-- include/configs/k2g_evm.h | 2 - include/configs/socfpga_common.h | 2 - include/configs/stv0991.h | 2 - include/spi.h | 32 +- include/spi_flash.h | 12 - include/wait_bit.h | 85 ++--- scripts/config_whitelist.txt | 2 - 79 files changed, 1616 insertions(+), 519 deletions(-) create mode 100644 drivers/spi/bcm63xx_hsspi.c create mode 100644 drivers/spi/bcm63xx_spi.c

2 1

[U-Boot] Please pull u-boot-coldfire/master
by Angelo Dureghello 26 Jan '18

26 Jan '18

The following changes since commit c761a7e29d703d60208585bb7d8415e00aa22556: Revert "travis-ci: Add qemu-x86_64 target" (2018-01-22 21:06:41 -0500) are available in the Git repository at: git://git.denx.de/u-boot-coldfire.git master for you to fetch changes up to b9153fe3088a4ea295d6cd23dd44bed51224679a: common/board_f.c: align m68k arch to use CONFIG_DISPLAY_CPUINFO (2018-01-23 23:47:02 +0100) ---------------------------------------------------------------- Angelo Dureghello (1): common/board_f.c: align m68k arch to use CONFIG_DISPLAY_CPUINFO arch/m68k/cpu/mcf5227x/cpu.c | 4 +++- arch/m68k/cpu/mcf523x/cpu.c | 4 +++- arch/m68k/cpu/mcf52x2/cpu.c | 29 +++++++++++++++++++++-------- arch/m68k/cpu/mcf530x/cpu.c | 4 +++- arch/m68k/cpu/mcf532x/cpu.c | 4 +++- arch/m68k/cpu/mcf5445x/cpu.c | 4 +++- arch/m68k/cpu/mcf547x_8x/cpu.c | 4 +++- common/Kconfig | 2 +- common/board_f.c | 3 +-- 9 files changed, 41 insertions(+), 17 deletions(-)

2 1

[U-Boot] [RFC] i2c, omap24xx: Fixup High Speed Initialization
by Adam Ford 26 Jan '18

26 Jan '18

For devices running I2C over 400KHz, this needs to be in HS mode. Currently, the code is only running in HS mode when the speed is equal or greater than 3.4MHz. Using the Linux kernel setup as a reference, I used much of their calculation for fsscll, fssclh, hsscll, and hssclh. However, Linux uses fclk = clk_get(omap->dev, "fck") and fclk_rate = clk_get_rate(fclk) to setup psc. I wasn't sure how to do that in U-Boot since the structures are different, so I assumed fclk = I2C_IP_CLK (48000000). I don't think this is correct, so I am hoping someone might have a suggestion. As it stands, attempts to initialize I2C1 @ 2.6MHz fail, but this RFC doesn't appear to give me issues. As of this writing, I don't have a scope to look at the actual clock speed. Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c index 5d33815..4c1aa5d 100644 --- a/drivers/i2c/omap24xx_i2c.c +++ b/drivers/i2c/omap24xx_i2c.c @@ -205,9 +205,12 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, uint speed, int hsscll = 0, hssclh = 0; u32 scll = 0, sclh = 0; - if (speed >= OMAP_I2C_HIGH_SPEED) { + if (speed > OMAP_I2C_FAST_MODE) { /* High speed */ - psc = I2C_IP_CLK / I2C_INTERNAL_SAMPLING_CLK; + int scl; + int internal_clk = 19200000; + + psc = I2C_IP_CLK / internal_clk; psc -= 1; if (psc < I2C_PSC_MIN) { printf("Error : I2C unsupported prescaler %d\n", psc); @@ -215,12 +218,10 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, uint speed, } /* For first phase of HS mode */ - fsscll = I2C_INTERNAL_SAMPLING_CLK / (2 * speed); - - fssclh = fsscll; + scl = internal_clk / (400000); + fsscll = scl - (scl / 3) - 7; + fssclh = (scl / 3) - 5; - fsscll -= I2C_HIGHSPEED_PHASE_ONE_SCLL_TRIM; - fssclh -= I2C_HIGHSPEED_PHASE_ONE_SCLH_TRIM; if (((fsscll < 0) || (fssclh < 0)) || ((fsscll > 255) || (fssclh > 255))) { puts("Error : I2C initializing first phase clock\n"); @@ -228,10 +229,11 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, uint speed, } /* For second phase of HS mode */ - hsscll = hssclh = I2C_INTERNAL_SAMPLING_CLK / (2 * speed); + scl = I2C_INTERNAL_SAMPLING_CLK / speed; + + hsscll = scl - (scl / 3) - 7; + hssclh = (scl / 3) - 5; - hsscll -= I2C_HIGHSPEED_PHASE_TWO_SCLL_TRIM; - hssclh -= I2C_HIGHSPEED_PHASE_TWO_SCLH_TRIM; if (((fsscll < 0) || (fssclh < 0)) || ((fsscll > 255) || (fssclh > 255))) { puts("Error : I2C initializing second phase clock\n"); -- 2.7.4

1 0

[U-Boot] How to build standalone app *outside* u-boot build tree
by Brett Stahlman 26 Jan '18

26 Jan '18

I'd like to build my own application - something like examples/standalone/hello_world - but if possible, I'd like to build it outside the u-boot tree. The standalone examples are meant to be invoked with a recursive make from an ancestor directory in the u-boot tree. They don't work if you just copy examples/standalone out into your own version controlled tree and attempt to build from there. Was wondering if there's a standard way to build your own standalone app, but using the u-boot infrastructure: e.g., something like the way you build a linux kernel module whose source lives outside the kernel source tree. Thanks, Brett S.

1 0

[U-Boot] [PATCH v4 0/2] Fix CAAM for TrustZone enable for warp7
by Bryan O'Donoghue 26 Jan '18

26 Jan '18

V4: - Fix dim-witted omission of #include <fsl_sec.h> to remove warning V3: - Changed location of sec_init() from warp.c::board_init() to soc.c::arch_misc_init() which will allow any i.MX7 which defines CONFIG_FSL_CAAM to forget about running sec_init(). V2: - Add an explicit assignment of JRMID when setting job-ring ownership Required on my reference part where the JRMID field is not set on the third job-ring V1: This series is the u-boot fix to a problem we encountered when enabling OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is activated the first page of CAAM registers becomes read-only, read-zero from the perspective of Linux and other non TrustZone contexts. Offlining the problem with Peng Fan[1] we eventually came to realise the problem could be worked around by 1. Making Linux skip RNG initialisation - a set of patches should be hitting LKML to do just that. 2. Initialising the RNG either from u-boot or OPTEE. In this case u-boot is the right place to-do that because there's upstream code in u-boot that just works. Patch #2 does that for the WaRP7. 3. Ensuring the job-ring registers are assigned to the non TrustZone mode. On the i.MX7 after the BootROM runs the job-ring registers are assigned to TrustZone. Patch #1 does that for all CAAM hardware. On point #3 this ordinarily isn't a problem because unless TrustZone is activated the restrictions on the job-ring registers don't kick in, its only after enabling TrustZone that Linux will loose access to the job-ring registers. Finally should OPTEE or another TEE want to do things with the job-ring registers it will have sufficient privilege to assign whichever job-ring registers it wants to OPTEE/TEE but will naturally then have to arbitrate with Linux to inform the Kernel CAAM driver which job-ring registers it can and cannot access. That arbitration process is for a future putative OPTEE/TEE CAAM driver to solve and is out of scope of this patchset. [1] Thanks for all of your help BTW - Peng, there's no way this would be working without you giving direction on how. Bryan O'Donoghue (2): drivers/crypto/fsl: assign job-rings to non-TrustZone imx: mx7: run sec_init for CAAM RNG arch/arm/mach-imx/mx7/soc.c | 5 +++++ drivers/crypto/fsl/jr.c | 9 +++++++++ drivers/crypto/fsl/jr.h | 2 ++ 3 files changed, 16 insertions(+) -- 2.7.4

1 1

[U-Boot] [PATCH] imx-common: spl: Allow booting from eMMC when SPL is loaded from non-eMMC device
by Lukasz Majewski 26 Jan '18

26 Jan '18

This patch tries to solve the problem described in following patch: https://patchwork.ozlabs.org/patch/796237/ The main argument against the above code was the potential lack of consistency if we boot SPL from the SD card (and then eMMC may load u-boot proper). This patch preserves this consistency if spl_boot_device() detects boot from either SD card or eMMC. It only will change boot device if boot from non-SD/eMMC device is detected - i.e SPI-NOR (as in this case). Signed-off-by: Lukasz Majewski <lukma(a)denx.de> --- arch/arm/mach-imx/spl.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 6c16872f59..735d9f6261 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -134,7 +134,12 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name) /* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */ u32 spl_boot_mode(const u32 boot_device) { - switch (spl_boot_device()) { + u32 spl_bd = spl_boot_device(); + + if (spl_bd != BOOT_DEVICE_MMC1) + spl_bd = boot_device; + + switch (spl_bd) { /* for MMC return either RAW or FAT mode */ case BOOT_DEVICE_MMC1: case BOOT_DEVICE_MMC2: -- 2.11.0

3 4

Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
by Duncan Hare 26 Jan '18

26 Jan '18

From: Heinrich Schuchardt <xypron.debian(a)gmx.de> To: Duncan Hare <dh(a)synoia.com>; Alexander Graf <agraf(a)suse.de> Subject: Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI On 01/25/2018 08:39 PM, Duncan Hare wrote: >>> ----- Forwarded Message ----- >>> From: Alexander Graf <agraf(a)suse.de> >>> To: Heinrich Schuchardt <xypron.glpk(a)gmx.de> >> >>>> The appended README explains how U-Boot and iPXE can be used >>>> to boot a diskless system from an iSCSI SAN. >>>> >> We are implementing a limited TCP and a wget (http 1.0) app.>> It is almost ready for an test release. Selective Acknowledgment (SACK) >> is under test as a final piece of the TCP stack. In which git can I find the code? >> >> We have noticed that omitting the http 1.0 declaration in >> downloading the kernel from an nginx web server that we remove the >> overhead of an http header completely. >> > RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 > You should not program to please another accommodating software but > according to a standard. I agree. The comment was a FYI. > The key to TCP performance is supporting multiple packets in flight. And we do. That's set in include/net.h in the buffer definitions.With single packet-at-a time one might as well stick with udp. I've worked on network communication protocols since 1973.c programming, not so much. git, I'm a newb. HeinrichIt is not yet pushed to git.I need to fix the bugs in SACK before taking that step. I had hoped this week but I was delayed by flu. It adheres to http 1.0. It is a minimal implementation. It is relatively fast. It drives a Raspberry Pi at 10 M bits/sec, the limitation being the raspberry pi processor speed. I can send you a tarball, together with the changes to tftp.c for testing that a downloaded image is correct. Regards Duncan Hare 714 931 7952

1 0

[U-Boot] [PATCH v2 00/12] sunxi: arm64 binary size fixes
by Maxime Ripard 26 Jan '18

26 Jan '18

Hi, As we discussed already, this is the list of options that we will need to disable by default. I also added to the mix a size check, which even though it's not really optimal, is temporary and will be removed in a future (and hopefully close) release. Tom, is this still something we can merge for 2018.01? Thanks! Maxime Changes from v1: - Fixed a couple of nitpicks - Rebased on top of current master - Fixed a build error with boards using DFU Andre Heider (1): sunxi: imply CONFIG_OF_LIBFDT_OVERLAY Maxime Ripard (11): dfu: select HASH cmd: crc32: Disable by default on sunXi cmd: unzip: Disable by default on sunXi cmd: loadb: Disable by default on sunXi cmd: loads: Disable by default on sunXi cmd: misc: Disable by default on sunXi video: bpp8: Disable by default on sunXi video: bpp16: Disable by default on sunXi net: regex: Disable by default on sunXi Makefile: Add size check to the u-boot.itb make target sunxi: Add limit with the MMC environment Makefile | 1 + arch/arm/Kconfig | 1 + cmd/Kconfig | 5 +++++ configs/CHIP_defconfig | 1 - configs/CHIP_pro_defconfig | 1 - drivers/dfu/Kconfig | 1 + drivers/video/Kconfig | 2 ++ include/configs/sunxi-common.h | 10 ++++++++++ lib/Kconfig | 1 + 9 files changed, 21 insertions(+), 2 deletions(-) -- 2.14.3

2 14

Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI
by Duncan Hare 26 Jan '18

26 Jan '18

> ----- Forwarded Message ----- > From: Alexander Graf <agraf(a)suse.de> > To: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > > The appended README explains how U-Boot and iPXE can be used > > to boot a diskless system from an iSCSI SAN. > > > > The maintainer for README.efi and README.iscsi is set. > > > > Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > > --- > +U-Boot has only a reduced set of supported network protocols. A > major gap is > > major gap is +the lack of a TCP stack. > > This is only semi-true. There is work in progress to get TCP support > into U-Boot. The protocols on top however are still missing and using > iPXE here is definitely a very reasonable approach. We are implementeinga limited TCP and a wget (http 1.0) app. It is almost ready for an test release. Selective Acknowledgment (SACK) is under test as a final piece of the TCP stack. We have noticed that omitting the http 1.0 declaration in downloading the kernel from an nginx web server that we remove the overhead of an http header completely. > > > + > > +For booting a diskless computer this leaves us with BOOTP or DHCP > > to get the +address of a boot script. TFTP can be used to load the > > boot script and the +operating system kernel and initial file > > system (initrd). We use DHCP or DNS. DHCP assumes one has control of the DHCP server and are generally inside the firewall, and is complex to adminsited is there are many (branch office) DHCP servers. With MS 2012 R2 server configuring DHCP options is complex. > > +These protocols are insecure. The client cannot validate the > > authenticity +of the contacted servers. And the server cannot > > verify the identity of the +client. Yes and no. We (optionally) use the burnt in MAC address or serial number to identify a client machine, and can prevent boot if it is not authorized by denying the download of the *nix kernel. If inside the firewall and using DHCP security is probably completly under the control of the enterprise admins. We use locally administered DNS servers to control address resolution under DNS. > > iPXE is the > > "swiss army knife" of +network booting. It supports both HTTPS and > > iSCSI. It has a script engine for +fine grained control of the boot > > process and can provide a command shell. + (1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex) or (2)u-boot (+ missing functions)->kernel? > > +protocol. Now iPXE can call the simple file protocol to load Grub. I seem to be missing the point. We use U-boot to load and run the kernel with tcp+http 1.0. https would be a nice enhancement, as would an encrypted connection for the *nix kernel to access the image, but complete security requires more. If you are going to do this we need to discuss accessing the *nix image over a secure protocol. AFAIK the *nix kernel does not use secure protocols with network *nix images. In the netboot process we'd address the performance limitations of NFS, especially during boot, with either lookahead caching at the client or use HTTPS for image access, both of which are outside u-boot's scope.

3 2

[U-Boot] [PATCH v2 0/2] Fix CAAM for TrustZone enable for warp7
by Bryan O'Donoghue 26 Jan '18

26 Jan '18

V2: - Add an explicit assignment of JRMID when setting job-ring ownership Required on my reference part where the JRMID field is not set on the third job-ring V1: This series is the u-boot fix to a problem we encountered when enabling OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is activated the first page of CAAM registers becomes read-only, read-zero from the perspective of Linux and other non TrustZone contexts. Offlining the problem with Peng Fan[1] we eventually came to realise the problem could be worked around by 1. Making Linux skip RNG initialisation - a set of patches should be hitting LKML to do just that. 2. Initialising the RNG either from u-boot or OPTEE. In this case u-boot is the right place to-do that because there's upstream code in u-boot that just works. Patch #2 does that for the WaRP7. 3. Ensuring the job-ring registers are assigned to the non TrustZone mode. On the i.MX7 after the BootROM runs the job-ring registers are assigned to TrustZone. Patch #1 does that for all CAAM hardware. On point #3 this ordinarily isn't a problem because unless TrustZone is activated the restrictions on the job-ring registers don't kick in, its only after enabling TrustZone that Linux will loose access to the job-ring registers. Finally should OPTEE or another TEE want to do things with the job-ring registers it will have sufficient privilege to assign whichever job-ring registers it wants to OPTEE/TEE but will naturally then have to arbitrate with Linux to inform the Kernel CAAM driver which job-ring registers it can and cannot access. That arbitration process is for a future putative OPTEE/TEE CAAM driver to solve and is out of scope of this patchset. [1] Thanks for all of your help BTW - Peng, there's no way this would be working without you giving direction on how. Bryan O'Donoghue (2): drivers/crypto/fsl: assign job-rings to non-TrustZone warp7 : run sec_init for CAAM RNG board/warp7/warp7.c | 6 +++++- drivers/crypto/fsl/jr.c | 9 +++++++++ drivers/crypto/fsl/jr.h | 2 ++ 3 files changed, 16 insertions(+), 1 deletion(-) -- 2.7.4

2 6