[PATCH 1/2] drm/property: Enforce more lifetime rules

[PATCH 1/2] drm/property: Enforce more lifetime rules

[Daniel Vetter]

Properties can't be attached after registering, userspace would get
confused (no one bothers to reprobe really).

- Add kerneldoc
- Enforce this with some checks. This needs a somewhat ugly check
  since connectors can be added later on, but we still need to attach
  all properties before they go public.

Note that we already enforce that properties themselves are created
before the entire device is registered.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
index 6a23e36ed4fe..35c2719407a8 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
  * This attaches the given property to the modeset object with the given initial
  * value. Currently this function cannot fail since the properties are stored in
  * a statically sized array.
+ *
+ * Note that all properties must be attached before the object itself is
+ * registered and accessible from userspace.
  */
 void drm_object_attach_property(struct drm_mode_object *obj,
 				struct drm_property *property,
 				uint64_t init_val)
 {
 	int count = obj->properties->count;
+	struct drm_device *dev = property->dev;
+
+
+	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
+		struct drm_connector *connector = obj_to_connector(obj);
+
+		WARN_ON(!dev->driver->load &&
+			connector->registration_state == DRM_CONNECTOR_REGISTERED);
+	} else {
+		WARN_ON(!dev->driver->load && dev->registered);
+	}
 
 	if (count == DRM_OBJECT_MAX_PROPERTY) {
 		WARN(1, "Failed to attach object property (type: 0x%x). Please "
-- 
2.23.0

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

[Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Daniel Vetter]

Properties can't be attached after registering, userspace would get
confused (no one bothers to reprobe really).

- Add kerneldoc
- Enforce this with some checks. This needs a somewhat ugly check
  since connectors can be added later on, but we still need to attach
  all properties before they go public.

Note that we already enforce that properties themselves are created
before the entire device is registered.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
index 6a23e36ed4fe..35c2719407a8 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
  * This attaches the given property to the modeset object with the given initial
  * value. Currently this function cannot fail since the properties are stored in
  * a statically sized array.
+ *
+ * Note that all properties must be attached before the object itself is
+ * registered and accessible from userspace.
  */
 void drm_object_attach_property(struct drm_mode_object *obj,
 				struct drm_property *property,
 				uint64_t init_val)
 {
 	int count = obj->properties->count;
+	struct drm_device *dev = property->dev;
+
+
+	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
+		struct drm_connector *connector = obj_to_connector(obj);
+
+		WARN_ON(!dev->driver->load &&
+			connector->registration_state == DRM_CONNECTOR_REGISTERED);
+	} else {
+		WARN_ON(!dev->driver->load && dev->registered);
+	}
 
 	if (count == DRM_OBJECT_MAX_PROPERTY) {
 		WARN(1, "Failed to attach object property (type: 0x%x). Please "
-- 
2.23.0

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

[PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Daniel Vetter]

They're midlayer, broken, and because of the old gunk, we can't fix
them. For examples see the various checks in drm_mode_object.c against
dev->registered, which cannot be enforced if the driver still uses the
load hook.

Unfortunately our biggest driver still uses load/unload, so this would
be really great to get fixed.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/todo.rst | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 73c51b5a0997..5a44f46380c2 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -351,6 +351,23 @@ connector register/unregister fixes
 
 Level: Intermediate
 
+Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+---------------------------------------------------------------
+
+The load/unload callbacks in struct &drm_driver are very much midlayers, plus
+for historical reasons they get the ordering wrong (and we can't fix that)
+between setting up the &drm_driver structure and calling drm_dev_register().
+
+- Rework drivers to no longer use the load/unload callbacks, directly coding the
+  load/unload sequence into the driver's probe function.
+
+- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
+  callbacks for all modern drivers.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
 Core refactorings
 =================
 
-- 
2.23.0

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

[PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Daniel Vetter]

They're midlayer, broken, and because of the old gunk, we can't fix
them. For examples see the various checks in drm_mode_object.c against
dev->registered, which cannot be enforced if the driver still uses the
load hook.

Unfortunately our biggest driver still uses load/unload, so this would
be really great to get fixed.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/todo.rst | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 73c51b5a0997..5a44f46380c2 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -351,6 +351,23 @@ connector register/unregister fixes
 
 Level: Intermediate
 
+Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+---------------------------------------------------------------
+
+The load/unload callbacks in struct &drm_driver are very much midlayers, plus
+for historical reasons they get the ordering wrong (and we can't fix that)
+between setting up the &drm_driver structure and calling drm_dev_register().
+
+- Rework drivers to no longer use the load/unload callbacks, directly coding the
+  load/unload sequence into the driver's probe function.
+
+- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
+  callbacks for all modern drivers.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
 Core refactorings
 =================
 
-- 
2.23.0

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

[Intel-gfx] [PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Daniel Vetter]

They're midlayer, broken, and because of the old gunk, we can't fix
them. For examples see the various checks in drm_mode_object.c against
dev->registered, which cannot be enforced if the driver still uses the
load hook.

Unfortunately our biggest driver still uses load/unload, so this would
be really great to get fixed.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/todo.rst | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 73c51b5a0997..5a44f46380c2 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -351,6 +351,23 @@ connector register/unregister fixes
 
 Level: Intermediate
 
+Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+---------------------------------------------------------------
+
+The load/unload callbacks in struct &drm_driver are very much midlayers, plus
+for historical reasons they get the ordering wrong (and we can't fix that)
+between setting up the &drm_driver structure and calling drm_dev_register().
+
+- Rework drivers to no longer use the load/unload callbacks, directly coding the
+  load/unload sequence into the driver's probe function.
+
+- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
+  callbacks for all modern drivers.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
 Core refactorings
 =================
 
-- 
2.23.0

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

✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/property: Enforce more lifetime rules

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/property: Enforce more lifetime rules
URL   : https://patchwork.freedesktop.org/series/68467/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
33ce34335c16 drm/property: Enforce more lifetime rules
-:40: CHECK:LINE_SPACING: Please don't use multiple blank lines
#40: FILE: drivers/gpu/drm/drm_mode_object.c:238:
+
+

-:51: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 1 checks, 26 lines checked
85155761fd1f drm/todo: Add entry to remove load/unload hooks
-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 23 lines checked

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/property: Enforce more lifetime rules

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/property: Enforce more lifetime rules
URL   : https://patchwork.freedesktop.org/series/68467/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
33ce34335c16 drm/property: Enforce more lifetime rules
-:40: CHECK:LINE_SPACING: Please don't use multiple blank lines
#40: FILE: drivers/gpu/drm/drm_mode_object.c:238:
+
+

-:51: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 1 checks, 26 lines checked
85155761fd1f drm/todo: Add entry to remove load/unload hooks
-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 23 lines checked

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

✓ Fi.CI.BAT: success for series starting with [1/2] drm/property: Enforce more lifetime rules

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/property: Enforce more lifetime rules
URL   : https://patchwork.freedesktop.org/series/68467/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7167 -> Patchwork_14952
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live_gem_contexts:
    - fi-cfl-8109u:       [PASS][1] -> [DMESG-FAIL][2] ([fdo#112050 ])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html

  
#### Possible fixes ####

  * igt@gem_sync@basic-store-all:
    - {fi-tgl-u}:         [INCOMPLETE][3] ([fdo#111880]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-tgl-u/igt@gem_sync@basic-store-all.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-tgl-u/igt@gem_sync@basic-store-all.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-skl-6600u:       [FAIL][5] ([fdo#107707]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-skl-6600u/igt@i915_pm_rpm@basic-pci-d3-state.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-skl-6600u/igt@i915_pm_rpm@basic-pci-d3-state.html

  * {igt@i915_selftest@live_gt_heartbeat}:
    - {fi-icl-dsi}:       [DMESG-FAIL][7] -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
    - fi-kbl-8809g:       [DMESG-FAIL][9] ([fdo#112096]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html

  
#### Warnings ####

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][11] ([fdo#111407]) -> [FAIL][12] ([fdo#111045] / [fdo#111096])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
  [fdo#112050 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112050 
  [fdo#112096]: https://bugs.freedesktop.org/show_bug.cgi?id=112096


Participating hosts (52 -> 45)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7167 -> Patchwork_14952

  CI-20190529: 20190529
  CI_DRM_7167: a62b1c4e7739c6777d51e7b2d66406b935131451 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5236: 8153b95b53bdef26d2c3e318197d174e982b4265 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14952: 85155761fd1fd0f023f36abdf6d760b1909891b6 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

85155761fd1f drm/todo: Add entry to remove load/unload hooks
33ce34335c16 drm/property: Enforce more lifetime rules

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/index.html
_______________________________________________
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 [1/2] drm/property: Enforce more lifetime rules

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/property: Enforce more lifetime rules
URL   : https://patchwork.freedesktop.org/series/68467/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7167 -> Patchwork_14952
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live_gem_contexts:
    - fi-cfl-8109u:       [PASS][1] -> [DMESG-FAIL][2] ([fdo#112050 ])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html

  
#### Possible fixes ####

  * igt@gem_sync@basic-store-all:
    - {fi-tgl-u}:         [INCOMPLETE][3] ([fdo#111880]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-tgl-u/igt@gem_sync@basic-store-all.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-tgl-u/igt@gem_sync@basic-store-all.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-skl-6600u:       [FAIL][5] ([fdo#107707]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-skl-6600u/igt@i915_pm_rpm@basic-pci-d3-state.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-skl-6600u/igt@i915_pm_rpm@basic-pci-d3-state.html

  * {igt@i915_selftest@live_gt_heartbeat}:
    - {fi-icl-dsi}:       [DMESG-FAIL][7] -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
    - fi-kbl-8809g:       [DMESG-FAIL][9] ([fdo#112096]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html

  
#### Warnings ####

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][11] ([fdo#111407]) -> [FAIL][12] ([fdo#111045] / [fdo#111096])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
  [fdo#112050 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112050 
  [fdo#112096]: https://bugs.freedesktop.org/show_bug.cgi?id=112096


Participating hosts (52 -> 45)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7167 -> Patchwork_14952

  CI-20190529: 20190529
  CI_DRM_7167: a62b1c4e7739c6777d51e7b2d66406b935131451 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5236: 8153b95b53bdef26d2c3e318197d174e982b4265 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14952: 85155761fd1fd0f023f36abdf6d760b1909891b6 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

85155761fd1f drm/todo: Add entry to remove load/unload hooks
33ce34335c16 drm/property: Enforce more lifetime rules

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Thierry Reding]

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

On Wed, Oct 23, 2019 at 04:49:53PM +0200, Daniel Vetter wrote:
> They're midlayer, broken, and because of the old gunk, we can't fix
> them. For examples see the various checks in drm_mode_object.c against
> dev->registered, which cannot be enforced if the driver still uses the
> load hook.
> 
> Unfortunately our biggest driver still uses load/unload, so this would
> be really great to get fixed.
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)

Reminds me that I need to still do that for Tegra:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [Intel-gfx] [PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Thierry Reding]

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

On Wed, Oct 23, 2019 at 04:49:53PM +0200, Daniel Vetter wrote:
> They're midlayer, broken, and because of the old gunk, we can't fix
> them. For examples see the various checks in drm_mode_object.c against
> dev->registered, which cannot be enforced if the driver still uses the
> load hook.
> 
> Unfortunately our biggest driver still uses load/unload, so this would
> be really great to get fixed.
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)

Reminds me that I need to still do that for Tegra:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [PATCH 1/2] drm/property: Enforce more lifetime rules

[Thierry Reding]

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

On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
> 
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
>   since connectors can be added later on, but we still need to attach
>   all properties before they go public.
> 
> Note that we already enforce that properties themselves are created
> before the entire device is registered.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> index 6a23e36ed4fe..35c2719407a8 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
>   * This attaches the given property to the modeset object with the given initial
>   * value. Currently this function cannot fail since the properties are stored in
>   * a statically sized array.
> + *
> + * Note that all properties must be attached before the object itself is
> + * registered and accessible from userspace.
>   */
>  void drm_object_attach_property(struct drm_mode_object *obj,
>  				struct drm_property *property,
>  				uint64_t init_val)
>  {
>  	int count = obj->properties->count;
> +	struct drm_device *dev = property->dev;
> +
> +
> +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> +		struct drm_connector *connector = obj_to_connector(obj);
> +
> +		WARN_ON(!dev->driver->load &&
> +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> +	} else {
> +		WARN_ON(!dev->driver->load && dev->registered);
> +	}

I'm not sure I understand why dev->driver->load needs to be a special
case. Don't the same rules apply for those drivers as well?

Thierry

>  
>  	if (count == DRM_OBJECT_MAX_PROPERTY) {
>  		WARN(1, "Failed to attach object property (type: 0x%x). Please "
> -- 
> 2.23.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Thierry Reding]

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

On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
> 
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
>   since connectors can be added later on, but we still need to attach
>   all properties before they go public.
> 
> Note that we already enforce that properties themselves are created
> before the entire device is registered.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> index 6a23e36ed4fe..35c2719407a8 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
>   * This attaches the given property to the modeset object with the given initial
>   * value. Currently this function cannot fail since the properties are stored in
>   * a statically sized array.
> + *
> + * Note that all properties must be attached before the object itself is
> + * registered and accessible from userspace.
>   */
>  void drm_object_attach_property(struct drm_mode_object *obj,
>  				struct drm_property *property,
>  				uint64_t init_val)
>  {
>  	int count = obj->properties->count;
> +	struct drm_device *dev = property->dev;
> +
> +
> +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> +		struct drm_connector *connector = obj_to_connector(obj);
> +
> +		WARN_ON(!dev->driver->load &&
> +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> +	} else {
> +		WARN_ON(!dev->driver->load && dev->registered);
> +	}

I'm not sure I understand why dev->driver->load needs to be a special
case. Don't the same rules apply for those drivers as well?

Thierry

>  
>  	if (count == DRM_OBJECT_MAX_PROPERTY) {
>  		WARN(1, "Failed to attach object property (type: 0x%x). Please "
> -- 
> 2.23.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Thierry Reding]

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

On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
> 
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
>   since connectors can be added later on, but we still need to attach
>   all properties before they go public.
> 
> Note that we already enforce that properties themselves are created
> before the entire device is registered.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> index 6a23e36ed4fe..35c2719407a8 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
>   * This attaches the given property to the modeset object with the given initial
>   * value. Currently this function cannot fail since the properties are stored in
>   * a statically sized array.
> + *
> + * Note that all properties must be attached before the object itself is
> + * registered and accessible from userspace.
>   */
>  void drm_object_attach_property(struct drm_mode_object *obj,
>  				struct drm_property *property,
>  				uint64_t init_val)
>  {
>  	int count = obj->properties->count;
> +	struct drm_device *dev = property->dev;
> +
> +
> +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> +		struct drm_connector *connector = obj_to_connector(obj);
> +
> +		WARN_ON(!dev->driver->load &&
> +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> +	} else {
> +		WARN_ON(!dev->driver->load && dev->registered);
> +	}

I'm not sure I understand why dev->driver->load needs to be a special
case. Don't the same rules apply for those drivers as well?

Thierry

>  
>  	if (count == DRM_OBJECT_MAX_PROPERTY) {
>  		WARN(1, "Failed to attach object property (type: 0x%x). Please "
> -- 
> 2.23.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [PATCH 1/2] drm/property: Enforce more lifetime rules

[Thierry Reding]

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

On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > Properties can't be attached after registering, userspace would get
> > confused (no one bothers to reprobe really).
> > 
> > - Add kerneldoc
> > - Enforce this with some checks. This needs a somewhat ugly check
> >   since connectors can be added later on, but we still need to attach
> >   all properties before they go public.
> > 
> > Note that we already enforce that properties themselves are created
> > before the entire device is registered.
> > 
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Rajat Jain <rajatja@google.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> > index 6a23e36ed4fe..35c2719407a8 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
> >   * This attaches the given property to the modeset object with the given initial
> >   * value. Currently this function cannot fail since the properties are stored in
> >   * a statically sized array.
> > + *
> > + * Note that all properties must be attached before the object itself is
> > + * registered and accessible from userspace.
> >   */
> >  void drm_object_attach_property(struct drm_mode_object *obj,
> >  				struct drm_property *property,
> >  				uint64_t init_val)
> >  {
> >  	int count = obj->properties->count;
> > +	struct drm_device *dev = property->dev;
> > +
> > +
> > +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> > +		struct drm_connector *connector = obj_to_connector(obj);
> > +
> > +		WARN_ON(!dev->driver->load &&
> > +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> > +	} else {
> > +		WARN_ON(!dev->driver->load && dev->registered);
> > +	}
> 
> I'm not sure I understand why dev->driver->load needs to be a special
> case. Don't the same rules apply for those drivers as well?

Nevermind, I just noticed that drm_dev_register() sets dev->registered
to true before calling the driver's ->load() implementation, so makes
sense:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Thierry Reding]

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

On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > Properties can't be attached after registering, userspace would get
> > confused (no one bothers to reprobe really).
> > 
> > - Add kerneldoc
> > - Enforce this with some checks. This needs a somewhat ugly check
> >   since connectors can be added later on, but we still need to attach
> >   all properties before they go public.
> > 
> > Note that we already enforce that properties themselves are created
> > before the entire device is registered.
> > 
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Rajat Jain <rajatja@google.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> > index 6a23e36ed4fe..35c2719407a8 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
> >   * This attaches the given property to the modeset object with the given initial
> >   * value. Currently this function cannot fail since the properties are stored in
> >   * a statically sized array.
> > + *
> > + * Note that all properties must be attached before the object itself is
> > + * registered and accessible from userspace.
> >   */
> >  void drm_object_attach_property(struct drm_mode_object *obj,
> >  				struct drm_property *property,
> >  				uint64_t init_val)
> >  {
> >  	int count = obj->properties->count;
> > +	struct drm_device *dev = property->dev;
> > +
> > +
> > +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> > +		struct drm_connector *connector = obj_to_connector(obj);
> > +
> > +		WARN_ON(!dev->driver->load &&
> > +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> > +	} else {
> > +		WARN_ON(!dev->driver->load && dev->registered);
> > +	}
> 
> I'm not sure I understand why dev->driver->load needs to be a special
> case. Don't the same rules apply for those drivers as well?

Nevermind, I just noticed that drm_dev_register() sets dev->registered
to true before calling the driver's ->load() implementation, so makes
sense:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Thierry Reding]

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

On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > Properties can't be attached after registering, userspace would get
> > confused (no one bothers to reprobe really).
> > 
> > - Add kerneldoc
> > - Enforce this with some checks. This needs a somewhat ugly check
> >   since connectors can be added later on, but we still need to attach
> >   all properties before they go public.
> > 
> > Note that we already enforce that properties themselves are created
> > before the entire device is registered.
> > 
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Rajat Jain <rajatja@google.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> > index 6a23e36ed4fe..35c2719407a8 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
> >   * This attaches the given property to the modeset object with the given initial
> >   * value. Currently this function cannot fail since the properties are stored in
> >   * a statically sized array.
> > + *
> > + * Note that all properties must be attached before the object itself is
> > + * registered and accessible from userspace.
> >   */
> >  void drm_object_attach_property(struct drm_mode_object *obj,
> >  				struct drm_property *property,
> >  				uint64_t init_val)
> >  {
> >  	int count = obj->properties->count;
> > +	struct drm_device *dev = property->dev;
> > +
> > +
> > +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> > +		struct drm_connector *connector = obj_to_connector(obj);
> > +
> > +		WARN_ON(!dev->driver->load &&
> > +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> > +	} else {
> > +		WARN_ON(!dev->driver->load && dev->registered);
> > +	}
> 
> I'm not sure I understand why dev->driver->load needs to be a special
> case. Don't the same rules apply for those drivers as well?

Nevermind, I just noticed that drm_dev_register() sets dev->registered
to true before calling the driver's ->load() implementation, so makes
sense:

Reviewed-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

Re: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Daniel Vetter]

On Thu, Oct 24, 2019 at 12:43 PM Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> > On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > > Properties can't be attached after registering, userspace would get
> > > confused (no one bothers to reprobe really).
> > >
> > > - Add kerneldoc
> > > - Enforce this with some checks. This needs a somewhat ugly check
> > >   since connectors can be added later on, but we still need to attach
> > >   all properties before they go public.
> > >
> > > Note that we already enforce that properties themselves are created
> > > before the entire device is registered.
> > >
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Rajat Jain <rajatja@google.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> > > index 6a23e36ed4fe..35c2719407a8 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
> > >   * This attaches the given property to the modeset object with the given initial
> > >   * value. Currently this function cannot fail since the properties are stored in
> > >   * a statically sized array.
> > > + *
> > > + * Note that all properties must be attached before the object itself is
> > > + * registered and accessible from userspace.
> > >   */
> > >  void drm_object_attach_property(struct drm_mode_object *obj,
> > >                             struct drm_property *property,
> > >                             uint64_t init_val)
> > >  {
> > >     int count = obj->properties->count;
> > > +   struct drm_device *dev = property->dev;
> > > +
> > > +
> > > +   if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> > > +           struct drm_connector *connector = obj_to_connector(obj);
> > > +
> > > +           WARN_ON(!dev->driver->load &&
> > > +                   connector->registration_state == DRM_CONNECTOR_REGISTERED);
> > > +   } else {
> > > +           WARN_ON(!dev->driver->load && dev->registered);
> > > +   }
> >
> > I'm not sure I understand why dev->driver->load needs to be a special
> > case. Don't the same rules apply for those drivers as well?
>
> Nevermind, I just noticed that drm_dev_register() sets dev->registered
> to true before calling the driver's ->load() implementation, so makes
> sense:

We tried to be clever with this already before, see:

commit e0f32f78e51b9989ee89f608fd0dd10e9c230652 (tag:
drm-misc-next-fixes-2019-09-18)
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Sep 17 14:09:35 2019 +0200

    drm/kms: Duct-tape for mode object lifetime checks

    commit 4f5368b5541a902f6596558b05f5c21a9770dd32
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Jun 14 08:17:23 2019 +0200

        drm/kms: Catch mode_object lifetime errors

    uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
    all except i915) register all the dp stuff in their init code, which
    is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up,
    because drm_dp_aux_register tries to add a child to a device in sysfs
    (the connector) which doesn't even exist yet.

    No one seems to have cared thus far. But with the above change I also
    moved the setting of dev->registered after the ->load callback, in an
    attempt to keep old drivers from hitting any WARN_ON backtraces. But
    that moved radeon.ko from the "working, by accident" to "now also
    broken" category.

    Since this is a huge mess I figured a revert would be simplest. But
    this check has already caught issues in i915:

    commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0
    Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Date:   Tue Aug 20 19:16:57 2019 +0300

        drm/i915: Do not create a new max_bpc prop for MST connectors

    Hence I'd like to retain it. Fix the radeon regression by moving the
    setting of dev->registered back to were it was, and stop the
    backtraces with an explicit check for dev->driver->load.

    Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
    next patch will improve the kerneldoc and add a todo entry for this.

    Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors")
    Cc: Sean Paul <sean@poorly.run>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Reported-by: Michel Dänzer <michel@daenzer.net>
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    Tested-by: Michel Dänzer <mdaenzer@redhat.com>
    Cc: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190917120936.7501-1-daniel.vetter@ffwll.ch>

I think I'll add a reference to the above to the commit message when applying.

> Reviewed-by: Thierry Reding <treding@nvidia.com>

Thanks for taking a look.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Daniel Vetter]

On Thu, Oct 24, 2019 at 12:43 PM Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> > On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > > Properties can't be attached after registering, userspace would get
> > > confused (no one bothers to reprobe really).
> > >
> > > - Add kerneldoc
> > > - Enforce this with some checks. This needs a somewhat ugly check
> > >   since connectors can be added later on, but we still need to attach
> > >   all properties before they go public.
> > >
> > > Note that we already enforce that properties themselves are created
> > > before the entire device is registered.
> > >
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Rajat Jain <rajatja@google.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> > > index 6a23e36ed4fe..35c2719407a8 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
> > >   * This attaches the given property to the modeset object with the given initial
> > >   * value. Currently this function cannot fail since the properties are stored in
> > >   * a statically sized array.
> > > + *
> > > + * Note that all properties must be attached before the object itself is
> > > + * registered and accessible from userspace.
> > >   */
> > >  void drm_object_attach_property(struct drm_mode_object *obj,
> > >                             struct drm_property *property,
> > >                             uint64_t init_val)
> > >  {
> > >     int count = obj->properties->count;
> > > +   struct drm_device *dev = property->dev;
> > > +
> > > +
> > > +   if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> > > +           struct drm_connector *connector = obj_to_connector(obj);
> > > +
> > > +           WARN_ON(!dev->driver->load &&
> > > +                   connector->registration_state == DRM_CONNECTOR_REGISTERED);
> > > +   } else {
> > > +           WARN_ON(!dev->driver->load && dev->registered);
> > > +   }
> >
> > I'm not sure I understand why dev->driver->load needs to be a special
> > case. Don't the same rules apply for those drivers as well?
>
> Nevermind, I just noticed that drm_dev_register() sets dev->registered
> to true before calling the driver's ->load() implementation, so makes
> sense:

We tried to be clever with this already before, see:

commit e0f32f78e51b9989ee89f608fd0dd10e9c230652 (tag:
drm-misc-next-fixes-2019-09-18)
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Sep 17 14:09:35 2019 +0200

    drm/kms: Duct-tape for mode object lifetime checks

    commit 4f5368b5541a902f6596558b05f5c21a9770dd32
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Jun 14 08:17:23 2019 +0200

        drm/kms: Catch mode_object lifetime errors

    uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
    all except i915) register all the dp stuff in their init code, which
    is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up,
    because drm_dp_aux_register tries to add a child to a device in sysfs
    (the connector) which doesn't even exist yet.

    No one seems to have cared thus far. But with the above change I also
    moved the setting of dev->registered after the ->load callback, in an
    attempt to keep old drivers from hitting any WARN_ON backtraces. But
    that moved radeon.ko from the "working, by accident" to "now also
    broken" category.

    Since this is a huge mess I figured a revert would be simplest. But
    this check has already caught issues in i915:

    commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0
    Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Date:   Tue Aug 20 19:16:57 2019 +0300

        drm/i915: Do not create a new max_bpc prop for MST connectors

    Hence I'd like to retain it. Fix the radeon regression by moving the
    setting of dev->registered back to were it was, and stop the
    backtraces with an explicit check for dev->driver->load.

    Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
    next patch will improve the kerneldoc and add a todo entry for this.

    Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors")
    Cc: Sean Paul <sean@poorly.run>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Reported-by: Michel Dänzer <michel@daenzer.net>
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    Tested-by: Michel Dänzer <mdaenzer@redhat.com>
    Cc: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190917120936.7501-1-daniel.vetter@ffwll.ch>

I think I'll add a reference to the above to the commit message when applying.

> Reviewed-by: Thierry Reding <treding@nvidia.com>

Thanks for taking a look.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/2] drm/property: Enforce more lifetime rules

[Jani Nikula]

On Wed, 23 Oct 2019, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
>
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
>   since connectors can be added later on, but we still need to attach
>   all properties before they go public.
>
> Note that we already enforce that properties themselves are created
> before the entire device is registered.
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> index 6a23e36ed4fe..35c2719407a8 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
>   * This attaches the given property to the modeset object with the given initial
>   * value. Currently this function cannot fail since the properties are stored in
>   * a statically sized array.
> + *
> + * Note that all properties must be attached before the object itself is
> + * registered and accessible from userspace.
>   */
>  void drm_object_attach_property(struct drm_mode_object *obj,
>  				struct drm_property *property,
>  				uint64_t init_val)
>  {
>  	int count = obj->properties->count;
> +	struct drm_device *dev = property->dev;
> +
> +

Superfluous newline, with that fixed,

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

> +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> +		struct drm_connector *connector = obj_to_connector(obj);
> +
> +		WARN_ON(!dev->driver->load &&
> +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> +	} else {
> +		WARN_ON(!dev->driver->load && dev->registered);
> +	}
>  
>  	if (count == DRM_OBJECT_MAX_PROPERTY) {
>  		WARN(1, "Failed to attach object property (type: 0x%x). Please "

-- 
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 1/2] drm/property: Enforce more lifetime rules

[Jani Nikula]

On Wed, 23 Oct 2019, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
>
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
>   since connectors can be added later on, but we still need to attach
>   all properties before they go public.
>
> Note that we already enforce that properties themselves are created
> before the entire device is registered.
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> index 6a23e36ed4fe..35c2719407a8 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
>   * This attaches the given property to the modeset object with the given initial
>   * value. Currently this function cannot fail since the properties are stored in
>   * a statically sized array.
> + *
> + * Note that all properties must be attached before the object itself is
> + * registered and accessible from userspace.
>   */
>  void drm_object_attach_property(struct drm_mode_object *obj,
>  				struct drm_property *property,
>  				uint64_t init_val)
>  {
>  	int count = obj->properties->count;
> +	struct drm_device *dev = property->dev;
> +
> +

Superfluous newline, with that fixed,

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

> +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> +		struct drm_connector *connector = obj_to_connector(obj);
> +
> +		WARN_ON(!dev->driver->load &&
> +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> +	} else {
> +		WARN_ON(!dev->driver->load && dev->registered);
> +	}
>  
>  	if (count == DRM_OBJECT_MAX_PROPERTY) {
>  		WARN(1, "Failed to attach object property (type: 0x%x). Please "

-- 
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: [Intel-gfx] [PATCH 1/2] drm/property: Enforce more lifetime rules

[Jani Nikula]

On Wed, 23 Oct 2019, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
>
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
>   since connectors can be added later on, but we still need to attach
>   all properties before they go public.
>
> Note that we already enforce that properties themselves are created
> before the entire device is registered.
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rajat Jain <rajatja@google.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> index 6a23e36ed4fe..35c2719407a8 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
>   * This attaches the given property to the modeset object with the given initial
>   * value. Currently this function cannot fail since the properties are stored in
>   * a statically sized array.
> + *
> + * Note that all properties must be attached before the object itself is
> + * registered and accessible from userspace.
>   */
>  void drm_object_attach_property(struct drm_mode_object *obj,
>  				struct drm_property *property,
>  				uint64_t init_val)
>  {
>  	int count = obj->properties->count;
> +	struct drm_device *dev = property->dev;
> +
> +

Superfluous newline, with that fixed,

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

> +	if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> +		struct drm_connector *connector = obj_to_connector(obj);
> +
> +		WARN_ON(!dev->driver->load &&
> +			connector->registration_state == DRM_CONNECTOR_REGISTERED);
> +	} else {
> +		WARN_ON(!dev->driver->load && dev->registered);
> +	}
>  
>  	if (count == DRM_OBJECT_MAX_PROPERTY) {
>  		WARN(1, "Failed to attach object property (type: 0x%x). Please "

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

✗ Fi.CI.IGT: failure for series starting with [1/2] drm/property: Enforce more lifetime rules

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/property: Enforce more lifetime rules
URL   : https://patchwork.freedesktop.org/series/68467/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7167_full -> Patchwork_14952_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_14952_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14952_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_14952_full:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_ctx_shared@q-promotion-bsd1:
    - shard-iclb:         NOTRUN -> [FAIL][1] +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_ctx_shared@q-promotion-bsd1.html
    - shard-apl:          [PASS][2] -> [FAIL][3]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-apl2/igt@gem_ctx_shared@q-promotion-bsd1.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-apl8/igt@gem_ctx_shared@q-promotion-bsd1.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
    - {shard-tglb}:       [PASS][4] -> [INCOMPLETE][5]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb1/igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb2/igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@vcs1-dirty-create:
    - shard-iclb:         [PASS][6] -> [SKIP][7] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb1/igt@gem_ctx_isolation@vcs1-dirty-create.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@gem_ctx_isolation@vcs1-dirty-create.html

  * igt@gem_eio@in-flight-suspend:
    - shard-skl:          [PASS][8] -> [INCOMPLETE][9] ([fdo#104108])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl1/igt@gem_eio@in-flight-suspend.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl9/igt@gem_eio@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][10] -> [SKIP][11] ([fdo#110854])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_parallel@vcs1-fds:
    - shard-iclb:         [PASS][12] -> [SKIP][13] ([fdo#112080]) +7 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@gem_exec_parallel@vcs1-fds.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_exec_parallel@vcs1-fds.html

  * igt@gem_exec_schedule@pi-ringfull-render:
    - shard-kbl:          [PASS][14] -> [INCOMPLETE][15] ([fdo#103665])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl6/igt@gem_exec_schedule@pi-ringfull-render.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl2/igt@gem_exec_schedule@pi-ringfull-render.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [PASS][16] -> [SKIP][17] ([fdo#111325]) +5 similar issues
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-snb:          [PASS][18] -> [DMESG-WARN][19] ([fdo#111870])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb2/igt@gem_userptr_blits@dmabuf-sync.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb2/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
    - shard-hsw:          [PASS][20] -> [DMESG-WARN][21] ([fdo#111870])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [PASS][22] -> [DMESG-WARN][23] ([fdo#108566]) +1 similar issue
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-apl7/igt@i915_suspend@sysfs-reader.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-apl6/igt@i915_suspend@sysfs-reader.html

  * igt@kms_color@pipe-b-ctm-0-75:
    - shard-skl:          [PASS][24] -> [DMESG-WARN][25] ([fdo#106107])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl4/igt@kms_color@pipe-b-ctm-0-75.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl8/igt@kms_color@pipe-b-ctm-0-75.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          [PASS][26] -> [FAIL][27] ([fdo#105363])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
    - shard-apl:          [PASS][28] -> [INCOMPLETE][29] ([fdo#103927]) +1 similar issue
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-apl8/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-apl1/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-skl:          [PASS][30] -> [INCOMPLETE][31] ([fdo#109507])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl8/igt@kms_flip@flip-vs-suspend.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl1/igt@kms_flip@flip-vs-suspend.html
    - shard-hsw:          [PASS][32] -> [INCOMPLETE][33] ([fdo#103540])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw4/igt@kms_flip@flip-vs-suspend.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw4/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite:
    - shard-iclb:         [PASS][34] -> [FAIL][35] ([fdo#103167]) +5 similar issues
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-kbl:          [PASS][36] -> [DMESG-WARN][37] ([fdo#108566]) +1 similar issue
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][38] -> [FAIL][39] ([fdo#108145] / [fdo#110403])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][40] -> [SKIP][41] ([fdo#109642] / [fdo#111068])
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb4/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@no_drrs:
    - shard-iclb:         [PASS][42] -> [FAIL][43] ([fdo#108341])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb4/igt@kms_psr@no_drrs.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb1/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [PASS][44] -> [SKIP][45] ([fdo#109441]) +1 similar issue
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@kms_psr@psr2_cursor_blt.html

  * igt@prime_busy@after-bsd2:
    - shard-iclb:         [PASS][46] -> [SKIP][47] ([fdo#109276]) +9 similar issues
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb1/igt@prime_busy@after-bsd2.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@prime_busy@after-bsd2.html

  * igt@prime_busy@wait-hang-bsd:
    - shard-kbl:          [PASS][48] -> [SKIP][49] ([fdo#109271])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl6/igt@prime_busy@wait-hang-bsd.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl2/igt@prime_busy@wait-hang-bsd.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-kbl:          [DMESG-WARN][50] ([fdo#108566]) -> [PASS][51] +7 similar issues
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl1/igt@gem_ctx_isolation@rcs0-s3.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl4/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_ctx_isolation@vcs1-none:
    - shard-iclb:         [SKIP][52] ([fdo#109276] / [fdo#112080]) -> [PASS][53]
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb6/igt@gem_ctx_isolation@vcs1-none.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@gem_ctx_isolation@vcs1-none.html

  * igt@gem_ctx_switch@vcs1-heavy-queue:
    - shard-iclb:         [SKIP][54] ([fdo#112080]) -> [PASS][55] +14 similar issues
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@gem_ctx_switch@vcs1-heavy-queue.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@gem_ctx_switch@vcs1-heavy-queue.html

  * igt@gem_eio@unwedge-stress:
    - shard-snb:          [FAIL][56] ([fdo#109661]) -> [PASS][57] +1 similar issue
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb5/igt@gem_eio@unwedge-stress.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb1/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_reloc@basic-cpu-wc-active:
    - shard-skl:          [DMESG-WARN][58] ([fdo#106107]) -> [PASS][59]
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl6/igt@gem_exec_reloc@basic-cpu-wc-active.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl9/igt@gem_exec_reloc@basic-cpu-wc-active.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [SKIP][60] ([fdo#111325]) -> [PASS][61] +5 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-render:
    - shard-kbl:          [FAIL][62] -> [PASS][63] +1 similar issue
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl2/igt@gem_exec_schedule@preempt-queue-contexts-render.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl3/igt@gem_exec_schedule@preempt-queue-contexts-render.html

  * igt@gem_linear_blits@interruptible:
    - {shard-tglb}:       [TIMEOUT][64] -> [PASS][65] +1 similar issue
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb7/igt@gem_linear_blits@interruptible.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb5/igt@gem_linear_blits@interruptible.html

  * igt@gem_persistent_relocs@forked-thrash-inactive:
    - shard-snb:          [INCOMPLETE][66] ([fdo#105411]) -> [PASS][67]
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb4/igt@gem_persistent_relocs@forked-thrash-inactive.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb4/igt@gem_persistent_relocs@forked-thrash-inactive.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][68] ([fdo#104108]) -> [PASS][69] +1 similar issue
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl6/igt@gem_softpin@noreloc-s3.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl9/igt@gem_softpin@noreloc-s3.html

  * igt@gem_sync@basic-store-all:
    - {shard-tglb}:       [INCOMPLETE][70] ([fdo#111647]) -> [PASS][71]
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb4/igt@gem_sync@basic-store-all.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb8/igt@gem_sync@basic-store-all.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
    - shard-snb:          [DMESG-WARN][72] ([fdo#111870]) -> [PASS][73]
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb5/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-hsw:          [DMESG-WARN][74] ([fdo#111870]) -> [PASS][75]
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw4/igt@gem_userptr_blits@sync-unmap.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw5/igt@gem_userptr_blits@sync-unmap.html

  * igt@i915_hangman@error-state-basic:
    - shard-kbl:          [SKIP][76] ([fdo#109271]) -> [PASS][77] +2 similar issues
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl2/igt@i915_hangman@error-state-basic.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl3/igt@i915_hangman@error-state-basic.html

  * {igt@i915_pm_dc@dc6-dpms}:
    - shard-iclb:         [FAIL][78] ([fdo#110548]) -> [PASS][79]
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb7/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_rpm@modeset-stress-extra-wait:
    - shard-glk:          [DMESG-WARN][80] ([fdo#105763] / [fdo#106538]) -> [PASS][81]
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-glk8/igt@i915_pm_rpm@modeset-stress-extra-wait.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-glk3/igt@i915_pm_rpm@modeset-stress-extra-wait.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
    - shard-skl:          [INCOMPLETE][82] ([fdo#104108] / [fdo#107807]) -> [PASS][83]
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl7/igt@i915_pm_rpm@system-suspend-execbuf.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl7/igt@i915_pm_rpm@system-suspend-execbuf.html

  * {igt@i915_selftest@live_gt_heartbeat}:
    - shard-skl:          [DMESG-FAIL][84] -> [PASS][85]
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl3/igt@i915_selftest@live_gt_heartbeat.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl7/igt@i915_selftest@live_gt_heartbeat.html

  * igt@i915_selftest@live_hangcheck:
    - shard-hsw:          [DMESG-FAIL][86] ([fdo#111991]) -> [PASS][87]
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw7/igt@i915_selftest@live_hangcheck.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw1/igt@i915_selftest@live_hangcheck.html
    - shard-iclb:         [INCOMPLETE][88] ([fdo#107713] / [fdo#108569]) -> [PASS][89]
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@i915_selftest@live_hangcheck.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@i915_selftest@live_hangcheck.html

  * igt@kms_cursor_legacy@cursor-vs-flip-legacy:
    - shard-hsw:          [FAIL][90] ([fdo#103355]) -> [PASS][91]
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw6/igt@kms_cursor_legacy@cursor-vs-flip-legacy.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw8/igt@kms_cursor_legacy@cursor-vs-flip-legacy.html

  * igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
    - {shard-tglb}:       [INCOMPLETE][92] -> [PASS][93]
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb3/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb2/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - shard-iclb:         [FAIL][94] ([fdo#103167]) -> [PASS][95] +8 similar issues
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt:
    - shard-snb:          [SKIP][96] ([fdo#109271]) -> [PASS][97] +1 similar issue
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - {shard-tglb}:       [INCOMPLETE][98] ([fdo#111832] / [fdo#111850] / [fdo#111884]) -> [PASS][99]
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb4/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb1/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
    - shard-iclb:         [FAIL][100] ([fdo#103167] / [fdo#110378]) -> [PASS][101]
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-rte.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-rte.html

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
    - {shard-tglb}:       [FAIL][102] ([fdo#103167]) -> [PASS][103] +2 similar issues
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [FAIL][104] ([fdo#108145]) -> [PASS][105]
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
    - shard-iclb:         [SKIP][106] ([fd

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/index.html
_______________________________________________
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 [1/2] drm/property: Enforce more lifetime rules

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/property: Enforce more lifetime rules
URL   : https://patchwork.freedesktop.org/series/68467/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7167_full -> Patchwork_14952_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_14952_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14952_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_14952_full:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_ctx_shared@q-promotion-bsd1:
    - shard-iclb:         NOTRUN -> [FAIL][1] +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_ctx_shared@q-promotion-bsd1.html
    - shard-apl:          [PASS][2] -> [FAIL][3]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-apl2/igt@gem_ctx_shared@q-promotion-bsd1.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-apl8/igt@gem_ctx_shared@q-promotion-bsd1.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
    - {shard-tglb}:       [PASS][4] -> [INCOMPLETE][5]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb1/igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb2/igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@vcs1-dirty-create:
    - shard-iclb:         [PASS][6] -> [SKIP][7] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb1/igt@gem_ctx_isolation@vcs1-dirty-create.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@gem_ctx_isolation@vcs1-dirty-create.html

  * igt@gem_eio@in-flight-suspend:
    - shard-skl:          [PASS][8] -> [INCOMPLETE][9] ([fdo#104108])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl1/igt@gem_eio@in-flight-suspend.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl9/igt@gem_eio@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][10] -> [SKIP][11] ([fdo#110854])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_parallel@vcs1-fds:
    - shard-iclb:         [PASS][12] -> [SKIP][13] ([fdo#112080]) +7 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@gem_exec_parallel@vcs1-fds.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_exec_parallel@vcs1-fds.html

  * igt@gem_exec_schedule@pi-ringfull-render:
    - shard-kbl:          [PASS][14] -> [INCOMPLETE][15] ([fdo#103665])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl6/igt@gem_exec_schedule@pi-ringfull-render.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl2/igt@gem_exec_schedule@pi-ringfull-render.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [PASS][16] -> [SKIP][17] ([fdo#111325]) +5 similar issues
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-snb:          [PASS][18] -> [DMESG-WARN][19] ([fdo#111870])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb2/igt@gem_userptr_blits@dmabuf-sync.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb2/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
    - shard-hsw:          [PASS][20] -> [DMESG-WARN][21] ([fdo#111870])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [PASS][22] -> [DMESG-WARN][23] ([fdo#108566]) +1 similar issue
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-apl7/igt@i915_suspend@sysfs-reader.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-apl6/igt@i915_suspend@sysfs-reader.html

  * igt@kms_color@pipe-b-ctm-0-75:
    - shard-skl:          [PASS][24] -> [DMESG-WARN][25] ([fdo#106107])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl4/igt@kms_color@pipe-b-ctm-0-75.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl8/igt@kms_color@pipe-b-ctm-0-75.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          [PASS][26] -> [FAIL][27] ([fdo#105363])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
    - shard-apl:          [PASS][28] -> [INCOMPLETE][29] ([fdo#103927]) +1 similar issue
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-apl8/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-apl1/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-skl:          [PASS][30] -> [INCOMPLETE][31] ([fdo#109507])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl8/igt@kms_flip@flip-vs-suspend.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl1/igt@kms_flip@flip-vs-suspend.html
    - shard-hsw:          [PASS][32] -> [INCOMPLETE][33] ([fdo#103540])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw4/igt@kms_flip@flip-vs-suspend.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw4/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite:
    - shard-iclb:         [PASS][34] -> [FAIL][35] ([fdo#103167]) +5 similar issues
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-kbl:          [PASS][36] -> [DMESG-WARN][37] ([fdo#108566]) +1 similar issue
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][38] -> [FAIL][39] ([fdo#108145] / [fdo#110403])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][40] -> [SKIP][41] ([fdo#109642] / [fdo#111068])
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb4/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@no_drrs:
    - shard-iclb:         [PASS][42] -> [FAIL][43] ([fdo#108341])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb4/igt@kms_psr@no_drrs.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb1/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [PASS][44] -> [SKIP][45] ([fdo#109441]) +1 similar issue
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@kms_psr@psr2_cursor_blt.html

  * igt@prime_busy@after-bsd2:
    - shard-iclb:         [PASS][46] -> [SKIP][47] ([fdo#109276]) +9 similar issues
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb1/igt@prime_busy@after-bsd2.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@prime_busy@after-bsd2.html

  * igt@prime_busy@wait-hang-bsd:
    - shard-kbl:          [PASS][48] -> [SKIP][49] ([fdo#109271])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl6/igt@prime_busy@wait-hang-bsd.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl2/igt@prime_busy@wait-hang-bsd.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-kbl:          [DMESG-WARN][50] ([fdo#108566]) -> [PASS][51] +7 similar issues
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl1/igt@gem_ctx_isolation@rcs0-s3.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl4/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_ctx_isolation@vcs1-none:
    - shard-iclb:         [SKIP][52] ([fdo#109276] / [fdo#112080]) -> [PASS][53]
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb6/igt@gem_ctx_isolation@vcs1-none.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@gem_ctx_isolation@vcs1-none.html

  * igt@gem_ctx_switch@vcs1-heavy-queue:
    - shard-iclb:         [SKIP][54] ([fdo#112080]) -> [PASS][55] +14 similar issues
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@gem_ctx_switch@vcs1-heavy-queue.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@gem_ctx_switch@vcs1-heavy-queue.html

  * igt@gem_eio@unwedge-stress:
    - shard-snb:          [FAIL][56] ([fdo#109661]) -> [PASS][57] +1 similar issue
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb5/igt@gem_eio@unwedge-stress.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb1/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_reloc@basic-cpu-wc-active:
    - shard-skl:          [DMESG-WARN][58] ([fdo#106107]) -> [PASS][59]
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl6/igt@gem_exec_reloc@basic-cpu-wc-active.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl9/igt@gem_exec_reloc@basic-cpu-wc-active.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [SKIP][60] ([fdo#111325]) -> [PASS][61] +5 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb5/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-render:
    - shard-kbl:          [FAIL][62] -> [PASS][63] +1 similar issue
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl2/igt@gem_exec_schedule@preempt-queue-contexts-render.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl3/igt@gem_exec_schedule@preempt-queue-contexts-render.html

  * igt@gem_linear_blits@interruptible:
    - {shard-tglb}:       [TIMEOUT][64] -> [PASS][65] +1 similar issue
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb7/igt@gem_linear_blits@interruptible.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb5/igt@gem_linear_blits@interruptible.html

  * igt@gem_persistent_relocs@forked-thrash-inactive:
    - shard-snb:          [INCOMPLETE][66] ([fdo#105411]) -> [PASS][67]
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb4/igt@gem_persistent_relocs@forked-thrash-inactive.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb4/igt@gem_persistent_relocs@forked-thrash-inactive.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][68] ([fdo#104108]) -> [PASS][69] +1 similar issue
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl6/igt@gem_softpin@noreloc-s3.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl9/igt@gem_softpin@noreloc-s3.html

  * igt@gem_sync@basic-store-all:
    - {shard-tglb}:       [INCOMPLETE][70] ([fdo#111647]) -> [PASS][71]
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb4/igt@gem_sync@basic-store-all.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb8/igt@gem_sync@basic-store-all.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
    - shard-snb:          [DMESG-WARN][72] ([fdo#111870]) -> [PASS][73]
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb5/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-hsw:          [DMESG-WARN][74] ([fdo#111870]) -> [PASS][75]
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw4/igt@gem_userptr_blits@sync-unmap.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw5/igt@gem_userptr_blits@sync-unmap.html

  * igt@i915_hangman@error-state-basic:
    - shard-kbl:          [SKIP][76] ([fdo#109271]) -> [PASS][77] +2 similar issues
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-kbl2/igt@i915_hangman@error-state-basic.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-kbl3/igt@i915_hangman@error-state-basic.html

  * {igt@i915_pm_dc@dc6-dpms}:
    - shard-iclb:         [FAIL][78] ([fdo#110548]) -> [PASS][79]
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb7/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_rpm@modeset-stress-extra-wait:
    - shard-glk:          [DMESG-WARN][80] ([fdo#105763] / [fdo#106538]) -> [PASS][81]
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-glk8/igt@i915_pm_rpm@modeset-stress-extra-wait.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-glk3/igt@i915_pm_rpm@modeset-stress-extra-wait.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
    - shard-skl:          [INCOMPLETE][82] ([fdo#104108] / [fdo#107807]) -> [PASS][83]
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl7/igt@i915_pm_rpm@system-suspend-execbuf.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl7/igt@i915_pm_rpm@system-suspend-execbuf.html

  * {igt@i915_selftest@live_gt_heartbeat}:
    - shard-skl:          [DMESG-FAIL][84] -> [PASS][85]
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl3/igt@i915_selftest@live_gt_heartbeat.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl7/igt@i915_selftest@live_gt_heartbeat.html

  * igt@i915_selftest@live_hangcheck:
    - shard-hsw:          [DMESG-FAIL][86] ([fdo#111991]) -> [PASS][87]
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw7/igt@i915_selftest@live_hangcheck.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw1/igt@i915_selftest@live_hangcheck.html
    - shard-iclb:         [INCOMPLETE][88] ([fdo#107713] / [fdo#108569]) -> [PASS][89]
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb3/igt@i915_selftest@live_hangcheck.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb6/igt@i915_selftest@live_hangcheck.html

  * igt@kms_cursor_legacy@cursor-vs-flip-legacy:
    - shard-hsw:          [FAIL][90] ([fdo#103355]) -> [PASS][91]
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-hsw6/igt@kms_cursor_legacy@cursor-vs-flip-legacy.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-hsw8/igt@kms_cursor_legacy@cursor-vs-flip-legacy.html

  * igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
    - {shard-tglb}:       [INCOMPLETE][92] -> [PASS][93]
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb3/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb2/igt@kms_flip@blocking-absolute-wf_vblank-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - shard-iclb:         [FAIL][94] ([fdo#103167]) -> [PASS][95] +8 similar issues
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt:
    - shard-snb:          [SKIP][96] ([fdo#109271]) -> [PASS][97] +1 similar issue
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-snb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-snb6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - {shard-tglb}:       [INCOMPLETE][98] ([fdo#111832] / [fdo#111850] / [fdo#111884]) -> [PASS][99]
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb4/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb1/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
    - shard-iclb:         [FAIL][100] ([fdo#103167] / [fdo#110378]) -> [PASS][101]
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-rte.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-rte.html

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
    - {shard-tglb}:       [FAIL][102] ([fdo#103167]) -> [PASS][103] +2 similar issues
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [FAIL][104] ([fdo#108145]) -> [PASS][105]
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7167/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
    - shard-iclb:         [SKIP][106] ([fd

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14952/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Daniel Vetter]

On Thu, Oct 24, 2019 at 12:35:52PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 04:49:53PM +0200, Daniel Vetter wrote:
> > They're midlayer, broken, and because of the old gunk, we can't fix
> > them. For examples see the various checks in drm_mode_object.c against
> > dev->registered, which cannot be enforced if the driver still uses the
> > load hook.
> > 
> > Unfortunately our biggest driver still uses load/unload, so this would
> > be really great to get fixed.
> > 
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Harry Wentland <harry.wentland@amd.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/todo.rst | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> 
> Reminds me that I need to still do that for Tegra:
> 
> Reviewed-by: Thierry Reding <treding@nvidia.com>

Both patches applied, thanks for taking a look.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/todo: Add entry to remove load/unload hooks

[Daniel Vetter]

On Thu, Oct 24, 2019 at 12:35:52PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 04:49:53PM +0200, Daniel Vetter wrote:
> > They're midlayer, broken, and because of the old gunk, we can't fix
> > them. For examples see the various checks in drm_mode_object.c against
> > dev->registered, which cannot be enforced if the driver still uses the
> > load hook.
> > 
> > Unfortunately our biggest driver still uses load/unload, so this would
> > be really great to get fixed.
> > 
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Harry Wentland <harry.wentland@amd.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/todo.rst | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> 
> Reminds me that I need to still do that for Tegra:
> 
> Reviewed-by: Thierry Reding <treding@nvidia.com>

Both patches applied, thanks for taking a look.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx