[OpenWrt-Devel][PATCH v2 2/2] octeontx: enable Cavium CPT and ZIP drivers

Tue Jun 30 16:27:43 EDT 2020

On 6/24/20 11:06 PM, Tim Harvey wrote:
> 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
>> product:
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob_plain;f=target/linux/lantiq/files/firmware/lantiq/xrx200_phy11g_a14.bin;hb=HEAD
>>
>> 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.
>>
> 
> Hauke
> 
> The system works without the firmware in the kernel, just does not
> provide crypto offload.

Ok this is good. Then we can activate the driver even when we do not
ship the FW.

> 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.

The FW does not have to be GPL or even open source, binary only is ok,
but when OpenWrt ships it we have to be allowed to ship the binary, we
need the binary only firmware under a license which allows
redistribution. I understood the license like it is only allowed to ship
it in a final product, the Marvell legal department probably did not
thought about shipping a software image without the hardware.

OpenWrt also inteagrtes and ships some of the firmware files found here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/
Only very few (less than 10) of these binaries are licensed under an
open source license, most of then are shipped binary only, but everyone
is allowed to redistribute them.

> 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.

For me it would be fine if you activate the driver driver even when you
do not integrate the firmware. Whoever wants to use the crypto offload
can then use the driver, but has to get the crypto offload firmware from
somewhere else. I would prefer to have the drivers as a module when
possible. You can also describe where to get the firmware in the commit
message which adds the driver or in some ReadMe or description.

Hauke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200630/97c51374/attachment-0001.sig>