Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
These functions are CPU-related and do not use driver model. Move them to
cpu_func.h
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
The blob_encap and blob_decap functions were not flushing the dcache
before passing data to CAAM/DMA and not invalidating the dcache when
getting data back.
Therefore, blob encapsulation and decapsulation failed with errors like
the following due to data cache incoherency:
"40000006: DECO: desc idx 0: Invalid KEY command"
To ensure coherency, we require the key_mod, src and dst buffers to be
aligned to the cache line size and flush/invalidate the memory regions.
The same requirements apply to the job descriptor.
Tested on an i.MX6Q board.
Reviewed-by: Sumit Garg <sumit.garg@nxp.com>
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Now, include/linux/errno.h is a wrapper of <asm-generic/errno.h>.
Replace all include directives for <asm-generic/errno.h> with
<linux/errno.h>.
<asm-generic/...> is supposed to be included from <asm/...> when
arch-headers fall back into generic implementation. Generally, they
should not be directly included from .c files.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add drivers/usb/host/xhci-rockchip.c]
Signed-off-by: Tom Rini <trini@konsulko.com>
Update blob cmd to accept 64bit source, key modifier and destination
addresses. Also correct output result print format for fsl specific
implementation of blob cmd.
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Freescale's SEC block has built-in Data Encryption
Key(DEK) Blob Protocol which provides a method for
protecting a DEK for non-secure memory storage.
SEC block protects data in a data structure called
a Secret Key Blob, which provides both confidentiality
and integrity protection.
Every time the blob encapsulation is executed,
a AES-256 key is randomly generated to encrypt the DEK.
This key is encrypted with the OTP Secret key
from SoC. The resulting blob consists of the encrypted
AES-256 key, the encrypted DEK, and a 16-bit MAC.
During decapsulation, the reverse process is performed
to get back the original DEK. A caveat to the blob
decapsulation process, is that the DEK is decrypted
in secure-memory and can only be read by FSL SEC HW.
The DEK is used to decrypt data during encrypted boot.
Commands added
--------------
dek_blob - encapsulating DEK as a cryptgraphic blob
Commands Syntax
---------------
dek_blob src dst len
Encapsulate and create blob of a len-bits DEK at
address src and store the result at address dst.
Signed-off-by: Raul Cardenas <Ulises.Cardenas@freescale.com>
Signed-off-by: Nitin Garg <nitin.garg@freescale.com>
Signed-off-by: Ulises Cardenas <ulises.cardenas@freescale.com>
Signed-off-by: Ulises Cardenas-B45798 <Ulises.Cardenas@freescale.com>
This patch does the following:
1. The function names for encapsulation and decapsulation
were inconsitent in freescale's implementation and cmd_blob file.
This patch corrects the issues.
2. The function protopye is also modified to change the length parameter
from u8 to u32 to allow encapsulation and decapsulation of larger images.
3. Modified the description of km paramter in the command usage for better
readability.
Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com>
Reviewed-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Freescale's SEC block has built-in Blob Protocol which provides
a method for protecting user-defined data across system power
cycles. SEC block protects data in a data structure called a Blob,
which provides both confidentiality and integrity protection.
Encapsulating data as a blob
Each time that the Blob Protocol is used to protect data, a
different randomly generated key is used to encrypt the data.
This random key is itself encrypted using a key which is derived
from SoC's non volatile secret key and a 16 bit Key identifier.
The resulting encrypted key along with encrypted data is called a blob.
The non volatile secure key is available for use only during secure boot.
During decapsulation, the reverse process is performed to get back
the original data.
Commands added
--------------
blob enc - encapsulating data as a cryptgraphic blob
blob dec - decapsulating cryptgraphic blob to get the data
Commands Syntax
---------------
blob enc src dst len km
Encapsulate and create blob of data $len bytes long
at address $src and store the result at address $dst.
$km is the 16 byte key modifier is also required for
generation/use as key for cryptographic operation. Key
modifier should be 16 byte long.
blob dec src dst len km
Decapsulate the blob of data at address $src and
store result of $len byte at addr $dst.
$km is the 16 byte key modifier is also required for
generation/use as key for cryptographic operation. Key
modifier should be 16 byte long.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
