From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 18 Nov 2002 18:00:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 18 Nov 2002 18:00:10 -0500 Received: from SUNLIGHT.WICHITA.EDU ([156.26.1.5]:56763 "EHLO sunlight.wichita.edu") by vger.kernel.org with ESMTP id ; Mon, 18 Nov 2002 18:00:09 -0500 Date: Mon, 18 Nov 2002 17:07:10 -0600 From: deepak Subject: patch To: linux-kernel@vger.kernel.org Message-id: <3DD66292@webmail.wichita.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: dxbadami@wichita.edu X-EXP32-SerialNo: 00003023 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org how do i uninstall a patch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 18 Nov 2002 18:14:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 18 Nov 2002 18:14:24 -0500 Received: from 1-064.ctame701-1.telepar.net.br ([200.181.137.64]:4804 "EHLO 1-064.ctame701-1.telepar.net.br") by vger.kernel.org with ESMTP id ; Mon, 18 Nov 2002 18:13:57 -0500 Date: Mon, 18 Nov 2002 21:20:43 -0200 (BRST) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: deepak cc: linux-kernel@vger.kernel.org Subject: Re: patch In-Reply-To: <3DD66292@webmail.wichita.edu> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Nov 2002, deepak wrote: > how do i uninstall a patch $ man patch ... -R or --reverse Assume that this patch was created with the old and new files swapped. (Yes, I'm afraid that does happen occa­ sionally, human nature being what it is.) patch attempts to swap each hunk around before applying it. Rejects come out in the swapped format. The -R option ... Next time you should read the man page yourself ;) Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: october@surriel.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 19 Nov 2002 03:25:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 19 Nov 2002 03:25:59 -0500 Received: from smtp-out-2.wanadoo.fr ([193.252.19.254]:25236 "EHLO mel-rto2.wanadoo.fr") by vger.kernel.org with ESMTP id ; Tue, 19 Nov 2002 03:25:59 -0500 From: Duncan Sands To: Rik van Riel , deepak Subject: Re: patch Date: Tue, 19 Nov 2002 08:33:20 +0100 User-Agent: KMail/1.4.7 Cc: linux-kernel@vger.kernel.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200211190833.20443.baldrick@wanadoo.fr> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 19 November 2002 00:20, Rik van Riel wrote: > On Mon, 18 Nov 2002, deepak wrote: > > how do i uninstall a patch > > $ man patch > ... > -R or --reverse > Assume that this patch was created with the old and new > files swapped. (Yes, I'm afraid that does happen occa­ > sionally, human nature being what it is.) patch > attempts to swap each hunk around before applying it. > Rejects come out in the swapped format. The -R option > ... > > Next time you should read the man page yourself ;) Come on, be fair. This text is pretty obscure. If you didn't know so already, would you understand from it that -R undoes a patch? Duncan. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759786Ab0EDQrw (ORCPT ); Tue, 4 May 2010 12:47:52 -0400 Received: from ey-out-2122.google.com ([74.125.78.25]:12261 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753102Ab0EDQru (ORCPT ); Tue, 4 May 2010 12:47:50 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:user-agent; b=km/C6G9kqkskBY+OLWj0Uqi+ECwgSUMXkyrNd0f1jPDB1A7pQcvJHtD385QEQJNuvm U63tCaK6UQrZbhzIAso7EsjxjMA8ZTA6e55n6xRSYUnTtrc0lTpptQgEIHQeNiFl7yos BpKwPeEJo6Anqju2Meza4djyh9vGwTdDJjmSk= Date: Tue, 4 May 2010 18:48:25 +0200 From: Kristoffer Ericson To: jeff@garzik.org Cc: linux-kernel@vger.kernel.org Subject: patch Message-ID: <20100504164825.GA2584@boggieman> Reply-To: Kristoffer Ericson MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey, did you get my patch concerning those hash changes? Havent gotten any reply. Best wishes Kristoffer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755851Ab3KVQll (ORCPT ); Fri, 22 Nov 2013 11:41:41 -0500 Received: from blu0-omc1-s31.blu0.hotmail.com ([65.55.116.42]:26719 "EHLO blu0-omc1-s31.blu0.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755526Ab3KVQlj convert rfc822-to-8bit (ORCPT ); Fri, 22 Nov 2013 11:41:39 -0500 X-Greylist: delayed 369 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 Nov 2013 11:41:39 EST X-TMN: [kRNp0XFnhdmB7iPSnkXUT98U3oVAfhbx] X-Originating-Email: [aschwal@hotmail.com] Message-ID: Date: Fri, 22 Nov 2013 11:35:26 -0500 From: Arthur Schwalbenberg User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Daniel Vetter , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arthur Schwalbenberg Subject: Patch Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8BIT X-OriginalArrivalTime: 22 Nov 2013 16:35:28.0456 (UTC) FILETIME=[DA5BDC80:01CEE7A0] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001 From: Arthur Schwalbenberg Date: Thu, 21 Nov 2013 19:42:44 -0500 Subject: [PATCH] Staging: Fixed compilar warnings and coding style issues in i915_debugfs.c MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is a patch fixing both a compilar warning: ‘val’ may be used uninitialized in this function and various coding style issues which include line length warnings and a few errors as defined by 'checkpatch.pl' tool Signed-off-by: Arthur Schwalbenberg --- drivers/gpu/drm/i915/i915_debugfs.c | 75 ++++++++++++++++++++--------------- 1 file changed, 44 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 6ed45a9..01135d4 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1,5 +1,5 @@ /* - * Copyright © 2008 Intel Corporation + * Copyright © 2008 Intel Corporation * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the "Software"), @@ -87,8 +87,8 @@ static int i915_capabilities(struct seq_file *m, void *data) seq_printf(m, "gen: %d\n", info->gen); seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev)); -#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x)) -#define SEP_SEMICOLON ; +#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x)); +#define SEP_SEMICOLON DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG, SEP_SEMICOLON); #undef PRINT_FLAG #undef SEP_SEMICOLON @@ -144,7 +144,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) if (obj->pin_count) seq_printf(m, " (pinned x %d)", obj->pin_count); if (obj->pin_display) - seq_printf(m, " (display)"); + seq_puts(m, " (display)"); if (obj->fence_reg != I915_FENCE_REG_NONE) seq_printf(m, " (fence: %d)", obj->fence_reg); list_for_each_entry(vma, &obj->vma_list, vma_link) { @@ -210,9 +210,9 @@ static int i915_gem_object_list_info(struct seq_file *m, void *data) total_obj_size = total_gtt_size = count = 0; list_for_each_entry(vma, head, mm_list) { - seq_printf(m, " "); + seq_puts(m, " "); describe_obj(m, vma->obj); - seq_printf(m, "\n"); + seq_puts(m, "\n"); total_obj_size += vma->obj->base.size; total_gtt_size += vma->node.size; count++; @@ -333,7 +333,7 @@ static int per_file_stats(int id, void *ptr, void *data) } \ } while (0) -static int i915_gem_object_info(struct seq_file *m, void* data) +static int i915_gem_object_info(struct seq_file *m, void *data) { struct drm_info_node *node = (struct drm_info_node *) m->private; struct drm_device *dev = node->minor->dev; @@ -460,6 +460,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void *data) static int i915_gem_pageflip_info(struct seq_file *m, void *data) { + struct drm_i915_gem_object *obj = NULL; struct drm_info_node *node = (struct drm_info_node *) m->private; struct drm_device *dev = node->minor->dev; unsigned long flags; @@ -487,19 +488,22 @@ static int i915_gem_pageflip_info(struct seq_file *m, void *data) seq_puts(m, "Stall check enabled, "); else seq_puts(m, "Stall check waiting for page flip ioctl, "); - seq_printf(m, "%d prepares\n", atomic_read(&work->pending)); + + seq_printf(m, "%d prepares\n", + atomic_read(&work->pending)); if (work->old_fb_obj) { - struct drm_i915_gem_object *obj = work->old_fb_obj; + obj = work->old_fb_obj; if (obj) seq_printf(m, "Old framebuffer gtt_offset 0x%08lx\n", - i915_gem_obj_ggtt_offset(obj)); + i915_gem_obj_ggtt_offset(obj)); } if (work->pending_flip_obj) { - struct drm_i915_gem_object *obj = work->pending_flip_obj; + obj = work->pending_flip_obj; if (obj) - seq_printf(m, "New framebuffer gtt_offset 0x%08lx\n", - i915_gem_obj_ggtt_offset(obj)); + seq_printf(m, + "New framebuffer gtt_offset 0x%08lx\n", + i915_gem_obj_ggtt_offset(obj)); } } spin_unlock_irqrestore(&dev->event_lock, flags); @@ -530,9 +534,8 @@ static int i915_gem_request_info(struct seq_file *m, void *data) list_for_each_entry(gem_request, &ring->request_list, list) { - seq_printf(m, " %d @ %d\n", - gem_request->seqno, - (int) (jiffies - gem_request->emitted_jiffies)); + seq_printf(m, " %d @ %d\n", gem_request->seqno, + (int) (jiffies - gem_request->emitted_jiffies)); } count++; } @@ -909,7 +912,9 @@ static int i915_rstdby_delays(struct seq_file *m, void *unused) mutex_unlock(&dev->struct_mutex); - seq_printf(m, "w/ctx: %d, w/o ctx: %d\n", (crstanddelay >> 8) & 0x3f, (crstanddelay & 0x3f)); + seq_printf(m, "w/ctx: %d, w/o ctx: %d\n", + (crstanddelay >> 8) & 0x3f, + (crstanddelay & 0x3f)); return 0; } @@ -929,10 +934,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) seq_printf(m, "Requested P-state: %d\n", (rgvswctl >> 8) & 0xf); seq_printf(m, "Requested VID: %d\n", rgvswctl & 0x3f); - seq_printf(m, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK) >> - MEMSTAT_VID_SHIFT); + seq_printf(m, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK) + >> MEMSTAT_VID_SHIFT); seq_printf(m, "Current P-state: %d\n", - (rgvstat & MEMSTAT_PSTATE_MASK) >> MEMSTAT_PSTATE_SHIFT); + (rgvstat & MEMSTAT_PSTATE_MASK) >> + MEMSTAT_PSTATE_SHIFT); } else if ((IS_GEN6(dev) || IS_GEN7(dev)) && !IS_VALLEYVIEW(dev)) { u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS); u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS); @@ -1173,13 +1179,13 @@ static int gen6_drpc_info(struct seq_file *m) spin_unlock_irq(&dev_priv->uncore.lock); if (forcewake_count) { - seq_puts(m, "RC information inaccurate because somebody " - "holds a forcewake reference \n"); + seq_puts(m, "RC information inaccurate because somebody holds a forcewake reference\n"); } else { /* NB: we cannot use forcewake, else we read the wrong values */ while (count++ < 50 && (I915_READ_NOTRACE(FORCEWAKE_ACK) & 1)) udelay(10); - seq_printf(m, "RC information accurate: %s\n", yesno(count < 51)); + seq_printf(m, "RC information accurate: %s\n", + yesno(count < 51)); } gt_core_status = readl(dev_priv->regs + GEN6_GT_CORE_STATUS); @@ -1549,7 +1555,8 @@ static int i915_context_status(struct seq_file *m, void *unused) describe_ctx(m, ctx); for_each_ring(ring, dev_priv, i) if (ring->default_context == ctx) - seq_printf(m, "(default context %s) ", ring->name); + seq_printf(m, "(default context %s) ", + ring->name); describe_obj(m, ctx->obj); seq_putc(m, '\n'); @@ -1683,10 +1690,15 @@ static void gen6_ppgtt_info(struct seq_file *m, struct drm_device *dev) for_each_ring(ring, dev_priv, i) { seq_printf(m, "%s\n", ring->name); if (INTEL_INFO(dev)->gen == 7) - seq_printf(m, "GFX_MODE: 0x%08x\n", I915_READ(RING_MODE_GEN7(ring))); - seq_printf(m, "PP_DIR_BASE: 0x%08x\n", I915_READ(RING_PP_DIR_BASE(ring))); - seq_printf(m, "PP_DIR_BASE_READ: 0x%08x\n", I915_READ(RING_PP_DIR_BASE_READ(ring))); - seq_printf(m, "PP_DIR_DCLV: 0x%08x\n", I915_READ(RING_PP_DIR_DCLV(ring))); + seq_printf(m, "GFX_MODE: 0x%08x\n", + I915_READ(RING_MODE_GEN7(ring))); + + seq_printf(m, "PP_DIR_BASE: 0x%08x\n", + I915_READ(RING_PP_DIR_BASE(ring))); + seq_printf(m, "PP_DIR_BASE_READ: 0x%08x\n", + I915_READ(RING_PP_DIR_BASE_READ(ring))); + seq_printf(m, "PP_DIR_DCLV: 0x%08x\n", + I915_READ(RING_PP_DIR_DCLV(ring))); } if (dev_priv->mm.aliasing_ppgtt) { struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt; @@ -2347,7 +2359,7 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, { struct drm_i915_private *dev_priv = dev->dev_private; struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe]; - u32 val; + u32 val = 0; int ret; if (pipe_crc->source == source) @@ -2362,7 +2374,7 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, else if (INTEL_INFO(dev)->gen < 5) ret = i9xx_pipe_crc_ctl_reg(dev, pipe, &source, &val); else if (IS_VALLEYVIEW(dev)) - ret = vlv_pipe_crc_ctl_reg(dev,pipe, &source, &val); + ret = vlv_pipe_crc_ctl_reg(dev, pipe, &source, &val); else if (IS_GEN5(dev) || IS_GEN6(dev)) ret = ilk_pipe_crc_ctl_reg(&source, &val); else @@ -3046,7 +3058,8 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_gem_gtt", i915_gem_gtt_info, 0}, {"i915_gem_pinned", i915_gem_gtt_info, 0, (void *) PINNED_LIST}, {"i915_gem_active", i915_gem_object_list_info, 0, (void *) ACTIVE_LIST}, - {"i915_gem_inactive", i915_gem_object_list_info, 0, (void *) INACTIVE_LIST}, + {"i915_gem_inactive", i915_gem_object_list_info, 0, + (void *) INACTIVE_LIST}, {"i915_gem_stolen", i915_gem_stolen_list_info }, {"i915_gem_pageflip", i915_gem_pageflip_info, 0}, {"i915_gem_request", i915_gem_request_info, 0}, -- 1.7.9.5 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932104Ab3KVRgw (ORCPT ); Fri, 22 Nov 2013 12:36:52 -0500 Received: from mail-bk0-f43.google.com ([209.85.214.43]:35062 "EHLO mail-bk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755721Ab3KVRgv (ORCPT ); Fri, 22 Nov 2013 12:36:51 -0500 Message-ID: <528F9630.6090202@linux.com> Date: Fri, 22 Nov 2013 18:36:48 +0100 From: Levente Kurusa Reply-To: Levente Kurusa User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Arthur Schwalbenberg , Daniel Vetter , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arthur Schwalbenberg Subject: Re: Patch References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2013-11-22 17:35, Arthur Schwalbenberg: > > From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001 > From: Arthur Schwalbenberg > Date: Thu, 21 Nov 2013 19:42:44 -0500 > Subject: [PATCH] Staging: Fixed compilar warnings and coding style > issues in i915_debugfs.c > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > This is a patch fixing both a compilar warning: > ‘val’ may be used uninitialized in this function > and various coding style issues which include line length > warnings and a few errors as defined by 'checkpatch.pl' tool > > Signed-off-by: Arthur Schwalbenberg Hi, When you break 80+ lines into two lines, you should also indent the newly created line so that it shows that it is a part of something. I as well don't think it is worth splitting lines that are 84 characters long into two lines, that just doesn't make sense. Also, your patch seems (atleast to me) a 'bit' whitespace damaged. -- Regards, Levente Kurusa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754458Ab3KYI6J (ORCPT ); Mon, 25 Nov 2013 03:58:09 -0500 Received: from mail-wg0-f44.google.com ([74.125.82.44]:50508 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825Ab3KYI6D (ORCPT ); Mon, 25 Nov 2013 03:58:03 -0500 Date: Mon, 25 Nov 2013 09:58:43 +0100 From: Daniel Vetter To: Levente Kurusa Cc: Arthur Schwalbenberg , Daniel Vetter , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arthur Schwalbenberg Subject: Re: Patch Message-ID: <20131125085843.GX27344@phenom.ffwll.local> Mail-Followup-To: Levente Kurusa , Arthur Schwalbenberg , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arthur Schwalbenberg References: <528F9630.6090202@linux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <528F9630.6090202@linux.com> X-Operating-System: Linux phenom 3.12.0+ User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 22, 2013 at 06:36:48PM +0100, Levente Kurusa wrote: > 2013-11-22 17:35, Arthur Schwalbenberg: > > > > From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001 > > From: Arthur Schwalbenberg > > Date: Thu, 21 Nov 2013 19:42:44 -0500 > > Subject: [PATCH] Staging: Fixed compilar warnings and coding style > > issues in i915_debugfs.c > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > This is a patch fixing both a compilar warning: > > ‘val’ may be used uninitialized in this function > > and various coding style issues which include line length > > warnings and a few errors as defined by 'checkpatch.pl' tool > > > > Signed-off-by: Arthur Schwalbenberg > > Hi, > > When you break 80+ lines into two lines, you should also > indent the newly created line so that it shows that it is a part of something. > I as well don't think it is worth splitting lines that are 84 characters long into > two lines, that just doesn't make sense. > > Also, your patch seems (atleast to me) a 'bit' whitespace damaged. Also, please don't smash different changes into the same patch. Especially pure whitespace changes _must_ be separate from actual code changes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch