All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Alex Deucher <alexdeucher@gmail.com>,
	Deepak R Varma <mh12gx2825@gmail.com>,
	David Airlie <airlied@linux.ie>,
	LKML <linux-kernel@vger.kernel.org>,
	Maling list - DRI developers  <dri-devel@lists.freedesktop.org>,
	Melissa Wen <melissa.srw@gmail.com>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
Date: Tue, 3 Nov 2020 09:23:51 +0100	[thread overview]
Message-ID: <bc1fcda4-d229-c5a1-bea4-eda646a12bd0@amd.com> (raw)
In-Reply-To: <20201103075355.GA2505796@kroah.com>

Am 03.11.20 um 08:53 schrieb Greg KH:
> On Mon, Nov 02, 2020 at 09:48:25PM +0100, Christian König wrote:
>> Am 03.11.20 um 07:53 schrieb Greg KH:
>>> On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
>>>> Am 02.11.20 um 20:43 schrieb Alex Deucher:
>>>>> On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma <mh12gx2825@gmail.com> wrote:
>>>>>> Initializing global variable to 0 or NULL is not necessary and should
>>>>>> be avoided. Issue reported by checkpatch script as:
>>>>>> ERROR: do not initialise globals to 0 (or NULL).
>>>>> I agree that this is technically correct, but a lot of people don't
>>>>> seem to know that so we get a lot of comments about this code for the
>>>>> variables that are not explicitly set.  Seems less confusing to
>>>>> initialize them even if it not necessary.  I don't have a particularly
>>>>> strong opinion on it however.
>>>> Agree with Alex.
>>>>
>>>> Especially for the module parameters we should have a explicit init value
>>>> for documentation purposes, even when it is 0.
>>> Why is this one tiny driver somehow special compared to the entire rest
>>> of the kernel?  (hint, it isn't...)
>> And it certainly shouldn't :)
>>
>>> Please follow the normal coding style rules, there's no reason to ignore
>>> them unless you like to constantly reject patches like this that get
>>> sent to you.
>> Yeah, that's a rather good point.
>>
>> Not a particular strong opinion on this either, but when something global is
>> set to 0 people usually do this to emphases that it is important that it is
>> zero.
> Again, no, that's not what we have been doing in the kernel for the past
> 20+ years.  If you do not set it to anything, we all know it is
> important for it to be set to 0.  Otherwise we would explicitly set it
> to something else.  And if we don't care, then that too doesn't matter
> so we let it be 0 by not initializing it, it doesn't matter.
>
> I think this very change is what started the whole "kernel janitor"
> movement all those years ago, because it was easily proven that this
> simple change saved both time and memory.

Ok, well that is even better because it is a technical argument.

You have convinced me, the patch is Reviewed-by: Christian König 
<christian.koenig@amd.com>.

Regards,
Christian.

>
> This shouldn't even be an argument we are having anymore...
>
> thanks,
>
> greg k-h


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Deepak R Varma <mh12gx2825@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	LKML <linux-kernel@vger.kernel.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Melissa Wen <melissa.srw@gmail.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
Date: Tue, 3 Nov 2020 09:23:51 +0100	[thread overview]
Message-ID: <bc1fcda4-d229-c5a1-bea4-eda646a12bd0@amd.com> (raw)
In-Reply-To: <20201103075355.GA2505796@kroah.com>

Am 03.11.20 um 08:53 schrieb Greg KH:
> On Mon, Nov 02, 2020 at 09:48:25PM +0100, Christian König wrote:
>> Am 03.11.20 um 07:53 schrieb Greg KH:
>>> On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
>>>> Am 02.11.20 um 20:43 schrieb Alex Deucher:
>>>>> On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma <mh12gx2825@gmail.com> wrote:
>>>>>> Initializing global variable to 0 or NULL is not necessary and should
>>>>>> be avoided. Issue reported by checkpatch script as:
>>>>>> ERROR: do not initialise globals to 0 (or NULL).
>>>>> I agree that this is technically correct, but a lot of people don't
>>>>> seem to know that so we get a lot of comments about this code for the
>>>>> variables that are not explicitly set.  Seems less confusing to
>>>>> initialize them even if it not necessary.  I don't have a particularly
>>>>> strong opinion on it however.
>>>> Agree with Alex.
>>>>
>>>> Especially for the module parameters we should have a explicit init value
>>>> for documentation purposes, even when it is 0.
>>> Why is this one tiny driver somehow special compared to the entire rest
>>> of the kernel?  (hint, it isn't...)
>> And it certainly shouldn't :)
>>
>>> Please follow the normal coding style rules, there's no reason to ignore
>>> them unless you like to constantly reject patches like this that get
>>> sent to you.
>> Yeah, that's a rather good point.
>>
>> Not a particular strong opinion on this either, but when something global is
>> set to 0 people usually do this to emphases that it is important that it is
>> zero.
> Again, no, that's not what we have been doing in the kernel for the past
> 20+ years.  If you do not set it to anything, we all know it is
> important for it to be set to 0.  Otherwise we would explicitly set it
> to something else.  And if we don't care, then that too doesn't matter
> so we let it be 0 by not initializing it, it doesn't matter.
>
> I think this very change is what started the whole "kernel janitor"
> movement all those years ago, because it was easily proven that this
> simple change saved both time and memory.

Ok, well that is even better because it is a technical argument.

You have convinced me, the patch is Reviewed-by: Christian König 
<christian.koenig@amd.com>.

Regards,
Christian.

>
> This shouldn't even be an argument we are having anymore...
>
> thanks,
>
> greg k-h

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

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Deepak R Varma <mh12gx2825@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	LKML <linux-kernel@vger.kernel.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Melissa Wen <melissa.srw@gmail.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Alex Deucher <alexdeucher@gmail.com>
Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
Date: Tue, 3 Nov 2020 09:23:51 +0100	[thread overview]
Message-ID: <bc1fcda4-d229-c5a1-bea4-eda646a12bd0@amd.com> (raw)
In-Reply-To: <20201103075355.GA2505796@kroah.com>

Am 03.11.20 um 08:53 schrieb Greg KH:
> On Mon, Nov 02, 2020 at 09:48:25PM +0100, Christian König wrote:
>> Am 03.11.20 um 07:53 schrieb Greg KH:
>>> On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
>>>> Am 02.11.20 um 20:43 schrieb Alex Deucher:
>>>>> On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma <mh12gx2825@gmail.com> wrote:
>>>>>> Initializing global variable to 0 or NULL is not necessary and should
>>>>>> be avoided. Issue reported by checkpatch script as:
>>>>>> ERROR: do not initialise globals to 0 (or NULL).
>>>>> I agree that this is technically correct, but a lot of people don't
>>>>> seem to know that so we get a lot of comments about this code for the
>>>>> variables that are not explicitly set.  Seems less confusing to
>>>>> initialize them even if it not necessary.  I don't have a particularly
>>>>> strong opinion on it however.
>>>> Agree with Alex.
>>>>
>>>> Especially for the module parameters we should have a explicit init value
>>>> for documentation purposes, even when it is 0.
>>> Why is this one tiny driver somehow special compared to the entire rest
>>> of the kernel?  (hint, it isn't...)
>> And it certainly shouldn't :)
>>
>>> Please follow the normal coding style rules, there's no reason to ignore
>>> them unless you like to constantly reject patches like this that get
>>> sent to you.
>> Yeah, that's a rather good point.
>>
>> Not a particular strong opinion on this either, but when something global is
>> set to 0 people usually do this to emphases that it is important that it is
>> zero.
> Again, no, that's not what we have been doing in the kernel for the past
> 20+ years.  If you do not set it to anything, we all know it is
> important for it to be set to 0.  Otherwise we would explicitly set it
> to something else.  And if we don't care, then that too doesn't matter
> so we let it be 0 by not initializing it, it doesn't matter.
>
> I think this very change is what started the whole "kernel janitor"
> movement all those years ago, because it was easily proven that this
> simple change saved both time and memory.

Ok, well that is even better because it is a technical argument.

You have convinced me, the patch is Reviewed-by: Christian König 
<christian.koenig@amd.com>.

Regards,
Christian.

>
> This shouldn't even be an argument we are having anymore...
>
> thanks,
>
> greg k-h

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

  reply	other threads:[~2020-11-03  8:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 18:41 [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL Deepak R Varma
2020-11-02 18:41 ` Deepak R Varma
2020-11-02 18:41 ` Deepak R Varma
2020-11-02 19:43 ` Alex Deucher
2020-11-02 19:43   ` Alex Deucher
2020-11-02 19:43   ` Alex Deucher
2020-11-02 20:06   ` Christian König
2020-11-02 20:06     ` Christian König
2020-11-02 20:06     ` Christian König
2020-11-03  6:53     ` Greg KH
2020-11-03  6:53       ` Greg KH
2020-11-03  6:53       ` Greg KH
2020-11-02 20:48       ` Christian König
2020-11-02 20:48         ` Christian König
2020-11-02 20:48         ` Christian König
2020-11-03  7:53         ` Greg KH
2020-11-03  7:53           ` Greg KH
2020-11-03  7:53           ` Greg KH
2020-11-03  8:23           ` Christian König [this message]
2020-11-03  8:23             ` Christian König
2020-11-03  8:23             ` Christian König
2020-11-03 14:50       ` Deucher, Alexander
2020-11-03 14:50         ` Deucher, Alexander
2020-11-03 14:50         ` Deucher, Alexander
2020-11-03 15:34         ` Greg KH
2020-11-03 15:34           ` Greg KH
2020-11-03 15:34           ` Greg KH
2020-11-02 20:10   ` Greg KH
2020-11-02 20:10     ` Greg KH
2020-11-02 20:10     ` Greg KH
2020-11-02 22:30     ` David Laight
2020-11-02 22:30       ` David Laight
2020-11-02 22:30       ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc1fcda4-d229-c5a1-bea4-eda646a12bd0@amd.com \
    --to=christian.koenig@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=melissa.srw@gmail.com \
    --cc=mh12gx2825@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.