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

[Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>]

On 8/20/2026 10:00 PM, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> 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@oss.qualcomm.com>
> ---

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@oss.qualcomm.com>

Thanks,
Gopikrishna