From: Greg KH <gregkh@linuxfoundation.org>
To: Badal Nilawar <badal.nilawar@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 v7 2/9] mei: late_bind: add late binding component driver
Date: Tue, 8 Jul 2025 08:48:20 +0200 [thread overview]
Message-ID: <2025070810-clinic-decode-57e6@gregkh> (raw)
In-Reply-To: <20250707191237.1782824-3-badal.nilawar@intel.com>
On Tue, Jul 08, 2025 at 12:42:30AM +0530, Badal Nilawar wrote:
> From: Alexander Usyskin <alexander.usyskin@intel.com>
>
> Add late binding component driver.
That says what this does, but not why, or even what "late binding"
means.
> 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@intel.com>
> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
> ---
> drivers/misc/mei/Kconfig | 11 +
> drivers/misc/mei/Makefile | 1 +
> drivers/misc/mei/mei_late_bind.c | 271 ++++++++++++++++++++
> include/drm/intel/i915_component.h | 1 +
> include/drm/intel/late_bind_mei_interface.h | 62 +++++
> 5 files changed, 346 insertions(+)
> create mode 100644 drivers/misc/mei/mei_late_bind.c
> create mode 100644 include/drm/intel/late_bind_mei_interface.h
>
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
> index 7575fee96cc6..36569604038c 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -81,6 +81,17 @@ config INTEL_MEI_VSC
> This driver can also be built as a module. If so, the module
> will be called mei-vsc.
>
> +config INTEL_MEI_LATE_BIND
> + tristate "Intel late binding support on ME Interface"
> + depends on INTEL_MEI_ME
> + depends on DRM_XE
> + help
> + MEI Support for Late Binding for Intel graphics card.
> +
> + Enables the ME FW interfaces for Late Binding feature,
> + allowing loading of firmware for the devices like Fan
> + Controller by Intel Xe driver.
Where is "Late Binding feature" documented so we know what that is? Why
wouldn't it just always be enabled and why must it be a config option?
> --- /dev/null
> +++ b/include/drm/intel/late_bind_mei_interface.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright (c) 2025 Intel Corporation
> + */
> +
> +#ifndef _LATE_BIND_MEI_INTERFACE_H_
> +#define _LATE_BIND_MEI_INTERFACE_H_
> +
> +#include <linux/types.h>
> +
> +struct device;
> +struct module;
Not needed.
> +
> +/**
> + * Late Binding flags
> + * Persistent across warm reset
persistent where?
> + */
> +#define CSC_LATE_BINDING_FLAGS_IS_PERSISTENT BIT(0)
> +
> +/**
> + * xe_late_bind_fw_type - enum to determine late binding fw type
> + */
> +enum late_bind_type {
> + CSC_LATE_BINDING_TYPE_FAN_CONTROL = 1,
> +};
shouldn't you have mei_ as a prefix for the enum type and the values?
> +
> +/**
> + * Late Binding payload status
> + */
> +enum csc_late_binding_status {
Same here, what is "CSC"?
> + CSC_LATE_BINDING_STATUS_SUCCESS = 0,
> + CSC_LATE_BINDING_STATUS_4ID_MISMATCH = 1,
> + CSC_LATE_BINDING_STATUS_ARB_FAILURE = 2,
> + CSC_LATE_BINDING_STATUS_GENERAL_ERROR = 3,
> + CSC_LATE_BINDING_STATUS_INVALID_PARAMS = 4,
> + CSC_LATE_BINDING_STATUS_INVALID_SIGNATURE = 5,
> + CSC_LATE_BINDING_STATUS_INVALID_PAYLOAD = 6,
> + CSC_LATE_BINDING_STATUS_TIMEOUT = 7,
> +};
This enum type is never used.
> +
> +/**
> + * struct late_bind_component_ops - ops for Late Binding services.
> + * @owner: Module providing the ops
> + * @push_config: Sends a config to FW.
> + */
> +struct late_bind_component_ops {
> + /**
> + * @push_config: Sends a config to FW.
What is "FW"?
> + * @dev: device struct corresponding to the mei device
Why not pass in the mei device structure, not a 'struct device' so that
we know this is correct?
> + * @type: payload type
> + * @flags: payload flags
> + * @payload: payload buffer
Where are these defined? Why are they not enums?
> + * @payload_size: payload buffer size
Size in what?
> + *
> + * Return: 0 success, negative errno value on transport failure,
> + * positive status returned by FW
> + */
> + int (*push_config)(struct device *dev, u32 type, u32 flags,
> + const void *payload, size_t payload_size);
> +};
> +
> +#endif /* _LATE_BIND_MEI_INTERFACE_H_ */
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-07-08 6:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 19:12 [PATCH v7 0/9] Introducing firmware late binding Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 1/9] mei: bus: add mei_cldev_mtu interface Badal Nilawar
2025-07-08 6:44 ` Greg KH
2025-07-07 19:12 ` [PATCH v7 2/9] mei: late_bind: add late binding component driver Badal Nilawar
2025-07-08 6:48 ` Greg KH [this message]
2025-07-08 7:49 ` Gupta, Anshuman
2025-07-09 14:51 ` Usyskin, Alexander
2025-07-07 19:12 ` [PATCH v7 3/9] drm/xe/xe_late_bind_fw: Introducing xe_late_bind_fw Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 4/9] drm/xe/xe_late_bind_fw: Initialize late binding firmware Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 5/9] drm/xe/xe_late_bind_fw: Load " Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 6/9] drm/xe/xe_late_bind_fw: Reload late binding fw in rpm resume Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 7/9] drm/xe/xe_late_bind_fw: Reload late binding fw during system resume Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 8/9] drm/xe/xe_late_bind_fw: Introduce debug fs node to disable late binding Badal Nilawar
2025-07-07 19:12 ` [PATCH v7 9/9] drm/xe/xe_late_bind_fw: Extract and print version info Badal Nilawar
2025-07-07 19:40 ` ✗ CI.checkpatch: warning for Introducing firmware late binding Patchwork
2025-07-07 19:42 ` ✓ CI.KUnit: success " Patchwork
2025-07-07 19:56 ` ✗ CI.checksparse: warning " Patchwork
2025-07-07 20:48 ` ✓ Xe.CI.BAT: success " Patchwork
2025-07-08 0:11 ` ✗ Xe.CI.Full: failure " Patchwork
2025-07-08 6:49 ` [PATCH v7 0/9] " Greg KH
2025-07-08 10:57 ` Gupta, Anshuman
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=2025070810-clinic-decode-57e6@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.