[PATCH 1/2] imx: container: Eliminate IMX_PQC_SUPPORT

[Ye Li]

On 11/28/2025 7:58 PM, Marek Vasut wrote:
> On 11/28/25 6:31 AM, Ye Li wrote:
>>
>>
>> On 11/28/2025 1:09 PM, Marek Vasut wrote:
>>> On 11/28/25 4:26 AM, Ye Li wrote:
>>>
>>> Hello everyone,
>>>
>>>>> +static inline int container_hdr_alignment(void)
>>>>> +{
>>>>> +    if (is_imx94())
>>>>> +        return 0x4000;    /* PQC */
>>>>> +
>>>>> +    if (is_imx95() && (soc_rev() >= CHIP_REV_2_0))
>>>>> +        return 0x4000;    /* PQC on i.MX95 B0 and newer */
>>>>> +
>>>>> +    return 0x400;    /* Non-PQC on i.MX95 A1 and older */
>>>>
>>>>
>>>> I understand you want to use single uboot and spl image for A0 and 
>>>> B0. But A0 is not production. Only early customers get few A0 
>>>> samples. NXP marketing has notified these customers to replace A0 to 
>>>> B0. Are you still using A0 board? Is it necessary to do such change 
>>>> as we want to remove A0 to simplify the codes?
>>>
>>> I have both A0 and B0 device.
>>>
>>> I do not see why we need to have a Kconfig option for something we 
>>> can trivially auto-detect, hence this patch.
>>
>> Yes, it can auto-detect. The history is we dropped A0 when upstreaming 
>> B0 support. But someone from community complained A0 broken and 
>> requested to add back A0. Using static Kconfig is easy for removing A0 
>> in future.
> 
> Adding another Kconfig symbol and ifdeffery seems easy, but it also had 
> additional implications -- more code paths because of the ifdeffery, 
> more Kconfig symbols which the user has to understand, and another 
> machine config has to be built in the CI to cover this configuration.
> 
> The auto-detection avoids all these problems.
> 
I agree to remove IMX95_A0, but I don't suggest removing 
IMX_PQC_SUPPORT. For each SOC, supporting PQC container or not is 
definite. Adding runtime detect is just for iMX95. But iMX95 A1 is EOL, 
everyone must use B0. And A1 codes should be removed.
You said you have A1 board, could you share the board name?

>>>> Eliminate IMX_PQC_SUPPORT config is not a good way. When adding new 
>>>> SOC, developer has to update the container_hdr_alignment, then it 
>>>> will be a long list in this function. Actually only iMX95 is the 
>>>> exception. If you insist keeping A0, I prefer change like below and 
>>>> retain IMX_PQC_SUPPORT.
>>>>
>>>> #if IS_ENABLED(CONFIG_IMX95)
>>>> static inline u32 container_hdr_alignment(void)
>>>> {
>>>>      if (is_imx95() && (soc_rev() >= CHIP_REV_2_0))
>>>>          return 0x4000;
>>>>      else
>>>>          return 0x400;
>>>> }
>>>> #else
>>>> static inline u32 container_hdr_alignment(void)
>>>> {
>>>> #if IS_ENABLED(CONFIG_IMX_PQC_SUPPORT)
>>>>      return 0x4000;
>>>> #else
>>>>      return 0x400;
>>>> #endif
>>>> }
>>>> #endif
>>> This adds even more ifdeffery and makes the code even worse, so no.
>>>
>>> But if you are sure that every new SoC will have the PQC alignment, 
>>> then the condition in this patch can be inverted this way:
>>>
>>> static inline int container_hdr_alignment(void)
>>> {
>>>      if (is_imx95() && (soc_rev() < CHIP_REV_2_0))
>>>          return 0x400;    /* PQC on i.MX95 A1 and older */
>>>
>>>      return 0x4000;    /* PQC is the default */
>>> }
>>>
>>> Are you sure every new SoC (at least in the foreseeable future) will 
>>> be like that ?
>> No, it can't be guaranteed. And we have legacy SOC like 
>> 8QM/8QXP/8ULP/93/91 using this container without PQC support, above 
>> new change will break them. Please consider keeping the 
>> IMX_PQC_SUPPORT, so every soc can select it to work.
> See above why adding more and more Kconfig options is not a good solution.
> 
> I believe the original implementation in this patch does not break the 
> legacy SoCs ?
Your original implementation does not break legacy SoCs. I mean the new 
change break them.

> 
> If you are concerned about growing list of SoCs in this function, then 
> this function can list the five legacy SoCs + imx95a0 SoC with non-PQC 
> alignment and by default return PQC alignment ?

I can't ensure no new SoC with legacy container. From roadmap, there is 
still some iMX93 derivations planned. This way is just better than 
original implementation in this patch.

Best regards,
Ye Li