Re: [PATCH] soc: qcom: smem: support Glymur DRAM info

[Gopikrishna Garmidi]

On 8/20/2026 10:00 PM, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>
> Glymur firmware provides a version 7 DDR-info SMEM entry whose 872-byte
> layout is different from the one the driver supports today.
>
> The data contains 16 channel descriptors, 14 DDR frequency slots, four
> 4 DDR region slots, a 10-entry SHUB frequency plan, and v6 misc information.
> It accounts for 616 bytes; the captured SMEM entry has a further 256
> zero bytes.
>
> Add a Glymur-specific version 7 layout and recognize that complete entry.
> Parse the DDR frequencies and highest-bank bit from the common fields.
>
> Assisted-by: LLM
> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> ---

Hi Konrad,

I tested this on the Glymur CRD.

The new v7 layout is parsed correctly: the "unknown type of DRAM info
struct (size = 872)" error is gone, and hbb reports 16.

The frequency list is almost correct, but the highest entry is truncated:

    # cat /sys/kernel/debug/qcom_smem/dram_frequencies
    200000000
    547200000
    1353600000
    1555200000
    1708800000
    2092800000
    2736000000
    3187200000
    3686400000
    4224000000
    466632704

The last value should be 4761600000. This is caused by a 32-bit overflow
in the frequency calculation:

    dram->frequencies[dram->num_frequencies++] = 1000 * freq_khz;

Since freq_khz is a u32, the multiplication is performed as a 32-bit
operation before being assigned to the u64 array. Using 1000UL instead
fixes the overflow:

    dram->frequencies[dram->num_frequencies++] = 1000UL * freq_khz;

The same issue exists in the v3, v4, v5, and v7 parsing functions. It
was not exposed previously because their maximum frequencies were below
the 32-bit limit.
With this change, the last frequency is reported correctly as
4761600000.

I can send the overflow fix as a separate patch, or you can fold it in 
—whichever you prefer.

Tested-by: Gopikrishna Garmidi <gopikrishna.garmidi@xxxxxxxxxxxxxxxx>

Thanks,
Gopikrishna