[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54CA0CBA.6030900@ti.com>
Date: Thu, 29 Jan 2015 12:34:34 +0200
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Nicholas Mc Guire <der.herr@...r.at>
CC: "K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
<devel@...uxdriverproject.org>, <linux-fbdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3 v2] hyperv: hyperv_fb.c: match wait_for_completion_timeout
return type
On 29/01/15 11:38, Nicholas Mc Guire wrote:
> On Mon, 26 Jan 2015, Tomi Valkeinen wrote:
>
>> Hi,
>>
>> On 25/01/15 16:47, Nicholas Mc Guire wrote:
>>> Signed-off-by: Nicholas Mc Guire <der.herr@...r.at>
>>> ---
>>>
>>> v2: fixed subject line
>>>
>>> The return type of wait_for_completion_timeout is unsigned long not
>>> int. This patch fixes up the declarations only.
>>>
>>> Patch was compile tested only for x86_64_defconfig + CONFIG_X86_VSMP=y
>>> CONFIG_HYPERV=m, CONFIG_FB_HYPERV=m
>>
>> Why didn't you set the text above as the patch description (which is
>> empty at the moment)?
>>
> basically because the one-line is sufficient to understand the patch
You didn't have one line, you had no description. Patch subject is not
patch description. In the minimal case, the description should have the
same text as the subject, but usually it's better to have a bit more
text in the description.
> and the rest of the information is not relevant for the git log but only
> for the review
>
> if you think it is necessary to understand the patch I'll move it and
> resubmit.
Well, a good description is not only about understanding the code in the
patch. It may contain information like which platform/setup this issue
happened on, are the any possible side effects, or whatever might be
relevant for someone looking at the patch years later.
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists