Message ID | 20201012105719.12492-1-schalla@marvell.com |
---|---|
Headers | show |
Series | Add Support for Marvell OcteonTX2 Cryptographic | expand |
On Mon, 12 Oct 2020 16:27:08 +0530 Srujana Challa wrote: > On OcteonTX2 SoC, the admin function (AF) is the only one with all > priviliges to configure HW and alloc resources, PFs and it's VFs > have to request AF via mailbox for all their needs. This patch adds > a mailbox interface for CPT PFs and VFs to allocate resources > for cryptography and inline-IPsec. > Inline-IPsec mailbox messages are added here to provide the interface > to Marvell VFIO drivers to allocate and configure HW resources > for inline IPsec feature. > > Signed-off-by: Suheil Chandran <schandran@marvell.com> > Signed-off-by: Vidya Sagar Velumuri <vvelumuri@marvell.com> > Signed-off-by: Srujana Challa <schalla@marvell.com> Please drop the IPsec support from this series, and limit it to just what's needed to get the Linux crypto API working.
On Mon, 12 Oct 2020 16:27:13 +0530 Srujana Challa wrote: > +/* tar header as defined in POSIX 1003.1-1990. */ > +struct tar_hdr_t { > + char name[100]; > + char mode[8]; > + char uid[8]; > + char gid[8]; > + char size[12]; > + char mtime[12]; > + char chksum[8]; > + char typeflag; > + char linkname[100]; > + char magic[6]; > + char version[2]; > + char uname[32]; > + char gname[32]; > + char devmajor[8]; > + char devminor[8]; > + char prefix[155]; > +}; > + > +struct tar_blk_t { > + union { > + struct tar_hdr_t hdr; > + char block[TAR_BLOCK_LEN]; > + }; > +}; In networking we've been pushing back on parsing firmware files in the kernel. Why do you need to parse tar archives?
> Subject: [EXT] Re: [PATCH v7,net-next,07/13] crypto: octeontx2: load microcode > and create engine groups > > External Email > > ---------------------------------------------------------------------- > On Mon, 12 Oct 2020 16:27:13 +0530 Srujana Challa wrote: > > +/* tar header as defined in POSIX 1003.1-1990. */ > > +struct tar_hdr_t { > > + char name[100]; > > + char mode[8]; > > + char uid[8]; > > + char gid[8]; > > + char size[12]; > > + char mtime[12]; > > + char chksum[8]; > > + char typeflag; > > + char linkname[100]; > > + char magic[6]; > > + char version[2]; > > + char uname[32]; > > + char gname[32]; > > + char devmajor[8]; > > + char devminor[8]; > > + char prefix[155]; > > +}; > > + > > +struct tar_blk_t { > > + union { > > + struct tar_hdr_t hdr; > > + char block[TAR_BLOCK_LEN]; > > + }; > > +}; > > In networking we've been pushing back on parsing firmware files > in the kernel. Why do you need to parse tar archives? We have 3 variants of crypto engines and each uses a different firmware file. So instead of 3 independent files in /lib/firmware, we have a consolidated tar file. The tar file is a container. Minimal parsing of firmware file is required to ensure parity between engine, firmware and driver. For example we verify version compatibility.