mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	"Usyskin, Alexander" <alexander.usyskin@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<anshuman.gupta@intel.com>, <rodrigo.vivi@intel.com>,
	<alexander.usyskin@intel.com>, <daniele.ceraolospurio@intel.com>
Subject: Re: [PATCH v4 02/10] mei: late_bind: add late binding component driver
Date: Tue, 1 Jul 2025 14:02:15 +0530	[thread overview]
Message-ID: <205cc43a-4254-4d27-9b4f-139006e871e4@intel.com> (raw)
In-Reply-To: <2025062834-scraggly-barracuda-7ea6@gregkh>


On 28-06-2025 17:48, Greg KH wrote:
> On Wed, Jun 25, 2025 at 10:30:07PM +0530, Badal Nilawar wrote:
>> --- /dev/null
>> +++ b/drivers/misc/mei/late_bind/mei_late_bind.c
>> @@ -0,0 +1,281 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2025 Intel Corporation
>> + */
>> +#include <drm/intel/i915_component.h>
>> +#include <drm/intel/late_bind_mei_interface.h>
>> +#include <linux/component.h>
>> +#include <linux/pci.h>
>> +#include <linux/mei_cl_bus.h>
>> +#include <linux/module.h>
>> +#include <linux/overflow.h>
>> +#include <linux/slab.h>
>> +#include <linux/uuid.h>
>> +
>> +#include "mkhi.h"
>> +
>> +#define GFX_SRV_MKHI_LATE_BINDING_CMD 0x12
>> +#define GFX_SRV_MKHI_LATE_BINDING_RSP (GFX_SRV_MKHI_LATE_BINDING_CMD | 0x80)
>> +
>> +#define LATE_BIND_SEND_TIMEOUT_MSEC 3000
>> +#define LATE_BIND_RECV_TIMEOUT_MSEC 3000
>> +
>> +/**
>> + * struct csc_heci_late_bind_req - late binding request
>> + * @header: @ref mkhi_msg_hdr
>> + * @type: type of the late binding payload
>> + * @flags: flags to be passed to the firmware
>> + * @reserved: reserved field
> Reserved for what?  All reserved fields need to be set to a default
> value, please document that here.
Reserved by CSC firmware probably for future use.  default value should 
be 0.
>
>> + * @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.
On __u32 I doubt we need to do it as csc send copy it to internal buffer.

Sasha can help to answer.

>
>> +/**
>> + * struct csc_heci_late_bind_rsp - late binding response
>> + * @header: @ref mkhi_msg_hdr
>> + * @type: type of the late binding payload
>> + * @reserved: reserved field
>> + * @status: status of the late binding command execution by firmware
>> + */
>> +struct csc_heci_late_bind_rsp {
>> +	struct mkhi_msg_hdr header;
>> +	u32 type;
>> +	u32 reserved[2];
>> +	u32 status;
> Same questions as above.
>
>> +} __packed;
>> +/**
>> + * mei_late_bind_push_config - Sends a config to the firmware.
>> + * @dev: device struct corresponding to the mei device
>> + * @type: payload type
> Shouldn't type be an enum?
Sure will make enum.
>
>> + * @flags: payload flags
>> + * @payload: payload buffer
>> + * @payload_size: payload buffer size
>> + *
>> + * Return: 0 success, negative errno value on transport failure,
>> + *         positive status returned by FW
>> + */
>> +static int mei_late_bind_push_config(struct device *dev, u32 type, u32 flags,
>> +				     const void *payload, size_t payload_size)
> Why do static functions need kerneldoc formatting?
Sasha can help to answer this.
>
>> +{
>> +	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.
>
>
>> +
>> +	cldev = to_mei_cl_device(dev);
>> +
>> +	ret = mei_cldev_enable(cldev);
>> +	if (ret < 0) {
> You mean:
> 	if (ret)
> right?
yes
>
>
>> +		dev_dbg(dev, "mei_cldev_enable failed. %zd\n", ret);
> Why display the error again if this failed?  The caller already did
> that.
>
> And the function returns an int, not a ssize_t, didn't the compiler
> complain

It didn't. This is for debug from mei side, this can be removed or will 
fix format specifier.

Thanks,
Badal

>
> thanks,
>
> greg k-h

  reply	other threads:[~2025-07-01  8:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25 17:00 [PATCH v4 00/10] Introducing firmware late binding Badal Nilawar
2025-06-25 17:00 ` [PATCH v4 01/10] mei: bus: add mei_cldev_mtu interface Badal Nilawar
2025-06-25 17:00 ` [PATCH v4 02/10] mei: late_bind: add late binding component driver Badal Nilawar
2025-06-26  3:50   ` Gupta, Anshuman
2025-06-27 14:06     ` Nilawar, Badal
2025-06-28 12:18   ` Greg KH
2025-07-01  8:32     ` Nilawar, Badal [this message]
2025-07-01  9:45       ` Greg KH
2025-07-01 12:34         ` Nilawar, Badal
2025-07-01 16:41           ` Nilawar, Badal
2025-07-01 17:34             ` Rodrigo Vivi
2025-07-02  4:12               ` Gupta, Anshuman
2025-07-02  6:24               ` Usyskin, Alexander
2025-07-01 10:05     ` Usyskin, Alexander
2025-06-28 12:19   ` Greg KH
2025-07-01  8:07     ` Nilawar, Badal
2025-07-01  8:17       ` Greg KH
2025-07-01  8:22         ` Nilawar, Badal
2025-07-01  8:32           ` Usyskin, Alexander
2025-06-25 17:00 ` [PATCH v4 03/10] drm/xe/xe_late_bind_fw: Introducing xe_late_bind_fw Badal Nilawar
2025-06-27 21:04   ` Rodrigo Vivi
2025-06-30 13:49     ` Nilawar, Badal
2025-06-25 17:00 ` [PATCH v4 04/10] drm/xe/xe_late_bind_fw: Initialize late binding firmware Badal Nilawar
2025-06-26 21:06   ` Daniele Ceraolo Spurio
2025-06-27 12:48     ` Nilawar, Badal
2025-06-25 17:00 ` [PATCH v4 05/10] drm/xe/xe_late_bind_fw: Load " Badal Nilawar
2025-06-26 17:24   ` Rodrigo Vivi
2025-06-26 21:27     ` Daniele Ceraolo Spurio
2025-06-26 21:49       ` Rodrigo Vivi
2025-06-26 22:38         ` Daniele Ceraolo Spurio
2025-06-26 22:49           ` Rodrigo Vivi
2025-06-25 17:00 ` [PATCH v4 06/10] drm/xe/xe_late_bind_fw: Reload late binding fw in rpm resume Badal Nilawar
2025-06-25 17:00 ` [PATCH v4 07/10] drm/xe/xe_late_bind_fw: Reload late binding fw during system resume Badal Nilawar
2025-06-27  7:53   ` Nilawar, Badal
2025-06-25 17:00 ` [PATCH v4 08/10] drm/xe/xe_late_bind_fw: Introduce debug fs node to disable late binding Badal Nilawar
2025-06-25 17:00 ` [PATCH v4 09/10] drm/xe/xe_late_bind_fw: Extract and print version info Badal Nilawar
2025-06-26 21:32   ` Daniele Ceraolo Spurio
2025-06-25 17:00 ` [PATCH v4 10/10] drm/xe/xe_late_bind_fw: Select INTEL_MEI_LATE_BIND for CI Badal Nilawar

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=205cc43a-4254-4d27-9b4f-139006e871e4@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

all inboxes | Powered by JetHome®