Jeff Johnson <quic_jjohnson@xxxxxxxxxxx> writes:
> On 8/12/2022 9:09 AM, Kalle Valo wrote:
>> From: Kalle Valo <quic_kvalo@xxxxxxxxxxx>
>>
>> (Patches split into one patch per file for easier review, but the final
>> commit will be one big patch. See the cover letter for more info.)
>>
>> Signed-off-by: Kalle Valo <quic_kvalo@xxxxxxxxxxx>
>> ---
>> drivers/net/wireless/ath/ath12k/qmi.h | 610 ++++++++++++++++++++++++++++++++++
> [...]
>> +struct qmi_wlanfw_ce_tgt_pipe_cfg_s_v01 {
>> + __le32 pipe_num;
>> + __le32 pipe_dir;
>> + __le32 nentries;
>> + __le32 nbytes_max;
>> + __le32 flags;
>> +};
>> +
>> +struct qmi_wlanfw_ce_svc_pipe_cfg_s_v01 {
>> + __le32 service_id;
>> + __le32 pipe_dir;
>> + __le32 pipe_num;
>> +};
>
> curious why the above two structs use __le32 definitions but none of
> the others do. I thought the QMI interface would use the qmi_elem_info
> to properly encode/decode in host order on both sides of the pipe and
> hence we should expect host order on both sides
That is a good question, I was also expecting QMI to be in host order.
In ce.h I see this:
/* Establish a mapping between a service/direction and a pipe.
* Configuration information for a Copy Engine pipe and services.
* Passed from Host to Target through QMI message and must be in
* little endian format.
*/
struct service_to_pipe {
__le32 service_id;
__le32 pipedir;
__le32 pipenum;
};
But I'm not convinced about that comments. Thoughts?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
