Re: [PATCH v1 06/12] drivers: soc: qcom: Add support for Qualcomm QDU device.

[Kishore Batta <kishore.batta@oss.qualcomm.com>]

On 3/7/2026 6:50 PM, Krzysztof Kozlowski wrote:
> On 07/03/2026 12:33, Kishore Batta wrote:
>> On 8/28/2025 7:49 PM, Krzysztof Kozlowski wrote:
>>> On 25/08/2025 12:19, Kishore Batta wrote:
>>>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>>>> index 99e490e3174e..8d036edf304a 100644
>>>> --- a/drivers/soc/qcom/Makefile
>>>> +++ b/drivers/soc/qcom/Makefile
>>>> @@ -41,3 +41,4 @@ obj-$(CONFIG_QCOM_INLINE_CRYPTO_ENGINE)	+= qcom_ice.o
>>>>    obj-$(CONFIG_QCOM_PBS) +=	qcom-pbs.o
>>>>    obj-$(CONFIG_QCOM_UBWC_CONFIG) += ubwc_config.o
>>>>    obj-$(CONFIG_QCOM_SAHARA_PROTOCOL) += sahara/
>>>> +obj-$(CONFIG_QCOM_QDU) += qdu.o
>>>> diff --git a/drivers/soc/qcom/qdu.c b/drivers/soc/qcom/qdu.c
>>>> new file mode 100644
>>>> index 000000000000..afd8011793fa
>>>> --- /dev/null
>>>> +++ b/drivers/soc/qcom/qdu.c
>>>> @@ -0,0 +1,85 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +/* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. */
>>>> +
>>>> +#include <linux/init.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/sahara_image_table_ops.h>
>>>> +
>>>> +static const char * const qdu100_image_table[] = {
>>>> +	[5] = "qcom/qdu100/uefi.elf",
>>>> +	[8] = "qcom/qdu100/qdsp6sw.mbn",
>>>> +	[16] = "qcom/qdu100/efs1.bin",
>>>> +	[17] = "qcom/qdu100/efs2.bin",
>>>> +	[20] = "qcom/qdu100/efs3.bin",
>>>> +	[23] = "qcom/qdu100/aop.mbn",
>>>> +	[25] = "qcom/qdu100/tz.mbn",
>>>> +	[29] = "qcom/qdu100/zeros_1sector.bin",
>>>> +	[33] = "qcom/qdu100/hypvm.mbn",
>>>> +	[34] = "qcom/qdu100/mdmddr.mbn",
>>>> +	[36] = "qcom/qdu100/multi_image_qti.mbn",
>>>> +	[37] = "qcom/qdu100/multi_image.mbn",
>>>> +	[38] = "qcom/qdu100/xbl_config.elf",
>>>> +	[39] = "qcom/qdu100/abl_userdebug.elf",
>>>> +	[40] = "qcom/qdu100/zeros_1sector.bin",
>>>> +	[41] = "qcom/qdu100/devcfg.mbn",
>>>> +	[42] = "qcom/qdu100/zeros_1sector.bin",
>>>> +	[43] = "qcom/qdu100/kernel_boot.elf",
>>> We should not accept this code because corresponding linux-firmware
>>> release was not properly authorized in Qualcomm. All of above might change.
>>>
>>> I can give more details in private.
>> Thanks for the comment. The QDu100 image table in v2 reflects the
>> firmware images required by the device for boot. The sahara driver
>> relies on request_firmware_nowarn() and does not make assumptions about
>> firmware distributions or availability.
> You did not answer to my comment at all. It does not matter what it
> reflects to. You violated GPL license and that's NAK here.
>
> And responding to this after half a year with irrelevant comment of
> whatever is clearly:
>
> NAK
>
>
> Best regards,
> Krzysztof

We understand the concern regarding GPL compliance and firmware 
redistribution. The kernel_boot.elf image required for this device is 
not authorized for inclusion in linux-firmware, and we agree that 
referencing a non-distributable firmware artifact directly from upstream 
kernel code is not appropriate. We also note that this kernel_boot.elf 
is no longer present in the linux-firmware repository.

 From a technical standpoint, the QDU100 device does not boot without 
kernel_boot.elf being provided by the platform. However, given the 
redistribution constraints, we are looking for guidance on the preferred 
upstream approach in this situation.

Would you recommend:

1. Dropping the explicit firmware reference from upstream and leaving 
firmware provisioning entirely to downstream/vendor kernels, or

2. An alternative pattern that upstream considers acceptable when 
boot-critical firmware cannot be redistributed ?