[PATCH v6 02/10] mei: late_bind: add late binding component driver
Greg KH
gregkh at linuxfoundation.org
Fri Jul 4 10:34:00 UTC 2025
On Fri, Jul 04, 2025 at 03:59:40PM +0530, Nilawar, Badal wrote:
>
> On 04-07-2025 10:44, Greg KH wrote:
> > On Fri, Jul 04, 2025 at 01:00:58AM +0530, Badal Nilawar wrote:
> > > From: Alexander Usyskin <alexander.usyskin at intel.com>
> > >
> > > Add late binding component driver.
> > > It allows pushing the late binding configuration from, for example,
> > > the Xe graphics driver to the Intel discrete graphics card's CSE device.
> > >
> > > Signed-off-by: Alexander Usyskin <alexander.usyskin at intel.com>
> > > Signed-off-by: Badal Nilawar <badal.nilawar at intel.com>
> > > Reviewed-by: Anshuman Gupta <anshuman.gupta at intel.com>
> > > ---
> > > drivers/misc/mei/Kconfig | 1 +
> > > drivers/misc/mei/Makefile | 1 +
> > > drivers/misc/mei/late_bind/Kconfig | 13 +
> > > drivers/misc/mei/late_bind/Makefile | 9 +
> > > drivers/misc/mei/late_bind/mei_late_bind.c | 272 ++++++++++++++++++++
> > Why do you have a whole subdir for a single .c file? What's wrong with
> > just keepign it in drivers/misc/mei/ ?
>
> There is separate subdir for each component used by i915/xe, so one was
> created for late_bind as well. Should we still drop late_bind subdir?
>
> cd drivers/misc/mei/
> gsc_proxy/ hdcp/ late_bind/ pxp/
For "modules" that are just a single file, yeah, that's silly, don't do
that.
> > > +/**
> > > + * 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? Set to what?
>
> Reserved by firmware for future use, default value set to 0, I will update
> above doc.
>
> >
> > > + * @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;
> > > + u32 reserved[2];
> > > + u32 payload_size;
> > As these cross the kernel boundry, they should be the correct type
> > (__u32), but really, please define the endiness of them (__le32) and use
> > the proper macros for that.
> If we go with __le32 then while populating elements of structure
> csc_heci_late_bind_req I will be using cpu_to_le32().
>
> When mapping the response buffer from the firmware with struct
> csc_heci_late_bind_rsp, there's no need to use le32_to_cpu() since the
> response will already be in little-endian format.
How do you know? Where is that defined? Where did the conversion
happen?
> Are you fine with this?
Please be explicit.
> > > + ret = (int)rsp.status;
> > > +end:
> > > + mei_cldev_disable(cldev);
> > > + kfree(req);
> > > + return ret;
> > > +}
> > > +
> > > +static const struct late_bind_component_ops mei_late_bind_ops = {
> > > + .owner = THIS_MODULE,
> > I thought you were going to drop the .owner stuff?
> >
> > Or if not, please implement it properly (i.e. by NOT forcing people to
> > manually set it here.)
>
> Somehow I missed this. I will drop it.
And from the structure definition please.
thanks,
greg k-h
More information about the dri-devel
mailing list