[OpenWrt-Devel][PATCH v2 2/2] octeontx: enable Cavium CPT and ZIP drivers
tharvey at gateworks.com
Wed Jun 24 17:06:38 EDT 2020
On Thu, Jun 11, 2020 at 5:22 AM Hauke Mehrtens <hauke at hauke-m.de> wrote:
> On 6/3/20 10:16 PM, Tim Harvey wrote:
> > On Tue, Jun 2, 2020 at 3:21 PM Hauke Mehrtens <hauke at hauke-m.de> wrote:
> >> On 6/2/20 7:05 PM, Tim Harvey wrote:
> >>> The CPT module requires firmware which we add here as well.
> >>> Signed-off-by: Tim Harvey <tharvey at gateworks.com>
> >>> ---
> >>> v2: added license file for firmware
> >>> ---
> >>> target/linux/octeontx/config-5.4 | 11 +++++++++++
> >>> target/linux/octeontx/files/firmware/cpt8x-mc-ae.out | Bin 0 -> 9760 bytes
> >>> target/linux/octeontx/files/firmware/cpt8x-mc-se.out | Bin 0 -> 35584 bytes
> >>> target/linux/octeontx/files/firmware/license.txt | 11 +++++++++++
> >>> 4 files changed, 22 insertions(+)
> >>> create mode 100644 target/linux/octeontx/files/firmware/cpt8x-mc-ae.out
> >>> create mode 100644 target/linux/octeontx/files/firmware/cpt8x-mc-se.out
> >>> create mode 100644 target/linux/octeontx/files/firmware/license.txt
> >>> diff --git a/target/linux/octeontx/config-5.4 b/target/linux/octeontx/config-5.4
> >>> index cfb8b19..9fcd12b 100644
> >>> --- a/target/linux/octeontx/config-5.4
> >>> +++ b/target/linux/octeontx/config-5.4
> >> ......
> >>> @@ -233,6 +239,8 @@ CONFIG_EEPROM_AT24=y
> >>> CONFIG_EFI_EARLYCON=y
> >>> CONFIG_EXT4_FS=y
> >>> CONFIG_EXT4_FS_POSIX_ACL=y
> >>> +CONFIG_EXTRA_FIRMWARE="cpt8x-mc-ae.out cpt8x-mc-se.out"
> >>> +CONFIG_EXTRA_FIRMWARE_DIR="firmware"
> >>> CONFIG_F2FS_FS=y
> >>> CONFIG_F2FS_FS_XATTR=y
> >>> CONFIG_F2FS_STAT_FS=y
> >> ....
> >>> diff --git a/target/linux/octeontx/files/firmware/license.txt b/target/linux/octeontx/files/firmware/license.txt
> >>> new file mode 100644
> >>> index 0000000..531eaba
> >>> --- /dev/null
> >>> +++ b/target/linux/octeontx/files/firmware/license.txt
> >> Hi,
> >> I think this is not compatible with the OpenWrt license or at least goes
> >> into a gray area.
> >>> @@ -0,0 +1,11 @@
> >>> +Copyright (C) 2019 Marvell International Ltd.
> >>> +
> >>> +The software package is subject to the Marvell binary license that prohibits the
> >>> +licensee to modify the software, in any manner and that prohibits to distribute
> >>> +the software as a stand-alone product.
> >> Is the distribution in
> >> target/linux/octeontx/files/firmware/cpt8x-mc-se.out not a standalone
> >> product?
> > Hauke,
> > I agree that this is a gray area for sure. I don't like the wording at
> > all either.
> >> You can create a link to https://git.openwrt.org where you can directly
> >> download it when we push it into openwrt master.
> > I'm not sure what you mean by this. Are you saying we can still push
> > the firmware binaries 'somewhere' on https://git.openwrt.org but not
> > include the build process?
> I do not know if such a link would be a distribution as a standalone
> I would prefer if the user has to get the firmware files from somewhere
> else if we wants to use this feature as long as Marvell is not willing
> to change the license.
> >>> +Any use of the software, in all or in
> >>> +part, shall not be made subject to or otherwise contaminated by, a copyleft open
> >>> +source license (as defined by the Open Source Initiative), such as without
> >>> +limitation, GNU GPL or LGPL licenses.
> >> Adding this file in CONFIG_EXTRA_FIRMWARE could be seen as bundeling it
> >> with GPL code.
> >> The CONFIG_EXTRA_FIRMWARE option says this:
> >> WARNING: If you include additional firmware files into your binary
> >> kernel image that are not available under the terms of the GPL,
> >> then it may be a violation of the GPL to distribute the resulting
> >> image since it combines both GPL and non-GPL work. You should
> >> consult a lawyer of your own before distributing such an image.
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/firmware_loader/Kconfig#n32
> >>> +Any software which integrates this code or any part of it thereof, should
> >>> +include in its header the above license.
> >> We would have to extend the license information for all our octeontx
> >> binaries to add this information.
> > I can replace this with a patch that enables the cpt driver as a
> > module to make it easier for people to use but they will have to go
> > get firmware and place it in their /lib/firmware on their rootfs this
> > way.
> >> If this firmware contains cryptography we could also violate some export
> >> control regulation, but normally no one cares.
> > agreed.
> Having this as a module and the user has to download the firmware on his
> own would be nice. If you add a script to make it easier to download it
> would be nice, but not necessary in my opineon.
> If the system still works without this firmware I am also find with
> building this into the kernel if this would be needed.
The system works without the firmware in the kernel, just does not
provide crypto offload.
So the firmware does not have to be GPL in order for me to provide a
recipe upstream in OpenWrt to package it right as long as the recipe
has 'somewhere' to obtain it from which is not an openwrt site? I see
this is done with package/firmware/cypress-firmware/Makefile for
example which downloads a zip file from a cypress site which does not
require a EULA for firmware that has a clear license which is not GPL.
Honestly, I'm not even clear what crypto firmware bings to the table
these days, with a processor like the OcteonTX software crypto greatly
outperforms hardware crypto so the only thing it brings to the table
is the ability to offload crypto from the CPU if you need the CPU
cycles and are ok with lower-latency crypto.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel