From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: "Usyskin, Alexander" <alexander.usyskin@intel.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
"Gupta, Anshuman" <anshuman.gupta@intel.com>
Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
Date: Wed, 13 Aug 2025 15:21:09 +0530 [thread overview]
Message-ID: <7aa74159-a9a8-4ca7-9635-a806c57bf7f4@intel.com> (raw)
In-Reply-To: <CY5PR11MB6366AF03A73910CED71C7E37ED5BA@CY5PR11MB6366.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4250 bytes --]
Hi Greg,
On 27-07-2025 20:16, Usyskin, Alexander wrote:
>> Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
>>
>> On Wed, Jul 16, 2025 at 02:26:26PM +0000, Usyskin, Alexander wrote:
>>>>>>> + if (bytes < sizeof(rsp)) {
>>>>>>> + dev_err(dev, "bad response from the firmware: size
>> %zd <
>>>>>> %zu\n",
>>>>>>> + bytes, sizeof(rsp));
>>>>>>> + ret = -EPROTO;
>>>>>>> + goto end;
>>>>>>> + }
>>>>>> Why not check this above when you check against the size of the
>> header?
>>>>>> You only need one size check, not 2.
>>>>> Firmware may return only header with result field set without the data.
>>>> Then the firmware is broken :)
>>>>
>>>>> We are parsing the header first and then starting to parse data.
>>>>> If we check for whole message size at the beginning we'll miss the result
>>>> data.
>>>>
>>>> You mean you will make it harder to debug the firmware, as you will not
>>>> be printing out the header information? Or something else? The
>>>> bytes variable HAS to match the full structure size, not just the header
>>>> size, according to this code. So just test for that and be done with
>>>> it!
>>> The CSME firmware returns only command header if, like, command is not
>> recognised.
>>> This may happen because of firmware bug or for firmware is
>> configured/compiled
>>> that way.
>>> This seems reasonable for the complex protocols where firmware may not be
>>> aware of this particular command at all and have no idea what the data size
>> it
>>> should send in reply.
>>> Printing result from the header will allow us to understand either this is the
>> firmware
>>> problem or driver sent something wrong.
>> Then make it obvious in your checking and in your error messages as to
>> what you are doing here. Checking the size of the buffer in two
>> different places, with different values is very odd, and deserves a lot
>> of explaination.
>>
> Is this addition
> /*
> * Received message size may be smaller than the full message size when
> * reply contains only MKHI header with result field set to the error code.
> * Check the header size and content first to output exact error, if needed,
> * and then process to the whole message.
> */
>
> and remodelling error messages like "received less then header size from the firmware"
> made it clean for people not involved with our firmware?
> I'm too deep in this to judge the wording.
I'm planning to include the following code in the next revision. Does
this change align with your recommendation?
+ /*
+ * Received message size may be smaller than the full
message size when
+ * reply contains only MKHI header with result field set to
the error code.
+ * Check the header size and content first to output exact
error, if needed,
+ * and then process to the whole message.
+ */
if (bytes < sizeof(rsp.header)) {
- dev_err(dev, "bad response header from the firmware:
size %zd < %zu\n",
+ dev_err(dev, "received less than header size from
the firmware: %zd < %zu\n",
bytes, sizeof(rsp.header));
ret = -EPROTO;
goto end;
}
if (mei_lb_check_response(dev, &rsp.header)) {
- dev_err(dev, "bad result response from the firmware:
0x%x\n",
+ dev_err(dev, "bad response from the firmware:
header: 0x%x\n",
*(uint32_t *)&rsp.header);
ret = -EPROTO;
goto end;
}
if (bytes < sizeof(rsp)) {
- dev_err(dev, "bad response from the firmware: size
%zd < %zu\n",
+ dev_err(dev, "received less than message size from
the firmware: %zd < %zu\n",
bytes, sizeof(rsp));
ret = -EPROTO;
goto end;
Thanks,
Badal
>
> - -
> Thanks,
> Sasha
>
>
[-- Attachment #2: Type: text/html, Size: 9573 bytes --]
next prev parent reply other threads:[~2025-08-13 9:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 15:08 [PATCH 0/9] Introducing firmware late binding Rodrigo Vivi
2025-07-10 15:08 ` [PATCH 1/9] mei: bus: add mei_cldev_mtu interface Rodrigo Vivi
2025-07-10 15:08 ` [PATCH 2/9] mei: late_bind: add late binding component driver Rodrigo Vivi
2025-07-16 11:48 ` Greg KH
2025-07-16 11:58 ` Usyskin, Alexander
2025-07-16 12:07 ` Greg KH
2025-07-16 14:26 ` Usyskin, Alexander
2025-07-16 14:45 ` Greg KH
2025-07-27 14:46 ` Usyskin, Alexander
2025-08-13 9:51 ` Nilawar, Badal [this message]
2025-08-13 12:13 ` Greg KH
2025-07-10 15:08 ` [PATCH 3/9] drm/xe/xe_late_bind_fw: Introducing xe_late_bind_fw Rodrigo Vivi
2025-07-25 21:38 ` Lucas De Marchi
2025-07-30 11:47 ` Nilawar, Badal
2025-07-10 15:08 ` [PATCH 4/9] drm/xe/xe_late_bind_fw: Initialize late binding firmware Rodrigo Vivi
2025-07-10 15:08 ` [PATCH 5/9] drm/xe/xe_late_bind_fw: Load " Rodrigo Vivi
2025-07-10 15:08 ` [PATCH 6/9] drm/xe/xe_late_bind_fw: Reload late binding fw in rpm resume Rodrigo Vivi
2025-07-10 15:08 ` [PATCH 7/9] drm/xe/xe_late_bind_fw: Reload late binding fw during system resume Rodrigo Vivi
2025-07-10 15:08 ` [PATCH 8/9] drm/xe/xe_late_bind_fw: Introduce debug fs node to disable late binding Rodrigo Vivi
2025-07-31 20:03 ` Summers, Stuart
2025-08-01 15:17 ` Rodrigo Vivi
2025-09-05 15:40 ` Nilawar, Badal
2025-07-10 15:08 ` [PATCH 9/9] drm/xe/xe_late_bind_fw: Extract and print version info Rodrigo Vivi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7aa74159-a9a8-4ca7-9635-a806c57bf7f4@intel.com \
--to=badal.nilawar@intel.com \
--cc=alexander.usyskin@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox