On 8/14/2025 9:20 AM, Konrad Dybcio wrote: > On 8/14/25 1:19 AM, Amirreza Zarrabi wrote: >> >> >> On 8/14/2025 8:49 AM, Konrad Dybcio wrote: >>> On 8/14/25 12:24 AM, Amirreza Zarrabi wrote: >>>> >>>> >>>> On 8/13/2025 8:00 PM, Konrad Dybcio wrote: >>>>> On 8/13/25 2:35 AM, Amirreza Zarrabi wrote: >>>>>> Enable userspace to allocate shared memory with QTEE. Since >>>>>> QTEE handles shared memory as object, a wrapper is implemented >>>>>> to represent tee_shm as an object. The shared memory identifier, >>>>>> obtained through TEE_IOC_SHM_ALLOC, is transferred to the driver using >>>>>> TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT/OUTPUT. >>>>>> >>>>>> Tested-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx> >>>>>> Acked-by: Sumit Garg <sumit.garg@xxxxxxxxxxxxxxxx> >>>>>> Tested-by: Harshal Dev <quic_hdev@xxxxxxxxxxx> >>>>>> Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@xxxxxxxxxxxxxxxx> >>>>>> --- >>>>> >>>>> [...] >>>>> >>>>>> +/* Mapping information format as expected by QTEE. */ >>>>>> +struct qcomtee_mapping_info { >>>>>> + u64 paddr; >>>>>> + u64 len; >>>>>> + u32 perms; >>>>>> +} __packed; >>>>> >>>>> Please use types with explicit endianness, e.g. __le32. I'm assuming >>>>> TZ will always be little-endian, regardless of the host OS >>>>> >>>> >>>> I'm not entirely sure how this point is relevant. As I understand it, >>>> the core that populates this struct is the same one that accesses it in TZ. >>>> Your argument would absolutely make sense if the host and TZ were operating >>>> on different cores with distinct architectures -- such as one being >>>> little-endian and the other big-endian, which is not the case. >>> >>> CONFIG_CPU_BIG_ENDIAN=y exists on arm64 >>> >> >> Or, you are saying we may have a configuration where host is big-endian >> but TZ is little-endian? > > I was indeed about to say that.. I believe our tz is always little-endian > but you can run the HLOS of either endianness > Okay, I’ve thought about this point and also discussed it internally. I can add an entry to Kconfig to ensure the driver is unavailable when CONFIG_CPU_BIG_ENDIAN is selected -- for now. However, without a clear usecase, adding all the le32_to_cpu/cpu_to_le32 conversions just makes the driver messy. Regards, Amir > Konrad