[PATCH 4/7] acpi: processor: fix section mismatch

[PATCH 4/7] acpi: processor: fix section mismatch

[Felipe Contreras]

WARNING: drivers/acpi/processor.o(.text+0x99a): Section mismatch in
reference from the function acpi_processor_add() to the function
.cpuinit.text:acpi_processor_power_init()

acpi_processor_add replaced acpi_processor_start which had __cpuinit.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 drivers/acpi/processor_core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index c567b46..ec742a4 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -770,7 +770,7 @@ static struct notifier_block acpi_cpu_notifier =
 	    .notifier_call = acpi_cpu_soft_notify,
 };
 
-static int acpi_processor_add(struct acpi_device *device)
+static int __cpuinit acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr = NULL;
 	int result = 0;
-- 
1.6.5.1

[PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Felipe Contreras]

Many still remain.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 include/acpi/actypes.h |   36 ++++++++++++++++++------------------
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 153f12d..c1a0eb4 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -167,7 +167,7 @@ typedef u64 acpi_physical_address;
  * Note: Em64_t and other X86-64 processors support misaligned transfers,
  * so there is no need to define this flag.
  */
-#if defined (__IA64__) || defined (__ia64__)
+#if defined(__IA64__) || defined(__ia64__)
 #define ACPI_MISALIGNMENT_NOT_SUPPORTED
 #endif
 
@@ -242,10 +242,10 @@ typedef u32 acpi_physical_address;
  * Map the OSL Mutex interfaces to binary semaphores.
  */
 #define acpi_mutex                      acpi_semaphore
-#define acpi_os_create_mutex(out_handle) acpi_os_create_semaphore (1, 1, out_handle)
-#define acpi_os_delete_mutex(handle)    (void) acpi_os_delete_semaphore (handle)
-#define acpi_os_acquire_mutex(handle,time) acpi_os_wait_semaphore (handle, 1, time)
-#define acpi_os_release_mutex(handle)   (void) acpi_os_signal_semaphore (handle, 1)
+#define acpi_os_create_mutex(out_handle) acpi_os_create_semaphore(1, 1, out_handle)
+#define acpi_os_delete_mutex(handle)    (void) acpi_os_delete_semaphore(handle)
+#define acpi_os_acquire_mutex(handle, time) acpi_os_wait_semaphore(handle, 1, time)
+#define acpi_os_release_mutex(handle)   (void) acpi_os_signal_semaphore(handle, 1)
 #endif
 
 /* Configurable types for synchronization objects */
@@ -417,7 +417,7 @@ typedef unsigned long long acpi_integer;
 /*
  * Constants with special meanings
  */
-#define ACPI_ROOT_OBJECT                ACPI_ADD_PTR (acpi_handle, NULL, ACPI_MAX_PTR)
+#define ACPI_ROOT_OBJECT                ACPI_ADD_PTR(acpi_handle, NULL, ACPI_MAX_PTR)
 #define ACPI_WAIT_FOREVER               0xFFFF	/* u16, as per ACPI spec */
 #define ACPI_DO_NOT_WAIT                0
 
@@ -438,8 +438,8 @@ typedef unsigned long long acpi_integer;
 
 #define ACPI_SET_BIT(target,bit)        ((target) |= (bit))
 #define ACPI_CLEAR_BIT(target,bit)      ((target) &= ~(bit))
-#define ACPI_MIN(a,b)                   (((a)<(b))?(a):(b))
-#define ACPI_MAX(a,b)                   (((a)>(b))?(a):(b))
+#define ACPI_MIN(a, b)                  (((a)<(b))?(a):(b))
+#define ACPI_MAX(a, b)                  (((a)>(b))?(a):(b))
 
 /* Size calculation */
 
@@ -449,21 +449,21 @@ typedef unsigned long long acpi_integer;
 
 #define ACPI_CAST_PTR(t, p)             ((t *) (acpi_uintptr_t) (p))
 #define ACPI_CAST_INDIRECT_PTR(t, p)    ((t **) (acpi_uintptr_t) (p))
-#define ACPI_ADD_PTR(t, a, b)           ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
-#define ACPI_PTR_DIFF(a, b)             (acpi_size) (ACPI_CAST_PTR (u8, (a)) - ACPI_CAST_PTR (u8, (b)))
+#define ACPI_ADD_PTR(t, a, b)           ACPI_CAST_PTR(t, (ACPI_CAST_PTR(u8, (a)) + (acpi_size)(b)))
+#define ACPI_PTR_DIFF(a, b)             (acpi_size) (ACPI_CAST_PTR(u8, (a)) - ACPI_CAST_PTR(u8, (b)))
 
 /* Pointer/Integer type conversions */
 
-#define ACPI_TO_POINTER(i)              ACPI_ADD_PTR (void, (void *) NULL,(acpi_size) i)
-#define ACPI_TO_INTEGER(p)              ACPI_PTR_DIFF (p, (void *) NULL)
-#define ACPI_OFFSET(d, f)               (acpi_size) ACPI_PTR_DIFF (&(((d *)0)->f), (void *) NULL)
+#define ACPI_TO_POINTER(i)              ACPI_ADD_PTR(void, (void *) NULL, (acpi_size) i)
+#define ACPI_TO_INTEGER(p)              ACPI_PTR_DIFF(p, (void *) NULL)
+#define ACPI_OFFSET(d, f)               (acpi_size) ACPI_PTR_DIFF(&(((d *)0)->f), (void *) NULL)
 #define ACPI_PHYSADDR_TO_PTR(i)         ACPI_TO_POINTER(i)
 #define ACPI_PTR_TO_PHYSADDR(i)         ACPI_TO_INTEGER(i)
 
 #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
-#define ACPI_COMPARE_NAME(a,b)          (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b)))
+#define ACPI_COMPARE_NAME(a, b)         (*ACPI_CAST_PTR(u32, (a)) == *ACPI_CAST_PTR(u32, (b)))
 #else
-#define ACPI_COMPARE_NAME(a,b)          (!ACPI_STRNCMP (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAME_SIZE))
+#define ACPI_COMPARE_NAME(a, b)         (!ACPI_STRNCMP(ACPI_CAST_PTR(char, (a)), ACPI_CAST_PTR(char, (b)), ACPI_NAME_SIZE))
 #endif
 
 /*******************************************************************************
@@ -631,7 +631,7 @@ typedef u32 acpi_event_type;
 #define ACPI_EVENT_SLEEP_BUTTON         3
 #define ACPI_EVENT_RTC                  4
 #define ACPI_EVENT_MAX                  4
-#define ACPI_NUM_FIXED_EVENTS           ACPI_EVENT_MAX + 1
+#define ACPI_NUM_FIXED_EVENTS           (ACPI_EVENT_MAX + 1)
 
 /*
  * Event Status - Per event
@@ -778,7 +778,7 @@ typedef u8 acpi_adr_space_type;
 #define ACPI_BITREG_ARB_DISABLE                 0x13
 
 #define ACPI_BITREG_MAX                         0x13
-#define ACPI_NUM_BITREG                         ACPI_BITREG_MAX + 1
+#define ACPI_NUM_BITREG                         (ACPI_BITREG_MAX + 1)
 
 /* Status register values. A 1 clears a status bit. 0 = no effect */
 
@@ -945,7 +945,7 @@ typedef
 acpi_status(*acpi_adr_space_handler) (u32 function,
 				      acpi_physical_address address,
 				      u32 bit_width,
-				      acpi_integer * value,
+				      acpi_integer *value,
 				      void *handler_context,
 				      void *region_context);
 
-- 
1.6.5.1

[PATCH 6/7] acpi: fix trivial warning

[Felipe Contreras]

drivers/acpi/acpica/tbfadt.c: In function ‘acpi_tb_create_local_fadt’:
arch/x86/include/asm/string_32.h:74: warning: array subscript is above array bounds

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 include/acpi/actypes.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index c1a0eb4..7d989f1 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -438,8 +438,8 @@ typedef unsigned long long acpi_integer;
 
 #define ACPI_SET_BIT(target,bit)        ((target) |= (bit))
 #define ACPI_CLEAR_BIT(target,bit)      ((target) &= ~(bit))
-#define ACPI_MIN(a, b)                  (((a)<(b))?(a):(b))
-#define ACPI_MAX(a, b)                  (((a)>(b))?(a):(b))
+#define ACPI_MIN(a, b)                  min(a, b)
+#define ACPI_MAX(a, b)                  max(a, b)
 
 /* Size calculation */
 
-- 
1.6.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/7] acpi: fix trivial warnings caused by previous commmit

[Felipe Contreras]

drivers/acpi/acpica/exfldio.c: In function ‘acpi_ex_extract_from_field’:
drivers/acpi/acpica/exfldio.c:761: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:761: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:761: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:780: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:780: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:780: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c: In function ‘acpi_ex_insert_into_field’:
drivers/acpi/acpica/exfldio.c:880: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:880: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:880: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:933: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:933: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:933: warning: comparison of distinct pointer types lacks a cast

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 drivers/acpi/acpica/exfldio.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index d7b3b41..597bc39 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -761,7 +761,7 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
 
 		ACPI_MEMCPY(((char *)buffer) + buffer_offset, &merged_datum,
 			    ACPI_MIN(obj_desc->common_field.access_byte_width,
-				     buffer_length - buffer_offset));
+				     (u8)(buffer_length - buffer_offset)));
 
 		buffer_offset += obj_desc->common_field.access_byte_width;
 		merged_datum =
@@ -780,7 +780,7 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
 
 	ACPI_MEMCPY(((char *)buffer) + buffer_offset, &merged_datum,
 		    ACPI_MIN(obj_desc->common_field.access_byte_width,
-			     buffer_length - buffer_offset));
+			     (u8)(buffer_length - buffer_offset)));
 
 	return_ACPI_STATUS(AE_OK);
 }
@@ -880,7 +880,7 @@ acpi_ex_insert_into_field(union acpi_operand_object *obj_desc,
 
 	ACPI_MEMCPY(&raw_datum, buffer,
 		    ACPI_MIN(obj_desc->common_field.access_byte_width,
-			     buffer_length - buffer_offset));
+			     (u8)(buffer_length - buffer_offset)));
 
 	merged_datum =
 	    raw_datum << obj_desc->common_field.start_field_bit_offset;
@@ -933,7 +933,7 @@ acpi_ex_insert_into_field(union acpi_operand_object *obj_desc,
 		buffer_offset += obj_desc->common_field.access_byte_width;
 		ACPI_MEMCPY(&raw_datum, ((char *)buffer) + buffer_offset,
 			    ACPI_MIN(obj_desc->common_field.access_byte_width,
-				     buffer_length - buffer_offset));
+				     (u8)(buffer_length - buffer_offset)));
 		merged_datum |=
 		    raw_datum << obj_desc->common_field.start_field_bit_offset;
 	}
-- 
1.6.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] acpi: fix trivial warning

[Jiri Kosina]

On Mon, 19 Oct 2009, Felipe Contreras wrote:

> drivers/acpi/acpica/tbfadt.c: In function ?acpi_tb_create_local_fadt?:
> arch/x86/include/asm/string_32.h:74: warning: array subscript is above array bounds

Same is in your previous patch -- what gcc is that? I don't see any 
warning with 4.3.1

$ make drivers/acpi/acpica/tbfadt.o
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-x86
  CALL    scripts/checksyscalls.sh
  CC      drivers/acpi/acpica/tbfadt.o
$

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Jiri Kosina]

On Mon, 19 Oct 2009, Felipe Contreras wrote:

> Many still remain.
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>

I have never been in favor of merging whitespace-only patches (in a sense 
that the sole purpose of them being to change whitespaces, but no else 
value added). 

And after today's discussion on kernel summit on this topic, I wouldn't 
expect any maintainer to merge it, sorry :)

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Felipe Contreras]

On Mon, Oct 19, 2009 at 5:20 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 19 Oct 2009, Felipe Contreras wrote:
>
>> Many still remain.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>
> I have never been in favor of merging whitespace-only patches (in a sense
> that the sole purpose of them being to change whitespaces, but no else
> value added).

If somebody tries to send a patch for that file that doesn't fix the
white-space, checkpatch will complain, and people will complain that
checkpatch complains, which is precisely what happened, and I was
requested to write this patch by Daniel Walker (final mail wasn't on
the ml):

http://lkml.org/lkml/2009/9/14/183

> And after today's discussion on kernel summit on this topic, I wouldn't
> expect any maintainer to merge it, sorry :)

What are you talking about?

-- 
Felipe Contreras

Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Jiri Kosina]

On Mon, 19 Oct 2009, Felipe Contreras wrote:

> > I have never been in favor of merging whitespace-only patches (in a 
> > sense that the sole purpose of them being to change whitespaces, but 
> > no else value added).
> If somebody tries to send a patch for that file that doesn't fix the
> white-space, checkpatch will complain, and people will complain that
> checkpatch complains, which is precisely what happened, 

Oh, well ... checkpatch warning about this is somewhat controversial. My 
preferred way would be that it warns about whitespace only if there are 
also some other (non-whitespace) changes.

> and I was requested to write this patch by Daniel Walker (final mail 
> wasn't on the ml):
> 
> http://lkml.org/lkml/2009/9/14/183

This is something slightly different -- he asks you to fixup whitespace 
issue in the code you are newly introducing, right?

> > And after today's discussion on kernel summit on this topic, I wouldn't
> > expect any maintainer to merge it, sorry :)
> What are you talking about?

Seems like many kernel maintainers are just tired of 
'whitespace-cleanup-only' patches that bring no real added value 
otherwise.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Felipe Contreras]

On Mon, Oct 19, 2009 at 6:03 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 19 Oct 2009, Felipe Contreras wrote:
>
>> > I have never been in favor of merging whitespace-only patches (in a
>> > sense that the sole purpose of them being to change whitespaces, but
>> > no else value added).
>> If somebody tries to send a patch for that file that doesn't fix the
>> white-space, checkpatch will complain, and people will complain that
>> checkpatch complains, which is precisely what happened,
>
> Oh, well ... checkpatch warning about this is somewhat controversial. My
> preferred way would be that it warns about whitespace only if there are
> also some other (non-whitespace) changes.

Huh? I think we are talking about different things. See the next comment.

>> and I was requested to write this patch by Daniel Walker (final mail
>> wasn't on the ml):
>>
>> http://lkml.org/lkml/2009/9/14/183
>
> This is something slightly different -- he asks you to fixup whitespace
> issue in the code you are newly introducing, right?

No, did you read the thread?

This was my patch:
-#define ACPI_MIN(a,b)                   (((a)<(b))?(a):(b))
-#define ACPI_MAX(a,b)                   (((a)>(b))?(a):(b))
+#define ACPI_MIN(a,b)                   min(a, b)
+#define ACPI_MAX(a,b)                   max(a, b)

Checkpatch complains, even though my changes are ok. So that's what I
mean, if somebody wants to do a similar patch in the future so that
checkpatch doesn't complain; they would have to fix the white-spaces
again.

Or checkpatch should be fixed.

>> > And after today's discussion on kernel summit on this topic, I wouldn't
>> > expect any maintainer to merge it, sorry :)
>> What are you talking about?
>
> Seems like many kernel maintainers are just tired of
> 'whitespace-cleanup-only' patches that bring no real added value
> otherwise.

Hm, I wonder what would happen to the current badly formatted code.
Stay there forever?

-- 
Felipe Contreras

Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Artem Bityutskiy]

On Mon, 2009-10-19 at 17:03 +0200, Jiri Kosina wrote:
> On Mon, 19 Oct 2009, Felipe Contreras wrote:
> 
> > > I have never been in favor of merging whitespace-only patches (in a 
> > > sense that the sole purpose of them being to change whitespaces, but 
> > > no else value added).
> > If somebody tries to send a patch for that file that doesn't fix the
> > white-space, checkpatch will complain, and people will complain that
> > checkpatch complains, which is precisely what happened, 
> 
> Oh, well ... checkpatch warning about this is somewhat controversial. My 
> preferred way would be that it warns about whitespace only if there are 
> also some other (non-whitespace) changes.
> 
> > and I was requested to write this patch by Daniel Walker (final mail 
> > wasn't on the ml):
> > 
> > http://lkml.org/lkml/2009/9/14/183
> 
> This is something slightly different -- he asks you to fixup whitespace 
> issue in the code you are newly introducing, right?
> 
> > > And after today's discussion on kernel summit on this topic, I wouldn't
> > > expect any maintainer to merge it, sorry :)
> > What are you talking about?
> 
> Seems like many kernel maintainers are just tired of 
> 'whitespace-cleanup-only' patches that bring no real added value 
> otherwise.

May be some are tired, but others just say thanks and apply them,
because it is easier to apply than complain, and because they do not
mind if their subsystem becomes a tiny bit cleaner. Sometimes it may
cause troubles, but hey, development is not easy and we are accustomed
to fix conflict and amend patches. But the include/acpi/actypes.h does
not seem to be changing very often anyway.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/7] acpi: processor: fix section mismatch

[Jiri Kosina]

On Mon, 19 Oct 2009, Felipe Contreras wrote:

> WARNING: drivers/acpi/processor.o(.text+0x99a): Section mismatch in
> reference from the function acpi_processor_add() to the function
> .cpuinit.text:acpi_processor_power_init()
> 
> acpi_processor_add replaced acpi_processor_start which had __cpuinit.
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  drivers/acpi/processor_core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index c567b46..ec742a4 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -770,7 +770,7 @@ static struct notifier_block acpi_cpu_notifier =
>  	    .notifier_call = acpi_cpu_soft_notify,
>  };
>  
> -static int acpi_processor_add(struct acpi_device *device)
> +static int __cpuinit acpi_processor_add(struct acpi_device *device)
>  {
>  	struct acpi_processor *pr = NULL;
>  	int result = 0;

I don't see this patch in today's linux-next ... ACPI guys, are you going 
to merge it?

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [PATCH 4/7] acpi: processor: fix section mismatch

[Felipe Contreras]

On Wed, Nov 4, 2009 at 3:28 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> I don't see this patch in today's linux-next ... ACPI guys, are you going
> to merge it?

How critical are these section mismatch issues? Should this go into 2.6.32?

-- 
Felipe Contreras

Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Daniel Walker]

On Mon, 2009-10-19 at 16:20 +0200, Jiri Kosina wrote:
> On Mon, 19 Oct 2009, Felipe Contreras wrote:
> 
> > Many still remain.
> > 
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> 
> I have never been in favor of merging whitespace-only patches (in a sense 
> that the sole purpose of them being to change whitespaces, but no else 
> value added). 
> 
> And after today's discussion on kernel summit on this topic, I wouldn't 
> expect any maintainer to merge it, sorry :)

could you be more specific about what "discussion" you are talking
about.

Daniel

RE: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Moore, Robert]

>-----Original Message-----
>From: Daniel Walker [mailto:dwalker@fifo99.com]
>Sent: Friday, November 13, 2009 12:59 PM
>To: Jiri Kosina
>Cc: Felipe Contreras; linux-kernel@vger.kernel.org; Len Brown; Moore,
>Robert; Lin, Ming M; linux-acpi@vger.kernel.org
>Subject: Re: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'
>
>On Mon, 2009-10-19 at 16:20 +0200, Jiri Kosina wrote:
>> On Mon, 19 Oct 2009, Felipe Contreras wrote:
>>
>> > Many still remain.
>> >
>> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>
>> I have never been in favor of merging whitespace-only patches (in a sense
>> that the sole purpose of them being to change whitespaces, but no else
>> value added).
>>
>> And after today's discussion on kernel summit on this topic, I wouldn't
>> expect any maintainer to merge it, sorry :)
>
>could you be more specific about what "discussion" you are talking
>about.
>

Yes, do tell.


>Daniel

RE: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Jiri Kosina]

On Fri, 13 Nov 2009, Moore, Robert wrote:

> >> And after today's discussion on kernel summit on this topic, I 
> >> wouldn't expect any maintainer to merge it, sorry :)
> >could you be more specific about what "discussion" you are talking
> >about.
> Yes, do tell.

I have probably lost the track of the context here already, sorry.

But it probably had something to do with the fact that whitespace-only 
patches (which [PATCH 5/7] acpi: fix a bunch of style issues on 
'actypes.h' has been, as far as I remember), are unnecessary noise.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

RE: [PATCH 5/7] acpi: fix a bunch of style issues on 'actypes.h'

[Daniel Walker]

On Fri, 2009-11-13 at 22:41 +0100, Jiri Kosina wrote:
> On Fri, 13 Nov 2009, Moore, Robert wrote:
> 
> > >> And after today's discussion on kernel summit on this topic, I 
> > >> wouldn't expect any maintainer to merge it, sorry :)
> > >could you be more specific about what "discussion" you are talking
> > >about.
> > Yes, do tell.
> 
> I have probably lost the track of the context here already, sorry.
> 
> But it probably had something to do with the fact that whitespace-only 
> patches (which [PATCH 5/7] acpi: fix a bunch of style issues on 
> 'actypes.h' has been, as far as I remember), are unnecessary noise.

I don't think it was clear from the description , but I think this is
actually a checkpatch cleanup. So it's not just random whitespace
changes. AFAIK, maintainers do accept those.

Daniel