Re: [Intel-wired-lan] [PATCH iwl-next] virtchnl: fix m68k build.

[Przemek Kitszel <przemyslaw.kitszel@intel.com>]

On 10/17/24 08:39, Paolo Abeni wrote:
> On 10/17/24 00:49, Jacob Keller wrote:
>> On 10/15/2024 6:56 AM, Paolo Abeni wrote:
>>> The kernel test robot reported a build failure on m68k in the intel
>>> driver due to the recent shapers-related changes.
>>>
>>> The mentioned arch has funny alignment properties, let's be explicit
>>> about the binary layout expectation introducing a padding field.
>>>
>>> Fixes: 608a5c05c39b ("virtchnl: support queue rate limit and quanta 
>>> size configuration")
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Closes: https://lore.kernel.org/oe-kbuild-all/202410131710.71Wt6LKO- 
>>> lkp@intel.com/
>>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>>> ---
>>>   include/linux/avf/virtchnl.h | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/linux/avf/virtchnl.h b/include/linux/avf/virtchnl.h
>>> index 223e433c39fe..13a11f3c09b8 100644
>>> --- a/include/linux/avf/virtchnl.h
>>> +++ b/include/linux/avf/virtchnl.h
>>> @@ -1499,6 +1499,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(8, 
>>> virtchnl_queue_chunk);
>>>   struct virtchnl_quanta_cfg {
>>>       u16 quanta_size;
>>> +    u16 pad;
>>>       struct virtchnl_queue_chunk queue_select;
>>
>> There's a hidden 2 byte padding because queue_select requires 4-byte
>> alignment. We assume this, as the VIRTCHNL_CHECK_STRUCT_LEN for this
>> structure is 12 bytes.
>>
>> On mk68k, we must not be adding this padding, which results in a 10 byte
>> structure, failing the size check for VIRTCHNL_CHECK_STRUCT_LEN,
>> resulting in the compilation error?
> 
> Exactly!
> 
>> Adding the explicit size aligns with the actual expected layout and size
>> for this structure, fixing mk68k without affecting the other 
>> architectures.
>>
>> Ok.
>>
>> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> 
> Thanks,
> 
> Please LMK if you prefer/agree to have this one applied directly on net- 
> next, to reduce build issues spawning around ASAP.
> 
> Paolo
> 

Would be convenient, no objections!