[PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

We have already few similar implementation and a lot of code that can benefit
of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
 drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
 include/linux/string.h                               |  5 +++++
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
  *
  */
 
+#include <linux/string.h>
 #include <linux/uaccess.h>
 
 #include <drm/drm_debugfs.h>
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
 	uint32_t param1;
 };
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
  *
  * Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
 
 #include <linux/list.h>
 #include <linux/overflow.h>
+#include <linux/string.h>
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/workqueue.h>
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 static inline const char *onoff(bool v)
 {
 	return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
 
 #include <linux/seq_file.h>
 #include <linux/debugfs.h>
+#include <linux/string.h>
 #include <linux/string_helpers.h>
 #include <linux/sort.h>
 #include <linux/ctype.h>
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
 /* RSS Configuration.
  */
 
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
-	static const char *yes = "yes";
-	static const char *no = "no";
-
-	return x ? yes : no;
-}
-
 static int rss_config_show(struct seq_file *seq, void *v)
 {
 	struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
 	return strncmp(str, prefix, len) == 0 ? len : 0;
 }
 
+static inline const char *yesno(bool yes)
+{
+	return yes ? "yes" : "no";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

[PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

We have already few similar implementation and a lot of code that can benefit
of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
 drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
 include/linux/string.h                               |  5 +++++
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
  *
  */
 
+#include <linux/string.h>
 #include <linux/uaccess.h>
 
 #include <drm/drm_debugfs.h>
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
 	uint32_t param1;
 };
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
  *
  * Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
 
 #include <linux/list.h>
 #include <linux/overflow.h>
+#include <linux/string.h>
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/workqueue.h>
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 static inline const char *onoff(bool v)
 {
 	return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
 
 #include <linux/seq_file.h>
 #include <linux/debugfs.h>
+#include <linux/string.h>
 #include <linux/string_helpers.h>
 #include <linux/sort.h>
 #include <linux/ctype.h>
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
 /* RSS Configuration.
  */
 
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
-	static const char *yes = "yes";
-	static const char *no = "no";
-
-	return x ? yes : no;
-}
-
 static int rss_config_show(struct seq_file *seq, void *v)
 {
 	struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
 	return strncmp(str, prefix, len) == 0 ? len : 0;
 }
 
+static inline const char *yesno(bool yes)
+{
+	return yes ? "yes" : "no";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

We have already few similar implementation and a lot of code that can benefit
of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
 drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
 include/linux/string.h                               |  5 +++++
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
  *
  */
 
+#include <linux/string.h>
 #include <linux/uaccess.h>
 
 #include <drm/drm_debugfs.h>
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
 	uint32_t param1;
 };
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
  *
  * Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
 
 #include <linux/list.h>
 #include <linux/overflow.h>
+#include <linux/string.h>
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/workqueue.h>
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 static inline const char *onoff(bool v)
 {
 	return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
 
 #include <linux/seq_file.h>
 #include <linux/debugfs.h>
+#include <linux/string.h>
 #include <linux/string_helpers.h>
 #include <linux/sort.h>
 #include <linux/ctype.h>
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
 /* RSS Configuration.
  */
 
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
-	static const char *yes = "yes";
-	static const char *no = "no";
-
-	return x ? yes : no;
-}
-
 static int rss_config_show(struct seq_file *seq, void *v)
 {
 	struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
 	return strncmp(str, prefix, len) == 0 ? len : 0;
 }
 
+static inline const char *yesno(bool yes)
+{
+	return yes ? "yes" : "no";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

We have already few similar implementation and a lot of code that can benefit
of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
 drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
 include/linux/string.h                               |  5 +++++
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
  *
  */
 
+#include <linux/string.h>
 #include <linux/uaccess.h>
 
 #include <drm/drm_debugfs.h>
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
 	uint32_t param1;
 };
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
  *
  * Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
 
 #include <linux/list.h>
 #include <linux/overflow.h>
+#include <linux/string.h>
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/workqueue.h>
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *yesno(bool v)
-{
-	return v ? "yes" : "no";
-}
-
 static inline const char *onoff(bool v)
 {
 	return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
 
 #include <linux/seq_file.h>
 #include <linux/debugfs.h>
+#include <linux/string.h>
 #include <linux/string_helpers.h>
 #include <linux/sort.h>
 #include <linux/ctype.h>
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
 /* RSS Configuration.
  */
 
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
-	static const char *yes = "yes";
-	static const char *no = "no";
-
-	return x ? yes : no;
-}
-
 static int rss_config_show(struct seq_file *seq, void *v)
 {
 	struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
 	return strncmp(str, prefix, len) == 0 ? len : 0;
 }
 
+static inline const char *yesno(bool yes)
+{
+	return yes ? "yes" : "no";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 2/3] string: Move onoff() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index e6da5a951132..d2ac357896d4 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *onoff(bool v)
-{
-	return v ? "on" : "off";
-}
-
 static inline const char *enableddisabled(bool v)
 {
 	return v ? "enabled" : "disabled";
diff --git a/include/linux/string.h b/include/linux/string.h
index fd946a5e18c8..2a0589e945d9 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -313,4 +313,9 @@ static inline const char *yesno(bool yes)
 	return yes ? "yes" : "no";
 }
 
+static inline const char *onoff(bool on)
+{
+	return on ? "on" : "off";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

[PATCH v1 2/3] string: Move onoff() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index e6da5a951132..d2ac357896d4 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *onoff(bool v)
-{
-	return v ? "on" : "off";
-}
-
 static inline const char *enableddisabled(bool v)
 {
 	return v ? "enabled" : "disabled";
diff --git a/include/linux/string.h b/include/linux/string.h
index fd946a5e18c8..2a0589e945d9 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -313,4 +313,9 @@ static inline const char *yesno(bool yes)
 	return yes ? "yes" : "no";
 }
 
+static inline const char *onoff(bool on)
+{
+	return on ? "on" : "off";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Intel-gfx] [PATCH v1 2/3] string: Move onoff() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index e6da5a951132..d2ac357896d4 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *onoff(bool v)
-{
-	return v ? "on" : "off";
-}
-
 static inline const char *enableddisabled(bool v)
 {
 	return v ? "enabled" : "disabled";
diff --git a/include/linux/string.h b/include/linux/string.h
index fd946a5e18c8..2a0589e945d9 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -313,4 +313,9 @@ static inline const char *yesno(bool yes)
 	return yes ? "yes" : "no";
 }
 
+static inline const char *onoff(bool on)
+{
+	return on ? "on" : "off";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v1 2/3] string: Move onoff() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index e6da5a951132..d2ac357896d4 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *onoff(bool v)
-{
-	return v ? "on" : "off";
-}
-
 static inline const char *enableddisabled(bool v)
 {
 	return v ? "enabled" : "disabled";
diff --git a/include/linux/string.h b/include/linux/string.h
index fd946a5e18c8..2a0589e945d9 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -313,4 +313,9 @@ static inline const char *yesno(bool yes)
 	return yes ? "yes" : "no";
 }
 
+static inline const char *onoff(bool on)
+{
+	return on ? "on" : "off";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 3/3] string: Move enableddisabled() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index d2ac357896d4..b05d72b4dd93 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *enableddisabled(bool v)
-{
-	return v ? "enabled" : "disabled";
-}
-
 void add_taint_for_CI(struct drm_i915_private *i915, unsigned int taint);
 static inline void __add_taint_for_CI(unsigned int taint)
 {
diff --git a/include/linux/string.h b/include/linux/string.h
index 2a0589e945d9..25f055aa4c31 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -318,4 +318,9 @@ static inline const char *onoff(bool on)
 	return on ? "on" : "off";
 }
 
+static inline const char *enableddisabled(bool enabled)
+{
+	return enabled ? "enabled" : "disabled";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

[PATCH v1 3/3] string: Move enableddisabled() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index d2ac357896d4..b05d72b4dd93 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *enableddisabled(bool v)
-{
-	return v ? "enabled" : "disabled";
-}
-
 void add_taint_for_CI(struct drm_i915_private *i915, unsigned int taint);
 static inline void __add_taint_for_CI(unsigned int taint)
 {
diff --git a/include/linux/string.h b/include/linux/string.h
index 2a0589e945d9..25f055aa4c31 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -318,4 +318,9 @@ static inline const char *onoff(bool on)
 	return on ? "on" : "off";
 }
 
+static inline const char *enableddisabled(bool enabled)
+{
+	return enabled ? "enabled" : "disabled";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Intel-gfx] [PATCH v1 3/3] string: Move enableddisabled() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index d2ac357896d4..b05d72b4dd93 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *enableddisabled(bool v)
-{
-	return v ? "enabled" : "disabled";
-}
-
 void add_taint_for_CI(struct drm_i915_private *i915, unsigned int taint);
 static inline void __add_taint_for_CI(unsigned int taint)
 {
diff --git a/include/linux/string.h b/include/linux/string.h
index 2a0589e945d9..25f055aa4c31 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -318,4 +318,9 @@ static inline const char *onoff(bool on)
 	return on ? "on" : "off";
 }
 
+static inline const char *enableddisabled(bool enabled)
+{
+	return enabled ? "enabled" : "disabled";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v1 3/3] string: Move enableddisabled() helper under string.h hood

[Andy Shevchenko]

We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 5 -----
 include/linux/string.h            | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index d2ac357896d4..b05d72b4dd93 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -409,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
 #define MBps(x) KBps(1000 * (x))
 #define GBps(x) ((u64)1000 * MBps((x)))
 
-static inline const char *enableddisabled(bool v)
-{
-	return v ? "enabled" : "disabled";
-}
-
 void add_taint_for_CI(struct drm_i915_private *i915, unsigned int taint);
 static inline void __add_taint_for_CI(unsigned int taint)
 {
diff --git a/include/linux/string.h b/include/linux/string.h
index 2a0589e945d9..25f055aa4c31 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -318,4 +318,9 @@ static inline const char *onoff(bool on)
 	return on ? "on" : "off";
 }
 
+static inline const char *enableddisabled(bool enabled)
+{
+	return enabled ? "enabled" : "disabled";
+}
+
 #endif /* _LINUX_STRING_H_ */
-- 
2.30.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Christian König]

Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Looks like a good idea to me, feel free to add an Acked-by: Christian 
König <christian.koenig@amd.com> to the series.

But looking at the use cases for this, wouldn't it make more sense to 
teach kprintf some new format modifier for this?

Christian.

> ---
>   .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>   drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>   include/linux/string.h                               |  5 +++++
>   4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>    *
>    */
>   
> +#include <linux/string.h>
>   #include <linux/uaccess.h>
>   
>   #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>   	uint32_t param1;
>   };
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>    *
>    * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>   
>   #include <linux/list.h>
>   #include <linux/overflow.h>
> +#include <linux/string.h>
>   #include <linux/sched.h>
>   #include <linux/types.h>
>   #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>   #define MBps(x) KBps(1000 * (x))
>   #define GBps(x) ((u64)1000 * MBps((x)))
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   static inline const char *onoff(bool v)
>   {
>   	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/seq_file.h>
>   #include <linux/debugfs.h>
> +#include <linux/string.h>
>   #include <linux/string_helpers.h>
>   #include <linux/sort.h>
>   #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>   /* RSS Configuration.
>    */
>   
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>   static int rss_config_show(struct seq_file *seq, void *v)
>   {
>   	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>   	return strncmp(str, prefix, len) == 0 ? len : 0;
>   }
>   
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>   #endif /* _LINUX_STRING_H_ */

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Christian König]

Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Looks like a good idea to me, feel free to add an Acked-by: Christian 
König <christian.koenig@amd.com> to the series.

But looking at the use cases for this, wouldn't it make more sense to 
teach kprintf some new format modifier for this?

Christian.

> ---
>   .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>   drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>   include/linux/string.h                               |  5 +++++
>   4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>    *
>    */
>   
> +#include <linux/string.h>
>   #include <linux/uaccess.h>
>   
>   #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>   	uint32_t param1;
>   };
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>    *
>    * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>   
>   #include <linux/list.h>
>   #include <linux/overflow.h>
> +#include <linux/string.h>
>   #include <linux/sched.h>
>   #include <linux/types.h>
>   #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>   #define MBps(x) KBps(1000 * (x))
>   #define GBps(x) ((u64)1000 * MBps((x)))
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   static inline const char *onoff(bool v)
>   {
>   	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/seq_file.h>
>   #include <linux/debugfs.h>
> +#include <linux/string.h>
>   #include <linux/string_helpers.h>
>   #include <linux/sort.h>
>   #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>   /* RSS Configuration.
>    */
>   
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>   static int rss_config_show(struct seq_file *seq, void *v)
>   {
>   	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>   	return strncmp(str, prefix, len) == 0 ? len : 0;
>   }
>   
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>   #endif /* _LINUX_STRING_H_ */

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Christian König]

Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Looks like a good idea to me, feel free to add an Acked-by: Christian 
König <christian.koenig@amd.com> to the series.

But looking at the use cases for this, wouldn't it make more sense to 
teach kprintf some new format modifier for this?

Christian.

> ---
>   .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>   drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>   include/linux/string.h                               |  5 +++++
>   4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>    *
>    */
>   
> +#include <linux/string.h>
>   #include <linux/uaccess.h>
>   
>   #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>   	uint32_t param1;
>   };
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>    *
>    * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>   
>   #include <linux/list.h>
>   #include <linux/overflow.h>
> +#include <linux/string.h>
>   #include <linux/sched.h>
>   #include <linux/types.h>
>   #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>   #define MBps(x) KBps(1000 * (x))
>   #define GBps(x) ((u64)1000 * MBps((x)))
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   static inline const char *onoff(bool v)
>   {
>   	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/seq_file.h>
>   #include <linux/debugfs.h>
> +#include <linux/string.h>
>   #include <linux/string_helpers.h>
>   #include <linux/sort.h>
>   #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>   /* RSS Configuration.
>    */
>   
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>   static int rss_config_show(struct seq_file *seq, void *v)
>   {
>   	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>   	return strncmp(str, prefix, len) == 0 ? len : 0;
>   }
>   
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>   #endif /* _LINUX_STRING_H_ */

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Christian König]

Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Looks like a good idea to me, feel free to add an Acked-by: Christian 
König <christian.koenig@amd.com> to the series.

But looking at the use cases for this, wouldn't it make more sense to 
teach kprintf some new format modifier for this?

Christian.

> ---
>   .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>   drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>   include/linux/string.h                               |  5 +++++
>   4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>    *
>    */
>   
> +#include <linux/string.h>
>   #include <linux/uaccess.h>
>   
>   #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>   	uint32_t param1;
>   };
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>    *
>    * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>   
>   #include <linux/list.h>
>   #include <linux/overflow.h>
> +#include <linux/string.h>
>   #include <linux/sched.h>
>   #include <linux/types.h>
>   #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>   #define MBps(x) KBps(1000 * (x))
>   #define GBps(x) ((u64)1000 * MBps((x)))
>   
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>   static inline const char *onoff(bool v)
>   {
>   	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>   
>   #include <linux/seq_file.h>
>   #include <linux/debugfs.h>
> +#include <linux/string.h>
>   #include <linux/string_helpers.h>
>   #include <linux/sort.h>
>   #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>   /* RSS Configuration.
>    */
>   
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>   static int rss_config_show(struct seq_file *seq, void *v)
>   {
>   	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>   	return strncmp(str, prefix, len) == 0 ? len : 0;
>   }
>   
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>   #endif /* _LINUX_STRING_H_ */

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

+Cc: Sakari and printk people

On Mon, Feb 15, 2021 at 4:28 PM Christian König
<christian.koenig@amd.com> wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Looks like a good idea to me, feel free to add an Acked-by: Christian
> König <christian.koenig@amd.com> to the series.

Thanks.

> But looking at the use cases for this, wouldn't it make more sense to
> teach kprintf some new format modifier for this?

As a next step? IIRC Sakari has at some point the series converted
yesno and Co. to something which I don't remember the details of.

Guys, what do you think?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

+Cc: Sakari and printk people

On Mon, Feb 15, 2021 at 4:28 PM Christian König
<christian.koenig@amd.com> wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Looks like a good idea to me, feel free to add an Acked-by: Christian
> König <christian.koenig@amd.com> to the series.

Thanks.

> But looking at the use cases for this, wouldn't it make more sense to
> teach kprintf some new format modifier for this?

As a next step? IIRC Sakari has at some point the series converted
yesno and Co. to something which I don't remember the details of.

Guys, what do you think?

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

+Cc: Sakari and printk people

On Mon, Feb 15, 2021 at 4:28 PM Christian König
<christian.koenig@amd.com> wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Looks like a good idea to me, feel free to add an Acked-by: Christian
> König <christian.koenig@amd.com> to the series.

Thanks.

> But looking at the use cases for this, wouldn't it make more sense to
> teach kprintf some new format modifier for this?

As a next step? IIRC Sakari has at some point the series converted
yesno and Co. to something which I don't remember the details of.

Guys, what do you think?

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

+Cc: Sakari and printk people

On Mon, Feb 15, 2021 at 4:28 PM Christian König
<christian.koenig@amd.com> wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Looks like a good idea to me, feel free to add an Acked-by: Christian
> König <christian.koenig@amd.com> to the series.

Thanks.

> But looking at the use cases for this, wouldn't it make more sense to
> teach kprintf some new format modifier for this?

As a next step? IIRC Sakari has at some point the series converted
yesno and Co. to something which I don't remember the details of.

Guys, what do you think?

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Petr Mladek]

On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
> +Cc: Sakari and printk people
> 
> On Mon, Feb 15, 2021 at 4:28 PM Christian König
> <christian.koenig@amd.com> wrote:
> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > > We have already few similar implementation and a lot of code that can benefit
> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > Looks like a good idea to me, feel free to add an Acked-by: Christian
> > König <christian.koenig@amd.com> to the series.
> 
> Thanks.
> 
> > But looking at the use cases for this, wouldn't it make more sense to
> > teach kprintf some new format modifier for this?
> 
> As a next step? IIRC Sakari has at some point the series converted
> yesno and Co. to something which I don't remember the details of.
> 
> Guys, what do you think?

Honestly, I think that yesno() is much easier to understand than %py.
And %py[DOY] looks really scary. It has been suggested at
https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t

Yes, enabledisable() is hard to parse but it is still self-explaining
and can be found easily by cscope. On the contrary, %pyD will likely
print some python code and it is not clear if it would be compatible
with v3. I am just kidding but you get the picture.

Best Regards,
Petr

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Petr Mladek]

On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
> +Cc: Sakari and printk people
> 
> On Mon, Feb 15, 2021 at 4:28 PM Christian König
> <christian.koenig@amd.com> wrote:
> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > > We have already few similar implementation and a lot of code that can benefit
> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > Looks like a good idea to me, feel free to add an Acked-by: Christian
> > König <christian.koenig@amd.com> to the series.
> 
> Thanks.
> 
> > But looking at the use cases for this, wouldn't it make more sense to
> > teach kprintf some new format modifier for this?
> 
> As a next step? IIRC Sakari has at some point the series converted
> yesno and Co. to something which I don't remember the details of.
> 
> Guys, what do you think?

Honestly, I think that yesno() is much easier to understand than %py.
And %py[DOY] looks really scary. It has been suggested at
https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t

Yes, enabledisable() is hard to parse but it is still self-explaining
and can be found easily by cscope. On the contrary, %pyD will likely
print some python code and it is not clear if it would be compatible
with v3. I am just kidding but you get the picture.

Best Regards,
Petr
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Petr Mladek]

On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
> +Cc: Sakari and printk people
> 
> On Mon, Feb 15, 2021 at 4:28 PM Christian König
> <christian.koenig@amd.com> wrote:
> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > > We have already few similar implementation and a lot of code that can benefit
> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > Looks like a good idea to me, feel free to add an Acked-by: Christian
> > König <christian.koenig@amd.com> to the series.
> 
> Thanks.
> 
> > But looking at the use cases for this, wouldn't it make more sense to
> > teach kprintf some new format modifier for this?
> 
> As a next step? IIRC Sakari has at some point the series converted
> yesno and Co. to something which I don't remember the details of.
> 
> Guys, what do you think?

Honestly, I think that yesno() is much easier to understand than %py.
And %py[DOY] looks really scary. It has been suggested at
https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t

Yes, enabledisable() is hard to parse but it is still self-explaining
and can be found easily by cscope. On the contrary, %pyD will likely
print some python code and it is not clear if it would be compatible
with v3. I am just kidding but you get the picture.

Best Regards,
Petr
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Petr Mladek]

On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
> +Cc: Sakari and printk people
> 
> On Mon, Feb 15, 2021 at 4:28 PM Christian König
> <christian.koenig@amd.com> wrote:
> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > > We have already few similar implementation and a lot of code that can benefit
> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > Looks like a good idea to me, feel free to add an Acked-by: Christian
> > König <christian.koenig@amd.com> to the series.
> 
> Thanks.
> 
> > But looking at the use cases for this, wouldn't it make more sense to
> > teach kprintf some new format modifier for this?
> 
> As a next step? IIRC Sakari has at some point the series converted
> yesno and Co. to something which I don't remember the details of.
> 
> Guys, what do you think?

Honestly, I think that yesno() is much easier to understand than %py.
And %py[DOY] looks really scary. It has been suggested at
https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t

Yes, enabledisable() is hard to parse but it is still self-explaining
and can be found easily by cscope. On the contrary, %pyD will likely
print some python code and it is not clear if it would be compatible
with v3. I am just kidding but you get the picture.

Best Regards,
Petr
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Wed, 17 Feb 2021, Petr Mladek <pmladek@suse.com> wrote:
> On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
>> +Cc: Sakari and printk people
>> 
>> On Mon, Feb 15, 2021 at 4:28 PM Christian König
>> <christian.koenig@amd.com> wrote:
>> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
>> > > We have already few similar implementation and a lot of code that can benefit
>> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> > >
>> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> >
>> > Looks like a good idea to me, feel free to add an Acked-by: Christian
>> > König <christian.koenig@amd.com> to the series.
>> 
>> Thanks.
>> 
>> > But looking at the use cases for this, wouldn't it make more sense to
>> > teach kprintf some new format modifier for this?
>> 
>> As a next step? IIRC Sakari has at some point the series converted
>> yesno and Co. to something which I don't remember the details of.
>> 
>> Guys, what do you think?
>
> Honestly, I think that yesno() is much easier to understand than %py.
> And %py[DOY] looks really scary. It has been suggested at
> https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t
>
> Yes, enabledisable() is hard to parse but it is still self-explaining
> and can be found easily by cscope. On the contrary, %pyD will likely
> print some python code and it is not clear if it would be compatible
> with v3. I am just kidding but you get the picture.

Personally I prefer %s and the functions.

I think the format specifiers have become unwieldy. I don't remember any
of the kernel specific ones by heart, I always look them up or just
cargo-cult. I think the fourcc format specifiers are a nice cleanup, but
I don't remember them either. I'd like something like %foo{yesno} where,
if you remember the %foo part, you could actually also remember the
rest.

But really if you get *any* version accepted, I'm not going to argue
against it, and you can disregard this as meaningless bikeshedding.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Wed, 17 Feb 2021, Petr Mladek <pmladek@suse.com> wrote:
> On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
>> +Cc: Sakari and printk people
>> 
>> On Mon, Feb 15, 2021 at 4:28 PM Christian König
>> <christian.koenig@amd.com> wrote:
>> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
>> > > We have already few similar implementation and a lot of code that can benefit
>> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> > >
>> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> >
>> > Looks like a good idea to me, feel free to add an Acked-by: Christian
>> > König <christian.koenig@amd.com> to the series.
>> 
>> Thanks.
>> 
>> > But looking at the use cases for this, wouldn't it make more sense to
>> > teach kprintf some new format modifier for this?
>> 
>> As a next step? IIRC Sakari has at some point the series converted
>> yesno and Co. to something which I don't remember the details of.
>> 
>> Guys, what do you think?
>
> Honestly, I think that yesno() is much easier to understand than %py.
> And %py[DOY] looks really scary. It has been suggested at
> https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t
>
> Yes, enabledisable() is hard to parse but it is still self-explaining
> and can be found easily by cscope. On the contrary, %pyD will likely
> print some python code and it is not clear if it would be compatible
> with v3. I am just kidding but you get the picture.

Personally I prefer %s and the functions.

I think the format specifiers have become unwieldy. I don't remember any
of the kernel specific ones by heart, I always look them up or just
cargo-cult. I think the fourcc format specifiers are a nice cleanup, but
I don't remember them either. I'd like something like %foo{yesno} where,
if you remember the %foo part, you could actually also remember the
rest.

But really if you get *any* version accepted, I'm not going to argue
against it, and you can disregard this as meaningless bikeshedding.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Wed, 17 Feb 2021, Petr Mladek <pmladek@suse.com> wrote:
> On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
>> +Cc: Sakari and printk people
>> 
>> On Mon, Feb 15, 2021 at 4:28 PM Christian König
>> <christian.koenig@amd.com> wrote:
>> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
>> > > We have already few similar implementation and a lot of code that can benefit
>> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> > >
>> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> >
>> > Looks like a good idea to me, feel free to add an Acked-by: Christian
>> > König <christian.koenig@amd.com> to the series.
>> 
>> Thanks.
>> 
>> > But looking at the use cases for this, wouldn't it make more sense to
>> > teach kprintf some new format modifier for this?
>> 
>> As a next step? IIRC Sakari has at some point the series converted
>> yesno and Co. to something which I don't remember the details of.
>> 
>> Guys, what do you think?
>
> Honestly, I think that yesno() is much easier to understand than %py.
> And %py[DOY] looks really scary. It has been suggested at
> https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t
>
> Yes, enabledisable() is hard to parse but it is still self-explaining
> and can be found easily by cscope. On the contrary, %pyD will likely
> print some python code and it is not clear if it would be compatible
> with v3. I am just kidding but you get the picture.

Personally I prefer %s and the functions.

I think the format specifiers have become unwieldy. I don't remember any
of the kernel specific ones by heart, I always look them up or just
cargo-cult. I think the fourcc format specifiers are a nice cleanup, but
I don't remember them either. I'd like something like %foo{yesno} where,
if you remember the %foo part, you could actually also remember the
rest.

But really if you get *any* version accepted, I'm not going to argue
against it, and you can disregard this as meaningless bikeshedding.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Wed, 17 Feb 2021, Petr Mladek <pmladek@suse.com> wrote:
> On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
>> +Cc: Sakari and printk people
>> 
>> On Mon, Feb 15, 2021 at 4:28 PM Christian König
>> <christian.koenig@amd.com> wrote:
>> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
>> > > We have already few similar implementation and a lot of code that can benefit
>> > > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> > >
>> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> >
>> > Looks like a good idea to me, feel free to add an Acked-by: Christian
>> > König <christian.koenig@amd.com> to the series.
>> 
>> Thanks.
>> 
>> > But looking at the use cases for this, wouldn't it make more sense to
>> > teach kprintf some new format modifier for this?
>> 
>> As a next step? IIRC Sakari has at some point the series converted
>> yesno and Co. to something which I don't remember the details of.
>> 
>> Guys, what do you think?
>
> Honestly, I think that yesno() is much easier to understand than %py.
> And %py[DOY] looks really scary. It has been suggested at
> https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t
>
> Yes, enabledisable() is hard to parse but it is still self-explaining
> and can be found easily by cscope. On the contrary, %pyD will likely
> print some python code and it is not clear if it would be compatible
> with v3. I am just kidding but you get the picture.

Personally I prefer %s and the functions.

I think the format specifiers have become unwieldy. I don't remember any
of the kernel specific ones by heart, I always look them up or just
cargo-cult. I think the fourcc format specifiers are a nice cleanup, but
I don't remember them either. I'd like something like %foo{yesno} where,
if you remember the %foo part, you could actually also remember the
rest.

But really if you get *any* version accepted, I'm not going to argue
against it, and you can disregard this as meaningless bikeshedding.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Good luck. I gave up after just four versions. [1]

Acked-by: Jani Nikula <jani.nikula@intel.com>


BR,
Jani.


[1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>  drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>  include/linux/string.h                               |  5 +++++
>  4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>   *
>   */
>  
> +#include <linux/string.h>
>  #include <linux/uaccess.h>
>  
>  #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>  	uint32_t param1;
>  };
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>   *
>   * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>  
>  #include <linux/list.h>
>  #include <linux/overflow.h>
> +#include <linux/string.h>
>  #include <linux/sched.h>
>  #include <linux/types.h>
>  #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>  #define MBps(x) KBps(1000 * (x))
>  #define GBps(x) ((u64)1000 * MBps((x)))
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  static inline const char *onoff(bool v)
>  {
>  	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/seq_file.h>
>  #include <linux/debugfs.h>
> +#include <linux/string.h>
>  #include <linux/string_helpers.h>
>  #include <linux/sort.h>
>  #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>  /* RSS Configuration.
>   */
>  
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>  static int rss_config_show(struct seq_file *seq, void *v)
>  {
>  	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>  	return strncmp(str, prefix, len) == 0 ? len : 0;
>  }
>  
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>  #endif /* _LINUX_STRING_H_ */

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Good luck. I gave up after just four versions. [1]

Acked-by: Jani Nikula <jani.nikula@intel.com>


BR,
Jani.


[1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>  drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>  include/linux/string.h                               |  5 +++++
>  4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>   *
>   */
>  
> +#include <linux/string.h>
>  #include <linux/uaccess.h>
>  
>  #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>  	uint32_t param1;
>  };
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>   *
>   * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>  
>  #include <linux/list.h>
>  #include <linux/overflow.h>
> +#include <linux/string.h>
>  #include <linux/sched.h>
>  #include <linux/types.h>
>  #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>  #define MBps(x) KBps(1000 * (x))
>  #define GBps(x) ((u64)1000 * MBps((x)))
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  static inline const char *onoff(bool v)
>  {
>  	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/seq_file.h>
>  #include <linux/debugfs.h>
> +#include <linux/string.h>
>  #include <linux/string_helpers.h>
>  #include <linux/sort.h>
>  #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>  /* RSS Configuration.
>   */
>  
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>  static int rss_config_show(struct seq_file *seq, void *v)
>  {
>  	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>  	return strncmp(str, prefix, len) == 0 ? len : 0;
>  }
>  
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>  #endif /* _LINUX_STRING_H_ */

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Good luck. I gave up after just four versions. [1]

Acked-by: Jani Nikula <jani.nikula@intel.com>


BR,
Jani.


[1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>  drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>  include/linux/string.h                               |  5 +++++
>  4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>   *
>   */
>  
> +#include <linux/string.h>
>  #include <linux/uaccess.h>
>  
>  #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>  	uint32_t param1;
>  };
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>   *
>   * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>  
>  #include <linux/list.h>
>  #include <linux/overflow.h>
> +#include <linux/string.h>
>  #include <linux/sched.h>
>  #include <linux/types.h>
>  #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>  #define MBps(x) KBps(1000 * (x))
>  #define GBps(x) ((u64)1000 * MBps((x)))
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  static inline const char *onoff(bool v)
>  {
>  	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/seq_file.h>
>  #include <linux/debugfs.h>
> +#include <linux/string.h>
>  #include <linux/string_helpers.h>
>  #include <linux/sort.h>
>  #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>  /* RSS Configuration.
>   */
>  
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>  static int rss_config_show(struct seq_file *seq, void *v)
>  {
>  	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>  	return strncmp(str, prefix, len) == 0 ? len : 0;
>  }
>  
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>  #endif /* _LINUX_STRING_H_ */

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> We have already few similar implementation and a lot of code that can benefit
> of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

Good luck. I gave up after just four versions. [1]

Acked-by: Jani Nikula <jani.nikula@intel.com>


BR,
Jani.


[1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
>  drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
>  include/linux/string.h                               |  5 +++++
>  4 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 360952129b6d..7fde4f90e513 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -23,6 +23,7 @@
>   *
>   */
>  
> +#include <linux/string.h>
>  #include <linux/uaccess.h>
>  
>  #include <drm/drm_debugfs.h>
> @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
>  	uint32_t param1;
>  };
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>   *
>   * Function takes in attributes passed to debugfs write entry
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index abd4dcd9f79c..e6da5a951132 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -27,6 +27,7 @@
>  
>  #include <linux/list.h>
>  #include <linux/overflow.h>
> +#include <linux/string.h>
>  #include <linux/sched.h>
>  #include <linux/types.h>
>  #include <linux/workqueue.h>
> @@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
>  #define MBps(x) KBps(1000 * (x))
>  #define GBps(x) ((u64)1000 * MBps((x)))
>  
> -static inline const char *yesno(bool v)
> -{
> -	return v ? "yes" : "no";
> -}
> -
>  static inline const char *onoff(bool v)
>  {
>  	return v ? "on" : "off";
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> index 7d49fd4edc9e..c857d73abbd7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
> @@ -34,6 +34,7 @@
>  
>  #include <linux/seq_file.h>
>  #include <linux/debugfs.h>
> +#include <linux/string.h>
>  #include <linux/string_helpers.h>
>  #include <linux/sort.h>
>  #include <linux/ctype.h>
> @@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
>  /* RSS Configuration.
>   */
>  
> -/* Small utility function to return the strings "yes" or "no" if the supplied
> - * argument is non-zero.
> - */
> -static const char *yesno(int x)
> -{
> -	static const char *yes = "yes";
> -	static const char *no = "no";
> -
> -	return x ? yes : no;
> -}
> -
>  static int rss_config_show(struct seq_file *seq, void *v)
>  {
>  	struct adapter *adapter = seq->private;
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9521d8cab18e..fd946a5e18c8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
>  	return strncmp(str, prefix, len) == 0 ? len : 0;
>  }
>  
> +static inline const char *yesno(bool yes)
> +{
> +	return yes ? "yes" : "no";
> +}
> +
>  #endif /* _LINUX_STRING_H_ */

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> Good luck. I gave up after just four versions. [1]

Thanks for a pointer! I like your version, but here we also discussing a
possibility to do something like %py[DOY]. It will consolidate all those RO or
whatever sections inside one data structure.

> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> [1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> Good luck. I gave up after just four versions. [1]

Thanks for a pointer! I like your version, but here we also discussing a
possibility to do something like %py[DOY]. It will consolidate all those RO or
whatever sections inside one data structure.

> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> [1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


-- 
With Best Regards,
Andy Shevchenko


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> Good luck. I gave up after just four versions. [1]

Thanks for a pointer! I like your version, but here we also discussing a
possibility to do something like %py[DOY]. It will consolidate all those RO or
whatever sections inside one data structure.

> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> [1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


-- 
With Best Regards,
Andy Shevchenko


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> Good luck. I gave up after just four versions. [1]

Thanks for a pointer! I like your version, but here we also discussing a
possibility to do something like %py[DOY]. It will consolidate all those RO or
whatever sections inside one data structure.

> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> [1] http://lore.kernel.org/r/20191023131308.9420-1-jani.nikula@intel.com


-- 
With Best Regards,
Andy Shevchenko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v1,1/3] string: Consolidate yesno() helpers under string.h hood

[Patchwork]

== Series Details ==

Series: series starting with [v1,1/3] string: Consolidate yesno() helpers under string.h hood
URL   : https://patchwork.freedesktop.org/series/87096/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1160da278ef5 string: Consolidate yesno() helpers under string.h hood
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#6: 
We have already few similar implementation and a lot of code that can benefit

total: 0 errors, 1 warnings, 0 checks, 69 lines checked
3affb778da50 string: Move onoff() helper under string.h hood
bd1f4ebe13b4 string: Move enableddisabled() helper under string.h hood


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v1,1/3] string: Consolidate yesno() helpers under string.h hood

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 4074 bytes --]

== Series Details ==

Series: series starting with [v1,1/3] string: Consolidate yesno() helpers under string.h hood
URL   : https://patchwork.freedesktop.org/series/87096/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9776 -> Patchwork_19680
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/index.html

Known issues
------------

  Here are the changes found in Patchwork_19680 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@userptr:
    - fi-byt-j1900:       NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-byt-j1900/igt@amdgpu/amd_basic@userptr.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
    - fi-snb-2600:        NOTRUN -> [SKIP][2] ([fdo#109271]) +34 similar issues
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-snb-2600/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-snb-2600:        NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-snb-2600/igt@kms_chamelium@hdmi-crc-fast.html

  * igt@prime_self_import@basic-with_two_bos:
    - fi-tgl-y:           [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar issue
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
#### Possible fixes ####

  * igt@debugfs_test@read_all_entries:
    - fi-tgl-y:           [DMESG-WARN][6] ([i915#402]) -> [PASS][7] +2 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s0:
    - fi-tgl-u2:          [FAIL][8] ([i915#1888]) -> [PASS][9]
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
    - fi-byt-j1900:       [INCOMPLETE][10] ([i915#142] / [i915#2405]) -> [PASS][11]
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/fi-byt-j1900/igt@i915_pm_rpm@module-reload.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/fi-byt-j1900/igt@i915_pm_rpm@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
------------------------------

  Additional (1): fi-snb-2600 
  Missing    (5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9776 -> Patchwork_19680

  CI-20190529: 20190529
  CI_DRM_9776: 1d63cb5a7f02df241021731ce1ed8de3e3379bef @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19680: bd1f4ebe13b4642e7cfa84a64712db975cec6e00 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bd1f4ebe13b4 string: Move enableddisabled() helper under string.h hood
3affb778da50 string: Move onoff() helper under string.h hood
1160da278ef5 string: Consolidate yesno() helpers under string.h hood

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/index.html

[-- Attachment #1.2: Type: text/html, Size: 5061 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v1,1/3] string: Consolidate yesno() helpers under string.h hood

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 30308 bytes --]

== Series Details ==

Series: series starting with [v1,1/3] string: Consolidate yesno() helpers under string.h hood
URL   : https://patchwork.freedesktop.org/series/87096/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9776_full -> Patchwork_19680_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_19680_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19680_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_19680_full:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-wc:
    - shard-tglb:         [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb6/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-wc.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb6/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-wc.html

  
Known issues
------------

  Here are the changes found in Patchwork_19680_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_create@madvise:
    - shard-glk:          [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-glk6/igt@gem_exec_create@madvise.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-glk3/igt@gem_exec_create@madvise.html

  * igt@gem_exec_fair@basic-none@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][5] ([i915#2842])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb4/igt@gem_exec_fair@basic-none@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-glk:          [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-glk5/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-glk9/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][8] ([i915#2389])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb4/igt@gem_exec_reloc@basic-many-active@vcs1.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl6/igt@gem_softpin@noreloc-s3.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl2/igt@gem_softpin@noreloc-s3.html

  * igt@gem_userptr_blits@huge-split:
    - shard-apl:          [PASS][11] -> [INCOMPLETE][12] ([i915#2502])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl4/igt@gem_userptr_blits@huge-split.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl6/igt@gem_userptr_blits@huge-split.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-skl:          [PASS][13] -> [INCOMPLETE][14] ([i915#198] / [i915#2295])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl6/igt@gem_workarounds@suspend-resume-context.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl10/igt@gem_workarounds@suspend-resume-context.html

  * igt@gen3_mixed_blits:
    - shard-kbl:          NOTRUN -> [SKIP][15] ([fdo#109271]) +17 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl4/igt@gen3_mixed_blits.html

  * igt@gen7_exec_parse@cmd-crossing-page:
    - shard-iclb:         NOTRUN -> [SKIP][16] ([fdo#109289])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@gen7_exec_parse@cmd-crossing-page.html

  * igt@i915_pm_rpm@gem-execbuf-stress-pc8:
    - shard-iclb:         NOTRUN -> [SKIP][17] ([fdo#109293] / [fdo#109506])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html

  * igt@i915_selftest@live@hangcheck:
    - shard-hsw:          [PASS][18] -> [INCOMPLETE][19] ([i915#2782])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-hsw2/igt@i915_selftest@live@hangcheck.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-hsw2/igt@i915_selftest@live@hangcheck.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-270:
    - shard-iclb:         NOTRUN -> [SKIP][20] ([fdo#110725] / [fdo#111614])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_big_fb@y-tiled-64bpp-rotate-270.html

  * igt@kms_big_joiner@invalid-modeset:
    - shard-apl:          NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2705])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl1/igt@kms_big_joiner@invalid-modeset.html

  * igt@kms_chamelium@dp-hpd-enable-disable-mode:
    - shard-skl:          NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl4/igt@kms_chamelium@dp-hpd-enable-disable-mode.html

  * igt@kms_color_chamelium@pipe-a-ctm-0-75:
    - shard-kbl:          NOTRUN -> [SKIP][23] ([fdo#109271] / [fdo#111827]) +2 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl4/igt@kms_color_chamelium@pipe-a-ctm-0-75.html

  * igt@kms_color_chamelium@pipe-a-ctm-red-to-blue:
    - shard-iclb:         NOTRUN -> [SKIP][24] ([fdo#109284] / [fdo#111827]) +2 similar issues
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_color_chamelium@pipe-a-ctm-red-to-blue.html

  * igt@kms_color_chamelium@pipe-c-ctm-max:
    - shard-apl:          NOTRUN -> [SKIP][25] ([fdo#109271] / [fdo#111827]) +3 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl7/igt@kms_color_chamelium@pipe-c-ctm-max.html

  * igt@kms_cursor_crc@pipe-a-cursor-512x170-random:
    - shard-iclb:         NOTRUN -> [SKIP][26] ([fdo#109278] / [fdo#109279]) +1 similar issue
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_cursor_crc@pipe-a-cursor-512x170-random.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
    - shard-skl:          [PASS][27] -> [FAIL][28] ([i915#54]) +8 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl1/igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl7/igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_crc@pipe-d-cursor-256x85-onscreen:
    - shard-iclb:         NOTRUN -> [SKIP][29] ([fdo#109278]) +2 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_cursor_crc@pipe-d-cursor-256x85-onscreen.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-iclb:         NOTRUN -> [SKIP][30] ([fdo#109274] / [fdo#109278])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
    - shard-skl:          NOTRUN -> [FAIL][31] ([i915#2346])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html

  * igt@kms_flip@2x-blocking-wf_vblank:
    - shard-iclb:         NOTRUN -> [SKIP][32] ([fdo#109274]) +1 similar issue
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_flip@2x-blocking-wf_vblank.html

  * igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible@a-edp1:
    - shard-skl:          [PASS][33] -> [DMESG-WARN][34] ([i915#1982])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl1/igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible@a-edp1.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl5/igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible@a-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
    - shard-skl:          [PASS][35] -> [FAIL][36] ([i915#79])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@b-edp1:
    - shard-skl:          [PASS][37] -> [INCOMPLETE][38] ([i915#198])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl6/igt@kms_flip@flip-vs-suspend-interruptible@b-edp1.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl8/igt@kms_flip@flip-vs-suspend-interruptible@b-edp1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
    - shard-skl:          [PASS][39] -> [FAIL][40] ([i915#2122]) +1 similar issue
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl2/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html

  * igt@kms_flip@plain-flip-ts-check@a-hdmi-a1:
    - shard-glk:          [PASS][41] -> [FAIL][42] ([i915#2122]) +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-glk6/igt@kms_flip@plain-flip-ts-check@a-hdmi-a1.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-glk3/igt@kms_flip@plain-flip-ts-check@a-hdmi-a1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
    - shard-kbl:          NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#2642])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl4/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt:
    - shard-iclb:         NOTRUN -> [SKIP][44] ([fdo#109280]) +2 similar issues
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
    - shard-skl:          NOTRUN -> [SKIP][45] ([fdo#109271]) +8 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl9/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@psr-rgb565-draw-pwrite:
    - shard-apl:          NOTRUN -> [SKIP][46] ([fdo#109271]) +36 similar issues
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl7/igt@kms_frontbuffer_tracking@psr-rgb565-draw-pwrite.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence:
    - shard-apl:          NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#533])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl7/igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
    - shard-skl:          [PASS][48] -> [FAIL][49] ([fdo#108145] / [i915#265])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
    - shard-apl:          NOTRUN -> [FAIL][50] ([fdo#108145] / [i915#265])
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl7/igt@kms_plane_alpha_blend@pipe-c-alpha-7efc.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1:
    - shard-iclb:         NOTRUN -> [SKIP][51] ([i915#658])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1.html

  * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
    - shard-apl:          NOTRUN -> [SKIP][52] ([fdo#109271] / [i915#658])
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl7/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [PASS][53] -> [SKIP][54] ([fdo#109441]) +2 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb6/igt@kms_psr@psr2_primary_page_flip.html

  * igt@nouveau_crc@pipe-b-ctx-flip-detection:
    - shard-iclb:         NOTRUN -> [SKIP][55] ([i915#2530])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@nouveau_crc@pipe-b-ctx-flip-detection.html

  * igt@perf@polling-parameterized:
    - shard-glk:          [PASS][56] -> [FAIL][57] ([i915#1542])
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-glk9/igt@perf@polling-parameterized.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-glk6/igt@perf@polling-parameterized.html

  * igt@prime_nv_api@nv_i915_import_twice_check_flink_name:
    - shard-iclb:         NOTRUN -> [SKIP][58] ([fdo#109291])
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@prime_nv_api@nv_i915_import_twice_check_flink_name.html

  * igt@sysfs_clients@recycle:
    - shard-hsw:          [PASS][59] -> [FAIL][60] ([i915#3028])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-hsw5/igt@sysfs_clients@recycle.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-hsw2/igt@sysfs_clients@recycle.html

  * igt@sysfs_clients@sema-25@vecs0:
    - shard-skl:          [PASS][61] -> [SKIP][62] ([fdo#109271])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl9/igt@sysfs_clients@sema-25@vecs0.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl4/igt@sysfs_clients@sema-25@vecs0.html

  
#### Possible fixes ####

  * igt@gem_ctx_persistence@close-replace-race:
    - shard-kbl:          [TIMEOUT][63] ([i915#2918]) -> [PASS][64]
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl3/igt@gem_ctx_persistence@close-replace-race.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl2/igt@gem_ctx_persistence@close-replace-race.html

  * igt@gem_eio@unwedge-stress:
    - shard-iclb:         [TIMEOUT][65] ([i915#1037] / [i915#2481]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb6/igt@gem_eio@unwedge-stress.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb8/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-iclb:         [FAIL][67] ([i915#2842]) -> [PASS][68]
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb8/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
    - shard-kbl:          [FAIL][69] ([i915#2842]) -> [PASS][70]
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs0.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
    - shard-tglb:         [FAIL][71] ([i915#2842]) -> [PASS][72]
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb1/igt@gem_exec_fair@basic-pace@vecs0.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb8/igt@gem_exec_fair@basic-pace@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-glk:          [FAIL][73] ([i915#2842]) -> [PASS][74] +2 similar issues
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-glk1/igt@gem_exec_fair@basic-throttle@rcs0.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-glk1/igt@gem_exec_fair@basic-throttle@rcs0.html
    - shard-iclb:         [FAIL][75] ([i915#2849]) -> [PASS][76]
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb2/igt@gem_exec_fair@basic-throttle@rcs0.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb4/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
    - shard-glk:          [FAIL][77] ([i915#2389]) -> [PASS][78]
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-glk2/igt@gem_exec_reloc@basic-many-active@rcs0.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-glk6/igt@gem_exec_reloc@basic-many-active@rcs0.html

  * igt@gem_exec_schedule@u-fairslice-all:
    - shard-iclb:         [DMESG-WARN][79] ([i915#2803]) -> [PASS][80]
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb4/igt@gem_exec_schedule@u-fairslice-all.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb3/igt@gem_exec_schedule@u-fairslice-all.html

  * igt@i915_pm_rc6_residency@rc6-idle:
    - shard-hsw:          [WARN][81] ([i915#1519]) -> [PASS][82] +1 similar issue
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-hsw5/igt@i915_pm_rc6_residency@rc6-idle.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-hsw4/igt@i915_pm_rc6_residency@rc6-idle.html

  * igt@kms_async_flips@test-time-stamp:
    - shard-tglb:         [FAIL][83] ([i915#2574]) -> [PASS][84]
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb6/igt@kms_async_flips@test-time-stamp.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb2/igt@kms_async_flips@test-time-stamp.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
    - shard-skl:          [FAIL][85] ([i915#54]) -> [PASS][86] +8 similar issues
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl7/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic:
    - shard-tglb:         [FAIL][87] ([i915#2346]) -> [PASS][88]
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb3/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb2/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy:
    - shard-skl:          [FAIL][89] ([i915#2346]) -> [PASS][90]
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl7/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-kbl:          [INCOMPLETE][91] ([i915#155] / [i915#180] / [i915#636]) -> [PASS][92]
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@dpms-off-confusion-interruptible@a-edp1:
    - shard-skl:          [DMESG-WARN][93] ([i915#1982]) -> [PASS][94]
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl9/igt@kms_flip@dpms-off-confusion-interruptible@a-edp1.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl4/igt@kms_flip@dpms-off-confusion-interruptible@a-edp1.html

  * igt@kms_flip@flip-vs-absolute-wf_vblank@c-edp1:
    - shard-skl:          [FAIL][95] ([i915#2122]) -> [PASS][96]
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl3/igt@kms_flip@flip-vs-absolute-wf_vblank@c-edp1.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl3/igt@kms_flip@flip-vs-absolute-wf_vblank@c-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
    - shard-tglb:         [FAIL][97] ([i915#2598]) -> [PASS][98]
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb7/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
    - shard-apl:          [DMESG-WARN][99] ([i915#180]) -> [PASS][100] +1 similar issue
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl7/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html

  * igt@kms_hdr@bpc-switch:
    - shard-skl:          [FAIL][101] ([i915#1188]) -> [PASS][102]
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl7/igt@kms_hdr@bpc-switch.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl5/igt@kms_hdr@bpc-switch.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][103] ([fdo#108145] / [i915#265]) -> [PASS][104] +1 similar issue
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_sprite_mmap_gtt:
    - shard-iclb:         [SKIP][105] ([fdo#109441]) -> [PASS][106] +2 similar issues
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_gtt.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html

  * igt@perf@blocking:
    - shard-skl:          [FAIL][107] ([i915#1542]) -> [PASS][108]
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl9/igt@perf@blocking.html
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl7/igt@perf@blocking.html

  * {igt@sysfs_clients@recycle-many}:
    - shard-skl:          [FAIL][109] ([i915#3028]) -> [PASS][110]
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-skl2/igt@sysfs_clients@recycle-many.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-skl7/igt@sysfs_clients@recycle-many.html
    - shard-tglb:         [FAIL][111] ([i915#3028]) -> [PASS][112]
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb2/igt@sysfs_clients@recycle-many.html
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb3/igt@sysfs_clients@recycle-many.html

  
#### Warnings ####

  * igt@i915_pm_rc6_residency@rc6-fence:
    - shard-iclb:         [WARN][113] ([i915#1804] / [i915#2684]) -> [WARN][114] ([i915#2684])
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb6/igt@i915_pm_rc6_residency@rc6-fence.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb2/igt@i915_pm_rc6_residency@rc6-fence.html

  * igt@i915_selftest@live@gt_pm:
    - shard-tglb:         [DMESG-FAIL][115] ([i915#1759] / [i915#2291]) -> [DMESG-FAIL][116] ([i915#2291])
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-tglb5/igt@i915_selftest@live@gt_pm.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-tglb7/igt@i915_selftest@live@gt_pm.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [DMESG-WARN][117] ([i915#1226]) -> [SKIP][118] ([fdo#109349])
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb6/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4:
    - shard-iclb:         [SKIP][119] ([i915#2920]) -> [SKIP][120] ([i915#658]) +1 similar issue
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb6/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area-3:
    - shard-iclb:         [SKIP][121] ([i915#658]) -> [SKIP][122] ([i915#2920])
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb6/igt@kms_psr2_sf@plane-move-sf-dmg-area-3.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area-3.html

  * igt@runner@aborted:
    - shard-kbl:          ([FAIL][123], [FAIL][124], [FAIL][125], [FAIL][126], [FAIL][127]) ([i915#2295] / [i915#3002] / [i915#92]) -> ([FAIL][128], [FAIL][129], [FAIL][130]) ([i915#2295] / [i915#3002])
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl3/igt@runner@aborted.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl3/igt@runner@aborted.html
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl3/igt@runner@aborted.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl4/igt@runner@aborted.html
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-kbl1/igt@runner@aborted.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl2/igt@runner@aborted.html
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl4/igt@runner@aborted.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-kbl2/igt@runner@aborted.html
    - shard-iclb:         ([FAIL][131], [FAIL][132], [FAIL][133], [FAIL][134]) ([i915#2295] / [i915#2426] / [i915#2724] / [i915#3002]) -> ([FAIL][135], [FAIL][136], [FAIL][137]) ([i915#2295] / [i915#2724] / [i915#3002])
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb1/igt@runner@aborted.html
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb7/igt@runner@aborted.html
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb3/igt@runner@aborted.html
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-iclb4/igt@runner@aborted.html
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb1/igt@runner@aborted.html
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb5/igt@runner@aborted.html
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-iclb5/igt@runner@aborted.html
    - shard-apl:          ([FAIL][138], [FAIL][139], [FAIL][140], [FAIL][141], [FAIL][142], [FAIL][143]) ([i915#1610] / [i915#2292] / [i915#2295] / [i915#3002]) -> ([FAIL][144], [FAIL][145], [FAIL][146], [FAIL][147], [FAIL][148]) ([fdo#109271] / [i915#1814] / [i915#2295] / [i915#3002])
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl2/igt@runner@aborted.html
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl7/igt@runner@aborted.html
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl3/igt@runner@aborted.html
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl4/igt@runner@aborted.html
   [142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl4/igt@runner@aborted.html
   [143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9776/shard-apl7/igt@runner@aborted.html
   [144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl3/igt@runner@aborted.html
   [145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl6/igt@runner@aborted.html
   [146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl2/igt@runner@aborted.html
   [147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl2/igt@runner@aborted.html
   [148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/shard-apl3/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#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#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109293]: https://bugs.freedesktop.org/show_bug.cgi?id=109293
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#110725]: https://bugs.freedesktop.org/show_bug.cgi?id=110725
  [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1037]: https://gitlab.freedesktop.org/drm/intel/issues/1037
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
  [i915#1519]: https://gitlab.freedesktop.org/drm/intel/issues/1519
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
  [i915#1759]: https://gitlab.freedesktop.o

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19680/index.html

[-- Attachment #1.2: Type: text/html, Size: 34690 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Lucas De Marchi]

On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
>We have already few similar implementation and a lot of code that can benefit
>of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

I was taking a look on i915_utils.h to reduce it and move some of it
elsewhere to be shared with others.  I was starting with these helpers
and had [1] done, then Jani pointed me to this thread and also his
previous tentative. I thought the natural place for this would be
include/linux/string_helpers.h, but I will leave it up to you.

After reading the threads, I don't see real opposition to it.
Is there a tree you plan to take this through?

thanks
Lucas De Marchi

[1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
> drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
> include/linux/string.h                               |  5 +++++
> 4 files changed, 8 insertions(+), 21 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>index 360952129b6d..7fde4f90e513 100644
>--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>@@ -23,6 +23,7 @@
>  *
>  */
>
>+#include <linux/string.h>
> #include <linux/uaccess.h>
>
> #include <drm/drm_debugfs.h>
>@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
> 	uint32_t param1;
> };
>
>-static inline const char *yesno(bool v)
>-{
>-	return v ? "yes" : "no";
>-}
>-
> /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>  *
>  * Function takes in attributes passed to debugfs write entry
>diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
>index abd4dcd9f79c..e6da5a951132 100644
>--- a/drivers/gpu/drm/i915/i915_utils.h
>+++ b/drivers/gpu/drm/i915/i915_utils.h
>@@ -27,6 +27,7 @@
>
> #include <linux/list.h>
> #include <linux/overflow.h>
>+#include <linux/string.h>
> #include <linux/sched.h>
> #include <linux/types.h>
> #include <linux/workqueue.h>
>@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
> #define MBps(x) KBps(1000 * (x))
> #define GBps(x) ((u64)1000 * MBps((x)))
>
>-static inline const char *yesno(bool v)
>-{
>-	return v ? "yes" : "no";
>-}
>-
> static inline const char *onoff(bool v)
> {
> 	return v ? "on" : "off";
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
>index 7d49fd4edc9e..c857d73abbd7 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
>+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
>@@ -34,6 +34,7 @@
>
> #include <linux/seq_file.h>
> #include <linux/debugfs.h>
>+#include <linux/string.h>
> #include <linux/string_helpers.h>
> #include <linux/sort.h>
> #include <linux/ctype.h>
>@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
> /* RSS Configuration.
>  */
>
>-/* Small utility function to return the strings "yes" or "no" if the supplied
>- * argument is non-zero.
>- */
>-static const char *yesno(int x)
>-{
>-	static const char *yes = "yes";
>-	static const char *no = "no";
>-
>-	return x ? yes : no;
>-}
>-
> static int rss_config_show(struct seq_file *seq, void *v)
> {
> 	struct adapter *adapter = seq->private;
>diff --git a/include/linux/string.h b/include/linux/string.h
>index 9521d8cab18e..fd946a5e18c8 100644
>--- a/include/linux/string.h
>+++ b/include/linux/string.h
>@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
> 	return strncmp(str, prefix, len) == 0 ? len : 0;
> }
>
>+static inline const char *yesno(bool yes)
>+{
>+	return yes ? "yes" : "no";
>+}
>+
> #endif /* _LINUX_STRING_H_ */
>-- 
>2.30.0
>
>

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Lucas De Marchi]

On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
>We have already few similar implementation and a lot of code that can benefit
>of the yesno() helper.  Consolidate yesno() helpers under string.h hood.

I was taking a look on i915_utils.h to reduce it and move some of it
elsewhere to be shared with others.  I was starting with these helpers
and had [1] done, then Jani pointed me to this thread and also his
previous tentative. I thought the natural place for this would be
include/linux/string_helpers.h, but I will leave it up to you.

After reading the threads, I don't see real opposition to it.
Is there a tree you plan to take this through?

thanks
Lucas De Marchi

[1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c    |  6 +-----
> drivers/gpu/drm/i915/i915_utils.h                    |  6 +-----
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c   | 12 +-----------
> include/linux/string.h                               |  5 +++++
> 4 files changed, 8 insertions(+), 21 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>index 360952129b6d..7fde4f90e513 100644
>--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>@@ -23,6 +23,7 @@
>  *
>  */
>
>+#include <linux/string.h>
> #include <linux/uaccess.h>
>
> #include <drm/drm_debugfs.h>
>@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
> 	uint32_t param1;
> };
>
>-static inline const char *yesno(bool v)
>-{
>-	return v ? "yes" : "no";
>-}
>-
> /* parse_write_buffer_into_params - Helper function to parse debugfs write buffer into an array
>  *
>  * Function takes in attributes passed to debugfs write entry
>diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
>index abd4dcd9f79c..e6da5a951132 100644
>--- a/drivers/gpu/drm/i915/i915_utils.h
>+++ b/drivers/gpu/drm/i915/i915_utils.h
>@@ -27,6 +27,7 @@
>
> #include <linux/list.h>
> #include <linux/overflow.h>
>+#include <linux/string.h>
> #include <linux/sched.h>
> #include <linux/types.h>
> #include <linux/workqueue.h>
>@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
> #define MBps(x) KBps(1000 * (x))
> #define GBps(x) ((u64)1000 * MBps((x)))
>
>-static inline const char *yesno(bool v)
>-{
>-	return v ? "yes" : "no";
>-}
>-
> static inline const char *onoff(bool v)
> {
> 	return v ? "on" : "off";
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
>index 7d49fd4edc9e..c857d73abbd7 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
>+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
>@@ -34,6 +34,7 @@
>
> #include <linux/seq_file.h>
> #include <linux/debugfs.h>
>+#include <linux/string.h>
> #include <linux/string_helpers.h>
> #include <linux/sort.h>
> #include <linux/ctype.h>
>@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
> /* RSS Configuration.
>  */
>
>-/* Small utility function to return the strings "yes" or "no" if the supplied
>- * argument is non-zero.
>- */
>-static const char *yesno(int x)
>-{
>-	static const char *yes = "yes";
>-	static const char *no = "no";
>-
>-	return x ? yes : no;
>-}
>-
> static int rss_config_show(struct seq_file *seq, void *v)
> {
> 	struct adapter *adapter = seq->private;
>diff --git a/include/linux/string.h b/include/linux/string.h
>index 9521d8cab18e..fd946a5e18c8 100644
>--- a/include/linux/string.h
>+++ b/include/linux/string.h
>@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix
> 	return strncmp(str, prefix, len) == 0 ? len : 0;
> }
>
>+static inline const char *yesno(bool yes)
>+{
>+	return yes ? "yes" : "no";
>+}
>+
> #endif /* _LINUX_STRING_H_ */
>-- 
>2.30.0
>
>

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> I was taking a look on i915_utils.h to reduce it and move some of it
> elsewhere to be shared with others.  I was starting with these helpers
> and had [1] done, then Jani pointed me to this thread and also his
> previous tentative. I thought the natural place for this would be
> include/linux/string_helpers.h, but I will leave it up to you.

Seems reasonable to use string_helpers (headers and/or C-file).

> After reading the threads, I don't see real opposition to it.
> Is there a tree you plan to take this through?

I rest my series in favour of Jani's approach, so I suppose there is no go
for _this_ series.

> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> I was taking a look on i915_utils.h to reduce it and move some of it
> elsewhere to be shared with others.  I was starting with these helpers
> and had [1] done, then Jani pointed me to this thread and also his
> previous tentative. I thought the natural place for this would be
> include/linux/string_helpers.h, but I will leave it up to you.

Seems reasonable to use string_helpers (headers and/or C-file).

> After reading the threads, I don't see real opposition to it.
> Is there a tree you plan to take this through?

I rest my series in favour of Jani's approach, so I suppose there is no go
for _this_ series.

> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> I was taking a look on i915_utils.h to reduce it and move some of it
> elsewhere to be shared with others.  I was starting with these helpers
> and had [1] done, then Jani pointed me to this thread and also his
> previous tentative. I thought the natural place for this would be
> include/linux/string_helpers.h, but I will leave it up to you.

Seems reasonable to use string_helpers (headers and/or C-file).

> After reading the threads, I don't see real opposition to it.
> Is there a tree you plan to take this through?

I rest my series in favour of Jani's approach, so I suppose there is no go
for _this_ series.

> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can benefit
> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> 
> I was taking a look on i915_utils.h to reduce it and move some of it
> elsewhere to be shared with others.  I was starting with these helpers
> and had [1] done, then Jani pointed me to this thread and also his
> previous tentative. I thought the natural place for this would be
> include/linux/string_helpers.h, but I will leave it up to you.

Seems reasonable to use string_helpers (headers and/or C-file).

> After reading the threads, I don't see real opposition to it.
> Is there a tree you plan to take this through?

I rest my series in favour of Jani's approach, so I suppose there is no go
for _this_ series.

> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
>> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
>> > We have already few similar implementation and a lot of code that can benefit
>> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> 
>> I was taking a look on i915_utils.h to reduce it and move some of it
>> elsewhere to be shared with others.  I was starting with these helpers
>> and had [1] done, then Jani pointed me to this thread and also his
>> previous tentative. I thought the natural place for this would be
>> include/linux/string_helpers.h, but I will leave it up to you.
>
> Seems reasonable to use string_helpers (headers and/or C-file).
>
>> After reading the threads, I don't see real opposition to it.
>> Is there a tree you plan to take this through?
>
> I rest my series in favour of Jani's approach, so I suppose there is no go
> for _this_ series.

If you want to make it happen, please pick it up and drive it. I'm
thoroughly had enough of this.

BR,
Jani.


>
>> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
>> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
>> > We have already few similar implementation and a lot of code that can benefit
>> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> 
>> I was taking a look on i915_utils.h to reduce it and move some of it
>> elsewhere to be shared with others.  I was starting with these helpers
>> and had [1] done, then Jani pointed me to this thread and also his
>> previous tentative. I thought the natural place for this would be
>> include/linux/string_helpers.h, but I will leave it up to you.
>
> Seems reasonable to use string_helpers (headers and/or C-file).
>
>> After reading the threads, I don't see real opposition to it.
>> Is there a tree you plan to take this through?
>
> I rest my series in favour of Jani's approach, so I suppose there is no go
> for _this_ series.

If you want to make it happen, please pick it up and drive it. I'm
thoroughly had enough of this.

BR,
Jani.


>
>> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
>> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
>> > We have already few similar implementation and a lot of code that can benefit
>> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> 
>> I was taking a look on i915_utils.h to reduce it and move some of it
>> elsewhere to be shared with others.  I was starting with these helpers
>> and had [1] done, then Jani pointed me to this thread and also his
>> previous tentative. I thought the natural place for this would be
>> include/linux/string_helpers.h, but I will leave it up to you.
>
> Seems reasonable to use string_helpers (headers and/or C-file).
>
>> After reading the threads, I don't see real opposition to it.
>> Is there a tree you plan to take this through?
>
> I rest my series in favour of Jani's approach, so I suppose there is no go
> for _this_ series.

If you want to make it happen, please pick it up and drive it. I'm
thoroughly had enough of this.

BR,
Jani.


>
>> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Jani Nikula]

On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
>> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
>> > We have already few similar implementation and a lot of code that can benefit
>> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
>> 
>> I was taking a look on i915_utils.h to reduce it and move some of it
>> elsewhere to be shared with others.  I was starting with these helpers
>> and had [1] done, then Jani pointed me to this thread and also his
>> previous tentative. I thought the natural place for this would be
>> include/linux/string_helpers.h, but I will leave it up to you.
>
> Seems reasonable to use string_helpers (headers and/or C-file).
>
>> After reading the threads, I don't see real opposition to it.
>> Is there a tree you plan to take this through?
>
> I rest my series in favour of Jani's approach, so I suppose there is no go
> for _this_ series.

If you want to make it happen, please pick it up and drive it. I'm
thoroughly had enough of this.

BR,
Jani.


>
>> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >> > We have already few similar implementation and a lot of code that can benefit
> >> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >> 
> >> I was taking a look on i915_utils.h to reduce it and move some of it
> >> elsewhere to be shared with others.  I was starting with these helpers
> >> and had [1] done, then Jani pointed me to this thread and also his
> >> previous tentative. I thought the natural place for this would be
> >> include/linux/string_helpers.h, but I will leave it up to you.
> >
> > Seems reasonable to use string_helpers (headers and/or C-file).
> >
> >> After reading the threads, I don't see real opposition to it.
> >> Is there a tree you plan to take this through?
> >
> > I rest my series in favour of Jani's approach, so I suppose there is no go
> > for _this_ series.
> 
> If you want to make it happen, please pick it up and drive it. I'm
> thoroughly had enough of this.

My point is still the same, so it's more to Lucas.

I'm not going to drive this activity due to lack of time.

> >> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >> > We have already few similar implementation and a lot of code that can benefit
> >> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >> 
> >> I was taking a look on i915_utils.h to reduce it and move some of it
> >> elsewhere to be shared with others.  I was starting with these helpers
> >> and had [1] done, then Jani pointed me to this thread and also his
> >> previous tentative. I thought the natural place for this would be
> >> include/linux/string_helpers.h, but I will leave it up to you.
> >
> > Seems reasonable to use string_helpers (headers and/or C-file).
> >
> >> After reading the threads, I don't see real opposition to it.
> >> Is there a tree you plan to take this through?
> >
> > I rest my series in favour of Jani's approach, so I suppose there is no go
> > for _this_ series.
> 
> If you want to make it happen, please pick it up and drive it. I'm
> thoroughly had enough of this.

My point is still the same, so it's more to Lucas.

I'm not going to drive this activity due to lack of time.

> >> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >> > We have already few similar implementation and a lot of code that can benefit
> >> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >> 
> >> I was taking a look on i915_utils.h to reduce it and move some of it
> >> elsewhere to be shared with others.  I was starting with these helpers
> >> and had [1] done, then Jani pointed me to this thread and also his
> >> previous tentative. I thought the natural place for this would be
> >> include/linux/string_helpers.h, but I will leave it up to you.
> >
> > Seems reasonable to use string_helpers (headers and/or C-file).
> >
> >> After reading the threads, I don't see real opposition to it.
> >> Is there a tree you plan to take this through?
> >
> > I rest my series in favour of Jani's approach, so I suppose there is no go
> > for _this_ series.
> 
> If you want to make it happen, please pick it up and drive it. I'm
> thoroughly had enough of this.

My point is still the same, so it's more to Lucas.

I'm not going to drive this activity due to lack of time.

> >> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko

Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood

[Andy Shevchenko]

On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >> > We have already few similar implementation and a lot of code that can benefit
> >> > of the yesno() helper.  Consolidate yesno() helpers under string.h hood.
> >> 
> >> I was taking a look on i915_utils.h to reduce it and move some of it
> >> elsewhere to be shared with others.  I was starting with these helpers
> >> and had [1] done, then Jani pointed me to this thread and also his
> >> previous tentative. I thought the natural place for this would be
> >> include/linux/string_helpers.h, but I will leave it up to you.
> >
> > Seems reasonable to use string_helpers (headers and/or C-file).
> >
> >> After reading the threads, I don't see real opposition to it.
> >> Is there a tree you plan to take this through?
> >
> > I rest my series in favour of Jani's approach, so I suppose there is no go
> > for _this_ series.
> 
> If you want to make it happen, please pick it up and drive it. I'm
> thoroughly had enough of this.

My point is still the same, so it's more to Lucas.

I'm not going to drive this activity due to lack of time.

> >> [1] https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demarchi@intel.com/T/#u

-- 
With Best Regards,
Andy Shevchenko