Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Kees Bakker <kees@ijzerbout.nl>, <intel-xe@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Cc: <anshuman.gupta@intel.com>, <rodrigo.vivi@intel.com>,
	<alexander.usyskin@intel.com>, <gregkh@linuxfoundation.org>,
	<daniele.ceraolospurio@intel.com>,
	<mika.westerberg@linux.intel.com>, <lucas.demarchi@intel.com>,
	<karthik.poosa@intel.com>
Subject: Re: [PATCH v9 9/9] drm/xe/xe_late_bind_fw: Extract and print version info
Date: Thu, 25 Sep 2025 17:39:27 +0530	[thread overview]
Message-ID: <d695d564-6c4d-431f-9b21-5ebf574e0c2d@intel.com> (raw)
In-Reply-To: <e6da8bc1-12d2-433e-ad20-095c291e03d4@ijzerbout.nl>


On 25-09-2025 02:14, Kees Bakker wrote:
> Op 05-09-2025 om 17:49 schreef Badal Nilawar:
>> Extract and print version info of the late binding binary.
>>
>> v2: Some refinements (Daniele)
>>
>> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> ---
>>   drivers/gpu/drm/xe/xe_late_bind_fw.c       | 124 +++++++++++++++++++++
>>   drivers/gpu/drm/xe/xe_late_bind_fw_types.h |   3 +
>>   drivers/gpu/drm/xe/xe_uc_fw_abi.h          |  66 +++++++++++
>>   3 files changed, 193 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_late_bind_fw.c 
>> b/drivers/gpu/drm/xe/xe_late_bind_fw.c
>> index 0f062008ca83..38f3feb2aecd 100644
>> --- a/drivers/gpu/drm/xe/xe_late_bind_fw.c
>> +++ b/drivers/gpu/drm/xe/xe_late_bind_fw.c
>> @@ -45,6 +45,121 @@ late_bind_to_xe(struct xe_late_bind *late_bind)
>>       return container_of(late_bind, struct xe_device, late_bind);
>>   }
>>   +static struct xe_device *
>> +late_bind_fw_to_xe(struct xe_late_bind_fw *lb_fw)
>> +{
>> +    return container_of(lb_fw, struct xe_device, 
>> late_bind.late_bind_fw[lb_fw->id]);
>> +}
>> +
>> +/* Refer to the "Late Bind based Firmware Layout" documentation 
>> entry for details */
>> +static int parse_cpd_header(struct xe_late_bind_fw *lb_fw,
>> +                const void *data, size_t size, const char 
>> *manifest_entry)
>> +{
>> +    struct xe_device *xe = late_bind_fw_to_xe(lb_fw);
>> +    const struct gsc_cpd_header_v2 *header = data;
>> +    const struct gsc_manifest_header *manifest;
>> +    const struct gsc_cpd_entry *entry;
>> +    size_t min_size = sizeof(*header);
>> +    u32 offset;
>> +    int i;
>> +
>> +    /* manifest_entry is mandatory */
>> +    xe_assert(xe, manifest_entry);
>> +
>> +    if (size < min_size || header->header_marker != 
>> GSC_CPD_HEADER_MARKER)
>> +        return -ENOENT;
>> +
>> +    if (header->header_length < sizeof(struct gsc_cpd_header_v2)) {
>> +        drm_err(&xe->drm, "%s late binding fw: Invalid CPD header 
>> length %u!\n",
>> +            fw_id_to_name[lb_fw->id], header->header_length);
>> +        return -EINVAL;
>> +    }
>> +
>> +    min_size = header->header_length + sizeof(struct gsc_cpd_entry) 
>> * header->num_of_entries;
>> +    if (size < min_size) {
>> +        drm_err(&xe->drm, "%s late binding fw: too small! %zu < %zu\n",
>> +            fw_id_to_name[lb_fw->id], size, min_size);
>> +        return -ENODATA;
>> +    }
>> +
>> +    /* Look for the manifest first */
>> +    entry = (void *)header + header->header_length;
>> +    for (i = 0; i < header->num_of_entries; i++, entry++)
>> +        if (strcmp(entry->name, manifest_entry) == 0)
>> +            offset = entry->offset & GSC_CPD_ENTRY_OFFSET_MASK;
>> +
>> +    if (!offset) {
> This for loop looks suspicious. Do you continue the loop on purpose
> after finding the first match? Or should there be a break?
> Also, if there is no match then offset is uninitialized. Isn't it better
> to initialize offset at the start?

Thanks for highlighting. This has been addressed in this patch 
https://lore.kernel.org/intel-xe/20250924102208.9216-1-colin.i.king@gmail.com/.

Regards,
Badal


  reply	other threads:[~2025-09-25 12:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-05 15:49 [PATCH v9 0/9] Introducing firmware late binding Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 1/9] mei: bus: add mei_cldev_mtu interface Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 2/9] mei: late_bind: add late binding component driver Badal Nilawar
2025-09-08 16:25   ` Lucas De Marchi
2025-09-09  4:50     ` Usyskin, Alexander
2025-09-09 14:43       ` Lucas De Marchi
2025-09-12  5:19         ` Lucas De Marchi
2025-09-18 15:41           ` Rodrigo Vivi
2025-09-18 16:27           ` gregkh
2025-09-05 15:49 ` [PATCH v9 3/9] drm/xe/xe_late_bind_fw: Introduce xe_late_bind_fw Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 4/9] drm/xe/xe_late_bind_fw: Initialize late binding firmware Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 5/9] drm/xe/xe_late_bind_fw: Load " Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 6/9] drm/xe/xe_late_bind_fw: Reload late binding fw in rpm resume Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 7/9] drm/xe/xe_late_bind_fw: Reload late binding fw during system resume Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 8/9] drm/xe/xe_late_bind_fw: Introduce debug fs node to disable late binding Badal Nilawar
2025-09-05 15:49 ` [PATCH v9 9/9] drm/xe/xe_late_bind_fw: Extract and print version info Badal Nilawar
2025-09-24 20:44   ` Kees Bakker
2025-09-25 12:09     ` Nilawar, Badal [this message]
2025-09-05 16:08 ` ✗ CI.checkpatch: warning for Introducing firmware late binding Patchwork
2025-09-05 16:09 ` ✓ CI.KUnit: success " Patchwork
2025-09-05 16:24 ` ✗ CI.checksparse: warning " Patchwork
2025-09-05 16:51 ` ✓ Xe.CI.BAT: success " Patchwork
2025-09-06  2:54 ` ✓ Xe.CI.Full: " Patchwork

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=d695d564-6c4d-431f-9b21-5ebf574e0c2d@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=karthik.poosa@intel.com \
    --cc=kees@ijzerbout.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --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