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

[Marek Vasut]

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.

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

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 ?