* Re: linux-next: build failure after merge of the final tree (devicetree tree related)
From: Grant Likely @ 2012-04-17 3:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Thomas Abraham
In-Reply-To: <20120417132357.b38685ea31582e638623961c@canb.auug.org.au>
On Mon, Apr 16, 2012 at 9:23 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Grant,
>
> On Wed, 11 Apr 2012 18:35:34 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>>
>> On Wed, Apr 11, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > Hi Grant,
>> >
>> > On Wed, 11 Apr 2012 15:11:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >>
>> >> After merging the final tree, today's linux-next build (sparc64 defconfig)
>> >> failed like this:
>> >>
>> >> drivers/of/of_mdio.c: In function 'of_mdiobus_register':
>> >> drivers/of/of_mdio.c:75:4: error: implicit declaration of function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration]
>> >>
>> >> Caused by commit e46c11b94787 ("of/irq: add empty irq_of_parse_and_map()
>> >> for non-dt builds"). SPARC has CONFIG_OF but not CONFIG_OF_IRQ ...
>> >>
>> >> I have reverted that commit for today.
>> >
>> > That commit is actually in the devicetree-current tree.
>>
>> Yes, drop that tree or revert that commit. There's nothing else in
>> there and I didn't have time to pull it back today before you started
>> linux-next for the day. The change is bogus and I'll spin a proper
>> fixup for tomorrow.
>
> Ping?
Haven't got it done yet. It's still safe to ignore that tree.
g.
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the mfd tree
From: Stephen Rothwell @ 2012-04-17 3:34 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Peter Ujfalusi, Samuel Ortiz,
Benoit Cousson
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/board-generic.c between commit aa1d7775696c ("mfd:
Convert twl6040 to i2c driver, and separate it from twl core") from the
mfd tree and commit 93651b85bbd1 ("ARM: OMAP2+: board-generic: Remove i2c
static init") from the arm-soc tree.
The latter seems to supercede the former, so I used that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] seccomp: use a static inline for a function stub
From: James Morris @ 2012-04-17 3:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Will Drewry, linux-next, linux-kernel, H. Peter Anvin, Eric Paris,
Kees Cook
In-Reply-To: <20120417120848.e7f3eabfbf79dc609318ea1e@canb.auug.org.au>
On Tue, 17 Apr 2012, Stephen Rothwell wrote:
> Fixes this error message when CONFIG_SECCOMP is not set:
>
> arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
> arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
>
> Signed-off-by: Stephen Rothwell <sfr@ozlabs.au.ibm.com>
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: linux-next: build failure after merge of the v4l-dvb tree
From: Stephen Rothwell @ 2012-04-17 3:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: linux-next, linux-kernel, Srinivas Kandagatla, stable
In-Reply-To: <20120411121058.088008039d669521e9afdfeb@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 614 bytes --]
Hi Mauro,
On Wed, 11 Apr 2012 12:10:58 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the v4l-dvb tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "__kfifo_max_r" [drivers/media/rc/rc-core.ko] undefined!
>
> Caused by commit 24a19bcbceda ("[media] ir-raw: Check available elements
> in kfifo before adding"). kfifo_avail expands to a call to __kfifo_max_r
> which is not exported to modules.
>
> I have used the v4l-dvb tree from next-20120410 for today.
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] seccomp: use a static inline for a function stub
From: Kees Cook @ 2012-04-17 3:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Morris, Will Drewry, linux-next, linux-kernel,
H. Peter Anvin, Eric Paris
In-Reply-To: <20120417120848.e7f3eabfbf79dc609318ea1e@canb.auug.org.au>
On Mon, Apr 16, 2012 at 7:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Fixes this error message when CONFIG_SECCOMP is not set:
>
> arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
> arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
>
> Signed-off-by: Stephen Rothwell <sfr@ozlabs.au.ibm.com>
Acked-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
ChromeOS Security
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (devicetree tree related)
From: Stephen Rothwell @ 2012-04-17 3:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-next, linux-kernel, Thomas Abraham
In-Reply-To: <CACxGe6tDa+AzK0O=E+EPZ90Ek_C-rM-G4fHSnsdL0S+fNcmzmw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
Hi Grant,
On Wed, 11 Apr 2012 18:35:34 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> On Wed, Apr 11, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Grant,
> >
> > On Wed, 11 Apr 2012 15:11:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> After merging the final tree, today's linux-next build (sparc64 defconfig)
> >> failed like this:
> >>
> >> drivers/of/of_mdio.c: In function 'of_mdiobus_register':
> >> drivers/of/of_mdio.c:75:4: error: implicit declaration of function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration]
> >>
> >> Caused by commit e46c11b94787 ("of/irq: add empty irq_of_parse_and_map()
> >> for non-dt builds"). SPARC has CONFIG_OF but not CONFIG_OF_IRQ ...
> >>
> >> I have reverted that commit for today.
> >
> > That commit is actually in the devicetree-current tree.
>
> Yes, drop that tree or revert that commit. There's nothing else in
> there and I didn't have time to pull it back today before you started
> linux-next for the day. The change is bogus and I'll spin a proper
> fixup for tomorrow.
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] seccomp: use a static inline for a function stub
From: Stephen Rothwell @ 2012-04-17 2:08 UTC (permalink / raw)
To: James Morris
Cc: Will Drewry, linux-next, linux-kernel, H. Peter Anvin, Eric Paris,
Kees Cook
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
Fixes this error message when CONFIG_SECCOMP is not set:
arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
Signed-off-by: Stephen Rothwell <sfr@ozlabs.au.ibm.com>
---
include/linux/seccomp.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 5818e86..60f2b35 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -90,7 +90,7 @@ static inline int seccomp_mode(struct seccomp *s)
struct seccomp { };
struct seccomp_filter { };
-#define secure_computing(x) 0
+static inline int secure_computing(int this_syscall) { return 0; }
static inline long prctl_get_seccomp(void)
{
--
1.7.8.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (security tree related)
From: Stephen Rothwell @ 2012-04-17 2:02 UTC (permalink / raw)
To: James Morris
Cc: Will Drewry, linux-next, linux-kernel, H. Peter Anvin, Eric Paris,
Kees Cook
In-Reply-To: <alpine.LRH.2.02.1204171127130.14814@tundra.namei.org>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
Hi James,
On Tue, 17 Apr 2012 11:33:26 +1000 (EST) James Morris <jmorris@namei.org> wrote:
>
> On Mon, 16 Apr 2012, Will Drewry wrote:
>
> > >> arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
> > >> arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
> > >> cc1: all warnings being treated as errors
>
> Is this happening because of
>
> #define secure_computing(x) 0
>
> ?
>
> In any case, that should probably be a static inline.
That could well be so - sorry I missed that. The failure was in an
allnoconfig build, so CONFIG_SECCOMP was off.
And yes, changing that to:
static inline int secure_computing(int this_syscall) { return 0; }
fixes the build problem. So that is a better fix.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build warning in Linus' tree
From: Konrad Rzeszutek Wilk @ 2012-04-17 1:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20120417104430.d1844b17e4c7d5ffb132f816@canb.auug.org.au>
On Tue, Apr 17, 2012 at 10:44:30AM +1000, Stephen Rothwell wrote:
> Hi Konrad,
>
> Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/block/xen-blkback/xenbus.c: In function 'xen_blkbk_discard':
> drivers/block/xen-blkback/xenbus.c:419:4: warning: passing argument 1 of 'dev_warn' makes pointer from integer without a cast [enabled by default]
> include/linux/device.h:894:5: note: expected 'const struct device *' but argument is of type 'long int'
>
> Introduced by commit 3389bb8bf761 ("xen/blkback: Make optional features
> be really optional"). Passing "dev-dev" to dev_warn() was hopefully not
> intended ...
No it was not. Not even sure how that mistake passed my compile test.
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (security tree related)
From: James Morris @ 2012-04-17 1:33 UTC (permalink / raw)
To: Will Drewry
Cc: Stephen Rothwell, linux-next, linux-kernel, H. Peter Anvin,
Eric Paris, Kees Cook
In-Reply-To: <CABqD9hYhC3dNX3CVSbsuJaG=zBUC4VMyMVYYmyOTN+Xfb=uC8w@mail.gmail.com>
On Mon, 16 Apr 2012, Will Drewry wrote:
> >> arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
> >> arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
> >> cc1: all warnings being treated as errors
Is this happening because of
#define secure_computing(x) 0
?
In any case, that should probably be a static inline.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH -next] hippi: fix printk format in rrunner.c
From: Randy Dunlap @ 2012-04-17 1:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, netdev, linux-hippi, Jes Sorensen,
Andrew Morton
In-Reply-To: <20120416161121.261ba4e7e38989173accfb16@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix printk format warning (from i386 build):
drivers/net/hippi/rrunner.c:146:9: warning: format '%08llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Jes Sorensen <jes@trained-monkey.org>
Cc: linux-hippi@sunsite.dk
---
drivers/net/hippi/rrunner.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-next-20120416.orig/drivers/net/hippi/rrunner.c
+++ linux-next-20120416/drivers/net/hippi/rrunner.c
@@ -142,8 +142,9 @@ static int __devinit rr_init_one(struct
pci_set_master(pdev);
printk(KERN_INFO "%s: Essential RoadRunner serial HIPPI "
- "at 0x%08llx, irq %i, PCI latency %i\n", dev->name,
- pci_resource_start(pdev, 0), pdev->irq, pci_latency);
+ "at 0x%llx, irq %i, PCI latency %i\n", dev->name,
+ (unsigned long long)pci_resource_start(pdev, 0),
+ pdev->irq, pci_latency);
/*
* Remap the MMIO regs into kernel space.
^ permalink raw reply
* [PATCH -next] soc: fix printk format in soc-dapm.c
From: Randy Dunlap @ 2012-04-17 1:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: alsa-devel, Mark Brown, LKML, linux-next, Andrew Morton,
Liam Girdwood
In-Reply-To: <20120416161121.261ba4e7e38989173accfb16@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix printk format warning for 'formats':
sound/soc/soc-dapm.c:2913:5: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'u64'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org
---
sound/soc/soc-dapm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20120416.orig/sound/soc/soc-dapm.c
+++ linux-next-20120416/sound/soc/soc-dapm.c
@@ -2909,7 +2909,7 @@ static int snd_soc_dai_link_event(struct
if (config->formats) {
fmt = ffs(config->formats) - 1;
} else {
- dev_warn(w->dapm->dev, "Invalid format %lx specified\n",
+ dev_warn(w->dapm->dev, "Invalid format %llx specified\n",
config->formats);
fmt = 0;
}
^ permalink raw reply
* [PATCH -next] staging: fix android alarm.c printk format warnings
From: Randy Dunlap @ 2012-04-17 1:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Greg KH, Brian Swetland, Andrew Morton, devel
In-Reply-To: <20120416161121.261ba4e7e38989173accfb16@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix printk format warnings by using 't' modifier for ptrdiff_t.
drivers/staging/android/alarm.c:344:2: warning: format '%ld' expects type 'long int', but argument 2 has type 'int'
drivers/staging/android/alarm.c:367:3: warning: format '%ld' expects type 'long int', but argument 2 has type 'int'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Greg KH <greg@kroah.com>
Cc: Brian Swetland <swetland@google.com>
---
drivers/staging/android/alarm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20120416.orig/drivers/staging/android/alarm.c
+++ linux-next-20120416/drivers/staging/android/alarm.c
@@ -341,7 +341,7 @@ static enum hrtimer_restart alarm_timer_
now = base->stopped ? base->stopped_time : hrtimer_cb_get_time(timer);
now = ktime_sub(now, base->delta);
- pr_alarm(INT, "alarm_timer_triggered type %ld at %lld\n",
+ pr_alarm(INT, "alarm_timer_triggered type %td at %lld\n",
base - alarms, ktime_to_ns(now));
while (base->first) {
@@ -364,7 +364,7 @@ static enum hrtimer_restart alarm_timer_
spin_lock_irqsave(&alarm_slock, flags);
}
if (!base->first)
- pr_alarm(FLOW, "no more alarms of type %ld\n", base - alarms);
+ pr_alarm(FLOW, "no more alarms of type %td\n", base - alarms);
update_timer_locked(base, true);
spin_unlock_irqrestore(&alarm_slock, flags);
return HRTIMER_NORESTART;
^ permalink raw reply
* linux-next: build warning in Linus' tree
From: Stephen Rothwell @ 2012-04-17 0:44 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
Hi Konrad,
Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/block/xen-blkback/xenbus.c: In function 'xen_blkbk_discard':
drivers/block/xen-blkback/xenbus.c:419:4: warning: passing argument 1 of 'dev_warn' makes pointer from integer without a cast [enabled by default]
include/linux/device.h:894:5: note: expected 'const struct device *' but argument is of type 'long int'
Introduced by commit 3389bb8bf761 ("xen/blkback: Make optional features
be really optional"). Passing "dev-dev" to dev_warn() was hopefully not
intended ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH -next] soc: fix printk format in soc-dapm.c
From: Fabio Estevam @ 2012-04-16 22:52 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, alsa-devel, Mark Brown, LKML, linux-next,
Andrew Morton, Liam Girdwood
In-Reply-To: <4F8CC0E9.3010407@xenotime.net>
On Mon, Apr 16, 2012 at 10:01 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix printk format warning for 'formats':
>
> sound/soc/soc-dapm.c:2913:5: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'u64'
I have sent a fix for this earlier today and Mark has already applied it.
^ permalink raw reply
* Re: [PATCH -next] mtd: fix sbc2_flash build when PCI is not enabled
From: Randy Dunlap @ 2012-04-17 1:25 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Stephen Rothwell, linux-next, LKML, Andrew Morton,
David Woodhouse, linux-mtd, Tim Hockin
In-Reply-To: <CAP=VYLr6TtABMNz1EBY2T6vYdhpR5X6S3yQTtvvqV0D7c9U5Lw@mail.gmail.com>
On 04/16/2012 03:20 PM, Paul Gortmaker wrote:
> On Mon, Apr 16, 2012 at 3:50 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> From: Randy Dunlap <rdunlap@xenotime.net>
>>
>> sbc2_flash.c is a PCI driver, but its build fails when CONFIG_PCI
>
> Minor nit -- above line and subject reference sbc2, when fail comes
> from scb2 source module.
Ack. I noticed later that I had botched that.
Thanks.
> Paul.
> --
>
>> is not enabled, so make it depend on PCI.
>>
>> drivers/mtd/maps/scb2_flash.c:237:1: warning: data definition has no type or storage class
>> drivers/mtd/maps/scb2_flash.c:237:1: warning: type defaults to 'int' in declaration of 'module_pci_driver'
>> drivers/mtd/maps/scb2_flash.c:237:1: warning: parameter names (without types) in function declaration
>>
>> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: linux-mtd@lists.infradead.org
>> ---
>> drivers/mtd/maps/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- linux-next-20120416.orig/drivers/mtd/maps/Kconfig
>> +++ linux-next-20120416/drivers/mtd/maps/Kconfig
>> @@ -224,7 +224,7 @@ config MTD_CK804XROM
>>
>> config MTD_SCB2_FLASH
>> tristate "BIOS flash chip on Intel SCB2 boards"
>> - depends on X86 && MTD_JEDECPROBE
>> + depends on X86 && MTD_JEDECPROBE && PCI
>> help
>> Support for treating the BIOS flash chip on Intel SCB2 boards
>> as an MTD device - with this you can reprogram your BIOS.
>> --
--
~Randy
^ permalink raw reply
* Re: [PATCH -next] mtd: fix sbc2_flash build when PCI is not enabled
From: Paul Gortmaker @ 2012-04-16 22:20 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Andrew Morton,
David Woodhouse, linux-mtd, Tim Hockin
In-Reply-To: <4F8C780D.9010702@xenotime.net>
On Mon, Apr 16, 2012 at 3:50 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> sbc2_flash.c is a PCI driver, but its build fails when CONFIG_PCI
Minor nit -- above line and subject reference sbc2, when fail comes
from scb2 source module.
Paul.
--
> is not enabled, so make it depend on PCI.
>
> drivers/mtd/maps/scb2_flash.c:237:1: warning: data definition has no type or storage class
> drivers/mtd/maps/scb2_flash.c:237:1: warning: type defaults to 'int' in declaration of 'module_pci_driver'
> drivers/mtd/maps/scb2_flash.c:237:1: warning: parameter names (without types) in function declaration
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linux-mtd@lists.infradead.org
> ---
> drivers/mtd/maps/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20120416.orig/drivers/mtd/maps/Kconfig
> +++ linux-next-20120416/drivers/mtd/maps/Kconfig
> @@ -224,7 +224,7 @@ config MTD_CK804XROM
>
> config MTD_SCB2_FLASH
> tristate "BIOS flash chip on Intel SCB2 boards"
> - depends on X86 && MTD_JEDECPROBE
> + depends on X86 && MTD_JEDECPROBE && PCI
> help
> Support for treating the BIOS flash chip on Intel SCB2 boards
> as an MTD device - with this you can reprogram your BIOS.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -next] wireless: TI wlxxx depends on MAC80211
From: Randy Dunlap @ 2012-04-16 19:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Andrew Morton, Luciano Coelho, linux-wireless,
John W. Linville
In-Reply-To: <20120416161121.261ba4e7e38989173accfb16@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
wl12xx build fails with many undefined symbol errors when MAC80211
and CFG80211 are not enabled, so make WLCORE and WL12XX depend
on MAC80211 (which already depends on CFG80211).
Here are a few of the many build errors:
drivers/built-in.o: In function `wl1271_register_hw':
main.c:(.text+0x4197cd): undefined reference to `ieee80211_register_hw'
drivers/built-in.o: In function `wl1271_rx_streaming_timer':
main.c:(.text+0x419818): undefined reference to `ieee80211_queue_work'
drivers/built-in.o: In function `wl1271_flush_deferred_work':
main.c:(.text+0x419910): undefined reference to `ieee80211_rx'
main.c:(.text+0x419938): undefined reference to `ieee80211_tx_status'
drivers/built-in.o: In function `wl12xx_op_channel_switch':
main.c:(.text+0x419afc): undefined reference to `ieee80211_chswitch_done'
drivers/built-in.o: In function `wl1271_ssid_set':
drivers/built-in.o: In function `wl1271_event_process':
event.c:(.text+0x41fec4): undefined reference to `ieee80211_sched_scan_stopped'
event.c:(.text+0x41ff88): undefined reference to `ieee80211_cqm_rssi_notify'
event.c:(.text+0x42000d): undefined reference to `ieee80211_stop_rx_ba_session'
event.c:(.text+0x420048): undefined reference to `ieee80211_stop_rx_ba_session'
event.c:(.text+0x4200b8): undefined reference to `ieee80211_chswitch_done'
event.c:(.text+0x4201ae): undefined reference to `ieee80211_find_sta'
event.c:(.text+0x4201ba): undefined reference to `ieee80211_report_low_ack'
event.c:(.text+0x42021b): undefined reference to `ieee80211_connection_loss'
drivers/built-in.o: In function `wl1271_tx_complete_packet':
tx.c:(.text+0x4206a6): undefined reference to `ieee80211_get_hdrlen_from_skb'
drivers/built-in.o: In function `wl1271_tx_fill_hdr':
tx.c:(.text+0x4208ca): undefined reference to `ieee80211_hdrlen'
drivers/built-in.o: In function `wl1271_handle_tx_low_watermark':
(.text+0x420e25): undefined reference to `ieee80211_wake_queue'
drivers/built-in.o: In function `wl12xx_rearm_rx_streaming':
(.text+0x420ed9): undefined reference to `ieee80211_queue_work'
drivers/built-in.o: In function `wl1271_tx_work_locked':
(.text+0x421008): undefined reference to `ieee80211_free_txskb'
drivers/built-in.o: In function `wl1271_rx_status.clone.2':
rx.c:(.text+0x421593): undefined reference to `ieee80211_channel_to_frequency'
drivers/built-in.o: In function `wl1271_ps_filter_frames':
ps.c:(.text+0x421a41): undefined reference to `ieee80211_tx_status'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Luciano Coelho <coelho@ti.com>
Cc: linux-wireless@vger.kernel.org
Cc: "John W. Linville" <linville@tuxdriver.com>
---
drivers/net/wireless/ti/wl12xx/Kconfig | 1 +
drivers/net/wireless/ti/wlcore/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--- linux-next-20120416.orig/drivers/net/wireless/ti/wl12xx/Kconfig
+++ linux-next-20120416/drivers/net/wireless/ti/wl12xx/Kconfig
@@ -1,5 +1,6 @@
config WL12XX
tristate "TI wl12xx support"
+ depends on MAC80211
select WLCORE
---help---
This module adds support for wireless adapters based on TI wl1271,
--- linux-next-20120416.orig/drivers/net/wireless/ti/wlcore/Kconfig
+++ linux-next-20120416/drivers/net/wireless/ti/wlcore/Kconfig
@@ -1,6 +1,6 @@
config WLCORE
tristate "TI wlcore support"
- depends on WL_TI && GENERIC_HARDIRQS
+ depends on WL_TI && GENERIC_HARDIRQS && MAC80211
depends on INET
select FW_LOADER
---help---
^ permalink raw reply
* Re: [PATCH] mfd: fix modular builds of rc5t583 regulator support
From: Samuel Ortiz @ 2012-04-16 19:26 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Laxman Dewangan, broonie@opensource.wolfsonmicro.com,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org
In-Reply-To: <4F8C28C5.9070308@windriver.com>
Hi Paul, Laxman,
On Mon, Apr 16, 2012 at 10:12:21AM -0400, Paul Gortmaker wrote:
> On 12-04-16 02:54 AM, Laxman Dewangan wrote:
> > On Monday 16 April 2012 09:38 AM, Paul Gortmaker wrote:
> >> The combination of commit 1b1247dd75aa5cf5fae54a3bec7280046e9c7957
> >>
> >> "mfd: Add support for RICOH PMIC RC5T583"
> >>
> >> and commit 6ffc3270210efa2bea526953a142ffc908f5bd86
> >>
> >> "regulator: Add support for RICOH PMIC RC5T583 regulator"
> >>
> >> are causing the i386 allmodconfig builds to fail with this:
> >>
> >> ERROR: "rc5t583_update" [drivers/regulator/rc5t583-regulator.ko] undefined!
> >> ERROR: "rc5t583_set_bits" [drivers/regulator/rc5t583-regulator.ko] undefined!
> >> ERROR: "rc5t583_clear_bits" [drivers/regulator/rc5t583-regulator.ko] undefined!
> >> ERROR: "rc5t583_read" [drivers/regulator/rc5t583-regulator.ko] undefined!
> >>
> >> and this:
> >>
> >> ERROR: "rc5t583_ext_power_req_config" [drivers/regulator/rc5t583-regulator.ko] undefined!
> >>
> >> For the 1st four, make the simple ops static inline, instead of
> >> polluting the namespace with trivial exports. For the last one,
> >> add an EXPORT_SYMBOL.
> >>
> >> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> >> ---
> >>
> >> [ alternately, make REGULATOR_RC5T583 bool instead of tristate? ]
> >
> > Why not export all require symbol from mfd core.
> > I am sending the patch to exporting all required apis. Please review.
>
> As I said in the commit log, it doesn't seem to make sense to export
> them when they are trivial enough to be static inline, since it
> avoids having them pollute the /proc/kallsyms namespace.
I'm applying Paul's patch to my for-linus branch, thanks guys.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: linux-next: build failure after merge of the rcu tree
From: Paul E. McKenney @ 2012-04-16 17:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Linus Torvalds, Paul E. McKenney
In-Reply-To: <20120416141117.6dfcc5931400fede4e8cbe58@canb.auug.org.au>
On Mon, Apr 16, 2012 at 02:11:17PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/binfmt_misc.c: In function 'create_entry':
> fs/binfmt_misc.c:314:2: error: implicit declaration of function '_copy_from_user' [-Werror=implicit-function-declaration]
>
> Caused by commit d17faaa53e2e ("fs: Silence bogus copy_to_user() build
> errors"). _copy_from_user() appears to only exist for the x86 and tile
> architectures ...
>
> I have used the rcu tree from next-20120413 for today.
<red face>
It turns out that bug that commit d17faaa53e2e was working around has
been fixed in 3.4-rc2, so I have dropped that patch and reposted the
series. Please accept my apologies for the hassle!
Thanx, Paul
^ permalink raw reply
* [PATCH -next] mtd: fix sbc2_flash build when PCI is not enabled
From: Randy Dunlap @ 2012-04-16 19:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Andrew Morton, David Woodhouse, linux-mtd,
Tim Hockin
In-Reply-To: <20120416161121.261ba4e7e38989173accfb16@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
sbc2_flash.c is a PCI driver, but its build fails when CONFIG_PCI
is not enabled, so make it depend on PCI.
drivers/mtd/maps/scb2_flash.c:237:1: warning: data definition has no type or storage class
drivers/mtd/maps/scb2_flash.c:237:1: warning: type defaults to 'int' in declaration of 'module_pci_driver'
drivers/mtd/maps/scb2_flash.c:237:1: warning: parameter names (without types) in function declaration
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
---
drivers/mtd/maps/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20120416.orig/drivers/mtd/maps/Kconfig
+++ linux-next-20120416/drivers/mtd/maps/Kconfig
@@ -224,7 +224,7 @@ config MTD_CK804XROM
config MTD_SCB2_FLASH
tristate "BIOS flash chip on Intel SCB2 boards"
- depends on X86 && MTD_JEDECPROBE
+ depends on X86 && MTD_JEDECPROBE && PCI
help
Support for treating the BIOS flash chip on Intel SCB2 boards
as an MTD device - with this you can reprogram your BIOS.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (security tree related)
From: Will Drewry @ 2012-04-16 16:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Morris, linux-next, linux-kernel, H. Peter Anvin,
Eric Paris, Kees Cook
In-Reply-To: <CABqD9hauxzd4vVbxyC5M1p9e6mLt1cjYP7wbhzTKPi3iMpc0kg@mail.gmail.com>
On Mon, Apr 16, 2012 at 10:32 AM, Will Drewry <wad@chromium.org> wrote:
> On Mon, Apr 16, 2012 at 12:46 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> After merging the final tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
>>
>> arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
>> arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
>> cc1: all warnings being treated as errors
>>
>> Introduced by commit acf3b2c71ed2 ("seccomp: add SECCOMP_RET_ERRNO"). I
>> have applied the following hack fix that fixes the build, but the other
>> seven call sites of secure_computing() should be fixed up properly.
>
> Thanks for this, and the other two fixes! I'll pull together a patch
> fixing up the other call sites.
Hrm - with liberal application of grep and lxr, I'm not seeing any
other call sites that need to be fixed. I ended up with the exact
same patch as yours.
At present, the return value from secure_computing() can be ignored
for every arch that supports CONFIG_SECCOMP and does not support
CONFIG_HAVE_ARCH_SECCOMP_FILTER, so I don't necessarily see your patch
as a hack. Then as the pieces needed to support
CONFIG_HAVE_ARCH_SECCOMP_FILTER end up in place, the (void) cast will
be removed. (Respecting the return value is noted in the arch/Kconfig
description for adding support.)
I certainly don't mind bouncing the casts patch (broken out per-arch)
over to James's tree so that you don't have to carry the fix, but I
wonder if I'm missing some implicit context.
Thanks!
will
>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Mon, 16 Apr 2012 15:39:49 +1000
>> Subject: [PATCH] seccomp: hack fix for build failures with secure_computing
>> return value change
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> arch/microblaze/kernel/ptrace.c | 2 +-
>> arch/mips/kernel/ptrace.c | 2 +-
>> arch/powerpc/kernel/ptrace.c | 2 +-
>> arch/s390/kernel/ptrace.c | 2 +-
>> arch/sh/kernel/ptrace_32.c | 2 +-
>> arch/sh/kernel/ptrace_64.c | 2 +-
>> arch/sparc/kernel/ptrace_64.c | 2 +-
>> 7 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/microblaze/kernel/ptrace.c b/arch/microblaze/kernel/ptrace.c
>> index 6eb2aa9..9e3ffc9 100644
>> --- a/arch/microblaze/kernel/ptrace.c
>> +++ b/arch/microblaze/kernel/ptrace.c
>> @@ -136,7 +136,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
>> {
>> long ret = 0;
>>
>> - secure_computing(regs->r12);
>> + (void)secure_computing(regs->r12);
>>
>> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
>> tracehook_report_syscall_entry(regs))
>> diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
>> index 7c24c29..4f83d73 100644
>> --- a/arch/mips/kernel/ptrace.c
>> +++ b/arch/mips/kernel/ptrace.c
>> @@ -535,7 +535,7 @@ static inline int audit_arch(void)
>> asmlinkage void syscall_trace_enter(struct pt_regs *regs)
>> {
>> /* do the secure computing check first */
>> - secure_computing(regs->regs[2]);
>> + (void)secure_computing(regs->regs[2]);
>>
>> if (!(current->ptrace & PT_PTRACED))
>> goto out;
>> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
>> index 8d8e028..53cebc4 100644
>> --- a/arch/powerpc/kernel/ptrace.c
>> +++ b/arch/powerpc/kernel/ptrace.c
>> @@ -1710,7 +1710,7 @@ long do_syscall_trace_enter(struct pt_regs *regs)
>> {
>> long ret = 0;
>>
>> - secure_computing(regs->gpr[0]);
>> + (void)secure_computing(regs->gpr[0]);
>>
>> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
>> tracehook_report_syscall_entry(regs))
>> diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
>> index 02f300f..96e0dea 100644
>> --- a/arch/s390/kernel/ptrace.c
>> +++ b/arch/s390/kernel/ptrace.c
>> @@ -719,7 +719,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
>> long ret = 0;
>>
>> /* Do the secure computing check first. */
>> - secure_computing(regs->gprs[2]);
>> + (void)secure_computing(regs->gprs[2]);
>>
>> /*
>> * The sysc_tracesys code in entry.S stored the system
>> diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
>> index 9698671..cf55945 100644
>> --- a/arch/sh/kernel/ptrace_32.c
>> +++ b/arch/sh/kernel/ptrace_32.c
>> @@ -503,7 +503,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
>> {
>> long ret = 0;
>>
>> - secure_computing(regs->regs[0]);
>> + (void)secure_computing(regs->regs[0]);
>>
>> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
>> tracehook_report_syscall_entry(regs))
>> diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
>> index bc81e07..3d3600f 100644
>> --- a/arch/sh/kernel/ptrace_64.c
>> +++ b/arch/sh/kernel/ptrace_64.c
>> @@ -522,7 +522,7 @@ asmlinkage long long do_syscall_trace_enter(struct pt_regs *regs)
>> {
>> long long ret = 0;
>>
>> - secure_computing(regs->regs[9]);
>> + (void)secure_computing(regs->regs[9]);
>>
>> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
>> tracehook_report_syscall_entry(regs))
>> diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
>> index 6f97c07..6ddec1f 100644
>> --- a/arch/sparc/kernel/ptrace_64.c
>> +++ b/arch/sparc/kernel/ptrace_64.c
>> @@ -1062,7 +1062,7 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
>> int ret = 0;
>>
>> /* do the secure computing check first */
>> - secure_computing(regs->u_regs[UREG_G1]);
>> + (void)secure_computing(regs->u_regs[UREG_G1]);
>>
>> if (test_thread_flag(TIF_SYSCALL_TRACE))
>> ret = tracehook_report_syscall_entry(regs);
>> --
>> 1.7.10.rc3
>>
>> --
>> Cheers,
>> Stephen Rothwell sfr@canb.auug.org.au
>> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (security tree related)
From: Will Drewry @ 2012-04-16 15:44 UTC (permalink / raw)
To: Eric Paris
Cc: Stephen Rothwell, James Morris, linux-next, linux-kernel,
H. Peter Anvin, Kees Cook
In-Reply-To: <1334590461.2250.0.camel@localhost>
On Mon, Apr 16, 2012 at 10:34 AM, Eric Paris <eparis@redhat.com> wrote:
> On Mon, 2012-04-16 at 10:32 -0500, Will Drewry wrote:
>
>> Thanks for this, and the other two fixes! I'll pull together a patch
>> fixing up the other call sites. My past revisions had avoided this by
>> using a new symbol, and I totally forgot to touch these up in the last
>> round.
>>
>> What's the best way to submit the clean up -- against the security-next tree?
>>
>> Thanks and sorry for the noise!
>
> Just send fixes to James and they will get picked up by Stephen the day
> after he commits them to security-next.
Cool - thanks!
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (security tree related)
From: Eric Paris @ 2012-04-16 15:34 UTC (permalink / raw)
To: Will Drewry
Cc: Stephen Rothwell, James Morris, linux-next, linux-kernel,
H. Peter Anvin, Kees Cook
In-Reply-To: <CABqD9hauxzd4vVbxyC5M1p9e6mLt1cjYP7wbhzTKPi3iMpc0kg@mail.gmail.com>
On Mon, 2012-04-16 at 10:32 -0500, Will Drewry wrote:
> Thanks for this, and the other two fixes! I'll pull together a patch
> fixing up the other call sites. My past revisions had avoided this by
> using a new symbol, and I totally forgot to touch these up in the last
> round.
>
> What's the best way to submit the clean up -- against the security-next tree?
>
> Thanks and sorry for the noise!
Just send fixes to James and they will get picked up by Stephen the day
after he commits them to security-next.
-Eric
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (security tree related)
From: Will Drewry @ 2012-04-16 15:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Morris, linux-next, linux-kernel, H. Peter Anvin,
Eric Paris, Kees Cook
In-Reply-To: <20120416154607.302f7ae245472e1e917dacef@canb.auug.org.au>
On Mon, Apr 16, 2012 at 12:46 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
> arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]
> cc1: all warnings being treated as errors
>
> Introduced by commit acf3b2c71ed2 ("seccomp: add SECCOMP_RET_ERRNO"). I
> have applied the following hack fix that fixes the build, but the other
> seven call sites of secure_computing() should be fixed up properly.
Thanks for this, and the other two fixes! I'll pull together a patch
fixing up the other call sites. My past revisions had avoided this by
using a new symbol, and I totally forgot to touch these up in the last
round.
What's the best way to submit the clean up -- against the security-next tree?
Thanks and sorry for the noise!
will
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 16 Apr 2012 15:39:49 +1000
> Subject: [PATCH] seccomp: hack fix for build failures with secure_computing
> return value change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/microblaze/kernel/ptrace.c | 2 +-
> arch/mips/kernel/ptrace.c | 2 +-
> arch/powerpc/kernel/ptrace.c | 2 +-
> arch/s390/kernel/ptrace.c | 2 +-
> arch/sh/kernel/ptrace_32.c | 2 +-
> arch/sh/kernel/ptrace_64.c | 2 +-
> arch/sparc/kernel/ptrace_64.c | 2 +-
> 7 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/microblaze/kernel/ptrace.c b/arch/microblaze/kernel/ptrace.c
> index 6eb2aa9..9e3ffc9 100644
> --- a/arch/microblaze/kernel/ptrace.c
> +++ b/arch/microblaze/kernel/ptrace.c
> @@ -136,7 +136,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
> {
> long ret = 0;
>
> - secure_computing(regs->r12);
> + (void)secure_computing(regs->r12);
>
> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
> tracehook_report_syscall_entry(regs))
> diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
> index 7c24c29..4f83d73 100644
> --- a/arch/mips/kernel/ptrace.c
> +++ b/arch/mips/kernel/ptrace.c
> @@ -535,7 +535,7 @@ static inline int audit_arch(void)
> asmlinkage void syscall_trace_enter(struct pt_regs *regs)
> {
> /* do the secure computing check first */
> - secure_computing(regs->regs[2]);
> + (void)secure_computing(regs->regs[2]);
>
> if (!(current->ptrace & PT_PTRACED))
> goto out;
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 8d8e028..53cebc4 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -1710,7 +1710,7 @@ long do_syscall_trace_enter(struct pt_regs *regs)
> {
> long ret = 0;
>
> - secure_computing(regs->gpr[0]);
> + (void)secure_computing(regs->gpr[0]);
>
> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
> tracehook_report_syscall_entry(regs))
> diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
> index 02f300f..96e0dea 100644
> --- a/arch/s390/kernel/ptrace.c
> +++ b/arch/s390/kernel/ptrace.c
> @@ -719,7 +719,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
> long ret = 0;
>
> /* Do the secure computing check first. */
> - secure_computing(regs->gprs[2]);
> + (void)secure_computing(regs->gprs[2]);
>
> /*
> * The sysc_tracesys code in entry.S stored the system
> diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
> index 9698671..cf55945 100644
> --- a/arch/sh/kernel/ptrace_32.c
> +++ b/arch/sh/kernel/ptrace_32.c
> @@ -503,7 +503,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
> {
> long ret = 0;
>
> - secure_computing(regs->regs[0]);
> + (void)secure_computing(regs->regs[0]);
>
> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
> tracehook_report_syscall_entry(regs))
> diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
> index bc81e07..3d3600f 100644
> --- a/arch/sh/kernel/ptrace_64.c
> +++ b/arch/sh/kernel/ptrace_64.c
> @@ -522,7 +522,7 @@ asmlinkage long long do_syscall_trace_enter(struct pt_regs *regs)
> {
> long long ret = 0;
>
> - secure_computing(regs->regs[9]);
> + (void)secure_computing(regs->regs[9]);
>
> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
> tracehook_report_syscall_entry(regs))
> diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
> index 6f97c07..6ddec1f 100644
> --- a/arch/sparc/kernel/ptrace_64.c
> +++ b/arch/sparc/kernel/ptrace_64.c
> @@ -1062,7 +1062,7 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
> int ret = 0;
>
> /* do the secure computing check first */
> - secure_computing(regs->u_regs[UREG_G1]);
> + (void)secure_computing(regs->u_regs[UREG_G1]);
>
> if (test_thread_flag(TIF_SYSCALL_TRACE))
> ret = tracehook_report_syscall_entry(regs);
> --
> 1.7.10.rc3
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox