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
