debugfs files are not necessary for the usual operation of the driver
and the device. No need to check for the return values from the debugfs
file creation. Even if one debugfs file fails to create we try with the
next debugfs file and ultimately return success always so that the
driver continues to load.
cleanup will clean all the created debugfs files as the list of file
that are created are maintained in minor->debugfs_list.
Cc: Chris Wilson <[email protected]>
Signed-off-by: Sudip Mukherjee <[email protected]>
---
v1 was drm/i915: add error path
drivers/gpu/drm/i915/i915_debugfs.c | 31 ++++++++++++-------------------
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index caf1382..8b1a42a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5138,29 +5138,22 @@ void intel_display_crc_init(struct drm_device *dev)
int i915_debugfs_init(struct drm_minor *minor)
{
- int ret, i;
+ int i;
- ret = i915_forcewake_create(minor->debugfs_root, minor);
- if (ret)
- return ret;
+ i915_forcewake_create(minor->debugfs_root, minor);
- for (i = 0; i < ARRAY_SIZE(i915_pipe_crc_data); i++) {
- ret = i915_pipe_crc_create(minor->debugfs_root, minor, i);
- if (ret)
- return ret;
- }
+ for (i = 0; i < ARRAY_SIZE(i915_pipe_crc_data); i++)
+ i915_pipe_crc_create(minor->debugfs_root, minor, i);
- for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
- ret = i915_debugfs_create(minor->debugfs_root, minor,
- i915_debugfs_files[i].name,
- i915_debugfs_files[i].fops);
- if (ret)
- return ret;
- }
+ for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++)
+ i915_debugfs_create(minor->debugfs_root, minor,
+ i915_debugfs_files[i].name,
+ i915_debugfs_files[i].fops);
+
+ drm_debugfs_create_files(i915_debugfs_list, I915_DEBUGFS_ENTRIES,
+ minor->debugfs_root, minor);
- return drm_debugfs_create_files(i915_debugfs_list,
- I915_DEBUGFS_ENTRIES,
- minor->debugfs_root, minor);
+ return 0;
}
void i915_debugfs_cleanup(struct drm_minor *minor)
--
1.8.1.2
On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> debugfs files are not necessary for the usual operation of the driver
> and the device. No need to check for the return values from the debugfs
> file creation. Even if one debugfs file fails to create we try with the
> next debugfs file and ultimately return success always so that the
> driver continues to load.
> cleanup will clean all the created debugfs files as the list of file
> that are created are maintained in minor->debugfs_list.
>
> Cc: Chris Wilson <[email protected]>
> Signed-off-by: Sudip Mukherjee <[email protected]>
> ---
A gentle ping.
regards
sudip
On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > debugfs files are not necessary for the usual operation of the driver
> > and the device. No need to check for the return values from the debugfs
> > file creation. Even if one debugfs file fails to create we try with the
> > next debugfs file and ultimately return success always so that the
> > driver continues to load.
Does this even happen? I'm reluctant to merge patches without real-world
justification.
-Daniel
> > cleanup will clean all the created debugfs files as the list of file
> > that are created are maintained in minor->debugfs_list.
> >
> > Cc: Chris Wilson <[email protected]>
> > Signed-off-by: Sudip Mukherjee <[email protected]>
> > ---
> A gentle ping.
>
> regards
> sudip
> _______________________________________________
> dri-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Aug 03, 2015 at 12:54:33PM +0200, Daniel Vetter wrote:
> On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> > On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > > debugfs files are not necessary for the usual operation of the driver
> > > and the device. No need to check for the return values from the debugfs
> > > file creation. Even if one debugfs file fails to create we try with the
> > > next debugfs file and ultimately return success always so that the
> > > driver continues to load.
>
> Does this even happen?
realistically - I don't think it can happen. Even if it happens then
there will be more serious problem like memory crunch or filesystem
problem and in those cases there is no point in continuing to load the
driver.
regards
sudip