* Re: linux-next: build failure after merge of the final tree (arm-soc tree related)
From: Arnd Bergmann @ 2012-03-15 16:39 UTC (permalink / raw)
To: Jason Cooper
Cc: Stephen Rothwell, Olof Johansson, linux-arm-kernel, Michael Walle,
linux-next, linux-kernel
In-Reply-To: <20120315002020.GA16189@titan.lakedaemon.net>
On Thursday 15 March 2012, Jason Cooper wrote:
> That's my mistake. I did a pull request for the wrong branch. Olof,
> could you please drop the offending branch and I'll submit a new pull
> request once I have a chance to test Arnd's irq patch?
I reverted this in the for-next branch for now. The two initial patches
from the kirkwood/board branch are still present.
Arnd
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (arm-soc tree related)
From: Jason Cooper @ 2012-03-15 17:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Olof Johansson, linux-arm-kernel, Michael Walle,
linux-next, linux-kernel
In-Reply-To: <201203151639.38223.arnd@arndb.de>
On Thu, Mar 15, 2012 at 04:39:38PM +0000, Arnd Bergmann wrote:
> On Thursday 15 March 2012, Jason Cooper wrote:
> > That's my mistake. I did a pull request for the wrong branch. Olof,
> > could you please drop the offending branch and I'll submit a new pull
> > request once I have a chance to test Arnd's irq patch?
>
> I reverted this in the for-next branch for now. The two initial patches
> from the kirkwood/board branch are still present.
Okay, thanks. I've rebased onto next/boards and merged the
depends/irqdomain branch. I'm making progress, but not finished yet.
How is a pull-request done in the above scenario? is my merge commit
included in the series? what is the pull-request based on?
next/boards, or depends/irqdomain?
thx,
Jason.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (arm-soc tree related)
From: Arnd Bergmann @ 2012-03-15 17:32 UTC (permalink / raw)
To: Jason Cooper
Cc: Stephen Rothwell, Olof Johansson, linux-arm-kernel, Michael Walle,
linux-next, linux-kernel
In-Reply-To: <20120315172213.GC20243@titan.lakedaemon.net>
On Thursday 15 March 2012, Jason Cooper wrote:
> On Thu, Mar 15, 2012 at 04:39:38PM +0000, Arnd Bergmann wrote:
> > On Thursday 15 March 2012, Jason Cooper wrote:
> > > That's my mistake. I did a pull request for the wrong branch. Olof,
> > > could you please drop the offending branch and I'll submit a new pull
> > > request once I have a chance to test Arnd's irq patch?
> >
> > I reverted this in the for-next branch for now. The two initial patches
> > from the kirkwood/board branch are still present.
>
> Okay, thanks. I've rebased onto next/boards and merged the
> depends/irqdomain branch. I'm making progress, but not finished yet.
Ok. I hope we can still make it for v3.4, but I think it won't be
much of a problem if not -- it will get merged into linux-next
just after v3.4-rc1 in case we don't make it, and then you have
plenty of time to improve it further.
> How is a pull-request done in the above scenario? is my merge commit
> included in the series? what is the pull-request based on?
> next/boards, or depends/irqdomain?
You should base it on depends/irqdomain.
Arnd
^ permalink raw reply
* Re: linux-next: manual merge of the arm-soc tree with Linus' tree
From: Arnd Bergmann @ 2012-03-15 20:01 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Stephen Rothwell, Olof Johansson, linux-arm-kernel, linux-next,
linux-kernel, Magnus Damm, Rafael J. Wysocki, Paul Mundt
In-Reply-To: <1362815.uO65s14ojU@avalon>
On Thursday 15 March 2012, Laurent Pinchart wrote:
> The following patch (5d7220ec000f rebased on top of 1740d3448012) shows the
> correct conflict resolution in my opinion.
>
> From f040ba69632a54c86767974768d68b308901061c Mon Sep 17 00:00:00 2001
> From: Magnus Damm <damm@opensource.se>
> Date: Wed, 29 Feb 2012 12:37:19 +0900
> Subject: [PATCH] ARM: mach-shmobile: sh7372 map_io and init_early update
>
> ARM: mach-shmobile: sh7372 map_io and init_early update
>
> Update the sh7372 SoC and the AP4EVB and Mackerel boards to make use
> of the functions sh7372_map_io() and sh7372_add_early_devices().
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Hi Laurent,
I've merged Paul's branch into my renesas/soc branch, because I don't
rebase the branches once they are merged into arm-soc. Thanks a lot
for the resolution you suggested, I used the same resulting code
in the merge commit.
I'm not particularly happy about how we got here. Obviously, the bug
fixes that Paul sent should have gone through the arm-soc tree to
avoid this situation, and they should have been based on a -rc release
rather than some random commit after -rc6. It's not a big issue
because the next/soc branch already contains -rc7 though.
Arnd
^ permalink raw reply
* Re: linux-next: Tree for Mar 15 (crypto)
From: Jussi Kivilinna @ 2012-03-15 20:05 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-crypto
In-Reply-To: <4F620F37.4070404@xenotime.net>
Quoting Randy Dunlap <rdunlap@xenotime.net>:
> On 03/15/2012 12:59 AM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> News: the build system (see below) has had its toolchains for most
>> architectures updated to gcc 4.6.3. People might like to check the build
>> results and consider if this change has caused any problems. There are
>> also a number of architectures that are building today for the first
>> time. Thanks to Tony Breeds for his efforts in providing toolchains.
>>
>> Changes since 20120314:
>
>
> on x86_64:
>
> arch/x86/crypto/twofish-x86_64-3way.o: In function `fini':
> (.exit.text+0x0): multiple definition of `fini'
> arch/x86/crypto/camellia-x86_64.o:(.exit.text+0x0): first defined here
> arch/x86/crypto/twofish-x86_64-3way.o: In function `init':
> (.init.text+0x0): multiple definition of `init'
> arch/x86/crypto/camellia-x86_64.o:(.init.text+0x0): first defined here
>
Ah.. init()/fini() should be static functions but are not. I'll send
patches soon. Thanks.
>
> Full randconfig file is attached.
>
>
> --
> ~Randy
>
^ permalink raw reply
* [PATCH 1/2] crypto: camellia-x86_64 - module init/exit functions should be static
From: Jussi Kivilinna @ 2012-03-15 20:11 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Rothwell, Randy Dunlap, linux-next, linux-crypto,
linux-kernel
In-Reply-To: <4F620F37.4070404@xenotime.net>
This caused conflict with twofish-x86_64-3way when compiled into kernel,
same function names and not static.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
arch/x86/crypto/camellia_glue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index 1ca36a9..3306dc0 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -1925,7 +1925,7 @@ static int force;
module_param(force, int, 0);
MODULE_PARM_DESC(force, "Force module load, ignore CPU blacklist");
-int __init init(void)
+static int __init init(void)
{
if (!force && is_blacklisted_cpu()) {
printk(KERN_INFO
@@ -1938,7 +1938,7 @@ int __init init(void)
return crypto_register_algs(camellia_algs, ARRAY_SIZE(camellia_algs));
}
-void __exit fini(void)
+static void __exit fini(void)
{
crypto_unregister_algs(camellia_algs, ARRAY_SIZE(camellia_algs));
}
^ permalink raw reply related
* [PATCH 2/2] crypto: twofish-x86_64-3way - module init/exit functions should be static
From: Jussi Kivilinna @ 2012-03-15 20:11 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Rothwell, Randy Dunlap, linux-next, linux-crypto,
linux-kernel
In-Reply-To: <4F620F37.4070404@xenotime.net>
This caused conflict with camellia-x86_64 when compiled into kernel, same
function names and not static.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
arch/x86/crypto/twofish_glue_3way.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/twofish_glue_3way.c b/arch/x86/crypto/twofish_glue_3way.c
index 408fc0c..922ab24 100644
--- a/arch/x86/crypto/twofish_glue_3way.c
+++ b/arch/x86/crypto/twofish_glue_3way.c
@@ -668,7 +668,7 @@ static int force;
module_param(force, int, 0);
MODULE_PARM_DESC(force, "Force module load, ignore CPU blacklist");
-int __init init(void)
+static int __init init(void)
{
if (!force && is_blacklisted_cpu()) {
printk(KERN_INFO
@@ -681,7 +681,7 @@ int __init init(void)
return crypto_register_algs(tf_algs, ARRAY_SIZE(tf_algs));
}
-void __exit fini(void)
+static void __exit fini(void)
{
crypto_unregister_algs(tf_algs, ARRAY_SIZE(tf_algs));
}
^ permalink raw reply related
* Change of the linux-watchdog-next tree location
From: Wim Van Sebroeck @ 2012-03-15 20:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, linux-next, Linux Watchdog Mailing List, Linus,
Andrew Morton
In-Reply-To: <20111025185229.GY11844@infomag.iguana.be>
Hi Stephen,
Could you change the location of the linux-watchdog-next tree to the following tree and branch:
git://www.linux-watchdog.org/linux-watchdog-next.git master
Kind regards,
Wim.
^ permalink raw reply
* Re: linux-next: Tree for Mar 15 (staging/android/ram_console.c)
From: Greg Kroah-Hartman @ 2012-03-15 21:03 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, devel, Brian Swetland, linux-next, LKML
In-Reply-To: <4F62118A.2070403@xenotime.net>
On Thu, Mar 15, 2012 at 08:58:02AM -0700, Randy Dunlap wrote:
> On 03/15/2012 12:59 AM, Stephen Rothwell wrote:
>
> > Hi all,
> >
> > News: the build system (see below) has had its toolchains for most
> > architectures updated to gcc 4.6.3. People might like to check the build
> > results and consider if this change has caused any problems. There are
> > also a number of architectures that are building today for the first
> > time. Thanks to Tony Breeds for his efforts in providing toolchains.
> >
> > Changes since 20120314:
>
>
>
> on x86_64 when CONFIG_PRINTK is not enabled:
>
>
> drivers/staging/android/ram_console.c:99:6: error: 'dmesg_restrict' undeclared (first use in this function)
This patch should solve this, right?
diff --git a/drivers/staging/android/ram_console.c b/drivers/staging/android/ram_console.c
index 2918bc1..ce140ff 100644
--- a/drivers/staging/android/ram_console.c
+++ b/drivers/staging/android/ram_console.c
@@ -85,6 +85,10 @@ static int __init ram_console_module_init(void)
return platform_driver_probe(&ram_console_driver, ram_console_probe);
}
+#ifndef CONFIG_PRINTK
+#define dmesg_restrict 0
+#endif
+
static ssize_t ram_console_read_old(struct file *file, char __user *buf,
size_t len, loff_t *offset)
{
^ permalink raw reply related
* Re: linux-next: manual merge of the arm-soc tree with Linus' tree
From: Rafael J. Wysocki @ 2012-03-15 21:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Laurent Pinchart, Stephen Rothwell, Olof Johansson,
linux-arm-kernel, linux-next, linux-kernel, Magnus Damm,
Paul Mundt
In-Reply-To: <201203152001.12353.arnd@arndb.de>
On Thursday, March 15, 2012, Arnd Bergmann wrote:
> On Thursday 15 March 2012, Laurent Pinchart wrote:
> > The following patch (5d7220ec000f rebased on top of 1740d3448012) shows the
> > correct conflict resolution in my opinion.
> >
> > From f040ba69632a54c86767974768d68b308901061c Mon Sep 17 00:00:00 2001
> > From: Magnus Damm <damm@opensource.se>
> > Date: Wed, 29 Feb 2012 12:37:19 +0900
> > Subject: [PATCH] ARM: mach-shmobile: sh7372 map_io and init_early update
> >
> > ARM: mach-shmobile: sh7372 map_io and init_early update
> >
> > Update the sh7372 SoC and the AP4EVB and Mackerel boards to make use
> > of the functions sh7372_map_io() and sh7372_add_early_devices().
> >
> > Signed-off-by: Magnus Damm <damm@opensource.se>
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Hi Laurent,
>
> I've merged Paul's branch into my renesas/soc branch, because I don't
> rebase the branches once they are merged into arm-soc. Thanks a lot
> for the resolution you suggested, I used the same resulting code
> in the merge commit.
>
> I'm not particularly happy about how we got here. Obviously, the bug
> fixes that Paul sent should have gone through the arm-soc tree to
> avoid this situation, and they should have been based on a -rc release
> rather than some random commit after -rc6. It's not a big issue
> because the next/soc branch already contains -rc7 though.
This is a consequece of our decision that Paul would handle v3.3 fixes
and push them directly to Linus, while I would take new material for v3.4,
sorry about that.
It should be a temporary problem only, though, because once v3.3 has been
released, all arm/mach-shmobile fixes will go through the arm-soc tree.
Thanks,
Rafael
^ permalink raw reply
* Re: linux-next: Tree for Mar 15 (staging/android/ram_console.c)
From: Randy Dunlap @ 2012-03-15 21:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stephen Rothwell, devel, Brian Swetland, linux-next, LKML
In-Reply-To: <20120315210333.GA6647@kroah.com>
On 03/15/2012 02:03 PM, Greg Kroah-Hartman wrote:
> On Thu, Mar 15, 2012 at 08:58:02AM -0700, Randy Dunlap wrote:
>> On 03/15/2012 12:59 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> News: the build system (see below) has had its toolchains for most
>>> architectures updated to gcc 4.6.3. People might like to check the build
>>> results and consider if this change has caused any problems. There are
>>> also a number of architectures that are building today for the first
>>> time. Thanks to Tony Breeds for his efforts in providing toolchains.
>>>
>>> Changes since 20120314:
>>
>>
>>
>> on x86_64 when CONFIG_PRINTK is not enabled:
>>
>>
>> drivers/staging/android/ram_console.c:99:6: error: 'dmesg_restrict' undeclared (first use in this function)
>
> This patch should solve this, right?
>
>
> diff --git a/drivers/staging/android/ram_console.c b/drivers/staging/android/ram_console.c
> index 2918bc1..ce140ff 100644
> --- a/drivers/staging/android/ram_console.c
> +++ b/drivers/staging/android/ram_console.c
> @@ -85,6 +85,10 @@ static int __init ram_console_module_init(void)
> return platform_driver_probe(&ram_console_driver, ram_console_probe);
> }
>
> +#ifndef CONFIG_PRINTK
> +#define dmesg_restrict 0
> +#endif
> +
> static ssize_t ram_console_read_old(struct file *file, char __user *buf,
> size_t len, loff_t *offset)
> {
Yes, thanks.
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
--
~Randy
^ permalink raw reply
* Re: Change of the linux-watchdog-next tree location
From: Stephen Rothwell @ 2012-03-15 22:06 UTC (permalink / raw)
To: Wim Van Sebroeck
Cc: LKML, linux-next, Linux Watchdog Mailing List, Linus,
Andrew Morton
In-Reply-To: <20120315203004.GA4824@infomag>
[-- Attachment #1: Type: text/plain, Size: 333 bytes --]
Hi Win,
On Thu, 15 Mar 2012 21:32:36 +0100 Wim Van Sebroeck <wim@iguana.be> wrote:
>
> Could you change the location of the linux-watchdog-next tree to the following tree and branch:
> git://www.linux-watchdog.org/linux-watchdog-next.git master
Done.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] crypto: camellia-x86_64 - module init/exit functions should be static
From: Randy Dunlap @ 2012-03-15 22:49 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Herbert Xu, Stephen Rothwell, linux-next, linux-crypto,
linux-kernel
In-Reply-To: <20120315201151.11667.63183.stgit@localhost6.localdomain6>
On 03/15/2012 01:11 PM, Jussi Kivilinna wrote:
> This caused conflict with twofish-x86_64-3way when compiled into kernel,
> same function names and not static.
>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Thanks.
> ---
> arch/x86/crypto/camellia_glue.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
> index 1ca36a9..3306dc0 100644
> --- a/arch/x86/crypto/camellia_glue.c
> +++ b/arch/x86/crypto/camellia_glue.c
> @@ -1925,7 +1925,7 @@ static int force;
> module_param(force, int, 0);
> MODULE_PARM_DESC(force, "Force module load, ignore CPU blacklist");
>
> -int __init init(void)
> +static int __init init(void)
> {
> if (!force && is_blacklisted_cpu()) {
> printk(KERN_INFO
> @@ -1938,7 +1938,7 @@ int __init init(void)
> return crypto_register_algs(camellia_algs, ARRAY_SIZE(camellia_algs));
> }
>
> -void __exit fini(void)
> +static void __exit fini(void)
> {
> crypto_unregister_algs(camellia_algs, ARRAY_SIZE(camellia_algs));
> }
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] crypto: twofish-x86_64-3way - module init/exit functions should be static
From: Randy Dunlap @ 2012-03-15 22:49 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Herbert Xu, Stephen Rothwell, linux-next, linux-crypto,
linux-kernel
In-Reply-To: <20120315201157.11667.30754.stgit@localhost6.localdomain6>
On 03/15/2012 01:11 PM, Jussi Kivilinna wrote:
> This caused conflict with camellia-x86_64 when compiled into kernel, same
> function names and not static.
>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Thanks.
> ---
> arch/x86/crypto/twofish_glue_3way.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/crypto/twofish_glue_3way.c b/arch/x86/crypto/twofish_glue_3way.c
> index 408fc0c..922ab24 100644
> --- a/arch/x86/crypto/twofish_glue_3way.c
> +++ b/arch/x86/crypto/twofish_glue_3way.c
> @@ -668,7 +668,7 @@ static int force;
> module_param(force, int, 0);
> MODULE_PARM_DESC(force, "Force module load, ignore CPU blacklist");
>
> -int __init init(void)
> +static int __init init(void)
> {
> if (!force && is_blacklisted_cpu()) {
> printk(KERN_INFO
> @@ -681,7 +681,7 @@ int __init init(void)
> return crypto_register_algs(tf_algs, ARRAY_SIZE(tf_algs));
> }
>
> -void __exit fini(void)
> +static void __exit fini(void)
> {
> crypto_unregister_algs(tf_algs, ARRAY_SIZE(tf_algs));
> }
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Wang YanQing @ 2012-03-16 0:41 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, Florian Tobias Schandinat, linux-fbdev, x86,
Andrew Morton
In-Reply-To: <4F5FE9AD.7000204@zytor.com>
On Tue, Mar 13, 2012 at 05:43:25PM -0700, H. Peter Anvin wrote:
> On 03/13/2012 01:30 PM, Randy Dunlap wrote:
> > From: Randy Dunlap <rdunlap@xenotime.net>
> >
> > Export 'pcibios_enabled' so that when uvesafb is built as a
> > loadable module (on X86_32), the build will succeed.
> >
> > ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
> >
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > Cc: Michal Januszewski <spock@gentoo.org>
> > Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: x86@kernel.org
> > ---
> > Applies to mainline; found in linux-next.
> >
> > arch/x86/pci/pcbios.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> > +++ linux-next-20120313/arch/x86/pci/pcbios.c
> > @@ -27,6 +27,7 @@
> > #define PCIBIOS_HW_TYPE2_SPEC 0x20
> >
> > int pcibios_enabled;
> > +EXPORT_SYMBOL(pcibios_enabled);
> >
> > /* According to the BIOS specification at:
> > * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
>
> I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
> symbol with a very high likelihood to be abused in strange ways.
>
> -hpa
>
Yes, I think EXPORT_SYMBOL_GPL is better. Indeed, there is another issue I
meet about the pcibios NX protection code.
If I set "pcibios_enable = 1" forcely no matter whether set_bios_x had been executed, then
the BIOS code is not NX. The problem is, if set_bios_x had not been executed, of course set_memory_x
for the bios code page has no chance to execute, then why the BIOS code is not NX? Any comment?
Or because the default set for the BIOS range is X, if so we should set_memory_nx if pcibios_enable == 0.
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2012-03-16 1:58 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, Joe Perches, David Miller, netdev,
Sujith Manoharan
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/ath/ath9k/hw.c between commit 23677ce3172f
("drivers/net: Remove boolean comparisons to true/false") from the
net-next tree and commit caed6579c2f9 ("ath9k_hw: Cleanup
FastChannelChange") from the wireless-next tree.
The latter commit included the fix from the former, so I just used the
latter.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the drm tree
From: Stephen Rothwell @ 2012-03-16 2:53 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Hi Dave,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "drm_usb_init" [drivers/gpu/drm/udl/udl.ko] undefined!
ERROR: "drm_get_usb_dev" [drivers/gpu/drm/udl/udl.ko] undefined!
ERROR: "drm_usb_exit" [drivers/gpu/drm/udl/udl.ko] undefined!
Caused by commit 5320918b9a87 ("drm/udl: initial UDL driver (v4)").
I have used the drm tree from next-20120315 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
P.S. on the bright side, I didn't get any conflicts in the merge ...
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* sparc32 build...
From: David Miller @ 2012-03-16 2:59 UTC (permalink / raw)
To: sfr; +Cc: linux-next
Stephen, just checking, did my Makefile change make the sparc32 build
failures go away with newer tools?
^ permalink raw reply
* Re: sparc32 build...
From: Stephen Rothwell @ 2012-03-16 3:12 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, tony
In-Reply-To: <20120315.195934.2192536141028515540.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
Hi Dave,
On Thu, 15 Mar 2012 19:59:34 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> Stephen, just checking, did my Makefile change make the sparc32 build
> failures go away with newer tools?
Yeah, seems to have worked. See (sparc defconfig builds)
http://kisskb.ellerman.id.au/kisskb/buildresult/5869567/ (next-20120313 -
bad) v. http://kisskb.ellerman.id.au/kisskb/buildresult/5871624/
(next-20120314 - good)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: sparc32 build...
From: David Miller @ 2012-03-16 3:13 UTC (permalink / raw)
To: sfr; +Cc: linux-next, tony
In-Reply-To: <20120316141222.210a0ccf1a245367e5c956f5@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 16 Mar 2012 14:12:22 +1100
> Hi Dave,
>
> On Thu, 15 Mar 2012 19:59:34 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>>
>> Stephen, just checking, did my Makefile change make the sparc32 build
>> failures go away with newer tools?
>
> Yeah, seems to have worked. See (sparc defconfig builds)
> http://kisskb.ellerman.id.au/kisskb/buildresult/5869567/ (next-20120313 -
> bad) v. http://kisskb.ellerman.id.au/kisskb/buildresult/5871624/
> (next-20120314 - good)
Awesome, thanks.
^ permalink raw reply
* linux-next: manual merge of the trivial tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-16 3:56 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-next, linux-kernel, Masanari Iida, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/char/viotape.c between commit ba7a4822b48f ("powerpc: Remove some
of the legacy iSeries specific device drivers") from the powerpc tree and
commit a7ccf3775219 ("char: Fix typo in viotape.c") from the trivial tree.
The former commit removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the char-misc tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-16 5:52 UTC (permalink / raw)
To: Greg KH, Arnd Bergmann
Cc: linux-next, linux-kernel, Masanari Iida, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in
drivers/char/viotape.c between commit ba7a4822b48f ("powerpc: Remove some
of the legacy iSeries specific device drivers") from the powerpc tree and
commit 5fb15db4376f ("char: Fix typo in viotape.c") from the char-misc
tree.
The former removed this file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] watchdog: fix compiler error for missing parenthesis
From: Jaehoon Chung @ 2012-03-16 6:27 UTC (permalink / raw)
To: linux-next; +Cc: sfr, joe, Kyungmin Park
Hi Stephen.
Joe's patch(watchdog: Use pr_<fmt> and pr_<level>) is missed the parenthesis in s3c2410_wdt.c.
(based-on latest linux-next repository)
It's fixed with this patch.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/watchdog/s3c2410_wdt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 46c251d..04e5a6d 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -523,7 +523,7 @@ static struct platform_driver s3c2410wdt_driver = {
static int __init watchdog_init(void)
{
- pr_info("S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics\n";
+ pr_info("S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics\n");
return platform_driver_register(&s3c2410wdt_driver);
}
^ permalink raw reply related
* Re: [PATCH] watchdog: fix compiler error for missing parenthesis
From: Joe Perches @ 2012-03-16 6:35 UTC (permalink / raw)
To: Jaehoon Chung, Wim Van Sebroeck; +Cc: linux-next, sfr, Kyungmin Park
In-Reply-To: <4F62DD49.1040909@samsung.com>
On Fri, 2012-03-16 at 15:27 +0900, Jaehoon Chung wrote:
> Joe's patch(watchdog: Use pr_<fmt> and pr_<level>) is missed the parenthesis in s3c2410_wdt.c.
> (based-on latest linux-next repository)
> It's fixed with this patch.
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
[]
> static int __init watchdog_init(void)
> {
> - pr_info("S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics\n";
> + pr_info("S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics\n");
Thanks.
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the s5p tree
From: Stephen Rothwell @ 2012-03-16 6:45 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Kukjin Kim
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos/common.c between commit 1d7233ac478a ("Merge branch
'next/soc-exynos5250-arch-gpio' into for-next") from the s5p tree and
commit 853a0231e057 ("Merge branch 'samsung/soc' into next/soc2") from
the arm-soc tree.
These merge commits both looks suspect, but I fixed it up as best I could
(see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-exynos/common.c
index 4e1d0b7,e6cc50e..0000000
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@@ -593,6 -586,14 +593,13 @@@ static int __init exynos4_l2x0_cache_in
if (soc_is_exynos5250())
return 0;
- int ret;
+ ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
+ if (!ret) {
+ l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
+ clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
+ return 0;
+ }
+
if (!(__raw_readl(S5P_VA_L2CC + L2X0_CTRL) & 0x1)) {
l2x0_saved_regs.phy_base = EXYNOS4_PA_L2CC;
/* TAG, Data Latency Control: 2 cycles */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ 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