Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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