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

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

On 3/8/2026 11:42 AM, Kishore Batta wrote:
>
> 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 ?
>

Following up on this thread.

Based on the feedback, I have reworked the patch to remove the 
kernel_boot.elf reference from the qdu100_image_table and validated that 
the device can still boot when the image is provisioned by the platform 
downstream.

Unless there are objections, we will proceed with this approach and post 
an updated revision(v3) reflecting these changes.