* [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 12:30 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: intel-gfx, dri-devel, jani.nikula, Andrew Morton,
Greg Kroah-Hartman, Lucas De Marchi
Hey, I've sent this before, ages ago, but haven't really followed
through with it. I still think it would be useful for many scenarios
where a plain number is a clumsy interface for a module param.
Thoughts?
BR,
Jani.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Jani Nikula (1):
module: add enum module parameter type to map names to values
include/linux/moduleparam.h | 64 +++++++++++++++++++++++++++++++++++++
kernel/params.c | 41 ++++++++++++++++++++++++
2 files changed, 105 insertions(+)
--
2.30.2
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 12:30 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: jani.nikula, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
dri-devel, Andrew Morton
Hey, I've sent this before, ages ago, but haven't really followed
through with it. I still think it would be useful for many scenarios
where a plain number is a clumsy interface for a module param.
Thoughts?
BR,
Jani.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Jani Nikula (1):
module: add enum module parameter type to map names to values
include/linux/moduleparam.h | 64 +++++++++++++++++++++++++++++++++++++
kernel/params.c | 41 ++++++++++++++++++++++++
2 files changed, 105 insertions(+)
--
2.30.2
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 12:30 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: jani.nikula, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
dri-devel, Andrew Morton
Hey, I've sent this before, ages ago, but haven't really followed
through with it. I still think it would be useful for many scenarios
where a plain number is a clumsy interface for a module param.
Thoughts?
BR,
Jani.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Jani Nikula (1):
module: add enum module parameter type to map names to values
include/linux/moduleparam.h | 64 +++++++++++++++++++++++++++++++++++++
kernel/params.c | 41 ++++++++++++++++++++++++
2 files changed, 105 insertions(+)
--
2.30.2
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 1/1] module: add enum module parameter type to map names to values
2022-04-14 12:30 ` Jani Nikula
(?)
@ 2022-04-14 12:30 ` Jani Nikula
-1 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: intel-gfx, dri-devel, jani.nikula, Andrew Morton,
Greg Kroah-Hartman, Lucas De Marchi
Add enum module parameter type that's internally an int and externally
maps names to values. This makes the userspace interface more intuitive
to use and somewhat easier to document, while also limiting the allowed
values set by userspace to the defined set.
For example, given this code to define a "mode" in a fictional module
"foobar":
struct module_param_enumeration modes[] = {
{ "foo", 0 },
{ "bar", 1 },
{ "baz", -1 },
};
int mode;
module_param_enum(mode, modes, 0600);
You can probe foobar with "foobar.mode=bar" in the kernel or modprobe
command line to set the mode to 1.
Similarly, you can use the sysfs with the names:
# echo baz > /sys/module/foobar/parameters/mode
# cat /sys/module/foobar/parameters/mode
baz
With checks:
# echo nope > /sys/module/foobar/parameters/mode
echo: write error: Invalid argument
Of course, the kernel can still internally set the mode variable
directly to a value that is not defined in the enumerations (obviously
to be avoided), which will result in unknown key:
# cat /sys/module/foobar/parameters/mode
(unknown)
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
include/linux/moduleparam.h | 64 +++++++++++++++++++++++++++++++++++++
kernel/params.c | 41 ++++++++++++++++++++++++
2 files changed, 105 insertions(+)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 962cd41a2cb5..a11fb8f214e5 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -77,6 +77,7 @@ struct kernel_param {
void *arg;
const struct kparam_string *str;
const struct kparam_array *arr;
+ const struct kparam_enum *enumeration;
};
};
@@ -98,6 +99,19 @@ struct kparam_array
void *elem;
};
+/* Special ones for enums */
+struct module_param_enumeration {
+ const char *key;
+ int val;
+};
+
+struct kparam_enum
+{
+ const struct module_param_enumeration *enums;
+ unsigned int num_enums;
+ int *val;
+};
+
/**
* module_param - typesafe helper for a module/cmdline parameter
* @name: the variable to alter, and exposed parameter name.
@@ -484,6 +498,11 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
#define param_get_bint param_get_int
#define param_check_bint param_check_int
+/* An enumeration */
+extern const struct kernel_param_ops param_ops_enum;
+extern int param_set_enum(const char *key, const struct kernel_param *kp);
+extern int param_get_enum(char *buffer, const struct kernel_param *kp);
+
/**
* module_param_array - a parameter which is an array of some type
* @name: the name of the array variable
@@ -523,6 +542,51 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
perm, -1, 0); \
__MODULE_PARM_TYPE(name, "array of " #type)
+/**
+ * module_param_enum - a parameter which is an enumeration
+ * @name: the variable to alter, and exposed parameter name
+ * @enumerations: array of struct module_param_enumeration defining the enums
+ * @perm: visibility in sysfs
+ *
+ * The userspace input and output are based on the names defined in the
+ * @enumerations array, which maps the names to values stored in the int
+ * variable defined by @name.
+ *
+ * When initializing or changing the variable @name, ensure the value is defined
+ * in @enumerations. Otherwise, reading the parameter value via sysfs will
+ * output "(unknown)".
+ *
+ * ARRAY_SIZE(@enumerations) is used to determine the number of elements in the
+ * enumerations array, so the definition must be visible.
+ */
+
+#define module_param_enum(name, enumerations, perm) \
+ module_param_enum_named(name, name, enumerations, perm)
+
+/**
+ * module_param_enum_named - a renamed parameter which is an enumeration
+ * @name: a valid C identifier which is the parameter name
+ * @value: the actual lvalue int variable to alter
+ * @enumerations: array of struct module_param_enumeration defining the enums
+ * @perm: visibility in sysfs
+ *
+ * This exposes a different name than the actual variable name. See
+ * module_param_named() for why this might be necessary.
+ */
+#define module_param_enum_named(name, value, enumerations, perm) \
+ param_check_int(name, &(value)); \
+ static const struct kparam_enum __param_arr_##name = \
+ { \
+ .enums = enumerations, \
+ .num_enums = ARRAY_SIZE(enumerations), \
+ .val = &value \
+ }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_ops_enum, \
+ .enumeration = &__param_arr_##name, \
+ perm, -1, 0); \
+ __MODULE_PARM_TYPE(name, "enumeration")
+
enum hwparam_type {
hwparam_ioport, /* Module parameter configures an I/O port */
hwparam_iomem, /* Module parameter configures an I/O mem address */
diff --git a/kernel/params.c b/kernel/params.c
index 5b92310425c5..749fe42b1a44 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -534,6 +534,47 @@ const struct kernel_param_ops param_ops_string = {
};
EXPORT_SYMBOL(param_ops_string);
+int param_set_enum(const char *key, const struct kernel_param *kp)
+{
+ const struct kparam_enum *e = kp->enumeration;
+ unsigned int i;
+
+ for (i = 0; i < e->num_enums; i++) {
+ if (sysfs_streq(key, e->enums[i].key)) {
+ *(e->val) = e->enums[i].val;
+ return 0;
+ }
+ }
+
+ pr_err("%s: unknown key %s to enum parameter\n", kp->name, key);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(param_set_enum);
+
+int param_get_enum(char *buffer, const struct kernel_param *kp)
+{
+ const struct kparam_enum *e = kp->enumeration;
+ unsigned int i;
+
+ for (i = 0; i < e->num_enums; i++) {
+ if (*(e->val) == e->enums[i].val)
+ return sysfs_emit(buffer, "%s\n", e->enums[i].key);
+ }
+
+ pr_err("%s: enum parameter set to unknown value %d\n",
+ kp->name, *(e->val));
+
+ return sysfs_emit(buffer, "(unknown)\n");
+}
+EXPORT_SYMBOL(param_get_enum);
+
+const struct kernel_param_ops param_ops_enum = {
+ .set = param_set_enum,
+ .get = param_get_enum,
+};
+EXPORT_SYMBOL(param_ops_enum);
+
/* sysfs output in /sys/modules/XYZ/parameters/ */
#define to_module_attr(n) container_of(n, struct module_attribute, attr)
#define to_module_kobject(n) container_of(n, struct module_kobject, kobj)
--
2.30.2
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 1/1] module: add enum module parameter type to map names to values
@ 2022-04-14 12:30 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: jani.nikula, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
dri-devel, Andrew Morton
Add enum module parameter type that's internally an int and externally
maps names to values. This makes the userspace interface more intuitive
to use and somewhat easier to document, while also limiting the allowed
values set by userspace to the defined set.
For example, given this code to define a "mode" in a fictional module
"foobar":
struct module_param_enumeration modes[] = {
{ "foo", 0 },
{ "bar", 1 },
{ "baz", -1 },
};
int mode;
module_param_enum(mode, modes, 0600);
You can probe foobar with "foobar.mode=bar" in the kernel or modprobe
command line to set the mode to 1.
Similarly, you can use the sysfs with the names:
# echo baz > /sys/module/foobar/parameters/mode
# cat /sys/module/foobar/parameters/mode
baz
With checks:
# echo nope > /sys/module/foobar/parameters/mode
echo: write error: Invalid argument
Of course, the kernel can still internally set the mode variable
directly to a value that is not defined in the enumerations (obviously
to be avoided), which will result in unknown key:
# cat /sys/module/foobar/parameters/mode
(unknown)
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
include/linux/moduleparam.h | 64 +++++++++++++++++++++++++++++++++++++
kernel/params.c | 41 ++++++++++++++++++++++++
2 files changed, 105 insertions(+)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 962cd41a2cb5..a11fb8f214e5 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -77,6 +77,7 @@ struct kernel_param {
void *arg;
const struct kparam_string *str;
const struct kparam_array *arr;
+ const struct kparam_enum *enumeration;
};
};
@@ -98,6 +99,19 @@ struct kparam_array
void *elem;
};
+/* Special ones for enums */
+struct module_param_enumeration {
+ const char *key;
+ int val;
+};
+
+struct kparam_enum
+{
+ const struct module_param_enumeration *enums;
+ unsigned int num_enums;
+ int *val;
+};
+
/**
* module_param - typesafe helper for a module/cmdline parameter
* @name: the variable to alter, and exposed parameter name.
@@ -484,6 +498,11 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
#define param_get_bint param_get_int
#define param_check_bint param_check_int
+/* An enumeration */
+extern const struct kernel_param_ops param_ops_enum;
+extern int param_set_enum(const char *key, const struct kernel_param *kp);
+extern int param_get_enum(char *buffer, const struct kernel_param *kp);
+
/**
* module_param_array - a parameter which is an array of some type
* @name: the name of the array variable
@@ -523,6 +542,51 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
perm, -1, 0); \
__MODULE_PARM_TYPE(name, "array of " #type)
+/**
+ * module_param_enum - a parameter which is an enumeration
+ * @name: the variable to alter, and exposed parameter name
+ * @enumerations: array of struct module_param_enumeration defining the enums
+ * @perm: visibility in sysfs
+ *
+ * The userspace input and output are based on the names defined in the
+ * @enumerations array, which maps the names to values stored in the int
+ * variable defined by @name.
+ *
+ * When initializing or changing the variable @name, ensure the value is defined
+ * in @enumerations. Otherwise, reading the parameter value via sysfs will
+ * output "(unknown)".
+ *
+ * ARRAY_SIZE(@enumerations) is used to determine the number of elements in the
+ * enumerations array, so the definition must be visible.
+ */
+
+#define module_param_enum(name, enumerations, perm) \
+ module_param_enum_named(name, name, enumerations, perm)
+
+/**
+ * module_param_enum_named - a renamed parameter which is an enumeration
+ * @name: a valid C identifier which is the parameter name
+ * @value: the actual lvalue int variable to alter
+ * @enumerations: array of struct module_param_enumeration defining the enums
+ * @perm: visibility in sysfs
+ *
+ * This exposes a different name than the actual variable name. See
+ * module_param_named() for why this might be necessary.
+ */
+#define module_param_enum_named(name, value, enumerations, perm) \
+ param_check_int(name, &(value)); \
+ static const struct kparam_enum __param_arr_##name = \
+ { \
+ .enums = enumerations, \
+ .num_enums = ARRAY_SIZE(enumerations), \
+ .val = &value \
+ }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_ops_enum, \
+ .enumeration = &__param_arr_##name, \
+ perm, -1, 0); \
+ __MODULE_PARM_TYPE(name, "enumeration")
+
enum hwparam_type {
hwparam_ioport, /* Module parameter configures an I/O port */
hwparam_iomem, /* Module parameter configures an I/O mem address */
diff --git a/kernel/params.c b/kernel/params.c
index 5b92310425c5..749fe42b1a44 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -534,6 +534,47 @@ const struct kernel_param_ops param_ops_string = {
};
EXPORT_SYMBOL(param_ops_string);
+int param_set_enum(const char *key, const struct kernel_param *kp)
+{
+ const struct kparam_enum *e = kp->enumeration;
+ unsigned int i;
+
+ for (i = 0; i < e->num_enums; i++) {
+ if (sysfs_streq(key, e->enums[i].key)) {
+ *(e->val) = e->enums[i].val;
+ return 0;
+ }
+ }
+
+ pr_err("%s: unknown key %s to enum parameter\n", kp->name, key);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(param_set_enum);
+
+int param_get_enum(char *buffer, const struct kernel_param *kp)
+{
+ const struct kparam_enum *e = kp->enumeration;
+ unsigned int i;
+
+ for (i = 0; i < e->num_enums; i++) {
+ if (*(e->val) == e->enums[i].val)
+ return sysfs_emit(buffer, "%s\n", e->enums[i].key);
+ }
+
+ pr_err("%s: enum parameter set to unknown value %d\n",
+ kp->name, *(e->val));
+
+ return sysfs_emit(buffer, "(unknown)\n");
+}
+EXPORT_SYMBOL(param_get_enum);
+
+const struct kernel_param_ops param_ops_enum = {
+ .set = param_set_enum,
+ .get = param_get_enum,
+};
+EXPORT_SYMBOL(param_ops_enum);
+
/* sysfs output in /sys/modules/XYZ/parameters/ */
#define to_module_attr(n) container_of(n, struct module_attribute, attr)
#define to_module_kobject(n) container_of(n, struct module_kobject, kobj)
--
2.30.2
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [Intel-gfx] [PATCH 1/1] module: add enum module parameter type to map names to values
@ 2022-04-14 12:30 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: jani.nikula, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
dri-devel, Andrew Morton
Add enum module parameter type that's internally an int and externally
maps names to values. This makes the userspace interface more intuitive
to use and somewhat easier to document, while also limiting the allowed
values set by userspace to the defined set.
For example, given this code to define a "mode" in a fictional module
"foobar":
struct module_param_enumeration modes[] = {
{ "foo", 0 },
{ "bar", 1 },
{ "baz", -1 },
};
int mode;
module_param_enum(mode, modes, 0600);
You can probe foobar with "foobar.mode=bar" in the kernel or modprobe
command line to set the mode to 1.
Similarly, you can use the sysfs with the names:
# echo baz > /sys/module/foobar/parameters/mode
# cat /sys/module/foobar/parameters/mode
baz
With checks:
# echo nope > /sys/module/foobar/parameters/mode
echo: write error: Invalid argument
Of course, the kernel can still internally set the mode variable
directly to a value that is not defined in the enumerations (obviously
to be avoided), which will result in unknown key:
# cat /sys/module/foobar/parameters/mode
(unknown)
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
include/linux/moduleparam.h | 64 +++++++++++++++++++++++++++++++++++++
kernel/params.c | 41 ++++++++++++++++++++++++
2 files changed, 105 insertions(+)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 962cd41a2cb5..a11fb8f214e5 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -77,6 +77,7 @@ struct kernel_param {
void *arg;
const struct kparam_string *str;
const struct kparam_array *arr;
+ const struct kparam_enum *enumeration;
};
};
@@ -98,6 +99,19 @@ struct kparam_array
void *elem;
};
+/* Special ones for enums */
+struct module_param_enumeration {
+ const char *key;
+ int val;
+};
+
+struct kparam_enum
+{
+ const struct module_param_enumeration *enums;
+ unsigned int num_enums;
+ int *val;
+};
+
/**
* module_param - typesafe helper for a module/cmdline parameter
* @name: the variable to alter, and exposed parameter name.
@@ -484,6 +498,11 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
#define param_get_bint param_get_int
#define param_check_bint param_check_int
+/* An enumeration */
+extern const struct kernel_param_ops param_ops_enum;
+extern int param_set_enum(const char *key, const struct kernel_param *kp);
+extern int param_get_enum(char *buffer, const struct kernel_param *kp);
+
/**
* module_param_array - a parameter which is an array of some type
* @name: the name of the array variable
@@ -523,6 +542,51 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
perm, -1, 0); \
__MODULE_PARM_TYPE(name, "array of " #type)
+/**
+ * module_param_enum - a parameter which is an enumeration
+ * @name: the variable to alter, and exposed parameter name
+ * @enumerations: array of struct module_param_enumeration defining the enums
+ * @perm: visibility in sysfs
+ *
+ * The userspace input and output are based on the names defined in the
+ * @enumerations array, which maps the names to values stored in the int
+ * variable defined by @name.
+ *
+ * When initializing or changing the variable @name, ensure the value is defined
+ * in @enumerations. Otherwise, reading the parameter value via sysfs will
+ * output "(unknown)".
+ *
+ * ARRAY_SIZE(@enumerations) is used to determine the number of elements in the
+ * enumerations array, so the definition must be visible.
+ */
+
+#define module_param_enum(name, enumerations, perm) \
+ module_param_enum_named(name, name, enumerations, perm)
+
+/**
+ * module_param_enum_named - a renamed parameter which is an enumeration
+ * @name: a valid C identifier which is the parameter name
+ * @value: the actual lvalue int variable to alter
+ * @enumerations: array of struct module_param_enumeration defining the enums
+ * @perm: visibility in sysfs
+ *
+ * This exposes a different name than the actual variable name. See
+ * module_param_named() for why this might be necessary.
+ */
+#define module_param_enum_named(name, value, enumerations, perm) \
+ param_check_int(name, &(value)); \
+ static const struct kparam_enum __param_arr_##name = \
+ { \
+ .enums = enumerations, \
+ .num_enums = ARRAY_SIZE(enumerations), \
+ .val = &value \
+ }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_ops_enum, \
+ .enumeration = &__param_arr_##name, \
+ perm, -1, 0); \
+ __MODULE_PARM_TYPE(name, "enumeration")
+
enum hwparam_type {
hwparam_ioport, /* Module parameter configures an I/O port */
hwparam_iomem, /* Module parameter configures an I/O mem address */
diff --git a/kernel/params.c b/kernel/params.c
index 5b92310425c5..749fe42b1a44 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -534,6 +534,47 @@ const struct kernel_param_ops param_ops_string = {
};
EXPORT_SYMBOL(param_ops_string);
+int param_set_enum(const char *key, const struct kernel_param *kp)
+{
+ const struct kparam_enum *e = kp->enumeration;
+ unsigned int i;
+
+ for (i = 0; i < e->num_enums; i++) {
+ if (sysfs_streq(key, e->enums[i].key)) {
+ *(e->val) = e->enums[i].val;
+ return 0;
+ }
+ }
+
+ pr_err("%s: unknown key %s to enum parameter\n", kp->name, key);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(param_set_enum);
+
+int param_get_enum(char *buffer, const struct kernel_param *kp)
+{
+ const struct kparam_enum *e = kp->enumeration;
+ unsigned int i;
+
+ for (i = 0; i < e->num_enums; i++) {
+ if (*(e->val) == e->enums[i].val)
+ return sysfs_emit(buffer, "%s\n", e->enums[i].key);
+ }
+
+ pr_err("%s: enum parameter set to unknown value %d\n",
+ kp->name, *(e->val));
+
+ return sysfs_emit(buffer, "(unknown)\n");
+}
+EXPORT_SYMBOL(param_get_enum);
+
+const struct kernel_param_ops param_ops_enum = {
+ .set = param_set_enum,
+ .get = param_get_enum,
+};
+EXPORT_SYMBOL(param_ops_enum);
+
/* sysfs output in /sys/modules/XYZ/parameters/ */
#define to_module_attr(n) container_of(n, struct module_attribute, attr)
#define to_module_kobject(n) container_of(n, struct module_kobject, kobj)
--
2.30.2
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-14 12:30 ` Jani Nikula
(?)
@ 2022-04-14 13:19 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-14 13:19 UTC (permalink / raw)
To: Jani Nikula
Cc: Andrew Morton, intel-gfx, Lucas De Marchi, linux-kernel, dri-devel
On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> Hey, I've sent this before, ages ago, but haven't really followed
> through with it. I still think it would be useful for many scenarios
> where a plain number is a clumsy interface for a module param.
>
> Thoughts?
We should not be adding new module parameters anyway (they operate on
code, not data/devices), so what would this be used for?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 13:19 ` Greg Kroah-Hartman
0 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-14 13:19 UTC (permalink / raw)
To: Jani Nikula
Cc: Andrew Morton, intel-gfx, Lucas De Marchi, linux-kernel, dri-devel
On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> Hey, I've sent this before, ages ago, but haven't really followed
> through with it. I still think it would be useful for many scenarios
> where a plain number is a clumsy interface for a module param.
>
> Thoughts?
We should not be adding new module parameters anyway (they operate on
code, not data/devices), so what would this be used for?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 13:19 ` Greg Kroah-Hartman
0 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-14 13:19 UTC (permalink / raw)
To: Jani Nikula
Cc: linux-kernel, intel-gfx, dri-devel, Andrew Morton, Lucas De Marchi
On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> Hey, I've sent this before, ages ago, but haven't really followed
> through with it. I still think it would be useful for many scenarios
> where a plain number is a clumsy interface for a module param.
>
> Thoughts?
We should not be adding new module parameters anyway (they operate on
code, not data/devices), so what would this be used for?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for add support for enum module parameters
2022-04-14 12:30 ` Jani Nikula
` (3 preceding siblings ...)
(?)
@ 2022-04-14 13:59 ` Patchwork
-1 siblings, 0 replies; 31+ messages in thread
From: Patchwork @ 2022-04-14 13:59 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
== Series Details ==
Series: add support for enum module parameters
URL : https://patchwork.freedesktop.org/series/102695/
State : warning
== Summary ==
Error: dim checkpatch failed
8c6849f919aa module: add enum module parameter type to map names to values
-:73: ERROR:OPEN_BRACE: open brace '{' following struct go on the same line
#73: FILE: include/linux/moduleparam.h:109:
+struct kparam_enum
+{
-:88: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#88: FILE: include/linux/moduleparam.h:503:
+extern int param_set_enum(const char *key, const struct kernel_param *kp);
-:89: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#89: FILE: include/linux/moduleparam.h:504:
+extern int param_get_enum(char *buffer, const struct kernel_param *kp);
-:116: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible side-effects?
#116: FILE: include/linux/moduleparam.h:563:
+#define module_param_enum(name, enumerations, perm) \
+ module_param_enum_named(name, name, enumerations, perm)
-:129: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible side-effects?
#129: FILE: include/linux/moduleparam.h:576:
+#define module_param_enum_named(name, value, enumerations, perm) \
+ param_check_int(name, &(value)); \
+ static const struct kparam_enum __param_arr_##name = \
+ { \
+ .enums = enumerations, \
+ .num_enums = ARRAY_SIZE(enumerations), \
+ .val = &value \
+ }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_ops_enum, \
+ .enumeration = &__param_arr_##name, \
+ perm, -1, 0); \
+ __MODULE_PARM_TYPE(name, "enumeration")
-:129: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'value' - possible side-effects?
#129: FILE: include/linux/moduleparam.h:576:
+#define module_param_enum_named(name, value, enumerations, perm) \
+ param_check_int(name, &(value)); \
+ static const struct kparam_enum __param_arr_##name = \
+ { \
+ .enums = enumerations, \
+ .num_enums = ARRAY_SIZE(enumerations), \
+ .val = &value \
+ }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_ops_enum, \
+ .enumeration = &__param_arr_##name, \
+ perm, -1, 0); \
+ __MODULE_PARM_TYPE(name, "enumeration")
-:129: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'enumerations' - possible side-effects?
#129: FILE: include/linux/moduleparam.h:576:
+#define module_param_enum_named(name, value, enumerations, perm) \
+ param_check_int(name, &(value)); \
+ static const struct kparam_enum __param_arr_##name = \
+ { \
+ .enums = enumerations, \
+ .num_enums = ARRAY_SIZE(enumerations), \
+ .val = &value \
+ }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_ops_enum, \
+ .enumeration = &__param_arr_##name, \
+ perm, -1, 0); \
+ __MODULE_PARM_TYPE(name, "enumeration")
-:161: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around e->val
#161: FILE: kernel/params.c:544:
+ *(e->val) = e->enums[i].val;
-:178: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around e->val
#178: FILE: kernel/params.c:561:
+ if (*(e->val) == e->enums[i].val)
-:178: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'e->val'
#178: FILE: kernel/params.c:561:
+ if (*(e->val) == e->enums[i].val)
-:183: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around e->val
#183: FILE: kernel/params.c:566:
+ kp->name, *(e->val));
total: 1 errors, 0 warnings, 10 checks, 135 lines checked
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for add support for enum module parameters
2022-04-14 12:30 ` Jani Nikula
` (4 preceding siblings ...)
(?)
@ 2022-04-14 13:59 ` Patchwork
-1 siblings, 0 replies; 31+ messages in thread
From: Patchwork @ 2022-04-14 13:59 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
== Series Details ==
Series: add support for enum module parameters
URL : https://patchwork.freedesktop.org/series/102695/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for add support for enum module parameters
2022-04-14 12:30 ` Jani Nikula
` (5 preceding siblings ...)
(?)
@ 2022-04-14 14:22 ` Patchwork
-1 siblings, 0 replies; 31+ messages in thread
From: Patchwork @ 2022-04-14 14:22 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 6264 bytes --]
== Series Details ==
Series: add support for enum module parameters
URL : https://patchwork.freedesktop.org/series/102695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11499 -> Patchwork_102695v1
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/index.html
Participating hosts (49 -> 46)
------------------------------
Additional (1): fi-tgl-u2
Missing (4): bat-hsw-1 bat-adlm-1 fi-bsw-cyan fi-bdw-samus
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_102695v1:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_lmem_swapping@basic:
- {bat-rpls-2}: NOTRUN -> [FAIL][1] +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/bat-rpls-2/igt@gem_lmem_swapping@basic.html
* igt@i915_module_load@reload:
- {bat-rpls-2}: [INCOMPLETE][2] ([i915#5329]) -> [DMESG-WARN][3]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/bat-rpls-2/igt@i915_module_load@reload.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/bat-rpls-2/igt@i915_module_load@reload.html
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: NOTRUN -> [WARN][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/bat-rpls-2/igt@i915_pm_rpm@module-reload.html
Known issues
------------
Here are the changes found in Patchwork_102695v1 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_huc_copy@huc-copy:
- fi-tgl-u2: NOTRUN -> [SKIP][5] ([i915#2190])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-tgl-u2/igt@gem_huc_copy@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [PASS][6] -> [INCOMPLETE][7] ([i915#3921])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: NOTRUN -> [DMESG-WARN][8] ([i915#402])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-tgl-u2/igt@kms_busy@basic@flip.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2: NOTRUN -> [SKIP][9] ([fdo#109284] / [fdo#111827]) +8 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-tgl-u2/igt@kms_chamelium@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2: NOTRUN -> [SKIP][10] ([i915#4103]) +1 similar issue
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-tgl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-tgl-u2/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-u2: NOTRUN -> [SKIP][12] ([i915#3555])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-tgl-u2/igt@kms_setmode@basic-clone-single-crtc.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][13] ([i915#4312])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/fi-bdw-5557u/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_ringfill@basic-all:
- {bat-dg2-8}: [TIMEOUT][14] ([i915#5709]) -> [PASS][15]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/bat-dg2-8/igt@gem_ringfill@basic-all.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/bat-dg2-8/igt@gem_ringfill@basic-all.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/bat-adlp-6/igt@kms_flip@basic-flip-vs-modeset@a-edp1.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-modeset@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5087]: https://gitlab.freedesktop.org/drm/intel/issues/5087
[i915#5329]: https://gitlab.freedesktop.org/drm/intel/issues/5329
[i915#5709]: https://gitlab.freedesktop.org/drm/intel/issues/5709
Build changes
-------------
* Linux: CI_DRM_11499 -> Patchwork_102695v1
CI-20190529: 20190529
CI_DRM_11499: aad6e551495e0ff256adeae6106c8fa1bdb3faed @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6420: a3885810ccc0ce9e6552a20c910a0a322eca466c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_102695v1: aad6e551495e0ff256adeae6106c8fa1bdb3faed @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c72b06ac9474 module: add enum module parameter type to map names to values
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/index.html
[-- Attachment #2: Type: text/html, Size: 6952 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-14 13:19 ` [Intel-gfx] " Greg Kroah-Hartman
(?)
@ 2022-04-14 14:22 ` Jani Nikula
-1 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 14:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrew Morton, intel-gfx, Lucas De Marchi, linux-kernel, dri-devel
On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>> Hey, I've sent this before, ages ago, but haven't really followed
>> through with it. I still think it would be useful for many scenarios
>> where a plain number is a clumsy interface for a module param.
>>
>> Thoughts?
>
> We should not be adding new module parameters anyway (they operate on
> code, not data/devices), so what would this be used for?
I think it's just easier to use names than random values, and this also
gives you range check on the input.
I also keep telling people not to add new module parameters, but it's
not like they're going away anytime soon.
If there's a solution to being able to pass device specific debug
parameters at probe time, I'm all ears. At least i915 has a bunch of
things which can't really be changed after probe, when debugfs for the
device is around. Module parameters aren't ideal, but debugfs doesn't
work for this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 14:22 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 14:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrew Morton, intel-gfx, Lucas De Marchi, linux-kernel, dri-devel
On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>> Hey, I've sent this before, ages ago, but haven't really followed
>> through with it. I still think it would be useful for many scenarios
>> where a plain number is a clumsy interface for a module param.
>>
>> Thoughts?
>
> We should not be adding new module parameters anyway (they operate on
> code, not data/devices), so what would this be used for?
I think it's just easier to use names than random values, and this also
gives you range check on the input.
I also keep telling people not to add new module parameters, but it's
not like they're going away anytime soon.
If there's a solution to being able to pass device specific debug
parameters at probe time, I'm all ears. At least i915 has a bunch of
things which can't really be changed after probe, when debugfs for the
device is around. Module parameters aren't ideal, but debugfs doesn't
work for this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 14:22 ` Jani Nikula
0 siblings, 0 replies; 31+ messages in thread
From: Jani Nikula @ 2022-04-14 14:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, intel-gfx, dri-devel, Andrew Morton, Lucas De Marchi
On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>> Hey, I've sent this before, ages ago, but haven't really followed
>> through with it. I still think it would be useful for many scenarios
>> where a plain number is a clumsy interface for a module param.
>>
>> Thoughts?
>
> We should not be adding new module parameters anyway (they operate on
> code, not data/devices), so what would this be used for?
I think it's just easier to use names than random values, and this also
gives you range check on the input.
I also keep telling people not to add new module parameters, but it's
not like they're going away anytime soon.
If there's a solution to being able to pass device specific debug
parameters at probe time, I'm all ears. At least i915 has a bunch of
things which can't really be changed after probe, when debugfs for the
device is around. Module parameters aren't ideal, but debugfs doesn't
work for this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-14 14:22 ` [Intel-gfx] " Jani Nikula
(?)
@ 2022-04-14 14:29 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-14 14:29 UTC (permalink / raw)
To: Jani Nikula
Cc: Andrew Morton, intel-gfx, Lucas De Marchi, linux-kernel, dri-devel
On Thu, Apr 14, 2022 at 05:22:47PM +0300, Jani Nikula wrote:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >> Hey, I've sent this before, ages ago, but haven't really followed
> >> through with it. I still think it would be useful for many scenarios
> >> where a plain number is a clumsy interface for a module param.
> >>
> >> Thoughts?
> >
> > We should not be adding new module parameters anyway (they operate on
> > code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
Existing ones can not go away (or change), but we do not have to add new
ones.
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
configfs?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 14:29 ` Greg Kroah-Hartman
0 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-14 14:29 UTC (permalink / raw)
To: Jani Nikula
Cc: Andrew Morton, intel-gfx, Lucas De Marchi, linux-kernel, dri-devel
On Thu, Apr 14, 2022 at 05:22:47PM +0300, Jani Nikula wrote:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >> Hey, I've sent this before, ages ago, but haven't really followed
> >> through with it. I still think it would be useful for many scenarios
> >> where a plain number is a clumsy interface for a module param.
> >>
> >> Thoughts?
> >
> > We should not be adding new module parameters anyway (they operate on
> > code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
Existing ones can not go away (or change), but we do not have to add new
ones.
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
configfs?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-14 14:29 ` Greg Kroah-Hartman
0 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-14 14:29 UTC (permalink / raw)
To: Jani Nikula
Cc: linux-kernel, intel-gfx, dri-devel, Andrew Morton, Lucas De Marchi
On Thu, Apr 14, 2022 at 05:22:47PM +0300, Jani Nikula wrote:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >> Hey, I've sent this before, ages ago, but haven't really followed
> >> through with it. I still think it would be useful for many scenarios
> >> where a plain number is a clumsy interface for a module param.
> >>
> >> Thoughts?
> >
> > We should not be adding new module parameters anyway (they operate on
> > code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
Existing ones can not go away (or change), but we do not have to add new
ones.
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
configfs?
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for add support for enum module parameters
2022-04-14 12:30 ` Jani Nikula
` (6 preceding siblings ...)
(?)
@ 2022-04-14 16:49 ` Patchwork
-1 siblings, 0 replies; 31+ messages in thread
From: Patchwork @ 2022-04-14 16:49 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 53081 bytes --]
== Series Details ==
Series: add support for enum module parameters
URL : https://patchwork.freedesktop.org/series/102695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11499_full -> Patchwork_102695v1_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_102695v1_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102695v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 12)
------------------------------
Additional (2): shard-rkl shard-tglu
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_102695v1_full:
### IGT changes ###
#### Possible regressions ####
* igt@api_intel_allocator@two-level-inception:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-tglb8/igt@api_intel_allocator@two-level-inception.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb8/igt@api_intel_allocator@two-level-inception.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][3] -> [INCOMPLETE][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
Known issues
------------
Here are the changes found in Patchwork_102695v1_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +6 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl1/igt@gem_ctx_isolation@preservation-s3@bcs0.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl7/igt@gem_ctx_isolation@preservation-s3@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: NOTRUN -> [FAIL][7] ([i915#2846])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl4/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl8/igt@gem_exec_fair@basic-none@vcs0.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl3/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_flush@basic-wb-ro-default:
- shard-snb: [PASS][12] -> [SKIP][13] ([fdo#109271]) +1 similar issue
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-snb2/igt@gem_exec_flush@basic-wb-ro-default.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-snb6/igt@gem_exec_flush@basic-wb-ro-default.html
* igt@gem_lmem_swapping@basic:
- shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1 similar issue
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@gem_lmem_swapping@basic.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl4/igt@gem_lmem_swapping@heavy-random.html
* igt@gem_lmem_swapping@parallel-random:
- shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1 similar issue
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl6/igt@gem_lmem_swapping@parallel-random.html
* igt@gem_render_copy@x-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@gem_render_copy@x-tiled-to-vebox-y-tiled.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][18] ([i915#4991])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl3/igt@gem_userptr_blits@input-checking.html
* igt@gem_userptr_blits@vma-merge:
- shard-skl: NOTRUN -> [FAIL][19] ([i915#3318])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl1/igt@gem_userptr_blits@vma-merge.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#5566] / [i915#716])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk3/igt@gen9_exec_parse@allowed-all.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk7/igt@gen9_exec_parse@allowed-all.html
* igt@gen9_exec_parse@allowed-single:
- shard-kbl: [PASS][22] -> [DMESG-WARN][23] ([i915#5566] / [i915#716])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl4/igt@gen9_exec_parse@allowed-single.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@gen9_exec_parse@allowed-single.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-iclb: NOTRUN -> [SKIP][24] ([fdo#110892])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-snb: [PASS][25] -> [FAIL][26] ([i915#2521])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-snb5/igt@kms_async_flips@alternate-sync-async-flip.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-snb7/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180:
- shard-iclb: NOTRUN -> [SKIP][27] ([i915#5286])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180.html
* igt@kms_big_fb@linear-64bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][28] ([fdo#111614])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_big_fb@linear-64bpp-rotate-90.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-kbl: NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#3777]) +1 similar issue
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-skl: NOTRUN -> [SKIP][30] ([fdo#109271] / [i915#3777]) +2 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl9/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][31] ([i915#3743])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl10/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3777])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl4/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_joiner@invalid-modeset:
- shard-tglb: NOTRUN -> [SKIP][33] ([i915#2705])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#3886])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl4/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-kbl: NOTRUN -> [SKIP][35] ([fdo#109271] / [i915#3886]) +4 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][36] ([i915#3689] / [i915#3886])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][37] ([fdo#109271] / [i915#3886]) +3 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl1/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-iclb: NOTRUN -> [SKIP][38] ([fdo#109278] / [i915#3886])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium@dp-hpd-for-each-pipe:
- shard-kbl: NOTRUN -> [SKIP][39] ([fdo#109271] / [fdo#111827]) +10 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@kms_chamelium@dp-hpd-for-each-pipe.html
* igt@kms_chamelium@vga-hpd-after-suspend:
- shard-tglb: NOTRUN -> [SKIP][40] ([fdo#109284] / [fdo#111827]) +2 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_chamelium@vga-hpd-after-suspend.html
* igt@kms_chamelium@vga-hpd-without-ddc:
- shard-iclb: NOTRUN -> [SKIP][41] ([fdo#109284] / [fdo#111827])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_chamelium@vga-hpd-without-ddc.html
* igt@kms_color_chamelium@pipe-b-ctm-negative:
- shard-apl: NOTRUN -> [SKIP][42] ([fdo#109271] / [fdo#111827])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl4/igt@kms_color_chamelium@pipe-b-ctm-negative.html
* igt@kms_color_chamelium@pipe-d-ctm-red-to-blue:
- shard-skl: NOTRUN -> [SKIP][43] ([fdo#109271] / [fdo#111827]) +14 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl1/igt@kms_color_chamelium@pipe-d-ctm-red-to-blue.html
* igt@kms_content_protection@lic:
- shard-kbl: NOTRUN -> [TIMEOUT][44] ([i915#1319])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@kms_content_protection@lic.html
* igt@kms_cursor_crc@pipe-b-cursor-512x512-sliding:
- shard-iclb: NOTRUN -> [SKIP][45] ([fdo#109278] / [fdo#109279])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_cursor_crc@pipe-b-cursor-512x512-sliding.html
* igt@kms_cursor_crc@pipe-c-cursor-512x170-sliding:
- shard-iclb: NOTRUN -> [SKIP][46] ([fdo#109278] / [fdo#109279] / [i915#5691])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_cursor_crc@pipe-c-cursor-512x170-sliding.html
* igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement:
- shard-iclb: NOTRUN -> [SKIP][47] ([fdo#109278]) +5 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-iclb: NOTRUN -> [SKIP][48] ([fdo#109274] / [fdo#109278])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_cursor_legacy@cursorb-vs-flipa-toggle.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][49] -> [FAIL][50] ([i915#2346])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk1/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk9/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@pipe-d-single-bo:
- shard-kbl: NOTRUN -> [SKIP][51] ([fdo#109271] / [i915#533])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@kms_cursor_legacy@pipe-d-single-bo.html
* igt@kms_dither@fb-8bpc-vs-panel-8bpc@edp-1-pipe-a:
- shard-tglb: NOTRUN -> [SKIP][52] ([i915#3788])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_dither@fb-8bpc-vs-panel-8bpc@edp-1-pipe-a.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [PASS][53] -> [INCOMPLETE][54] ([i915#4939])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl4/igt@kms_fbcon_fbt@psr-suspend.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl4/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][55] -> [FAIL][56] ([i915#2122]) +1 similar issue
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2.html
* igt@kms_flip@2x-flip-vs-modeset:
- shard-apl: NOTRUN -> [SKIP][57] ([fdo#109271]) +25 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl4/igt@kms_flip@2x-flip-vs-modeset.html
* igt@kms_flip@2x-flip-vs-modeset-vs-hang:
- shard-tglb: NOTRUN -> [SKIP][58] ([fdo#109274] / [fdo#111825])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_flip@2x-flip-vs-modeset-vs-hang.html
* igt@kms_flip@2x-flip-vs-panning-vs-hang:
- shard-iclb: NOTRUN -> [SKIP][59] ([fdo#109274]) +2 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_flip@2x-flip-vs-panning-vs-hang.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling:
- shard-iclb: [PASS][60] -> [SKIP][61] ([i915#3701])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb3/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling:
- shard-glk: [PASS][62] -> [FAIL][63] ([i915#4911])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk9/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-mmap-wc:
- shard-kbl: NOTRUN -> [SKIP][64] ([fdo#109271]) +125 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-skl: NOTRUN -> [SKIP][65] ([fdo#109271]) +180 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl6/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> [SKIP][66] ([fdo#109280]) +4 similar issues
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move:
- shard-tglb: NOTRUN -> [SKIP][67] ([fdo#109280] / [fdo#111825]) +5 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move.html
* igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a:
- shard-skl: [PASS][68] -> [FAIL][69] ([i915#1188])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl7/igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl4/igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a.html
* igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c:
- shard-tglb: NOTRUN -> [SKIP][70] ([fdo#109289]) +1 similar issue
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c.html
* igt@kms_pipe_crc_basic@read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][71] ([fdo#109271] / [i915#533]) +2 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl10/igt@kms_pipe_crc_basic@read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
- shard-skl: NOTRUN -> [FAIL][72] ([i915#265])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl: NOTRUN -> [FAIL][73] ([fdo#108145] / [i915#265])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl4/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][74] -> [FAIL][75] ([fdo#108145] / [i915#265])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-tglb: NOTRUN -> [SKIP][76] ([fdo#111615])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_plane_multiple@atomic-pipe-b-tiling-yf.html
* igt@kms_psr2_sf@cursor-plane-update-sf:
- shard-skl: NOTRUN -> [SKIP][77] ([fdo#109271] / [i915#658]) +2 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl6/igt@kms_psr2_sf@cursor-plane-update-sf.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-iclb: NOTRUN -> [SKIP][78] ([fdo#111068] / [i915#658])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html
* igt@kms_psr2_su@page_flip-xrgb8888:
- shard-kbl: NOTRUN -> [SKIP][79] ([fdo#109271] / [i915#658]) +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl4/igt@kms_psr2_su@page_flip-xrgb8888.html
* igt@kms_psr@psr2_basic:
- shard-tglb: NOTRUN -> [FAIL][80] ([i915#132] / [i915#3467])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_psr@psr2_basic.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][81] -> [SKIP][82] ([fdo#109441]) +2 similar issues
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb7/igt@kms_psr@psr2_cursor_render.html
* igt@kms_psr_stress_test@invalidate-primary-flip-overlay:
- shard-tglb: [PASS][83] -> [SKIP][84] ([i915#5519])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-tglb5/igt@kms_psr_stress_test@invalidate-primary-flip-overlay.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb8/igt@kms_psr_stress_test@invalidate-primary-flip-overlay.html
* igt@kms_setmode@invalid-clone-single-crtc:
- shard-tglb: NOTRUN -> [SKIP][85] ([i915#3555])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@kms_setmode@invalid-clone-single-crtc.html
* igt@kms_writeback@writeback-invalid-parameters:
- shard-skl: NOTRUN -> [SKIP][86] ([fdo#109271] / [i915#2437])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl3/igt@kms_writeback@writeback-invalid-parameters.html
* igt@nouveau_crc@pipe-b-source-outp-complete:
- shard-iclb: NOTRUN -> [SKIP][87] ([i915#2530])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@nouveau_crc@pipe-b-source-outp-complete.html
* igt@nouveau_crc@pipe-b-source-outp-inactive:
- shard-tglb: NOTRUN -> [SKIP][88] ([i915#2530])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@nouveau_crc@pipe-b-source-outp-inactive.html
* igt@nouveau_crc@pipe-d-source-outp-inactive:
- shard-iclb: NOTRUN -> [SKIP][89] ([fdo#109278] / [i915#2530])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@nouveau_crc@pipe-d-source-outp-inactive.html
* igt@perf@non-zero-reason:
- shard-glk: [PASS][90] -> [FAIL][91] ([i915#5121])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk2/igt@perf@non-zero-reason.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk1/igt@perf@non-zero-reason.html
* igt@perf@stress-open-close:
- shard-glk: [PASS][92] -> [INCOMPLETE][93] ([i915#5213])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk7/igt@perf@stress-open-close.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk8/igt@perf@stress-open-close.html
* igt@syncobj_timeline@invalid-transfer-non-existent-point:
- shard-skl: NOTRUN -> [DMESG-WARN][94] ([i915#5098])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl6/igt@syncobj_timeline@invalid-transfer-non-existent-point.html
* igt@syncobj_timeline@transfer-timeline-point:
- shard-kbl: NOTRUN -> [DMESG-FAIL][95] ([i915#5098])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@syncobj_timeline@transfer-timeline-point.html
* igt@sysfs_clients@recycle-many:
- shard-skl: NOTRUN -> [SKIP][96] ([fdo#109271] / [i915#2994]) +2 similar issues
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl3/igt@sysfs_clients@recycle-many.html
* igt@sysfs_clients@sema-25:
- shard-kbl: NOTRUN -> [SKIP][97] ([fdo#109271] / [i915#2994]) +2 similar issues
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@sysfs_clients@sema-25.html
#### Possible fixes ####
* igt@gem_eio@kms:
- shard-tglb: [FAIL][98] ([i915#232]) -> [PASS][99]
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-tglb3/igt@gem_eio@kms.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb7/igt@gem_eio@kms.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [FAIL][100] ([i915#2842]) -> [PASS][101]
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb7/igt@gem_exec_fair@basic-none-share@rcs0.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb7/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl: [FAIL][102] ([i915#2842]) -> [PASS][103] +1 similar issue
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@gem_exec_fair@basic-none-vip@rcs0.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@gem_exec_fair@basic-none-vip@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [FAIL][104] ([i915#2849]) -> [PASS][105]
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb8/igt@gem_exec_fair@basic-throttle@rcs0.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb5/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_exec_flush@basic-wb-pro-default:
- shard-snb: [SKIP][106] ([fdo#109271]) -> [PASS][107]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-snb6/igt@gem_exec_flush@basic-wb-pro-default.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-snb4/igt@gem_exec_flush@basic-wb-pro-default.html
* igt@gem_exec_schedule@wide@bcs0:
- shard-kbl: [INCOMPLETE][108] -> [PASS][109]
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@gem_exec_schedule@wide@bcs0.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@gem_exec_schedule@wide@bcs0.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][110] ([i915#644]) -> [PASS][111]
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk9/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][112] ([i915#454]) -> [PASS][113]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-tglb: [INCOMPLETE][114] ([i915#2411]) -> [PASS][115]
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-tglb8/igt@i915_pm_rpm@modeset-lpsp-stress.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-tglb5/igt@i915_pm_rpm@modeset-lpsp-stress.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-glk: [DMESG-WARN][116] ([i915#118]) -> [PASS][117] +1 similar issue
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk3/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk4/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
* igt@kms_big_fb@yf-tiled-16bpp-rotate-0:
- shard-iclb: [FAIL][118] ([i915#1888]) -> [PASS][119]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb5/igt@kms_big_fb@yf-tiled-16bpp-rotate-0.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb3/igt@kms_big_fb@yf-tiled-16bpp-rotate-0.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [FAIL][120] ([i915#2346] / [i915#533]) -> [PASS][121]
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled:
- shard-skl: [DMESG-WARN][122] ([i915#1982]) -> [PASS][123]
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl9/igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl9/igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled.html
* igt@kms_flip@busy-flip@c-edp1:
- shard-skl: [FAIL][124] -> [PASS][125]
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl2/igt@kms_flip@busy-flip@c-edp1.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl1/igt@kms_flip@busy-flip@c-edp1.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl: [FAIL][126] ([i915#2122]) -> [PASS][127] +2 similar issues
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
- shard-skl: [INCOMPLETE][128] ([i915#4939]) -> [PASS][129]
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl9/igt@kms_flip@flip-vs-suspend-interruptible@c-edp1.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl9/igt@kms_flip@flip-vs-suspend-interruptible@c-edp1.html
* igt@kms_flip@flip-vs-suspend@a-dp1:
- shard-apl: [DMESG-WARN][130] ([i915#180]) -> [PASS][131] +3 similar issues
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl2/igt@kms_flip@flip-vs-suspend@a-dp1.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl7/igt@kms_flip@flip-vs-suspend@a-dp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: [DMESG-WARN][132] ([i915#180]) -> [PASS][133] +4 similar issues
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl7/igt@kms_flip@flip-vs-suspend@c-dp1.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl4/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt:
- shard-glk: [FAIL][134] ([i915#1888] / [i915#2546]) -> [PASS][135]
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk5/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk5/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][136] ([fdo#108145] / [i915#265]) -> [PASS][137] +1 similar issue
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_primary_blt:
- shard-iclb: [SKIP][138] ([fdo#109441]) -> [PASS][139] +1 similar issue
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb6/igt@kms_psr@psr2_primary_blt.html
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb2/igt@kms_psr@psr2_primary_blt.html
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk: [FAIL][140] ([i915#1888] / [i915#65]) -> [PASS][141]
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk5/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk5/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html
* igt@perf@polling-small-buf:
- shard-skl: [FAIL][142] ([i915#1722]) -> [PASS][143]
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl2/igt@perf@polling-small-buf.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl5/igt@perf@polling-small-buf.html
#### Warnings ####
* igt@gem_exec_balancer@parallel:
- shard-iclb: [SKIP][144] ([i915#4525]) -> [DMESG-WARN][145] ([i915#5614])
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb5/igt@gem_exec_balancer@parallel.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb4/igt@gem_exec_balancer@parallel.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [DMESG-FAIL][146] ([i915#5614]) -> [SKIP][147] ([i915#4525])
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb1/igt@gem_exec_balancer@parallel-ordering.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb6/igt@gem_exec_balancer@parallel-ordering.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][148] ([i915#2842]) -> [FAIL][149] ([i915#2851])
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk7/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk5/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][150] ([i915#588]) -> [SKIP][151] ([i915#658])
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb7/igt@i915_pm_dc@dc3co-vpb-simulation.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-iclb: [SKIP][152] ([fdo#111068] / [i915#658]) -> [SKIP][153] ([i915#2920])
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-iclb3/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
* igt@nouveau_crc@pipe-d-source-outp-inactive:
- shard-skl: [SKIP][154] ([fdo#109271] / [i915#1888]) -> [SKIP][155] ([fdo#109271])
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-skl2/igt@nouveau_crc@pipe-d-source-outp-inactive.html
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-skl5/igt@nouveau_crc@pipe-d-source-outp-inactive.html
* igt@runner@aborted:
- shard-apl: ([FAIL][156], [FAIL][157], [FAIL][158], [FAIL][159], [FAIL][160], [FAIL][161], [FAIL][162]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][163], [FAIL][164], [FAIL][165], [FAIL][166], [FAIL][167], [FAIL][168], [FAIL][169], [FAIL][170]) ([fdo#109271] / [i915#180] / [i915#3002] / [i915#4312] / [i915#5257])
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl6/igt@runner@aborted.html
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl2/igt@runner@aborted.html
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl2/igt@runner@aborted.html
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl7/igt@runner@aborted.html
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl6/igt@runner@aborted.html
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl6/igt@runner@aborted.html
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-apl8/igt@runner@aborted.html
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl7/igt@runner@aborted.html
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl2/igt@runner@aborted.html
[165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl2/igt@runner@aborted.html
[166]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl7/igt@runner@aborted.html
[167]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl2/igt@runner@aborted.html
[168]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl8/igt@runner@aborted.html
[169]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl6/igt@runner@aborted.html
[170]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-apl2/igt@runner@aborted.html
- shard-kbl: ([FAIL][171], [FAIL][172], [FAIL][173], [FAIL][174], [FAIL][175], [FAIL][176], [FAIL][177], [FAIL][178], [FAIL][179], [FAIL][180], [FAIL][181], [FAIL][182]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][183], [FAIL][184], [FAIL][185], [FAIL][186], [FAIL][187], [FAIL][188], [FAIL][189], [FAIL][190], [FAIL][191], [FAIL][192], [FAIL][193]) ([fdo#109271] / [i915#3002] / [i915#4312] / [i915#5257] / [i915#716])
[171]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@runner@aborted.html
[172]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@runner@aborted.html
[173]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@runner@aborted.html
[174]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl1/igt@runner@aborted.html
[175]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl7/igt@runner@aborted.html
[176]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl7/igt@runner@aborted.html
[177]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl6/igt@runner@aborted.html
[178]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl3/igt@runner@aborted.html
[179]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl7/igt@runner@aborted.html
[180]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl3/igt@runner@aborted.html
[181]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl7/igt@runner@aborted.html
[182]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-kbl4/igt@runner@aborted.html
[183]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl6/igt@runner@aborted.html
[184]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl6/igt@runner@aborted.html
[185]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl3/igt@runner@aborted.html
[186]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@runner@aborted.html
[187]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@runner@aborted.html
[188]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@runner@aborted.html
[189]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl6/igt@runner@aborted.html
[190]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl1/igt@runner@aborted.html
[191]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl3/igt@runner@aborted.html
[192]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@runner@aborted.html
[193]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-kbl7/igt@runner@aborted.html
- shard-glk: ([FAIL][194], [FAIL][195], [FAIL][196], [FAIL][197]) ([i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][198], [FAIL][199], [FAIL][200], [FAIL][201], [FAIL][202], [FAIL][203]) ([i915#2722] / [i915#3002] / [i915#4312] / [i915#5257])
[194]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk5/igt@runner@aborted.html
[195]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk2/igt@runner@aborted.html
[196]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk5/igt@runner@aborted.html
[197]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11499/shard-glk4/igt@runner@aborted.html
[198]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk8/igt@runner@aborted.html
[199]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk7/igt@runner@aborted.html
[200]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk8/igt@runner@aborted.html
[201]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk7/igt@runner@aborted.html
[202]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk5/igt@runner@aborted.html
[203]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/shard-glk5/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
[fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302
[fdo#109303]: https://bugs.freedesktop.org/show_bug.cgi?id=109303
[fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307
[fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109312]: https://bugs.freedesktop.org/show_bug.cgi?id=109312
[fdo#109314]: https://bugs.freedesktop.org/show_bug.cgi?id=109314
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110254]: https://bugs.freedesktop.org/show_bug.cgi?id=110254
[fdo#110542]: https://bugs.freedesktop.org/show_bug.cgi?id=110542
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#110892]: https://bugs.freedesktop.org/show_bug.cgi?id=110892
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111314]: https://bugs.freedesktop.org/show_bug.cgi?id=111314
[fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111644]: https://bugs.freedesktop.org/show_bug.cgi?id=111644
[fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112022]: https://bugs.freedesktop.org/show_bug.cgi?id=112022
[fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054
[fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
[i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1149]: https://gitlab.freedesktop.org/drm/intel/issues/1149
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1257]: https://gitlab.freedesktop.org/drm/intel/issues/1257
[i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
[i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#1722]: https://gitlab.freedesktop.org/drm/intel/issues/1722
[i915#1769]: https://gitlab.freedesktop.org/drm/intel/issues/1769
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1902]: https://gitlab.freedesktop.org/drm/intel/issues/1902
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#232]: https://gitlab.freedesktop.org/drm/intel/issues/232
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2433]: https://gitlab.freedesktop.org/drm/intel/issues/2433
[i915#2434]: https://gitlab.freedesktop.org/drm/intel/issues/2434
[i915#2435]: https://gitlab.freedesktop.org/drm/intel/issues/2435
[i915#2436]: https://gitlab.freedesktop.org/drm/intel/issues/2436
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
[i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
[i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530
[i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
[i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
[i915#2705]: https://gitlab.freedesktop.org/drm/intel/issues/2705
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#280]: https://gitlab.freedesktop.org/drm/intel/issues/280
[i915#284]: https://gitlab.freedesktop.org/drm/intel/issues/284
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2846]: https://gitlab.freedesktop.org/drm/intel/issues/2846
[i915#2849]: https://gitlab.freedesktop.org/drm/intel/issues/2849
[i915#2851]: https://gitlab.freedesktop.org/drm/intel/issues/2851
[i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
[i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
[i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
[i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
[i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318
[i915#3319]: https://gitlab.freedesktop.org/drm/intel/issues/3319
[i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
[i915#3464]: https://gitlab.freedesktop.org/drm/intel/issues/3464
[i915#3467]: https://gitlab.freedesktop.org/drm/intel/issues/3467
[i915#3469]: https://gitlab.freedesktop.org/drm/intel/issues/3469
[i915#3528]: https://gitlab.freedesktop.org/drm/intel/issues/3528
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
[i915#3639]: https://gitlab.freedesktop.org/drm/intel/issues/3639
[i915#3648]: https://gitlab.freedesktop.org/drm/intel/issues/3648
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3701]: https://gitlab.freedesktop.org/drm/intel/issues/3701
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3734]: https://gitlab.freedesktop.org/drm/intel/issues/3734
[i915#3736]: https://gitlab.freedesktop.org/drm/intel/issues/3736
[i915#3742]: https://gitlab.freedesktop.org/drm/intel/issues/3742
[i915#3743]: https://gitlab.freedesktop.org/drm/intel/issues/3743
[i915#3777]: https://gitlab.freedesktop.org/drm/intel/issues/3777
[i915#3788]: https://gitlab.freedesktop.org/drm/intel/issues/3788
[i915#3804]: https://gitlab.freedesktop.org/drm/intel/issues/3804
[i915#3810]: https://gitlab.freedesktop.org/drm/intel/issues/3810
[i915#3825]: https://gitlab.freedesktop.org/drm/intel/issues/3825
[i915#3826]: https://gitlab.freedesktop.org/drm/intel/issues/3826
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
[i915#4016]: https://gitlab.freedesktop.org/drm/intel/issues/4016
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#404]: https://gitlab.freedesktop.org/drm/intel/issues/404
[i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#426]: https://gitlab.freedesktop.org/drm/intel/issues/426
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4278]: https://gitlab.freedesktop.org/drm/intel/issues/4278
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369
[i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4893]: https://gitlab.freedesktop.org/drm/intel/issues/4893
[i915#4911]: https://gitlab.freedesktop.org/drm/intel/issues/4911
[i915#4939]: https://gitlab.freedesktop.org/drm/intel/issues/4939
[i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991
[i915#5076]: https://gitlab.freedesktop.org/drm/intel/issues/5076
[i915#5080]: https://gitlab.freedesktop.org/drm/intel/issues/5080
[i915#5098]: https://gitlab.freedesktop.org/drm/intel/issues/5098
[i915#5115]: https://gitlab.freedesktop.org/drm/intel/issues/5115
[i915#5121]: https://gitlab.freedesktop.org/drm/intel/issues/5121
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5182]: https://gitlab.freedesktop.org/drm/intel/issues/5182
[i915#5213]: https://gitlab.freedesktop.org/drm/intel/issues/5213
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#5287]: https://gitlab.freedesktop.org/drm/intel/issues/5287
[i915#5288]: https://gitlab.freedesktop.org/drm/intel/issues/5288
[i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289
[i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439
[i915#5461]: https://gitlab.freedesktop.org/drm/intel/issues/5461
[i915#5519]: https://gitlab.freedesktop.org/drm/intel/issues/5519
[i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
[i915#5577]: https://gitlab.freedesktop.org/drm/intel/issues/5577
[i915#5614]: https://gitlab.freedesktop.org/drm/intel/issues/5614
[i915#5691]: https://gitlab.freedesktop.org/drm/intel/issues/5691
[i915#588]: https://gitlab.freedesktop.org/drm/intel/issues/588
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#65]: https://gitlab.freedesktop.org/drm/intel/issues/65
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
[i915#768]: https://gitlab.freedesktop.org/drm/intel/issues/768
Build changes
-------------
* Linux: CI_DRM_11499 -> Patchwork_102695v1
CI-20190529: 20190529
CI_DRM_11499: aad6e551495e0ff256adeae6106c8fa1bdb3faed @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6420: a3885810ccc0ce9e6552a20c910a0a322eca466c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_102695v1: aad6e551495e0ff256adeae6106c8fa1bdb3faed @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102695v1/index.html
[-- Attachment #2: Type: text/html, Size: 56611 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-14 14:22 ` [Intel-gfx] " Jani Nikula
(?)
@ 2022-04-20 5:13 ` Kalle Valo
-1 siblings, 0 replies; 31+ messages in thread
From: Kalle Valo @ 2022-04-20 5:13 UTC (permalink / raw)
To: Jani Nikula
Cc: Greg Kroah-Hartman, linux-kernel, intel-gfx, dri-devel,
Andrew Morton, Lucas De Marchi, linux-wireless, netdev
+ linux-wireless, netdev
Jani Nikula <jani.nikula@intel.com> writes:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many scenarios
>>> where a plain number is a clumsy interface for a module param.
>>>
>>> Thoughts?
>>
>> We should not be adding new module parameters anyway (they operate on
>> code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
>
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.
Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-20 5:13 ` Kalle Valo
0 siblings, 0 replies; 31+ messages in thread
From: Kalle Valo @ 2022-04-20 5:13 UTC (permalink / raw)
To: Jani Nikula
Cc: linux-wireless, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
linux-kernel, dri-devel, netdev, Andrew Morton
+ linux-wireless, netdev
Jani Nikula <jani.nikula@intel.com> writes:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many scenarios
>>> where a plain number is a clumsy interface for a module param.
>>>
>>> Thoughts?
>>
>> We should not be adding new module parameters anyway (they operate on
>> code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
>
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.
Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-20 5:13 ` Kalle Valo
0 siblings, 0 replies; 31+ messages in thread
From: Kalle Valo @ 2022-04-20 5:13 UTC (permalink / raw)
To: Jani Nikula
Cc: linux-wireless, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
linux-kernel, dri-devel, netdev, Andrew Morton
+ linux-wireless, netdev
Jani Nikula <jani.nikula@intel.com> writes:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many scenarios
>>> where a plain number is a clumsy interface for a module param.
>>>
>>> Thoughts?
>>
>> We should not be adding new module parameters anyway (they operate on
>> code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
>
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.
Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-20 5:13 ` Kalle Valo
(?)
@ 2022-04-20 6:38 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-20 6:38 UTC (permalink / raw)
To: Kalle Valo
Cc: Jani Nikula, linux-kernel, intel-gfx, dri-devel, Andrew Morton,
Lucas De Marchi, linux-wireless, netdev
On Wed, Apr 20, 2022 at 08:13:47AM +0300, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
> > On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >>> Hey, I've sent this before, ages ago, but haven't really followed
> >>> through with it. I still think it would be useful for many scenarios
> >>> where a plain number is a clumsy interface for a module param.
> >>>
> >>> Thoughts?
> >>
> >> We should not be adding new module parameters anyway (they operate on
> >> code, not data/devices), so what would this be used for?
> >
> > I think it's just easier to use names than random values, and this also
> > gives you range check on the input.
> >
> > I also keep telling people not to add new module parameters, but it's
> > not like they're going away anytime soon.
> >
> > If there's a solution to being able to pass device specific debug
> > parameters at probe time, I'm all ears. At least i915 has a bunch of
> > things which can't really be changed after probe, when debugfs for the
> > device is around. Module parameters aren't ideal, but debugfs doesn't
> > work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
Again, configfs? That should be what that subsystem was designed for...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-20 6:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-20 6:38 UTC (permalink / raw)
To: Kalle Valo
Cc: Jani Nikula, linux-wireless, intel-gfx, Lucas De Marchi,
linux-kernel, dri-devel, netdev, Andrew Morton
On Wed, Apr 20, 2022 at 08:13:47AM +0300, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
> > On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >>> Hey, I've sent this before, ages ago, but haven't really followed
> >>> through with it. I still think it would be useful for many scenarios
> >>> where a plain number is a clumsy interface for a module param.
> >>>
> >>> Thoughts?
> >>
> >> We should not be adding new module parameters anyway (they operate on
> >> code, not data/devices), so what would this be used for?
> >
> > I think it's just easier to use names than random values, and this also
> > gives you range check on the input.
> >
> > I also keep telling people not to add new module parameters, but it's
> > not like they're going away anytime soon.
> >
> > If there's a solution to being able to pass device specific debug
> > parameters at probe time, I'm all ears. At least i915 has a bunch of
> > things which can't really be changed after probe, when debugfs for the
> > device is around. Module parameters aren't ideal, but debugfs doesn't
> > work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
Again, configfs? That should be what that subsystem was designed for...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-20 6:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2022-04-20 6:38 UTC (permalink / raw)
To: Kalle Valo
Cc: Jani Nikula, linux-wireless, intel-gfx, Lucas De Marchi,
linux-kernel, dri-devel, netdev, Andrew Morton
On Wed, Apr 20, 2022 at 08:13:47AM +0300, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
> > On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >>> Hey, I've sent this before, ages ago, but haven't really followed
> >>> through with it. I still think it would be useful for many scenarios
> >>> where a plain number is a clumsy interface for a module param.
> >>>
> >>> Thoughts?
> >>
> >> We should not be adding new module parameters anyway (they operate on
> >> code, not data/devices), so what would this be used for?
> >
> > I think it's just easier to use names than random values, and this also
> > gives you range check on the input.
> >
> > I also keep telling people not to add new module parameters, but it's
> > not like they're going away anytime soon.
> >
> > If there's a solution to being able to pass device specific debug
> > parameters at probe time, I'm all ears. At least i915 has a bunch of
> > things which can't really be changed after probe, when debugfs for the
> > device is around. Module parameters aren't ideal, but debugfs doesn't
> > work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
Again, configfs? That should be what that subsystem was designed for...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-20 5:13 ` Kalle Valo
(?)
@ 2022-04-20 15:35 ` Ben Greear
-1 siblings, 0 replies; 31+ messages in thread
From: Ben Greear @ 2022-04-20 15:35 UTC (permalink / raw)
To: Kalle Valo, Jani Nikula
Cc: Greg Kroah-Hartman, linux-kernel, intel-gfx, dri-devel,
Andrew Morton, Lucas De Marchi, linux-wireless, netdev
On 4/19/22 10:13 PM, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
>> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>>> Hey, I've sent this before, ages ago, but haven't really followed
>>>> through with it. I still think it would be useful for many scenarios
>>>> where a plain number is a clumsy interface for a module param.
>>>>
>>>> Thoughts?
>>>
>>> We should not be adding new module parameters anyway (they operate on
>>> code, not data/devices), so what would this be used for?
>>
>> I think it's just easier to use names than random values, and this also
>> gives you range check on the input.
>>
>> I also keep telling people not to add new module parameters, but it's
>> not like they're going away anytime soon.
>>
>> If there's a solution to being able to pass device specific debug
>> parameters at probe time, I'm all ears. At least i915 has a bunch of
>> things which can't really be changed after probe, when debugfs for the
>> device is around. Module parameters aren't ideal, but debugfs doesn't
>> work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
I used a 'fwcfg' file that is loaded during ath10k initialization, from
same general location as the firmware. Name is with pci-id or other unique
identifier like board files sometimes are named, and you get per radio
configuration at device load time. I'm sure I posted a patch on this
some years ago, but I can point you to my current tree if you prefer.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-20 15:35 ` Ben Greear
0 siblings, 0 replies; 31+ messages in thread
From: Ben Greear @ 2022-04-20 15:35 UTC (permalink / raw)
To: Kalle Valo, Jani Nikula
Cc: linux-wireless, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
linux-kernel, dri-devel, netdev, Andrew Morton
On 4/19/22 10:13 PM, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
>> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>>> Hey, I've sent this before, ages ago, but haven't really followed
>>>> through with it. I still think it would be useful for many scenarios
>>>> where a plain number is a clumsy interface for a module param.
>>>>
>>>> Thoughts?
>>>
>>> We should not be adding new module parameters anyway (they operate on
>>> code, not data/devices), so what would this be used for?
>>
>> I think it's just easier to use names than random values, and this also
>> gives you range check on the input.
>>
>> I also keep telling people not to add new module parameters, but it's
>> not like they're going away anytime soon.
>>
>> If there's a solution to being able to pass device specific debug
>> parameters at probe time, I'm all ears. At least i915 has a bunch of
>> things which can't really be changed after probe, when debugfs for the
>> device is around. Module parameters aren't ideal, but debugfs doesn't
>> work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
I used a 'fwcfg' file that is loaded during ath10k initialization, from
same general location as the firmware. Name is with pci-id or other unique
identifier like board files sometimes are named, and you get per radio
configuration at device load time. I'm sure I posted a patch on this
some years ago, but I can point you to my current tree if you prefer.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-20 15:35 ` Ben Greear
0 siblings, 0 replies; 31+ messages in thread
From: Ben Greear @ 2022-04-20 15:35 UTC (permalink / raw)
To: Kalle Valo, Jani Nikula
Cc: linux-wireless, Greg Kroah-Hartman, intel-gfx, Lucas De Marchi,
linux-kernel, dri-devel, netdev, Andrew Morton
On 4/19/22 10:13 PM, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
>> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>>> Hey, I've sent this before, ages ago, but haven't really followed
>>>> through with it. I still think it would be useful for many scenarios
>>>> where a plain number is a clumsy interface for a module param.
>>>>
>>>> Thoughts?
>>>
>>> We should not be adding new module parameters anyway (they operate on
>>> code, not data/devices), so what would this be used for?
>>
>> I think it's just easier to use names than random values, and this also
>> gives you range check on the input.
>>
>> I also keep telling people not to add new module parameters, but it's
>> not like they're going away anytime soon.
>>
>> If there's a solution to being able to pass device specific debug
>> parameters at probe time, I'm all ears. At least i915 has a bunch of
>> things which can't really be changed after probe, when debugfs for the
>> device is around. Module parameters aren't ideal, but debugfs doesn't
>> work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
I used a 'fwcfg' file that is loaded during ath10k initialization, from
same general location as the firmware. Name is with pci-id or other unique
identifier like board files sometimes are named, and you get per radio
configuration at device load time. I'm sure I posted a patch on this
some years ago, but I can point you to my current tree if you prefer.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
2022-04-20 5:13 ` Kalle Valo
(?)
@ 2022-04-22 20:44 ` Jakub Kicinski
-1 siblings, 0 replies; 31+ messages in thread
From: Jakub Kicinski @ 2022-04-22 20:44 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Jani Nikula, Greg Kroah-Hartman, intel-gfx,
Lucas De Marchi, linux-kernel, dri-devel, netdev, Andrew Morton
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote:
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
In netdev we have devlink which is used for all sort of device
configuration. devlink-resource sounds like what you need,
but it'd have to be extended to support configuration which requires
reload/re-probe. Currently only devlink-params support that but params
were a mistake so don't use that.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/1] add support for enum module parameters
@ 2022-04-22 20:44 ` Jakub Kicinski
0 siblings, 0 replies; 31+ messages in thread
From: Jakub Kicinski @ 2022-04-22 20:44 UTC (permalink / raw)
To: Kalle Valo
Cc: Jani Nikula, Greg Kroah-Hartman, linux-kernel, intel-gfx,
dri-devel, Andrew Morton, Lucas De Marchi, linux-wireless,
netdev
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote:
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
In netdev we have devlink which is used for all sort of device
configuration. devlink-resource sounds like what you need,
but it'd have to be extended to support configuration which requires
reload/re-probe. Currently only devlink-params support that but params
were a mistake so don't use that.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
@ 2022-04-22 20:44 ` Jakub Kicinski
0 siblings, 0 replies; 31+ messages in thread
From: Jakub Kicinski @ 2022-04-22 20:44 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Jani Nikula, Greg Kroah-Hartman, intel-gfx,
Lucas De Marchi, linux-kernel, dri-devel, netdev, Andrew Morton
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote:
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
In netdev we have devlink which is used for all sort of device
configuration. devlink-resource sounds like what you need,
but it'd have to be extended to support configuration which requires
reload/re-probe. Currently only devlink-params support that but params
were a mistake so don't use that.
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2022-04-25 13:04 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-14 12:30 [PATCH 0/1] add support for enum module parameters Jani Nikula
2022-04-14 12:30 ` [Intel-gfx] " Jani Nikula
2022-04-14 12:30 ` Jani Nikula
2022-04-14 12:30 ` [PATCH 1/1] module: add enum module parameter type to map names to values Jani Nikula
2022-04-14 12:30 ` [Intel-gfx] " Jani Nikula
2022-04-14 12:30 ` Jani Nikula
2022-04-14 13:19 ` [PATCH 0/1] add support for enum module parameters Greg Kroah-Hartman
2022-04-14 13:19 ` Greg Kroah-Hartman
2022-04-14 13:19 ` [Intel-gfx] " Greg Kroah-Hartman
2022-04-14 14:22 ` Jani Nikula
2022-04-14 14:22 ` Jani Nikula
2022-04-14 14:22 ` [Intel-gfx] " Jani Nikula
2022-04-14 14:29 ` Greg Kroah-Hartman
2022-04-14 14:29 ` Greg Kroah-Hartman
2022-04-14 14:29 ` [Intel-gfx] " Greg Kroah-Hartman
2022-04-20 5:13 ` Kalle Valo
2022-04-20 5:13 ` [Intel-gfx] " Kalle Valo
2022-04-20 5:13 ` Kalle Valo
2022-04-20 6:38 ` Greg Kroah-Hartman
2022-04-20 6:38 ` [Intel-gfx] " Greg Kroah-Hartman
2022-04-20 6:38 ` Greg Kroah-Hartman
2022-04-20 15:35 ` Ben Greear
2022-04-20 15:35 ` [Intel-gfx] " Ben Greear
2022-04-20 15:35 ` Ben Greear
2022-04-22 20:44 ` Jakub Kicinski
2022-04-22 20:44 ` [Intel-gfx] " Jakub Kicinski
2022-04-22 20:44 ` Jakub Kicinski
2022-04-14 13:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-04-14 13:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-14 14:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-14 16:49 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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.