* Re: linux-next: Tree for May 6 (acpi: PM=n)
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
@ 2010-05-06 15:05 ` Randy Dunlap
2010-05-06 20:26 ` [linux-pm] " Len Brown
2010-05-06 15:07 ` linux-next: Tree for May 6 (acpi: PCI=n) Randy Dunlap
` (6 subsequent siblings)
7 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 15:05 UTC (permalink / raw)
To: Stephen Rothwell, linux-pm; +Cc: linux-next, LKML, linux-acpi
On Thu, 6 May 2010 15:15:02 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20100505:
When CONFIG_PM is not set:
drivers/built-in.o: In function `acpi_init':
bus.c:(.init.text+0x2d84): undefined reference to `pm_flags'
bus.c:(.init.text+0x2d91): undefined reference to `pm_flags'
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [linux-pm] linux-next: Tree for May 6 (acpi: PM=n)
2010-05-06 15:05 ` linux-next: Tree for May 6 (acpi: PM=n) Randy Dunlap
@ 2010-05-06 20:26 ` Len Brown
2010-05-06 20:32 ` Randy Dunlap
0 siblings, 1 reply; 17+ messages in thread
From: Len Brown @ 2010-05-06 20:26 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-pm, linux-acpi, linux-next, LKML
> When CONFIG_PM is not set:
>
> drivers/built-in.o: In function `acpi_init':
> bus.c:(.init.text+0x2d84): undefined reference to `pm_flags'
> bus.c:(.init.text+0x2d91): undefined reference to `pm_flags'
CONFIG_ACPI depends on CONFIG_PM,
so acpi/bus.c should not be compiled for CONFIG_PM=n
Hmm, is is somebody doing something strange, like "select ACPI"
without guaranteeing that all of ACPI's dependencies are satisfied?
thanks,
Len Brown, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [linux-pm] linux-next: Tree for May 6 (acpi: PM=n)
2010-05-06 20:26 ` [linux-pm] " Len Brown
@ 2010-05-06 20:32 ` Randy Dunlap
2010-05-06 23:27 ` James Morris
0 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 20:32 UTC (permalink / raw)
To: Len Brown, James Morris
Cc: Stephen Rothwell, linux-pm, linux-acpi, linux-next, LKML
On Thu, 06 May 2010 16:26:13 -0400 (EDT) Len Brown wrote:
> > When CONFIG_PM is not set:
> >
> > drivers/built-in.o: In function `acpi_init':
> > bus.c:(.init.text+0x2d84): undefined reference to `pm_flags'
> > bus.c:(.init.text+0x2d91): undefined reference to `pm_flags'
>
> CONFIG_ACPI depends on CONFIG_PM,
> so acpi/bus.c should not be compiled for CONFIG_PM=n
>
> Hmm, is is somebody doing something strange, like "select ACPI"
> without guaranteeing that all of ACPI's dependencies are satisfied?
Oh, thanks for the clue.
That would be a patch that I commented on and was ignored,
but James Morris merged it anyway. Now it should be dropped.
http://lkml.org/lkml/2010/5/4/379
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [linux-pm] linux-next: Tree for May 6 (acpi: PM=n)
2010-05-06 20:32 ` Randy Dunlap
@ 2010-05-06 23:27 ` James Morris
2010-05-06 23:38 ` Randy Dunlap
0 siblings, 1 reply; 17+ messages in thread
From: James Morris @ 2010-05-06 23:27 UTC (permalink / raw)
To: Randy Dunlap
Cc: Len Brown, Stephen Rothwell, linux-pm, linux-acpi, linux-next,
LKML, Mimi Zohar, Rajiv Andrade
On Thu, 6 May 2010, Randy Dunlap wrote:
> On Thu, 06 May 2010 16:26:13 -0400 (EDT) Len Brown wrote:
>
> > > When CONFIG_PM is not set:
> > >
> > > drivers/built-in.o: In function `acpi_init':
> > > bus.c:(.init.text+0x2d84): undefined reference to `pm_flags'
> > > bus.c:(.init.text+0x2d91): undefined reference to `pm_flags'
> >
> > CONFIG_ACPI depends on CONFIG_PM,
> > so acpi/bus.c should not be compiled for CONFIG_PM=n
> >
> > Hmm, is is somebody doing something strange, like "select ACPI"
> > without guaranteeing that all of ACPI's dependencies are satisfied?
>
> Oh, thanks for the clue.
>
> That would be a patch that I commented on and was ignored,
> but James Morris merged it anyway. Now it should be dropped.
>
> http://lkml.org/lkml/2010/5/4/379
You weren't ignored. Mimi responded and mentioned a subsequent patch,
after which, there was no further discussion.
I've reverted:
b89e66e1e396f7b5436af154e58209320cc08aed
"TPM: ACPI/PNP dependency removal"
a674fa46c79ffa37995bd1c8e4daa2b3be5a95ae
"ima: remove ACPI dependency"
Note: any further ACPI-related changes here should have acks from
linux-acpi folk.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [linux-pm] linux-next: Tree for May 6 (acpi: PM=n)
2010-05-06 23:27 ` James Morris
@ 2010-05-06 23:38 ` Randy Dunlap
0 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 23:38 UTC (permalink / raw)
To: James Morris
Cc: Len Brown, Stephen Rothwell, linux-pm, linux-acpi, linux-next,
LKML, Mimi Zohar, Rajiv Andrade
On 05/06/10 16:27, James Morris wrote:
> On Thu, 6 May 2010, Randy Dunlap wrote:
>
>> On Thu, 06 May 2010 16:26:13 -0400 (EDT) Len Brown wrote:
>>
>>>> When CONFIG_PM is not set:
>>>>
>>>> drivers/built-in.o: In function `acpi_init':
>>>> bus.c:(.init.text+0x2d84): undefined reference to `pm_flags'
>>>> bus.c:(.init.text+0x2d91): undefined reference to `pm_flags'
>>>
>>> CONFIG_ACPI depends on CONFIG_PM,
>>> so acpi/bus.c should not be compiled for CONFIG_PM=n
>>>
>>> Hmm, is is somebody doing something strange, like "select ACPI"
>>> without guaranteeing that all of ACPI's dependencies are satisfied?
>>
>> Oh, thanks for the clue.
>>
>> That would be a patch that I commented on and was ignored,
>> but James Morris merged it anyway. Now it should be dropped.
>>
>> http://lkml.org/lkml/2010/5/4/379
>
> You weren't ignored. Mimi responded and mentioned a subsequent patch,
> after which, there was no further discussion.
OK. But merging a known bad patch doesn't make much sense to me.
> I've reverted:
>
> b89e66e1e396f7b5436af154e58209320cc08aed
> "TPM: ACPI/PNP dependency removal"
>
> a674fa46c79ffa37995bd1c8e4daa2b3be5a95ae
> "ima: remove ACPI dependency"
>
Thanks.
>
> Note: any further ACPI-related changes here should have acks from
> linux-acpi folk.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: Tree for May 6 (acpi: PCI=n)
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
2010-05-06 15:05 ` linux-next: Tree for May 6 (acpi: PM=n) Randy Dunlap
@ 2010-05-06 15:07 ` Randy Dunlap
2010-05-06 20:29 ` Len Brown
2010-05-06 18:18 ` linux-next: Tree for May 6 (nouveau) Randy Dunlap
` (5 subsequent siblings)
7 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 15:07 UTC (permalink / raw)
To: Stephen Rothwell, linux-acpi; +Cc: linux-next, LKML
On Thu, 6 May 2010 15:15:02 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20100505:
When CONFIG_PCI is not enabled:
arch/x86/kernel/acpi/boot.c:1034: error: 'pci_bus_type' undeclared
drivers/acpi/reboot.c:30: error:implicit declaration of function 'pci_find_bus'
drivers/acpi/reboot.c:30: warning: assignment makes pointer from integer without a cast
drivers/acpi/reboot.c:38: error:implicit declaration of function 'pci_bus_write_config_byte'
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for May 6 (acpi: PCI=n)
2010-05-06 15:07 ` linux-next: Tree for May 6 (acpi: PCI=n) Randy Dunlap
@ 2010-05-06 20:29 ` Len Brown
2010-05-06 20:42 ` Randy Dunlap
0 siblings, 1 reply; 17+ messages in thread
From: Len Brown @ 2010-05-06 20:29 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-acpi, linux-next, LKML
> When CONFIG_PCI is not enabled:
>
> arch/x86/kernel/acpi/boot.c:1034: error: 'pci_bus_type' undeclared
>
> drivers/acpi/reboot.c:30: error:implicit declaration of function 'pci_find_bus'
> drivers/acpi/reboot.c:30: warning: assignment makes pointer from integer without a cast
> drivers/acpi/reboot.c:38: error:implicit declaration of function 'pci_bus_write_config_byte'
CONFIG_ACPI depends on CONFIG_PCI, so this file should not be build with
CONFIG_PCI=n.
Please let me know how you were able to generate this illegal
configuration.
thanks,
Len Brown, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: Tree for May 6 (acpi: PCI=n)
2010-05-06 20:29 ` Len Brown
@ 2010-05-06 20:42 ` Randy Dunlap
0 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 20:42 UTC (permalink / raw)
To: Len Brown, James Morris; +Cc: Stephen Rothwell, linux-acpi, linux-next, LKML
On Thu, 06 May 2010 16:29:42 -0400 (EDT) Len Brown wrote:
> > When CONFIG_PCI is not enabled:
> >
> > arch/x86/kernel/acpi/boot.c:1034: error: 'pci_bus_type' undeclared
> >
> > drivers/acpi/reboot.c:30: error:implicit declaration of function 'pci_find_bus'
> > drivers/acpi/reboot.c:30: warning: assignment makes pointer from integer without a cast
> > drivers/acpi/reboot.c:38: error:implicit declaration of function 'pci_bus_write_config_byte'
>
> CONFIG_ACPI depends on CONFIG_PCI, so this file should not be build with
> CONFIG_PCI=n.
>
> Please let me know how you were able to generate this illegal
> configuration.
Same TPM kconfig that selects ACPI without any other qualifications.
In 50 randconfig builds, 12 build failures were due to that one bad kconfig.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: Tree for May 6 (nouveau)
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
2010-05-06 15:05 ` linux-next: Tree for May 6 (acpi: PM=n) Randy Dunlap
2010-05-06 15:07 ` linux-next: Tree for May 6 (acpi: PCI=n) Randy Dunlap
@ 2010-05-06 18:18 ` Randy Dunlap
2010-05-06 20:37 ` Len Brown
2010-05-06 23:41 ` [PATCH -next] IR: add header file to fix build Randy Dunlap
` (4 subsequent siblings)
7 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 18:18 UTC (permalink / raw)
To: Stephen Rothwell, David Airlie; +Cc: linux-next, LKML, dri-devel
On Thu, 6 May 2010 15:15:02 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20100505:
When CONFIG_ACPI_BUTTON=m:
drivers/built-in.o: In function `nouveau_connector_detect':
nouveau_connector.c:(.text+0x1d81cf): undefined reference to `acpi_lid_open'
#ifdef CONFIG_ACPI
if (!nouveau_ignorelid && !acpi_lid_open())
status = connector_status_unknown;
#endif
Do you want that to be
#ifdef CONFIG_ACPI_BUTTON
?
That will still only be built when CONFIG_ACPI_BUTTON=y (not =m).
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for May 6 (nouveau)
2010-05-06 18:18 ` linux-next: Tree for May 6 (nouveau) Randy Dunlap
@ 2010-05-06 20:37 ` Len Brown
0 siblings, 0 replies; 17+ messages in thread
From: Len Brown @ 2010-05-06 20:37 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, David Airlie, linux-next, LKML, dri-devel
> When CONFIG_ACPI_BUTTON=m:
>
> drivers/built-in.o: In function `nouveau_connector_detect':
> nouveau_connector.c:(.text+0x1d81cf): undefined reference to `acpi_lid_open'
>
>
> #ifdef CONFIG_ACPI
> if (!nouveau_ignorelid && !acpi_lid_open())
> status = connector_status_unknown;
> #endif
>
>
> Do you want that to be
> #ifdef CONFIG_ACPI_BUTTON
> ?
> That will still only be built when CONFIG_ACPI_BUTTON=y (not =m).
>
intel_lvds.c seems to handle this issue without #ifdefs
by including acpi/button.h
cheers,
Len Brown, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH -next] IR: add header file to fix build
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
` (2 preceding siblings ...)
2010-05-06 18:18 ` linux-next: Tree for May 6 (nouveau) Randy Dunlap
@ 2010-05-06 23:41 ` Randy Dunlap
2010-05-06 23:43 ` [PATCH -next] staging: fix arlan build-braces Randy Dunlap
` (3 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 23:41 UTC (permalink / raw)
To: Stephen Rothwell, Mauro Carvalho Chehab; +Cc: linux-next, LKML, linux-media
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build error:
drivers/media/IR/rc-map.c:51: error: implicit declaration of function 'msleep'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
---
drivers/media/IR/rc-map.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20100506.orig/drivers/media/IR/rc-map.c
+++ linux-next-20100506/drivers/media/IR/rc-map.c
@@ -13,6 +13,7 @@
*/
#include <media/ir-core.h>
+#include <linux/delay.h>
#include <linux/spinlock.h>
/* Used to handle IR raw handler extensions */
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH -next] staging: fix arlan build-braces
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
` (3 preceding siblings ...)
2010-05-06 23:41 ` [PATCH -next] IR: add header file to fix build Randy Dunlap
@ 2010-05-06 23:43 ` Randy Dunlap
2010-05-11 21:13 ` Greg KH
2010-05-06 23:44 ` [PATCH -next] staging: fix cxt1e1 semaphore build breakage Randy Dunlap
` (2 subsequent siblings)
7 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 23:43 UTC (permalink / raw)
To: Stephen Rothwell, gregkh; +Cc: linux-next, LKML, devel
From: Randy Dunlap <randy.dunlap@oracle.com>
The braces on the writeControlRegister() macro are not sufficient
(at least for one version of gcc):
drivers/staging/arlan/arlan-main.c:230: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:236: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:242: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:250: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:298: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:324: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:348: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:362: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:367: error: 'else' without a previous 'if'
drivers/staging/arlan/arlan-main.c:372: error: 'else' without a previous 'if'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/arlan/arlan.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-next-20100506.orig/drivers/staging/arlan/arlan.h
+++ linux-next-20100506/drivers/staging/arlan/arlan.h
@@ -461,10 +461,11 @@ struct arlan_private {
int cr; \
\
cr = readControlRegister(dev);\
- if (cr & ARLAN_CHANNEL_ATTENTION) \
+ if (cr & ARLAN_CHANNEL_ATTENTION) { \
writeControlRegister(dev, (cr & ~ARLAN_CHANNEL_ATTENTION));\
- else \
+ } else { \
writeControlRegister(dev, (cr | ARLAN_CHANNEL_ATTENTION));\
+ } \
}
#define clearChannelAttention(dev) { \
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH -next] staging: fix arlan build-braces
2010-05-06 23:43 ` [PATCH -next] staging: fix arlan build-braces Randy Dunlap
@ 2010-05-11 21:13 ` Greg KH
0 siblings, 0 replies; 17+ messages in thread
From: Greg KH @ 2010-05-11 21:13 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, gregkh, linux-next, LKML, devel
On Thu, May 06, 2010 at 04:43:03PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> The braces on the writeControlRegister() macro are not sufficient
> (at least for one version of gcc):
>
> drivers/staging/arlan/arlan-main.c:230: error: 'else' without a previous 'if'
This driver is now deleted, so I can't apply the patch :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH -next] staging: fix cxt1e1 semaphore build breakage
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
` (4 preceding siblings ...)
2010-05-06 23:43 ` [PATCH -next] staging: fix arlan build-braces Randy Dunlap
@ 2010-05-06 23:44 ` Randy Dunlap
2010-05-06 23:45 ` [PATCH -next] staging: fix ti-st, depends on RFKILL Randy Dunlap
2010-05-06 23:46 ` [PATCH -next] usb: fix u132-hcd code/data warning Randy Dunlap
7 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 23:44 UTC (permalink / raw)
To: Stephen Rothwell, gregkh; +Cc: linux-next, LKML, devel
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build errors by including linux/semaphore.h:
drivers/staging/cxt1e1/pmcc4_private.h:144: error: field 'sr_sem_busy' has incomplete type
drivers/staging/cxt1e1/pmcc4_private.h:146: error: field 'sr_sem_wait' has incomplete type
drivers/staging/cxt1e1/pmcc4_private.h:189: error: field 'sem_wdbusy' has incomplete type
drivers/staging/cxt1e1/musycc.c:617: error: implicit declaration of function 'down'
drivers/staging/cxt1e1/musycc.c:641: error: implicit declaration of function 'up'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/cxt1e1/pmcc4_private.h | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20100506.orig/drivers/staging/cxt1e1/pmcc4_private.h
+++ linux-next-20100506/drivers/staging/cxt1e1/pmcc4_private.h
@@ -20,6 +20,7 @@
#include <linux/kernel.h>
#include <linux/sched.h>
+#include <linux/semaphore.h>
#include <linux/spinlock.h>
#include <linux/interrupt.h> /* support for tasklets */
#include <linux/timer.h> /* support for timer */
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH -next] staging: fix ti-st, depends on RFKILL
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
` (5 preceding siblings ...)
2010-05-06 23:44 ` [PATCH -next] staging: fix cxt1e1 semaphore build breakage Randy Dunlap
@ 2010-05-06 23:45 ` Randy Dunlap
2010-05-06 23:46 ` [PATCH -next] usb: fix u132-hcd code/data warning Randy Dunlap
7 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 23:45 UTC (permalink / raw)
To: Stephen Rothwell, gregkh; +Cc: devel, linux-next, LKML
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build errors. st_kim.c uses rfkill*() interfaces, so it
should depend on RFKILL.
st_kim.c:(.text+0x291b21): undefined reference to `rfkill_unregister'
st_kim.c:(.text+0x291b31): undefined reference to `rfkill_destroy'
st_kim.c:(.text+0x291d8a): undefined reference to `rfkill_alloc'
st_kim.c:(.text+0x291db9): undefined reference to `rfkill_init_sw_state'
st_kim.c:(.text+0x291dc9): undefined reference to `rfkill_register'
st_kim.c:(.text+0x291e07): undefined reference to `rfkill_unregister'
(.text+0x291e85): undefined reference to `rfkill_set_hw_state'
(.text+0x292072): undefined reference to `rfkill_set_hw_state'
(.text+0x2920e1): undefined reference to `rfkill_set_hw_state
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/ti-st/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20100506.orig/drivers/staging/ti-st/Kconfig
+++ linux-next-20100506/drivers/staging/ti-st/Kconfig
@@ -5,6 +5,7 @@
menu "Texas Instruments shared transport line discipline"
config TI_ST
tristate "shared transport core driver"
+ depends on RFKILL
select FW_LOADER
help
This enables the shared transport core driver for TI
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH -next] usb: fix u132-hcd code/data warning
2010-05-06 5:15 linux-next: Tree for May 6 Stephen Rothwell
` (6 preceding siblings ...)
2010-05-06 23:45 ` [PATCH -next] staging: fix ti-st, depends on RFKILL Randy Dunlap
@ 2010-05-06 23:46 ` Randy Dunlap
7 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2010-05-06 23:46 UTC (permalink / raw)
To: Stephen Rothwell, gregkh; +Cc: linux-next, LKML, lud
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix gcc warning on mixed declarations/code:
drivers/usb/host/u132-hcd.c:1450: warning: ISO C90 forbids mixed declarations and code
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/usb/host/u132-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20100506.orig/drivers/usb/host/u132-hcd.c
+++ linux-next-20100506/drivers/usb/host/u132-hcd.c
@@ -1446,9 +1446,9 @@ static void u132_hcd_endp_work_scheduler
return;
} else {
int retval;
- address = u132->addr[endp->usb_addr].address;
struct urb *urb = endp->urb_list[ENDP_QUEUE_MASK &
endp->queue_next];
+ address = u132->addr[endp->usb_addr].address;
endp->active = 1;
ring->curr_endp = endp;
ring->in_use = 1;
^ permalink raw reply [flat|nested] 17+ messages in thread