* Re: linux-next: Tree for Aug 25
From: Randy Dunlap @ 2011-08-26 7:26 UTC (permalink / raw)
To: Stephen Rothwell, linux-scsi; +Cc: linux-next, LKML
In-Reply-To: <20110825163515.0ed2cf354f61a3e9c53564b2@canb.auug.org.au>
On Wed, August 24, 2011 11:35 pm, Stephen Rothwell wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
CONFIG_FCOE is not enabled:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function 'bnx2fc_net_config':
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN'
undeclared (first use in this function)
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN'
undeclared (first use in this function)
Maybe this driver should select FCOE?
~Randy
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Randy Dunlap @ 2011-08-26 8:07 UTC (permalink / raw)
To: Stephen Rothwell, Mauro Carvalho Chehab; +Cc: linux-next, LKML, linux-edac
In-Reply-To: <20110826150000.302334d0b86c17cd9b89b590@canb.auug.org.au>
On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
>
> Changes since 20110825:
on i386:
ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
in both get_sdram_scrub_rate()
and set_sdram_scrub_rate()
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Mimi Zohar @ 2011-08-26 12:39 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <CACqU3MWfKji5BcGRmwO_Y4_15oOq7Trw3u6j1g2meFAaG-s9-w@mail.gmail.com>
On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > I think that you are going to need to do something like Arnaud suggested
> > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> > unless you can convince someone that this is a kconfig bug.
> >
> dammit... I guess there is...
>
> If you consider the following Kconfig:
>
> config MOD
> bool
> default y
> option modules
>
> config EXPERIMENTAL
> bool
> default y
>
> menuconfig A
> tristate "A"
> depends on EXPERIMENTAL
>
> config B
> bool "B"
>
> config B0
> bool
>
> config C
> tristate "C"
> depends on B
>
> config C0
> tristate
>
> config D
> boolean "D"
> depends on A && B
> select C
> select C0
>
> config E
> tristate "E"
>
> config F
> tristate "F"
> select E
>
> B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> menuconfig highlight the problem very well. Proceeding as following
> A=m, B=y, C=m, E=y, F=y, we ends up having:
>
> <M> A --->
> [*] B
> {M} C
> [*] D
> -*- E
> <*> F
>
> which translate in the following config:
>
> CONFIG_MOD=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_A=m
> CONFIG_B=y
> CONFIG_C=m
> CONFIG_C0=m
> CONFIG_D=y
> CONFIG_E=y
> CONFIG_F=y
>
> I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> If you remove D's dependency on 'A', everything works as expected. So
> it would seem direct dependency state influence the state of reverse
> dependencies...
>
> Will have a look...
>
> - Arnaud
Thanks for looking into this! Instead of changing 'TCG_TPM' to
'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
thanks,
Mimi
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Sedat Dilek @ 2011-08-26 14:16 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Mauro Carvalho Chehab, linux-next, LKML,
linux-edac
In-Reply-To: <205ae102ed038641e32cf38c48334f9e.squirrel@xenotime.net>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Fri, Aug 26, 2011 at 10:07 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>>
>> Changes since 20110825:
>
>
> on i386:
>
> ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
>
> in both get_sdram_scrub_rate()
> and set_sdram_scrub_rate()
>
> --
> ~Randy
>
> --
> 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
>
Hi Randy,
can you test with the patch attached, please?
( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
do_div for 64-bit division to fix 32-bit kernels" )
Regards,
- Sedat -
[-- Attachment #2: i7core_edac.c.diff --]
[-- Type: text/x-patch, Size: 1032 bytes --]
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 7cb68de..4d4f3a5 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -37,6 +37,7 @@
#include <linux/smp.h>
#include <asm/mce.h>
#include <asm/processor.h>
+#include <asm/div64.h>
#include "edac_core.h"
@@ -2102,7 +2103,8 @@ static int set_sdram_scrub_rate(struct mem_ctl_info *mci, u32 new_bw)
* program the corresponding register value.
*/
scrub_interval = (unsigned long long)freq_dclk_mhz *
- cache_line_size * 1000000 / new_bw;
+ cache_line_size * 1000000);
+ do_div(scrub_interval, new_bw);
if (!scrub_interval || scrub_interval > SCRUBINTERVAL_MASK)
return -EINVAL;
@@ -2153,7 +2155,8 @@ static int get_sdram_scrub_rate(struct mem_ctl_info *mci)
/* Calculate scrub rate value into byte/sec bandwidth */
scrub_rate = (unsigned long long)freq_dclk_mhz *
- 1000000 * cache_line_size / scrubval;
+ 1000000 * cache_line_size);
+ do_div(scrub_rate, scrubval);
return (int)scrub_rate;
}
^ permalink raw reply related
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Borislav Petkov @ 2011-08-26 14:48 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: Randy Dunlap, Stephen Rothwell, Mauro Carvalho Chehab,
linux-next@vger.kernel.org, LKML, linux-edac@vger.kernel.org
In-Reply-To: <CA+icZUX1zaw7xxka8yP4B0tFt7XgXe=8faw8vBnNWm+6teJVaA@mail.gmail.com>
On Fri, Aug 26, 2011 at 10:16:11AM -0400, Sedat Dilek wrote:
> ( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
> 64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
> do_div for 64-bit division to fix 32-bit kernels" )
>
> Regards,
> - Sedat -
> diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
> index 7cb68de..4d4f3a5 100644
> --- a/drivers/edac/i7core_edac.c
> +++ b/drivers/edac/i7core_edac.c
> @@ -37,6 +37,7 @@
> #include <linux/smp.h>
> #include <asm/mce.h>
> #include <asm/processor.h>
> +#include <asm/div64.h>
>
> #include "edac_core.h"
>
> @@ -2102,7 +2103,8 @@ static int set_sdram_scrub_rate(struct mem_ctl_info *mci, u32 new_bw)
> * program the corresponding register value.
> */
> scrub_interval = (unsigned long long)freq_dclk_mhz *
> - cache_line_size * 1000000 / new_bw;
> + cache_line_size * 1000000);
> + do_div(scrub_interval, new_bw);
This has been an issue pretty often lately on lkml. Instead of doing
64-bit division on 32-bit (which is really slow), you could try to use
the commutative property of integer multiplication and thus reorder the
operations so that the division is 32-bit only. Maybe
((freq_dclk_mhz * cache_line_size) / new_bw) * 1000000
for example. You have to make sure though that new_bw as divisor can
never be bigger than the dividend because otherwise you get the 0. One
question would be what is the interval of freq_dclk_mhz and can (new_bw >> 6)
be ever bigger than it.
And while at it, the cache_line_size is pretty solidly staying 64 Byte
in the short-term future so no need for a local variable. Also, shifting
left by 6 should be a faster equivalent than multiplying by 64.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Arnaud Lacombe @ 2011-08-26 15:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel
In-Reply-To: <20110826103932.1626f1c5542b660bcd1b24aa@canb.auug.org.au>
Hi,
[Removed PPC folks from the CC list, the conversation drifted.]
On Thu, Aug 25, 2011 at 8:39 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Arnaud,
>
> On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>>
>> If you could provide an exhaustive list of them, I'd be interested. Do
>> you account/reference them in the report you make on each new -next
>> tree ?
>
> I don't refer to them at all :-(
>
> If you are not just referring to powerpc ones, then an x86_64
> allmodconfig is a good place to start, there are several in there.
>
> Otherwise, I will send you the results of some of my builds this evening.
>
Couldn't all the error log be public, rotated over a 7 iteration
period ? That would be fair to everyone.
Thanks,
- Arnaud
^ permalink raw reply
* Re: linux-next: Tree for Aug 25
From: Bhanu Prakash Gollapudi @ 2011-08-26 16:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-scsi@vger.kernel.org,
linux-next@vger.kernel.org, LKML, robert.w.love@intel.com,
devel@open-fcoe.org
In-Reply-To: <885a6d6210a7d4c56601380f146e7ba9.squirrel@xenotime.net>
On 8/26/2011 12:26 AM, Randy Dunlap wrote:
>
> On Wed, August 24, 2011 11:35 pm, Stephen Rothwell wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>
>
> CONFIG_FCOE is not enabled:
>
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function 'bnx2fc_net_config':
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN'
> undeclared (first use in this function)
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN'
> undeclared (first use in this function)
>
>
> Maybe this driver should select FCOE?
bnx2fc does not depend on FCOE. Instead both fcoe and bnx2fc drivers
depend on LIBFCOE. So, I'll modify to access
NETDEV_FCOE_WWNN/NETDEV_FCOE_WWPN when CONFIG_LIBFCOE is enabled.
Patch will be submitted soon.
Thanks,
Bhanu
>
> ~Randy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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
* RE: linux-next: Tree for Aug 25
From: Zou, Yi @ 2011-08-26 16:59 UTC (permalink / raw)
To: Bhanu Prakash Gollapudi, Randy Dunlap
Cc: Stephen Rothwell, linux-scsi@vger.kernel.org,
linux-next@vger.kernel.org, LKML, Love, Robert W,
devel@open-fcoe.org
In-Reply-To: <4E57CCEC.9060000@broadcom.com>
>
> On 8/26/2011 12:26 AM, Randy Dunlap wrote:
> >
> > On Wed, August 24, 2011 11:35 pm, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The powerpc allyesconfig build still fails today.
> >
> >
> > CONFIG_FCOE is not enabled:
> >
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function 'bnx2fc_net_config':
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN'
> > undeclared (first use in this function)
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN'
> > undeclared (first use in this function)
> >
> >
> > Maybe this driver should select FCOE?
> bnx2fc does not depend on FCOE. Instead both fcoe and bnx2fc drivers
> depend on LIBFCOE. So, I'll modify to access
> NETDEV_FCOE_WWNN/NETDEV_FCOE_WWPN when CONFIG_LIBFCOE is enabled.
>
Yes, both these two flags and ndo_fcoe_get_wwn() should be wrapped by
CONFIG_LIBFCOE || CONFIG_LIBFCOE_MODULE as bnx2fc is also using the get_wwn
hook I believe. Historically on fcoe module was using them.
> Patch will be submitted soon.
Thanks,
yi
>
> Thanks,
> Bhanu
> >
> > ~Randy
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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
* Re: linux-next: Tree for Aug 22 (evm)
From: Randy Dunlap @ 2011-08-26 17:00 UTC (permalink / raw)
To: Mimi Zohar
Cc: Arnaud Lacombe, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <1314362342.3224.19.camel@localhost.localdomain>
On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> > Hi,
> >
> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > > I think that you are going to need to do something like Arnaud suggested
> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> > > unless you can convince someone that this is a kconfig bug.
> > >
> > dammit... I guess there is...
> >
> > If you consider the following Kconfig:
> >
> > config MOD
> > bool
> > default y
> > option modules
> >
> > config EXPERIMENTAL
> > bool
> > default y
> >
> > menuconfig A
> > tristate "A"
> > depends on EXPERIMENTAL
> >
> > config B
> > bool "B"
> >
> > config B0
> > bool
> >
> > config C
> > tristate "C"
> > depends on B
> >
> > config C0
> > tristate
> >
> > config D
> > boolean "D"
> > depends on A && B
> > select C
> > select C0
> >
> > config E
> > tristate "E"
> >
> > config F
> > tristate "F"
> > select E
> >
> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> > menuconfig highlight the problem very well. Proceeding as following
> > A=m, B=y, C=m, E=y, F=y, we ends up having:
> >
> > <M> A --->
> > [*] B
> > {M} C
> > [*] D
> > -*- E
> > <*> F
> >
> > which translate in the following config:
> >
> > CONFIG_MOD=y
> > CONFIG_EXPERIMENTAL=y
> > CONFIG_A=m
> > CONFIG_B=y
> > CONFIG_C=m
> > CONFIG_C0=m
> > CONFIG_D=y
> > CONFIG_E=y
> > CONFIG_F=y
> >
> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> > If you remove D's dependency on 'A', everything works as expected. So
> > it would seem direct dependency state influence the state of reverse
> > dependencies...
> >
> > Will have a look...
> >
> > - Arnaud
>
> Thanks for looking into this! Instead of changing 'TCG_TPM' to
> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
Yes, linux-next (randconfig) builds are still failing, so we need something
to prevent that.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Randy Dunlap @ 2011-08-26 17:40 UTC (permalink / raw)
To: sedat.dilek
Cc: Sedat Dilek, Stephen Rothwell, Mauro Carvalho Chehab, linux-next,
LKML, linux-edac
In-Reply-To: <CA+icZUX1zaw7xxka8yP4B0tFt7XgXe=8faw8vBnNWm+6teJVaA@mail.gmail.com>
On Fri, 26 Aug 2011 16:16:11 +0200 Sedat Dilek wrote:
> On Fri, Aug 26, 2011 at 10:07 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >
> > On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The powerpc allyesconfig build still fails today.
> >>
> >> Changes since 20110825:
> >
> >
> > on i386:
> >
> > ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
> >
> > in both get_sdram_scrub_rate()
> > and set_sdram_scrub_rate()
> >
> > --
>
> Hi Randy,
>
> can you test with the patch attached, please?
>
> ( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
> 64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
> do_div for 64-bit division to fix 32-bit kernels" )
Yes, this works after I removed the extra right parens in both cases.
(did you test it?)
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Sedat Dilek @ 2011-08-26 17:54 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Mauro Carvalho Chehab, linux-next, LKML,
linux-edac
In-Reply-To: <20110826104031.4c5861e5.rdunlap@xenotime.net>
On Fri, Aug 26, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Fri, 26 Aug 2011 16:16:11 +0200 Sedat Dilek wrote:
>
>> On Fri, Aug 26, 2011 at 10:07 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> >
>> > On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
>> >> Hi all,
>> >>
>> >> The powerpc allyesconfig build still fails today.
>> >>
>> >> Changes since 20110825:
>> >
>> >
>> > on i386:
>> >
>> > ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
>> >
>> > in both get_sdram_scrub_rate()
>> > and set_sdram_scrub_rate()
>> >
>> > --
>>
>> Hi Randy,
>>
>> can you test with the patch attached, please?
>>
>> ( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
>> 64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
>> do_div for 64-bit division to fix 32-bit kernels" )
>
> Yes, this works after I removed the extra right parens in both cases.
The closing brackets were a test for you (indeed they are wrong).
> (did you test it?)
>
No, even not compile-tested, still struggling with todays linux-next.
Seems I am not alone [1].
- Sedat -
[1] http://lkml.org/lkml/2011/8/26/300
> thanks,
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
^ permalink raw reply
* [PATCH -next] staging: fix rts5139 depends & build
From: Randy Dunlap @ 2011-08-26 18:06 UTC (permalink / raw)
To: Stephen Rothwell, Edwin Rong, gregkh, akpm; +Cc: linux-next, LKML, driverdevel
In-Reply-To: <20110826150000.302334d0b86c17cd9b89b590@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
RTS5139 should depend on USB, not USB_SUPPORT, to fix build
errors.
USB_SUPPORT can be enabled for gadget-only support
or when PCI is not enabled.
ERROR: "usb_reset_endpoint" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_kill_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_deregister_dev" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_unlink_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_deregister" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_register_dev" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_free_coherent" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_submit_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_sg_cancel" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_find_interface" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_sg_init" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_register_driver" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_alloc_coherent" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_free_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_alloc_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Edwin Rong <edwin_rong@realsil.com.cn>
---
drivers/staging/rts5139/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20110826.orig/drivers/staging/rts5139/Kconfig
+++ linux-next-20110826/drivers/staging/rts5139/Kconfig
@@ -1,6 +1,6 @@
config RTS5139
tristate "Realtek RTS5139 USB card reader support"
- depends on USB_SUPPORT && SCSI
+ depends on USB && SCSI
help
Say Y here to include driver code to support the Realtek
RTS5139 USB card readers.
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Arnaud Lacombe @ 2011-08-27 6:06 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mimi Zohar, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <20110826100011.9213d872.rdunlap@xenotime.net>
Hi,
On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
>
>> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
>> > Hi,
>> >
>> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> > > I think that you are going to need to do something like Arnaud suggested
>> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
>> > > unless you can convince someone that this is a kconfig bug.
>> > >
>> > dammit... I guess there is...
>> >
>> > If you consider the following Kconfig:
>> >
>> > config MOD
>> > bool
>> > default y
>> > option modules
>> >
>> > config EXPERIMENTAL
>> > bool
>> > default y
>> >
>> > menuconfig A
>> > tristate "A"
>> > depends on EXPERIMENTAL
>> >
>> > config B
>> > bool "B"
>> >
>> > config B0
>> > bool
>> >
>> > config C
>> > tristate "C"
>> > depends on B
>> >
>> > config C0
>> > tristate
>> >
>> > config D
>> > boolean "D"
>> > depends on A && B
>> > select C
>> > select C0
>> >
>> > config E
>> > tristate "E"
>> >
>> > config F
>> > tristate "F"
>> > select E
>> >
>> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
>> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
>> > menuconfig highlight the problem very well. Proceeding as following
>> > A=m, B=y, C=m, E=y, F=y, we ends up having:
>> >
>> > <M> A --->
>> > [*] B
>> > {M} C
>> > [*] D
>> > -*- E
>> > <*> F
>> >
>> > which translate in the following config:
>> >
>> > CONFIG_MOD=y
>> > CONFIG_EXPERIMENTAL=y
>> > CONFIG_A=m
>> > CONFIG_B=y
>> > CONFIG_C=m
>> > CONFIG_C0=m
>> > CONFIG_D=y
>> > CONFIG_E=y
>> > CONFIG_F=y
>> >
>> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
>> > If you remove D's dependency on 'A', everything works as expected. So
>> > it would seem direct dependency state influence the state of reverse
>> > dependencies...
>> >
>> > Will have a look...
>> >
>> > - Arnaud
>>
>> Thanks for looking into this! Instead of changing 'TCG_TPM' to
>> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
>> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
>> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
>> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
>
> Yes, linux-next (randconfig) builds are still failing, so we need something
> to prevent that.
>
you may want to try:
git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes
only the last commit is relevant to the problem, but depend on one
another to get <assert.h>. The rest aims at tidying the expr stuff.
I'm looking for regression it may have introduced.
Thanks,
- Arnaud
ps: I'll most likely be AFK until sunday evening (to be conservative).
> thanks,
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" 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
* Re: iommu-tree for linux-next
From: Stephen Rothwell @ 2011-08-28 16:06 UTC (permalink / raw)
To: Joerg Roedel; +Cc: linux-next, LKML, David Woodhouse, iommu
In-Reply-To: <20110826114937.GE8978@8bytes.org>
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
Hi Joerg,
On Fri, 26 Aug 2011 13:49:37 +0200 Joerg Roedel <joro@8bytes.org> wrote:
>
> I would like to ask if you can include the iommu-tree into linux-next
> for broader testing? The tree can be pulled from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
>
> The tree currently contains iommu changes for dma-debug and omap-iommu.
> It will also contain changes to x86 iommu code in the near future.
I will add this from Monday unless there are objections.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next tree addition request (fbdev)
From: Stephen Rothwell @ 2011-08-28 16:19 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-next, linux-fbdev@vger.kernel.org, Paul Mundt
In-Reply-To: <20110825003353.e930fc7a664dd99c953b555c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
Hi Florian,
On Thu, 25 Aug 2011 00:33:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 24 Aug 2011 13:40:46 +0000 Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> >
> > can you please add
> >
> > git://github.com/schandinat/linux-2.6.git fbdev-next
> >
> > to linux-next. It collects patches for the frame buffer subsystem.
> > Can you please add the linux-fbdev@vger.kernel.org mailing list as additional
> > contact for warnings/errors/problems?
> >
> > You probably want to drop Paul's fbdev branches as they contain some outdated
> > patches that will conflict with the newer versions.
>
> OK, Paul is still listed as the frame buffer subsystem maintainer, so I
> will need an Ack from him. When I get that, I will replace his tree with
> yours. I assume someone will update the MAINTAINERS file.
>
> I also have another tree from Paul (called fbdev-current) that contained
> fixes for Linus' current release. I also assume that that tree will be
> dropped (unless you have a new version of that as well).
Ping? Anyone?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build failure in Linus' tree
From: Stephen Rothwell @ 2011-08-29 0:44 UTC (permalink / raw)
To: Linus
Cc: linux-next, linux-kernel, NeilBrown, linuxppc-dev, linux-parisc,
J. Bruce Fields
Hi Linus,
After merging the fixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kernel/built-in.o: In function `.sys_call_table':
(.text+0xbd00): undefined reference to `.sys_nfsservctl'
arch/powerpc/kernel/built-in.o: In function `.sys_call_table':
(.text+0xbd08): undefined reference to `.compat_sys_nfsservctl'
Caused by commit f5b940997397 ("All Arch: remove linkage for
sys_nfsservctl system call") which also missed parisc.
I will apply this patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Aug 2011 10:38:57 +1000
Subject: [PATCH] remove remaining references to nfsservctl
These were missed in commit f5b940997397 "All Arch: remove linkage
for sys_nfsservctl system call" due to them having no sys_ prefix
(presumably).
Cc: NeilBrown <neilb@suse.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/parisc/kernel/syscall_table.S | 2 +-
arch/powerpc/include/asm/systbl.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S
index e66366f..3735abd 100644
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
@@ -259,7 +259,7 @@
ENTRY_SAME(ni_syscall) /* query_module */
ENTRY_SAME(poll)
/* structs contain pointers and an in_addr... */
- ENTRY_COMP(nfsservctl)
+ ENTRY_SAME(ni_syscall) /* was nfsservctl */
ENTRY_SAME(setresgid) /* 170 */
ENTRY_SAME(getresgid)
ENTRY_SAME(prctl)
diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
index f6736b7..fa0d27a 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -171,7 +171,7 @@ SYSCALL_SPU(setresuid)
SYSCALL_SPU(getresuid)
SYSCALL(ni_syscall)
SYSCALL_SPU(poll)
-COMPAT_SYS(nfsservctl)
+SYSCALL(ni_syscall)
SYSCALL_SPU(setresgid)
SYSCALL_SPU(getresgid)
COMPAT_SYS_SPU(prctl)
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2011-08-29 1:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-next, linux-kernel, Sascha Hauer, Russell King,
Linus Walleij
Hi Arnd,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-u300/Makefile.boot between commit 74b84ad6c1a5 ("ARM:
7022/1: allow to detect conflicting zreladdrs") from the arm tree and
commit 732851465445 ("mach-u300: retire odd singlemem variant") from the
arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-u300/Makefile.boot
index 69357af,a06bb0d..0000000
--- a/arch/arm/mach-u300/Makefile.boot
+++ b/arch/arm/mach-u300/Makefile.boot
@@@ -1,15 -1,4 +1,4 @@@
- # Note: the following conditions must always be true:
- # ZRELADDR == virt_to_phys(TEXTADDR)
- # PARAMS_PHYS must be within 4MB of ZRELADDR
- # INITRD_PHYS must be in RAM
-
- ifdef CONFIG_MACH_U300_SINGLE_RAM
- zreladdr-y += 0x28E08000
- params_phys-y := 0x28E00100
- else
- zreladdr-y += 0x48008000
- params_phys-y := 0x48000100
- endif
-
- zreladdr-y := 0x48008000
++ zreladdr-y += 0x48008000
+ params_phys-y := 0x48000100
# This isn't used.
- #initrd_phys-y := 0x29800000
+ #initrd_phys-y := 0x48800000
^ permalink raw reply
* linux-next: build failure after merge of the scsi tree
From: Stephen Rothwell @ 2011-08-29 2:09 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-next, linux-kernel, Giridhar Malavali, Chad Dupuis
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
Hi James,
After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_alloc':
drivers/scsi/qla2xxx/qla_nx.c:4815:2: error: implicit declaration of function 'vmalloc'
drivers/scsi/qla2xxx/qla_nx.c:4815:14: warning: assignment makes pointer from integer without a cast
drivers/scsi/qla2xxx/qla_nx.c: In function 'qla82xx_md_free':
drivers/scsi/qla2xxx/qla_nx.c:4845:3: error: implicit declaration of function 'vfree'
Caused by commit b60bb5832c00 ("[SCSI] qla2xxx: Add support for ISP82xx
to capture dump (minidump) on failure"). Missing include of
linux/vmalloc.h. See Rule 1 in Documentation/SubmitChecklist.
I have used the scsi tree from next-20110826 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [Patch] numa: introduce CONFIG_NUMA_SYSFS for drivers/base/node.c
From: Cong Wang @ 2011-08-29 2:29 UTC (permalink / raw)
To: David Rientjes
Cc: Randy Dunlap, Andrew Morton, Stephen Rothwell, gregkh, linux-next,
LKML, linux-mm
In-Reply-To: <alpine.DEB.2.00.1108251356220.18747@chino.kir.corp.google.com>
于 2011年08月26日 04:57, David Rientjes 写道:
> On Thu, 25 Aug 2011, Cong Wang wrote:
>
>>> No, it doesn't work, CONFIG_HUGETLBFS can be enabled with CONFIG_NUMA=y
>>> and CONFIG_SYSFS=n and that uses data structures from drivers/base/node.c
>>> which doesn't get compiled with this patch.
>>
>> So, you mean with CONFIG_NUMA=y&& CONFIG_SYSFS=n&& CONFIG_HUGETLBFS=y
>> we still get compile error?
>>
>> Which data structures are used by hugetlbfs?
>>
>
> node_states[], which is revealed at link time if you tried to compile your
> patch. It's obvious that we don't want to add per-node hugetlbfs
> attributes to sysfs directories if sysfs is disabled, so you need to
> modify the hugetlbfs code as well.
Makes sense. Thanks!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* linux-next: build failure after merge of the iommu tree
From: Stephen Rothwell @ 2011-08-29 3:32 UTC (permalink / raw)
To: Joerg Roedel; +Cc: linux-next, linux-kernel, Ohad Ben-Cohen
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
Hi Joerg,
After merging the iommu tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/iommu/omap-iommu.c:27:24: fatal error: plat/iommu.h: No such file or directory
Caused by commit fcf3a6ef4a58 ("omap: iommu/iovmm: move to dedicated
iommu folder"). Presumably building of this code should be restricted to
just some platforms only.
I have dropped the iommu tree for today (since I have no older working
version).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the driver-core tree with the arm-soc tree
From: Stephen Rothwell @ 2011-08-29 4:31 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, "Uwe Kleine-König",
Arnd Bergmann
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
arch/arm/plat-mxc/devices.c between commit 160a84cfc975 ("ARM: mxc: drop
now unused function mxc_register_device") from the arm-soc tree and
commit 0e392412f334 ("ARM: mxc: convert device creation to use
platform_device_register_full") from the driver-core tree.
Just context changes. I fixed it up (see below) anc can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/plat-mxc/devices.c
index 5aaa8c5,a34b2ae..0000000
--- a/arch/arm/plat-mxc/devices.c
+++ b/arch/arm/plat-mxc/devices.c
@@@ -23,59 -23,20 +23,6 @@@
#include <linux/platform_device.h>
#include <mach/common.h>
- struct platform_device *__init imx_add_platform_device_dmamask(
- const char *name, int id,
- const struct resource *res, unsigned int num_resources,
- const void *data, size_t size_data, u64 dmamask)
- {
- int ret = -ENOMEM;
- struct platform_device *pdev;
-
- pdev = platform_device_alloc(name, id);
- if (!pdev)
- goto err;
-
- if (dmamask) {
- /*
- * This memory isn't freed when the device is put,
- * I don't have a nice idea for that though. Conceptually
- * dma_mask in struct device should not be a pointer.
- * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
- */
- pdev->dev.dma_mask =
- kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
- if (!pdev->dev.dma_mask)
- /* ret is still -ENOMEM; */
- goto err;
-
- *pdev->dev.dma_mask = dmamask;
- pdev->dev.coherent_dma_mask = dmamask;
- }
-
- if (res) {
- ret = platform_device_add_resources(pdev, res, num_resources);
- if (ret)
- goto err;
- }
-
- if (data) {
- ret = platform_device_add_data(pdev, data, size_data);
- if (ret)
- goto err;
- }
-
- ret = platform_device_add(pdev);
- if (ret) {
- err:
- if (dmamask)
- kfree(pdev->dev.dma_mask);
- platform_device_put(pdev);
- return ERR_PTR(ret);
- }
-
- return pdev;
- }
-
-int __init mxc_register_device(struct platform_device *pdev, void *data)
-{
- int ret;
-
- pdev->dev.platform_data = data;
-
- ret = platform_device_register(pdev);
- if (ret)
- pr_debug("Unable to register platform device '%s': %d\n",
- pdev->name, ret);
-
- return ret;
-}
-
struct device mxc_aips_bus = {
.init_name = "mxc_aips",
.parent = &platform_bus,
^ permalink raw reply
* Re: linux-next: build failure after merge of the iommu tree
From: Ohad Ben-Cohen @ 2011-08-29 5:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Joerg Roedel, linux-next, linux-kernel
In-Reply-To: <20110829133237.80467b5d54438ace53b324df@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Mon, Aug 29, 2011 at 6:32 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the iommu tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iommu/omap-iommu.c:27:24: fatal error: plat/iommu.h: No such file or directory
>
> Caused by commit fcf3a6ef4a58 ("omap: iommu/iovmm: move to dedicated
> iommu folder"). Presumably building of this code should be restricted to
> just some platforms only.
Thank you, Stephen, you're completely right of course.
Here is what we're missing (patch also attached):
>From 7a7949ca60bb0d58079b669733f9aa43015ba0f0 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon, 29 Aug 2011 07:57:44 +0300
Subject: [PATCH] iommu: omap: add Kconfig OMAP dependency
Make CONFIG_OMAP_IOMMU depend on CONFIG_ARCH_OMAP so other
allmodconfig builds won't fail.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/iommu/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 432463b..d901930 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -110,6 +110,7 @@ config INTR_REMAP
# OMAP IOMMU support
config OMAP_IOMMU
bool "OMAP IOMMU Support"
+ depends on ARCH_OMAP
select IOMMU_API
config OMAP_IOVMM
--
1.7.4.1
[-- Attachment #2: 0001-iommu-omap-add-Kconfig-OMAP-dependency.patch --]
[-- Type: text/x-patch, Size: 815 bytes --]
From 7a7949ca60bb0d58079b669733f9aa43015ba0f0 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon, 29 Aug 2011 07:57:44 +0300
Subject: [PATCH] iommu: omap: add Kconfig OMAP dependency
Make CONFIG_OMAP_IOMMU depend on CONFIG_ARCH_OMAP so other
allmodconfig builds won't fail.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/iommu/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 432463b..d901930 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -110,6 +110,7 @@ config INTR_REMAP
# OMAP IOMMU support
config OMAP_IOMMU
bool "OMAP IOMMU Support"
+ depends on ARCH_OMAP
select IOMMU_API
config OMAP_IOVMM
--
1.7.4.1
^ permalink raw reply related
* linux-next: manual merge of the scsi-post-merge tree with the akpm tree
From: Stephen Rothwell @ 2011-08-29 5:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Sergei Trofimovich
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/alpha/kernel/osf_sys.c between commit 2df7a7d1cd07 ("alpha: unbreak
osf_setsysinfo(SSI_NVPAIRS, [SSIN_UACPROC, UAC_SIGBUS])") from the tree
and commit db52f8af5ea5 ("The bug was accidentally found by the following
program:") from the akpm tree.
The former appears to be a later version of the latter, so I have dropped
the latter.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm with Linus' tree
From: Stephen Rothwell @ 2011-08-29 5:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, WANG Cong
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Hi Andrew,
Today's linux-next merge of the scsi-post-merge tree got a conflict in
arch/cris/include/asm/serial.h between commit 02016bc0381c ("cris: add
arch/cris/include/asm/serial.h") from Linus' tree and commit f8b20ed71f1b
("Fix the following build errors:") from the akpm tree.
There former appears to be a later version of the latter, so I dropped
the latter.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build warning after merge of the ptrace tree
From: Stephen Rothwell @ 2011-08-29 5:27 UTC (permalink / raw)
To: Tejun Heo, Oleg Nesterov; +Cc: linux-next, linux-kernel, Matt Fleming
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Hi all,
After merging the ptrace tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
fs/autofs4/waitq.c: In function 'autofs4_wait':
fs/autofs4/waitq.c:462:17: warning: unused variable 'irqflags'
Introduced by commit 33ee1d9bc213 ("autofs4: Use set_current_blocked()").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 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