Re: [PATCH v4 02/10] mei: late_bind: add late binding component driver

["Nilawar, Badal" <badal.nilawar@intel.com>]

On 01-07-2025 18:04, Nilawar, Badal wrote:
>
> On 01-07-2025 15:15, Greg KH wrote:
>> On Tue, Jul 01, 2025 at 02:02:15PM +0530, Nilawar, Badal wrote:
>>> On 28-06-2025 17:48, Greg KH wrote:
>>>>> + * @payload_size: size of the payload data in bytes
>>>>> + * @payload: data to be sent to the firmware
>>>>> + */
>>>>> +struct csc_heci_late_bind_req {
>>>>> +    struct mkhi_msg_hdr header;
>>>>> +    u32 type;
>>>>> +    u32 flags;
>>>> What is the endian of these fields?  And as this crosses the
>>>> kernel/hardware boundry, shouldn't these be __u32?
>>> endian of these fields is little endian, all the headers are little 
>>> endian.
>>> I will add comment at top.
>> No, use the proper types if this is little endian.  Don't rely on a
>> comment to catch things when it goes wrong.
>>
>>> On __u32 I doubt we need to do it as csc send copy it to internal 
>>> buffer.
>> If this crosses the kernel boundry, it needs to use the proper type.
>
> Understood. I will proceed with using __le32 in this context, provided 
> that Sasha agrees.

I believe __le{32, 16} is used only when the byte order is fixed and 
matches the host system's native endianness. Since the CSC controller is 
little-endian, is it necessary to specify the endianness here?
If it is mandatory to use the __le{32, 16} endian type, then is there 
need to convert endianness using cpu_to_le and le_to_cpu?

>
>>
>>>>> +{
>>>>> +    struct mei_cl_device *cldev;
>>>>> +    struct csc_heci_late_bind_req *req = NULL;
>>>>> +    struct csc_heci_late_bind_rsp rsp;
>>>>> +    size_t req_size;
>>>>> +    ssize_t ret;
>>>>> +
>>>>> +    if (!dev || !payload || !payload_size)
>>>>> +        return -EINVAL;
>>>> How can any of these ever happen as you control the callers of this
>>>> function?
>>> I will add WARN here.
>> So you will end up crashing the machine and getting a CVE assigned for
>> it?
>>
>> Please no.  If it can't happen, then don't check for it.  If it can
>> happen, great, handle it properly.  Don't just give up and cause a
>> system to reboot, that's a horrible way to write kernel code.
>
> Fine, will drop the idea of WARN here.
>
> Thanks,
> Badal
>
>>
>> thanks,
>>
>> greg k-h