All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Stuart Summers" <stuart.summers@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters
Date: Thu, 20 Aug 2026 20:19:55 +0000	[thread overview]
Message-ID: <20260820201956.0A36F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820200719.84681-20-stuart.summers@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Global namespace pollution from generic attribute names
--

--- Patch [8]: [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters ---
commit c6663e692904c84b3875225b65be4210162f1f5e
Author: Stuart Summers <stuart.summers@intel.com>

drm/xe: Add infrastructure for debug configfs parameters

This commit introduces an X-macro pattern for defining debug configfs parameters
in the Xe driver. It automatically generates backing structs, configuration
attributes, and accessors from a single parameter list to simplify adding new
debug entries.

> diff --git a/drivers/gpu/drm/xe/xe_configfs_debug_params.c b/drivers/gpu/drm/xe/xe_configfs_debug_params.c
> new file mode 100644
> index 0000000000000..00e5ff175c0af
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_configfs_debug_params.c

[ ... ]

> +/*
> + * Define the configfs_attribute objects. These are non-static so they
> + * can be referenced from xe_configfs_debug.c.
> + */
> +#define _XE_PARAM_DEFINE_ATTR(_T, _name, _def, _val, _vis, _get, _fallback) \
> +struct configfs_attribute attr_##_name = {                              \

[Severity: Low]
Could this naming convention cause global symbol collisions? 

Since these objects are non-static (defined in the global namespace), naming 
them attr_##_name could lead to link-time multiple definition errors if another 
subsystem happens to export a variable with a generic name like attr_timeout or 
attr_enable.

Would it be safer to use a subsystem-specific prefix, such as 
xe_configfs_attr_##_name, to prevent namespace pollution?

> +	.ca_name	= __stringify(_name),                           \
> +	.ca_owner	= THIS_MODULE,                                  \
> +	.ca_mode	= 0644,                                         \
> +	.show		= _name##_show,                                 \
> +	.store		= _name##_store,                                \
> +};
> +
> +XE_CONFIGFS_DEBUG_PARAMS_FOR_EACH(_XE_PARAM_DEFINE_ATTR)

[ ... ]

> diff --git a/drivers/gpu/drm/xe/xe_configfs_debug_params.h b/drivers/gpu/drm/xe/xe_configfs_debug_params.h
> new file mode 100644
> index 0000000000000..954ca4343136d
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_configfs_debug_params.h

[ ... ]

> +/*
> + * Forward declarations of the per-parameter configfs_attribute objects.
> + *
> + * The objects themselves are defined in xe_configfs_debug_params.c (as
> + * non-static so they can be referenced from xe_configfs_debug.c's
> + * xe_configfs_debug_attrs[] array and is_visible() callback). They live
> + * in the same translation unit as the X-macro-generated show/store
> + * handlers; consumers should reference them via attr_<name>.
> + */
> +#define _XE_PARAM_DECLARE_ATTR(_T, _name, _def, _val, _vis, _get, _fallback) \
> +	extern struct configfs_attribute attr_##_name;

[Severity: Low]
Similar to the definition above, this macro exposes attr_##_name in the global 
namespace. Adding a prefix like xe_configfs_attr_##_name here would align with 
the definition change and ensure namespace safety.

> +XE_CONFIGFS_DEBUG_PARAMS_FOR_EACH(_XE_PARAM_DECLARE_ATTR)
> +#undef _XE_PARAM_DECLARE_ATTR

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820200719.84681-12-stuart.summers@intel.com?part=8

  reply	other threads:[~2026-08-20 20:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 20:07 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-20 20:07 ` [PATCH 01/10] drm/xe: Guard configfs attribute reads in getters Stuart Summers
2026-08-20 20:19   ` sashiko-bot
2026-08-20 20:07 ` [PATCH 02/10] drm/xe: Sort xe_config_device fields Stuart Summers
2026-08-20 20:20   ` sashiko-bot
2026-08-20 20:07 ` [PATCH 03/10] drm/xe: Split out configfs data structures Stuart Summers
2026-08-20 20:07 ` [PATCH 04/10] drm/xe: Add a new debug focused configfs group Stuart Summers
2026-08-20 20:07 ` [PATCH 05/10] drm/xe: Move debug configfs entries to xe_configfs_debug.c Stuart Summers
2026-08-20 20:20   ` sashiko-bot
2026-08-20 20:07 ` [PATCH 06/10] drm/xe/guc: Add configfs support for guc_log_level Stuart Summers
2026-08-20 20:07 ` [PATCH 07/10] drm/xe/guc: Add support for NPK as a GuC log target Stuart Summers
2026-08-20 20:07 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-20 20:19   ` sashiko-bot [this message]
2026-08-20 21:08     ` Summers, Stuart
2026-08-20 20:07 ` [PATCH 09/10] drm/xe: Migrate existing debug configfs entries to params infrastructure Stuart Summers
2026-08-20 20:07 ` [PATCH 10/10] drm/xe: Taint kernel when debug configfs parameters are set Stuart Summers
2026-08-20 20:14 ` ✗ CI.checkpatch: warning for Add new debug infrastructure for configfs (rev6) Patchwork
2026-08-20 20:16 ` ✓ CI.KUnit: success " Patchwork
2026-08-20 20:54 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-20 22:45 ` ✗ Xe.CI.FULL: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2026-08-20 21:06 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-20 21:06 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-07 19:45 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-07 19:45 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-05 23:20 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-05 23:20 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers

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=20260820201956.0A36F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=stuart.summers@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.