Open lumag opened 9 months ago
I understand that this is an example of a certain vendor breaking all possible standards. This is mostly an RFC to trigger the discussion on how we can cope with this particular case.
Why is it important to you that this property not cause a warning? Just curious.
@robherring It's not the absense of a warning that is important to me. After getting this property documented I'd like to submit patches against soc/qcom
and drm/msm
that actually read and make use of that property for the purpose of setting up device correctly.
I propose we look at the thing that provides the data in this property instead.
I propose we look at the thing that provides the data in this property instead.
@konradybcio do you mean the bootloader? I do not expect that we can change ABL on end-user secured devices.
@lumag No, rather the place where that information comes from. I have something that resembles a PoC, but it's low prio for now.
The Qualcomm ABL bootloaders use the
ddr_device_type
property to describe the attached memory type. We can not really change this bootloader on the end-user devices thanks to the SecureBoot. Certain drivers (display, GPU, video-encoding) need this information to properly program the hardware. This PR attempts to document this property, while pointing out that its usage is limited to this particular bootloader, it should not be used by any other created designs and that its usage outside of the defined usecase is strictly forbidden.