dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Usyskin, Alexander" <alexander.usyskin@intel.com>
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>,
	"Nilawar, Badal" <badal.nilawar@intel.com>
Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
Date: Wed, 16 Jul 2025 16:45:33 +0200	[thread overview]
Message-ID: <2025071619-sterile-skiing-e64b@gregkh> (raw)
In-Reply-To: <CY5PR11MB636646E936C800D689BFBEEBED56A@CY5PR11MB6366.namprd11.prod.outlook.com>

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.

thanks,

greg k-h

  reply	other threads:[~2025-07-16 14:45 UTC|newest]

Thread overview: 22+ 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 [this message]
2025-07-27 14:46             ` Usyskin, Alexander
2025-08-13  9:51               ` Nilawar, Badal
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-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=2025071619-sterile-skiing-e64b@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=alexander.usyskin@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.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;
as well as URLs for NNTP newsgroup(s).