[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200227123404.GA962932@kroah.com>
Date: Thu, 27 Feb 2020 13:34:04 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Wambui Karuga <wambui.karugax@...il.com>
Cc: daniel@...ll.ch, airlied@...ux.ie, mripard@...nel.org,
maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 02/21] drm: convert the drm_driver.debugfs_init() hook to
return void.
On Thu, Feb 27, 2020 at 03:29:46PM +0300, Wambui Karuga wrote:
>
>
> On Thu, 27 Feb 2020, Greg KH wrote:
>
> > On Thu, Feb 27, 2020 at 03:02:13PM +0300, Wambui Karuga wrote:
> > > As a result of commit 987d65d01356 (drm: debugfs: make
> > > drm_debugfs_create_files() never fail) and changes to various debugfs
> > > functions in drm/core and across various drivers, there is no need for
> > > the drm_driver.debugfs_init() hook to have a return value. Therefore,
> > > declare it as void.
> > >
> > > Signed-off-by: Wambui Karuga <wambui.karugax@...il.com>
> > > ---
> > > include/drm/drm_drv.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > > index 97109df5beac..c6ae888c672b 100644
> > > --- a/include/drm/drm_drv.h
> > > +++ b/include/drm/drm_drv.h
> > > @@ -323,7 +323,7 @@ struct drm_driver {
> > > *
> > > * Allows drivers to create driver-specific debugfs files.
> > > */
> > > - int (*debugfs_init)(struct drm_minor *minor);
> > > + void (*debugfs_init)(struct drm_minor *minor);
> >
> >
> > Doesn't this patch break the build, or at least, cause lots of build
> > warnings to happen?
> >
> > Fixing it all up later is good, but I don't think you want to break
> > things at this point in the series.
> >
> So, should it come last in the series? All functions that use this hook have
> been converted to void in the patchset.
I recommend fixing up the functions to just always return 0 first, and
then in one last patch, change the function itself to return void along
with this.
That would make it easiest to review, and allow no build warnings at any
point in the series, right?
thanks,
greg k-h
Powered by blists - more mailing lists