linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: Tree for July 29
@ 2008-07-29  7:23 Stephen Rothwell
  2008-07-29  7:48 ` Fernando Luis Vázquez Cao
                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: Stephen Rothwell @ 2008-07-29  7:23 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 10403 bytes --]

Hi all,

Changes since next-20080728:

Temporarily dropped trees: acpi (it is being moved to a new tree and is
just accumulating conflicts against Linus' tree).
	v4l-dvb (got lots of conflicts against the version that was
merged to Linus).

Changed trees: the tests tree changed directory
	the sound tree changed branch

Linus' tree lost the three build fixes.

The pci-current tree gained a build fix patch.

The v4l-dvb tree gained 51 conflicts against Linus' tree and was dropped.

The tests tree lost its conflict.

The rr tree lost its conflicts.

The firmware tree gained a conflict against Linus' tree.

The kmemcheck tree lost its conflicts.

I have also applied the following patches for known problems:

	hfcmulti is not supported on big endian
	sparc: add iommu_num_pages helper function fix
	cpumask: statement expressions confuse some versions of gcc

The sparc(32) defconfig build still fails.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups, it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

We are up to 105 trees (counting Linus' and 14 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
Merging pci-current/for-linus
Applying powerpc: generic iommu helper fallout
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
CONFLICT (content): Merge conflict in drivers/dca/dca-sysfs.c
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in net/sunrpc/svc.c
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in drivers/pci/dmar.c
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
CONFLICT (content): Merge conflict in Documentation/video4linux/CARDLIST.em28xx
CONFLICT (add/add): Merge conflict in Documentation/video4linux/gspca.txt
CONFLICT (content): Merge conflict in drivers/media/dvb/dvb-usb/Kconfig
CONFLICT (content): Merge conflict in drivers/media/dvb/dvb-usb/Makefile
CONFLICT (add/add): Merge conflict in drivers/media/dvb/dvb-usb/anysee.c
CONFLICT (add/add): Merge conflict in drivers/media/dvb/siano/smscoreapi.c
CONFLICT (add/add): Merge conflict in drivers/media/dvb/siano/smsdvb.c
CONFLICT (content): Merge conflict in drivers/media/radio/radio-si470x.c
CONFLICT (content): Merge conflict in drivers/media/video/bt8xx/bttv-driver.c
CONFLICT (content): Merge conflict in drivers/media/video/cx18/cx18-firmware.c
CONFLICT (content): Merge conflict in drivers/media/video/cx18/cx18-ioctl.c
CONFLICT (content): Merge conflict in drivers/media/video/cx18/cx18-streams.c
CONFLICT (content): Merge conflict in drivers/media/video/cx23885/cx23885-417.c
CONFLICT (content): Merge conflict in drivers/media/video/cx23885/cx23885-cards.c
CONFLICT (content): Merge conflict in drivers/media/video/cx25840/cx25840-core.c
CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-cards.c
CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-dvb.c
CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx.h
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/conex.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/etoms.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/gspca.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/mars.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/ov519.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/pac207.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/pac7311.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sonixb.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sonixj.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca500.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca501.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca505.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca506.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca508.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca561.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/stk014.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sunplus.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/t613.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/tv8532.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/vc032x.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/zc3xx.c
CONFLICT (content): Merge conflict in drivers/media/video/ivtv/ivtv-ioctl.c
CONFLICT (add/add): Merge conflict in drivers/media/video/s2255drv.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-cards.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-empress.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-video.c
CONFLICT (add/add): Merge conflict in drivers/media/video/sh_mobile_ceu_camera.c
CONFLICT (content): Merge conflict in drivers/media/video/soc_camera.c
CONFLICT (add/add): Merge conflict in drivers/media/video/videobuf-dma-contig.c
CONFLICT (content): Merge conflict in drivers/media/video/videodev.c
CONFLICT (content): Merge conflict in drivers/media/video/zoran_card.c
CONFLICT (content): Merge conflict in include/linux/videodev2.h
CONFLICT (content): Merge conflict in include/media/v4l2-dev.h
$ git reset --hard
Merging s390/features
Merging sh/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging blackfin/for-linus
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ia64/test
Merging tests/master
Merging ocfs2/linux-next
Merging quilt/m68k
Merging powerpc/next
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging sparc/master
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging arm/devel
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
Merging bkl-removal/bkl-removal
Merging trivial/next
CONFLICT (content): Merge conflict in Documentation/edac.txt
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Kconfig
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
Merging pcmcia/master
Merging battery/master
CONFLICT (content): Merge conflict in drivers/power/Kconfig
CONFLICT (content): Merge conflict in drivers/power/Makefile
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Merging md/for-next
Merging cris/for-next
Merging kmemcheck/auto-kmemcheck-next
Merging generic-ipi/auto-generic-ipi-next
Merging mips/mips-for-linux-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (add/add): Merge conflict in drivers/gpu/Makefile
CONFLICT (add/add): Merge conflict in drivers/gpu/drm/i830/Makefile
CONFLICT (content): Merge conflict in include/Kbuild
CONFLICT (add/add): Merge conflict in include/drm/Kbuild
Merging voltage/reg-for-linus
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Applying hfcmulti is not supported on big endian
Applying sparc: add iommu_num_pages helper function fix
Applying cpumask: statement expressions confuse some versions of gcc

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29  7:23 linux-next: Tree for July 29 Stephen Rothwell
@ 2008-07-29  7:48 ` Fernando Luis Vázquez Cao
  2008-07-29 14:45 ` Dominik Brodowski
  2008-07-29 16:25 ` Bartlomiej Zolnierkiewicz
  2 siblings, 0 replies; 26+ messages in thread
From: Fernando Luis Vázquez Cao @ 2008-07-29  7:48 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML

The patch below gets rid of a compile error that would be nice to get
fixed in Linus' tree.

-------- Forwarded Message --------
From: Fernando Luis Vázquez Cao <fernando@oss.ntt.co.jp>
To: yi.zhu@intel.com, reinette.chatre@intel.com
Cc: ipw3945-devel@lists.sourceforge.net, akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: [PATCH] iwlwifi: fix iwl-led compile issue when CONFIG_IWLWIFI_DEBUG is not set
Date: 	Tue, 29 Jul 2008 14:58:42 +0900

Fix compile error when CONFIG_IWLWIFI_DEBUG not defined.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---

--- linux-2.6.27-rc1/drivers/net/wireless/iwlwifi/iwl-led.c	2008-07-29 13:51:26.000000000 +0900
+++ linux-2.6.27-rc1-iocontext/drivers/net/wireless/iwlwifi/iwl-led.c	2008-07-29 14:47:13.000000000 +0900
@@ -194,9 +194,10 @@ static void iwl_led_brightness_set(struc
 	if (test_bit(STATUS_EXIT_PENDING, &priv->status))
 		return;
 
-
+#ifdef CONFIG_IWLWIFI_DEBUG
 	IWL_DEBUG_LED("Led type = %s brightness = %d\n",
 			led_type_str[led->type], brightness);
+#endif /* CONFIG_IWLWIFI_DEBUG */
 	switch (brightness) {
 	case LED_FULL:
 		if (led->type == IWL_LED_TRG_ASSOC)


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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29  7:23 linux-next: Tree for July 29 Stephen Rothwell
  2008-07-29  7:48 ` Fernando Luis Vázquez Cao
@ 2008-07-29 14:45 ` Dominik Brodowski
  2008-08-03 14:56   ` Stephen Rothwell
  2008-07-29 16:25 ` Bartlomiej Zolnierkiewicz
  2 siblings, 1 reply; 26+ messages in thread
From: Dominik Brodowski @ 2008-07-29 14:45 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML

Hi,

On Tue, Jul 29, 2008 at 05:23:37PM +1000, Stephen Rothwell wrote:
> Changes since next-20080728:

is linux-next now open for 2.6.28 stuff?

Thanks,
	Dominik

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29  7:23 linux-next: Tree for July 29 Stephen Rothwell
  2008-07-29  7:48 ` Fernando Luis Vázquez Cao
  2008-07-29 14:45 ` Dominik Brodowski
@ 2008-07-29 16:25 ` Bartlomiej Zolnierkiewicz
  2008-07-29 18:16   ` Greg KH
  2008-07-30  1:05   ` linux-next: usb tree fix (Was: Re: linux-next: Tree for July 29) Stephen Rothwell
  2 siblings, 2 replies; 26+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-07-29 16:25 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, Dave Hansen, Greg KH


Hi,

On Tuesday 29 July 2008, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since next-20080728:

I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
when statically-allocated kobjects are used") with each linux-next release
to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).

Depending on the day I either forget to revert it on a first try or (lead by
incurable optimism) I don't try to revert it in hope that it was fixed.

Unfortunately the result is always the same cursing-during-qemu-test-run
-> git-revert -> recompile cycle and a needless time loss.

Could we have some action taken please?

Thanks,
Bart

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29 16:25 ` Bartlomiej Zolnierkiewicz
@ 2008-07-29 18:16   ` Greg KH
  2008-07-29 20:49     ` Hugh Dickins
  2008-07-30  1:05   ` linux-next: usb tree fix (Was: Re: linux-next: Tree for July 29) Stephen Rothwell
  1 sibling, 1 reply; 26+ messages in thread
From: Greg KH @ 2008-07-29 18:16 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: Stephen Rothwell, linux-next, LKML, Dave Hansen

On Tue, Jul 29, 2008 at 06:25:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Tuesday 29 July 2008, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since next-20080728:
> 
> I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> when statically-allocated kobjects are used") with each linux-next release
> to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> 
> Depending on the day I either forget to revert it on a first try or (lead by
> incurable optimism) I don't try to revert it in hope that it was fixed.
> 
> Unfortunately the result is always the same cursing-during-qemu-test-run
> -> git-revert -> recompile cycle and a needless time loss.
> 
> Could we have some action taken please?

What is the problem with this patch that has caused it to suddenly
keeping the boot from working?  Is the code in the patch warning you of
objects that are not properly being initialized?

I'll be glad to fix this if possible.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29 18:16   ` Greg KH
@ 2008-07-29 20:49     ` Hugh Dickins
  2008-07-30  4:48       ` Greg KH
  0 siblings, 1 reply; 26+ messages in thread
From: Hugh Dickins @ 2008-07-29 20:49 UTC (permalink / raw)
  To: Greg KH
  Cc: Bartlomiej Zolnierkiewicz, Stephen Rothwell, Bernhard Walle,
	linux-next, LKML, Dave Hansen

On Tue, 29 Jul 2008, Greg KH wrote:
> On Tue, Jul 29, 2008 at 06:25:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 29 July 2008, Stephen Rothwell wrote:
> > > 
> > > Changes since next-20080728:
> > 
> > I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> > when statically-allocated kobjects are used") with each linux-next release
> > to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> > 
> > Depending on the day I either forget to revert it on a first try or (lead by
> > incurable optimism) I don't try to revert it in hope that it was fixed.
> > 
> > Unfortunately the result is always the same cursing-during-qemu-test-run
> > -> git-revert -> recompile cycle and a needless time loss.
> > 
> > Could we have some action taken please?
> 
> What is the problem with this patch that has caused it to suddenly
> keeping the boot from working?  Is the code in the patch warning you of
> objects that are not properly being initialized?
> 
> I'll be glad to fix this if possible.

Isn't this the opposite end of the same problem for which Bernhard
has been repeatedly trying to find a taker for his patch:

http://article.gmane.org/gmane.linux.kernel.kexec/1882

Hugh

^ permalink raw reply	[flat|nested] 26+ messages in thread

* linux-next: usb tree fix (Was: Re: linux-next: Tree for July 29)
  2008-07-29 16:25 ` Bartlomiej Zolnierkiewicz
  2008-07-29 18:16   ` Greg KH
@ 2008-07-30  1:05   ` Stephen Rothwell
  2008-07-30 19:38     ` Bartlomiej Zolnierkiewicz
  1 sibling, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2008-07-30  1:05 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: linux-next, LKML, Dave Hansen, Greg KH

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

Hi Bart,

On Tue, 29 Jul 2008 18:25:14 +0200 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> when statically-allocated kobjects are used") with each linux-next release
> to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> 
> Depending on the day I either forget to revert it on a first try or (lead by
> incurable optimism) I don't try to revert it in hope that it was fixed.
> 
> Unfortunately the result is always the same cursing-during-qemu-test-run
> -> git-revert -> recompile cycle and a needless time loss.
> 
> Could we have some action taken please?

I have reverted that commit from linux-next today (its id has changed)
and will do so until Greg or Dave tells me it has been fixed.  To make
life easier for me, Greg, it would be nice if you removed it from your
series until that time.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29 20:49     ` Hugh Dickins
@ 2008-07-30  4:48       ` Greg KH
  2008-07-30  7:06         ` Bernhard Walle
  0 siblings, 1 reply; 26+ messages in thread
From: Greg KH @ 2008-07-30  4:48 UTC (permalink / raw)
  To: Hugh Dickins
  Cc: Greg KH, Bartlomiej Zolnierkiewicz, Stephen Rothwell,
	Bernhard Walle, linux-next, LKML, Dave Hansen

On Tue, Jul 29, 2008 at 09:49:24PM +0100, Hugh Dickins wrote:
> On Tue, 29 Jul 2008, Greg KH wrote:
> > On Tue, Jul 29, 2008 at 06:25:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 29 July 2008, Stephen Rothwell wrote:
> > > > 
> > > > Changes since next-20080728:
> > > 
> > > I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> > > when statically-allocated kobjects are used") with each linux-next release
> > > to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> > > 
> > > Depending on the day I either forget to revert it on a first try or (lead by
> > > incurable optimism) I don't try to revert it in hope that it was fixed.
> > > 
> > > Unfortunately the result is always the same cursing-during-qemu-test-run
> > > -> git-revert -> recompile cycle and a needless time loss.
> > > 
> > > Could we have some action taken please?
> > 
> > What is the problem with this patch that has caused it to suddenly
> > keeping the boot from working?  Is the code in the patch warning you of
> > objects that are not properly being initialized?
> > 
> > I'll be glad to fix this if possible.
> 
> Isn't this the opposite end of the same problem for which Bernhard
> has been repeatedly trying to find a taker for his patch:
> 
> http://article.gmane.org/gmane.linux.kernel.kexec/1882

Yes.  It's not the kobject patch at fault here, it's the use of kobjects
so early in the boot process.  That needs to be fixed.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30  4:48       ` Greg KH
@ 2008-07-30  7:06         ` Bernhard Walle
  2008-07-30  9:19           ` Andrew Morton
  0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Walle @ 2008-07-30  7:06 UTC (permalink / raw)
  To: Greg KH
  Cc: Hugh Dickins, Greg KH, Bartlomiej Zolnierkiewicz,
	Stephen Rothwell, linux-next, LKML, Dave Hansen

* Greg KH <greg@kroah.com> [2008-07-29 21:48]:
> > Isn't this the opposite end of the same problem for which Bernhard
> > has been repeatedly trying to find a taker for his patch:
> > 
> > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> 
> Yes.  It's not the kobject patch at fault here, it's the use of kobjects
> so early in the boot process.  That needs to be fixed.

Yes, but if somebody could tell me why nobody takes the patch, I would
be happy. Then I would be able to improve the patch. :)




Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30  7:06         ` Bernhard Walle
@ 2008-07-30  9:19           ` Andrew Morton
  2008-07-30 19:27             ` Bartlomiej Zolnierkiewicz
  0 siblings, 1 reply; 26+ messages in thread
From: Andrew Morton @ 2008-07-30  9:19 UTC (permalink / raw)
  To: Bernhard Walle
  Cc: Greg KH, Hugh Dickins, Greg KH, Bartlomiej Zolnierkiewicz,
	Stephen Rothwell, linux-next, LKML, Dave Hansen

On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <bwalle@suse.de> wrote:

> * Greg KH <greg@kroah.com> [2008-07-29 21:48]:
> > > Isn't this the opposite end of the same problem for which Bernhard
> > > has been repeatedly trying to find a taker for his patch:
> > > 
> > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> > 
> > Yes.  It's not the kobject patch at fault here, it's the use of kobjects
> > so early in the boot process.  That needs to be fixed.

It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
into the previously-atomic kobject_init().

It's only 128 bytes, so why can't we fix both problems thusly?

--- a/lib/kobject.c~a
+++ a/lib/kobject.c
@@ -38,12 +38,10 @@ static int ptr_in_range(void *ptr, void 
 
 static void verify_dynamic_kobject_allocation(struct kobject *kobj)
 {
-	char *namebuf;
+	char namebuf[KSYM_NAME_LEN];
 	const char *ret;
 
-	namebuf = kzalloc(KSYM_NAME_LEN, GFP_KERNEL);
-	ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL,
-			namebuf);
+	ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL, namebuf);
 	/*
 	 * This is the X86_32-only part of this function.
 	 * This is here because it is valid to have a kobject
@@ -63,7 +61,7 @@ static void verify_dynamic_kobject_alloc
 	/* dump_stack(); */
 	pr_debug("---- end silly warning ----\n");
 out:
-	kfree(namebuf);
+	return;
 }
 #else
 static void verify_dynamic_kobject_allocation(struct kobject *kobj) { }
_


> Yes, but if somebody could tell me why nobody takes the patch, I would
> be happy. Then I would be able to improve the patch. :)

Copy me on the patch.  Then I merge it and people know there will be no
hiding from it.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30  9:19           ` Andrew Morton
@ 2008-07-30 19:27             ` Bartlomiej Zolnierkiewicz
  2008-07-30 20:04               ` Andrew Morton
  0 siblings, 1 reply; 26+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-07-30 19:27 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Bernhard Walle, Greg KH, Hugh Dickins, Greg KH, Stephen Rothwell,
	linux-next, LKML, Dave Hansen

On Wednesday 30 July 2008, Andrew Morton wrote:
> On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <bwalle@suse.de> wrote:
> 
> > * Greg KH <greg@kroah.com> [2008-07-29 21:48]:
> > > > Isn't this the opposite end of the same problem for which Bernhard
> > > > has been repeatedly trying to find a taker for his patch:
> > > > 
> > > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> > > 
> > > Yes.  It's not the kobject patch at fault here, it's the use of kobjects
> > > so early in the boot process.  That needs to be fixed.
> 
> It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
> into the previously-atomic kobject_init().
> 
> It's only 128 bytes, so why can't we fix both problems thusly?

Fixes the bug for me (also true for previous patch from Bernhard).

Thanks!

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: usb tree fix (Was: Re: linux-next: Tree for July 29)
  2008-07-30  1:05   ` linux-next: usb tree fix (Was: Re: linux-next: Tree for July 29) Stephen Rothwell
@ 2008-07-30 19:38     ` Bartlomiej Zolnierkiewicz
  0 siblings, 0 replies; 26+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-07-30 19:38 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, Dave Hansen, Greg KH

On Wednesday 30 July 2008, Stephen Rothwell wrote:
> Hi Bart,
> 
> On Tue, 29 Jul 2008 18:25:14 +0200 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> >
> > I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> > when statically-allocated kobjects are used") with each linux-next release
> > to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> > 
> > Depending on the day I either forget to revert it on a first try or (lead by
> > incurable optimism) I don't try to revert it in hope that it was fixed.
> > 
> > Unfortunately the result is always the same cursing-during-qemu-test-run
> > -> git-revert -> recompile cycle and a needless time loss.
> > 
> > Could we have some action taken please?
> 
> I have reverted that commit from linux-next today (its id has changed)
> and will do so until Greg or Dave tells me it has been fixed.  To make
> life easier for me, Greg, it would be nice if you removed it from your
> series until that time.

Thanks but since now there is a fix (even two!) for the issue and Dave's
patch has the value of catching real bugs maybe we could have one of the
fixes in linux-next instead of revert?

PS ironically today's linux-next broke xorg for me... call me lucky...

Bart

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30 19:27             ` Bartlomiej Zolnierkiewicz
@ 2008-07-30 20:04               ` Andrew Morton
  2008-07-30 23:41                 ` Stephen Rothwell
  0 siblings, 1 reply; 26+ messages in thread
From: Andrew Morton @ 2008-07-30 20:04 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: bwalle, greg, hugh, gregkh, sfr, linux-next, linux-kernel,
	haveblue

On Wed, 30 Jul 2008 21:27:41 +0200
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 30 July 2008, Andrew Morton wrote:
> > On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <bwalle@suse.de> wrote:
> > 
> > > * Greg KH <greg@kroah.com> [2008-07-29 21:48]:
> > > > > Isn't this the opposite end of the same problem for which Bernhard
> > > > > has been repeatedly trying to find a taker for his patch:
> > > > > 
> > > > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> > > > 
> > > > Yes.  It's not the kobject patch at fault here, it's the use of kobjects
> > > > so early in the boot process.  That needs to be fixed.
> > 
> > It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
> > into the previously-atomic kobject_init().
> > 
> > It's only 128 bytes, so why can't we fix both problems thusly?
> 
> Fixes the bug for me (also true for previous patch from Bernhard).
> 

Cool.

The offending patch has just got itself turfed from linux-next so my
fix now has nothing to fix.

We'll see what happens!

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30 20:04               ` Andrew Morton
@ 2008-07-30 23:41                 ` Stephen Rothwell
  2008-07-30 23:44                   ` Greg KH
  0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2008-07-30 23:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Bartlomiej Zolnierkiewicz, bwalle, greg, hugh, gregkh, linux-next,
	linux-kernel, haveblue

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Hi Andrew,

On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> The offending patch has just got itself turfed from linux-next so my
> fix now has nothing to fix.
> 
> We'll see what happens!

I will put Dave's patch back with yours on top of it (hoping that Greg
will take your patch).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30 23:41                 ` Stephen Rothwell
@ 2008-07-30 23:44                   ` Greg KH
  2008-08-07  1:08                     ` Stephen Rothwell
  0 siblings, 1 reply; 26+ messages in thread
From: Greg KH @ 2008-07-30 23:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Bartlomiej Zolnierkiewicz, bwalle, greg, hugh,
	linux-next, linux-kernel, haveblue

On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > The offending patch has just got itself turfed from linux-next so my
> > fix now has nothing to fix.
> > 
> > We'll see what happens!
> 
> I will put Dave's patch back with yours on top of it (hoping that Greg
> will take your patch).

Greg will, it's in my queue.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-29 14:45 ` Dominik Brodowski
@ 2008-08-03 14:56   ` Stephen Rothwell
  2008-08-04  7:58     ` Dominik Brodowski
  0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2008-08-03 14:56 UTC (permalink / raw)
  To: Dominik Brodowski; +Cc: linux-next, LKML, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi Dominik,

On Tue, 29 Jul 2008 16:45:58 +0200 Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>
> On Tue, Jul 29, 2008 at 05:23:37PM +1000, Stephen Rothwell wrote:
> > Changes since next-20080728:
> 
> is linux-next now open for 2.6.28 stuff?

Yeah, I would say it is, now.  (Notice how I cleverly delayed it for a
week :-))

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-08-03 14:56   ` Stephen Rothwell
@ 2008-08-04  7:58     ` Dominik Brodowski
  0 siblings, 0 replies; 26+ messages in thread
From: Dominik Brodowski @ 2008-08-04  7:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, Andrew Morton

Hi Stephen,

On Mon, Aug 04, 2008 at 12:56:11AM +1000, Stephen Rothwell wrote:
> On Tue, 29 Jul 2008 16:45:58 +0200 Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> >
> > On Tue, Jul 29, 2008 at 05:23:37PM +1000, Stephen Rothwell wrote:
> > > Changes since next-20080728:
> > 
> > is linux-next now open for 2.6.28 stuff?
> 
> Yeah, I would say it is, now.  (Notice how I cleverly delayed it for a
> week :-))

Excellent. (Notice how I cunningly predicted this and sneaked in lots of
.28-stuff into pcmcia/master over the weekend ;-)).

Best,
	Dominik

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-07-30 23:44                   ` Greg KH
@ 2008-08-07  1:08                     ` Stephen Rothwell
  2008-08-07  3:40                       ` Greg KH
  0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2008-08-07  1:08 UTC (permalink / raw)
  To: Greg KH
  Cc: Andrew Morton, Bartlomiej Zolnierkiewicz, bwalle, greg, hugh,
	linux-next, linux-kernel, haveblue

HI Greg,

On Wed, 30 Jul 2008 16:44:19 -0700 Greg KH <gregkh@suse.de> wrote:
>
> On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > The offending patch has just got itself turfed from linux-next so my
> > > fix now has nothing to fix.
> > > 
> > > We'll see what happens!
> > 
> > I will put Dave's patch back with yours on top of it (hoping that Greg
> > will take your patch).
> 
> Greg will, it's in my queue.

This is still not in your patch series ...  summary email with patch
repeated below.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Date: Wed, 30 Jul 2008 02:19:47 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Bernhard Walle <bwalle@suse.de>
Cc: Greg KH <greg@kroah.com>, Hugh Dickins <hugh@veritas.com>,
        Greg KH <gregkh@suse.de>,
        Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
        Stephen Rothwell <sfr@canb.auug.org.au>, linux-next@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        Dave Hansen <haveblue@us.ibm.com>
Subject: driver-core: kobject verification fixup

On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <bwalle@suse.de> wrote:

> * Greg KH <greg@kroah.com> [2008-07-29 21:48]:
> > > Isn't this the opposite end of the same problem for which Bernhard
> > > has been repeatedly trying to find a taker for his patch:
> > > 
> > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> > 
> > Yes.  It's not the kobject patch at fault here, it's the use of kobjects
> > so early in the boot process.  That needs to be fixed.

It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
into the previously-atomic kobject_init().

It's only 128 bytes, so why can't we fix both problems thusly?

--- a/lib/kobject.c~a
+++ a/lib/kobject.c
@@ -38,12 +38,10 @@ static int ptr_in_range(void *ptr, void 
 
 static void verify_dynamic_kobject_allocation(struct kobject *kobj)
 {
-	char *namebuf;
+	char namebuf[KSYM_NAME_LEN];
 	const char *ret;
 
-	namebuf = kzalloc(KSYM_NAME_LEN, GFP_KERNEL);
-	ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL,
-			namebuf);
+	ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL, namebuf);
 	/*
 	 * This is the X86_32-only part of this function.
 	 * This is here because it is valid to have a kobject
@@ -63,7 +61,7 @@ static void verify_dynamic_kobject_alloc
 	/* dump_stack(); */
 	pr_debug("---- end silly warning ----\n");
 out:
-	kfree(namebuf);
+	return;
 }
 #else
 static void verify_dynamic_kobject_allocation(struct kobject *kobj) { }
_


> Yes, but if somebody could tell me why nobody takes the patch, I would
> be happy. Then I would be able to improve the patch. :)

Copy me on the patch.  Then I merge it and people know there will be no
hiding from it.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-08-07  1:08                     ` Stephen Rothwell
@ 2008-08-07  3:40                       ` Greg KH
  2008-08-07  6:10                         ` Stephen Rothwell
  0 siblings, 1 reply; 26+ messages in thread
From: Greg KH @ 2008-08-07  3:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Bartlomiej Zolnierkiewicz, bwalle, greg, hugh,
	linux-next, linux-kernel, haveblue

On Thu, Aug 07, 2008 at 11:08:44AM +1000, Stephen Rothwell wrote:
> HI Greg,
> 
> On Wed, 30 Jul 2008 16:44:19 -0700 Greg KH <gregkh@suse.de> wrote:
> >
> > On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > The offending patch has just got itself turfed from linux-next so my
> > > > fix now has nothing to fix.
> > > > 
> > > > We'll see what happens!
> > > 
> > > I will put Dave's patch back with yours on top of it (hoping that Greg
> > > will take your patch).
> > 
> > Greg will, it's in my queue.
> 
> This is still not in your patch series ...  summary email with patch
> repeated below.

Just went in about 3 hours ago :)

I merged it with the original, that's the best way to do it.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2008-08-07  3:40                       ` Greg KH
@ 2008-08-07  6:10                         ` Stephen Rothwell
  0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2008-08-07  6:10 UTC (permalink / raw)
  To: Greg KH
  Cc: Andrew Morton, Bartlomiej Zolnierkiewicz, bwalle, greg, hugh,
	linux-next, linux-kernel, haveblue

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Hi Greg,

On Wed, 6 Aug 2008 20:40:49 -0700 Greg KH <gregkh@suse.de> wrote:
>
> Just went in about 3 hours ago :)

Thanks.

> I merged it with the original, that's the best way to do it.

Yep.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* linux-next: Tree for July 29
@ 2009-07-29  7:36 Stephen Rothwell
  0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2009-07-29  7:36 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 8099 bytes --]

Hi all,

Changes since 20090728:

New trees: kmemleak

Removed tree: ttydev

This tree fails to build for powerpc allyesconfig (final link problem).

The drbd tree gained a couple of build failures due to interactions with
the block tree.  I applied a couple of patches.

The staging tree gained a conflict against the net tree.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 135 trees (counting Linus' and 19 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/journal.c
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/chips/tsl2550.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
CONFLICT (content): Merge conflict in drivers/media/dvb/b2c2/flexcop-fe-tuner.c
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-3945.h
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-tx.c
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl3945-base.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
CONFLICT (content): Merge conflict in fs/notify/inotify/inotify_user.c
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Applying: drbd: fixups for block api changes
Applying: drbd: fix for removal of blk_queue_stack_limits
Merging tip/auto-latest
CONFLICT (content): Merge conflict in drivers/oprofile/oprofile_stats.c
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_counter.c
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq_ondemand.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging quilt/driver-core
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* linux-next: Tree for July 29
@ 2010-07-29  4:32 Stephen Rothwell
  0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2010-07-29  4:32 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 13050 bytes --]

Hi all,

Changes since 20100728:

New tree: lost-spurious-irq

The mips tree lost its build failure.

The scsi tree lost its build failure.

The net tree gained a conflicts against the net-current tree and a build
failure for which I applied a patch.

The kvm tree still has its build failure.

The fsnotify tree lost a helper patch.

The xen tree lost its build failure and conflict.

The tip tree lost its complex conflict against the powerpc tree but
gained a build failure so I used the version from next-20100727.

The workqueues tree gained a conflict against the lost-spurious-irq tree.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 167 trees (counting Linus' and 22 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/rc-fixes
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-3430sdp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-3630sdp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-am3517evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-cm-t35.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-devkit8000.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-igep0020.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-ldp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3beagle.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3pandora.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3touchbook.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-overo.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom2.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom3.c
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
CONFLICT (content): Merge conflict in arch/arm/Kconfig
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
CONFLICT (content): Merge conflict in drivers/serial/mpc52xx_uart.c
Merging galak/next
Merging s390/features
Merging sh/master
Merging genesis/master
CONFLICT (content): Merge conflict in arch/arm/configs/ap4evb_defconfig
CONFLICT (content): Merge conflict in arch/arm/configs/g3evm_defconfig
CONFLICT (content): Merge conflict in arch/arm/configs/g4evm_defconfig
Merging sparc/master
Merging tile/master
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/ext4/inode.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_aops.c
Merging vfs/for-next
CONFLICT (content): Merge conflict in fs/nilfs2/super.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_aops.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_super.c
Applying: v9fs: fixup for inode_setattr being removed
Applying: xfs: update tracing for clear_inode to evit_inode transition
Applying: cifs: fix for clear_inode -> evict_inode API change
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
CONFLICT (content): Merge conflict in arch/arm/plat-omap/i2c.c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-cpm.c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mpc.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
CONFLICT (content): Merge conflict in arch/x86/kvm/paging_tmpl.h
Applying: kvm: u64's should be printed with %llx
Merging dlm/next
Merging ibft/master
Merging swiotlb/master
Merging scsi/master
Merging async_tx/next
CONFLICT (content): Merge conflict in arch/arm/mach-ux500/devices-db8500.c
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/e1000e/hw.h
CONFLICT (content): Merge conflict in net/bridge/br_input.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/um/drivers/hostaudio_kern.c
Merging input/next
CONFLICT (add/add): Merge conflict in arch/arm/plat-samsung/include/plat/keypad.h
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in drivers/block/virtio_blk.c
CONFLICT (content): Merge conflict in drivers/scsi/scsi_error.c
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
CONFLICT (content): Merge conflict in drivers/power/Kconfig
CONFLICT (content): Merge conflict in drivers/power/Makefile
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging viafb/viafb-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
CONFLICT (content): Merge conflict in drivers/net/wireless/ipw2x00/ipw2100.c
Merging bluetooth/master
Merging fsnotify/for-next
CONFLICT (delete/modify): fs/notify/inotify/inotify.c deleted in fsnotify/for-next and modified in HEAD. Version HEAD of fs/notify/inotify/inotify.c left in tree.
$ git rm -f fs/notify/inotify/inotify.c
Merging irda/for-next
CONFLICT (content): Merge conflict in drivers/net/irda/irda-usb.c
Merging catalin/for-next
CONFLICT (content): Merge conflict in arch/arm/kernel/entry-armv.S
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging alacrity/linux-next
Merging i7core_edac/linux_next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging devicetree/next-devicetree
CONFLICT (content): Merge conflict in arch/microblaze/kernel/Makefile
Merging spi/next-spi
Merging limits/writable_limits
CONFLICT (content): Merge conflict in arch/x86/ia32/ia32entry.S
CONFLICT (content): Merge conflict in arch/x86/include/asm/unistd_32.h
CONFLICT (content): Merge conflict in arch/x86/include/asm/unistd_64.h
CONFLICT (content): Merge conflict in arch/x86/kernel/syscall_table_32.S
CONFLICT (content): Merge conflict in include/asm-generic/unistd.h
Merging omap_dss2/for-next
Merging xen/upstream/xen
Merging tip/auto-latest
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in Makefile
CONFLICT (content): Merge conflict in arch/powerpc/kernel/time.c
CONFLICT (content): Merge conflict in drivers/Makefile
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
$ git reset --hard HEAD^
Merging refs/next/20100727/tip
CONFLICT (content): Merge conflict in Makefile
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
CONFLICT (content): Merge conflict in tools/perf/Makefile
[master dab36ec] Merge commit 'refs/next/20100727/tip'
Merging lost-spurious-irq/lost-spurious-irq
Merging edac-amd/for-next
Merging oprofile/for-next
Merging percpu/for-next
Merging workqueues/for-next
CONFLICT (content): Merge conflict in fs/cifs/cifsfs.c
CONFLICT (content): Merge conflict in fs/cifs/cifsglob.h
CONFLICT (content): Merge conflict in fs/cifs/file.c
CONFLICT (content): Merge conflict in include/linux/libata.h
CONFLICT (content): Merge conflict in include/linux/workqueue.h
CONFLICT (content): Merge conflict in kernel/trace/Kconfig
CONFLICT (content): Merge conflict in kernel/workqueue.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
CONFLICT (content): Merge conflict in mm/memory-failure.c
Merging sysctl/master
Merging bkl-core/bkl/core
Merging bkl-procfs/bkl/procfs
Merging bkl-ioctl/bkl/ioctl
Merging quilt/driver-core
Merging quilt/tty
CONFLICT (content): Merge conflict in include/linux/serial_core.h
Merging quilt/usb
Merging staging-next/staging-next
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/bat_sysfs.c
CONFLICT (delete/modify): drivers/staging/batman-adv/device.c deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/batman-adv/device.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/hard-interface.c
CONFLICT (delete/modify): drivers/staging/cx25821/cx25821-audups11.c deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/cx25821/cx25821-audups11.c left in tree.
$ git rm -f drivers/staging/cx25821/cx25821-audups11.c
$ git rm -f drivers/staging/batman-adv/device.c
Merging slabh/slabh
Merging scsi-post-merge/merge-base:master
$ git checkout scsi-post-merge/master
Applying: [SCSI] be2iscsi: Add support for iscsi boot
Applying: [SCSI] be2iscsi: Increase max sector
Applying: [SCSI] be2iscsi: Driver Version change to 2.0.549.0
Applying: net: bnx2x_cmn.c needs net/ip6_checksum.h for csum_ipv6_magic

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* linux-next: Tree for July 29
@ 2011-07-29  7:38 Stephen Rothwell
  2011-07-30 11:38 ` Sedat Dilek
  0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2011-07-29  7:38 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 26021 bytes --]

Hi all,

Just in case anyone needs reminding:  Please do not add anything destined
for v3.2 into linux-next included trees until after v3.1-rc1.

The powerpc allyesconfig and sparc defconfig build (at least) fail today.

Changes since 20110728:

New tree: moduleh

Linus' tree still has its build failure from the staging tree which I
have still left unfixed.

The i.MX tree lost its conflicts.

The xtensa tree lost its conflict.

The v4l-dvb tree lost a conflict and gained another against Linus' tree.

The l2-mtd tree gained a conflict against the mips tree.

The security-testing tree lost its conflict.

The moduleh tree gained a conflict against the v4l-dvb tree and lots of
build failures some of whcih I patched and some I just left for today.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 200 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging kbuild-current/rc-fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging fbdev-current/fbdev-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
Merging arm-lpae/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgalloc.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/proc-fns.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/tlb.h
CONFLICT (content): Merge conflict in arch/arm/mm/context.c
CONFLICT (content): Merge conflict in arch/arm/mm/proc-v7.S
Merging arm-soc/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-exynos4/pm.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/cm-regbits-44xx.h
Merging at91/at91-next
Merging davinci/davinci-next
Merging i.MX/for-next
Merging linux-spec/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-exynos4/Kconfig
CONFLICT (content): Merge conflict in arch/arm/mach-exynos4/mach-smdkc210.c
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging openrisc/for-upstream
Merging parisc/for-next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/powerpc/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging unicore32/unicore32
Merging xtensa/master
Merging ceph/for-next
CONFLICT (content): Merge conflict in fs/ceph/export.c
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/dev
CONFLICT (content): Merge conflict in fs/ext4/inode.c
Applying: vfs/ext4: merge fixup for moved function
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
Merging of-pci/of-pci
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging docs/docs-move
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-rx51-peripherals.c
CONFLICT (content): Merge conflict in drivers/staging/tm6000/tm6000-alsa.c
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
CONFLICT (content): Merge conflict in arch/ia64/Kconfig
CONFLICT (content): Merge conflict in arch/powerpc/Kconfig
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in lib/Kconfig
CONFLICT (content): Merge conflict in lib/Makefile
Merging idle-test/idle-test
Merging powertools/tools-test
Merging cpupowerutils/master
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging iscsi-target/for-next
Merging slave-dma/next
CONFLICT (content): Merge conflict in drivers/dma/mv_xor.c
Merging async_tx/next
Merging net/master
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging l2-mtd/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/lantiq-flash.c
CONFLICT (content): Merge conflict in drivers/mtd/maps/pxa2xx-flash.c
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging input-mt/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security-testing/next
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging suspend/linux-next
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
Merging devicetree/devicetree/next
Merging spi/spi/next
Merging gpio/gpio/next
Merging tip/auto-latest
Merging rcu/rcu/next
Merging kvm/linux-next
Merging oprofile/for-next
Merging ptrace/ptrace
Merging xen/upstream/xen
Merging xen-two/linux-next
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
Merging regmap/for-next
Merging driver-core/driver-core-next
Merging tty/tty-next
Merging usb/usb-next
Merging staging/staging-next
Merging bkl-config/config
Merging tmem/linux-next
Merging writeback/next
Merging arm-dt/devicetree/arm-next
Merging scsi-post-merge/merge-base:master
Merging moduleh/module.h-split
CONFLICT (content): Merge conflict in sound/i2c/other/tea575x-tuner.c
Applying: Partial revert of f7f927183dba
Applying: Partial revert of commit d03b684f1773
Applying: kxtj9: explictly include module.h
Applying: include export.h to use EXPORT_SYMBOL
Applying: ov5642: include module.h for its facilities
Applying: ir-raw: include kmod.h for request_module
Applying: ir-mce_kbd-decoder: include module.h for its facilities
$ git checkout akpm
Applying: kernel/fork.c:267: error: implicit declaration of function
Applying: WARNING: line over 80 characters
Applying: arch/cris/arch-v10/drivers/sync_serial.c:628: error: 'ret' undeclared (first use in this function)
Applying: arch/cris/arch-v10/drivers/sync_serial.c:961: error: conflicting types for 'sync_serial_ioctl'
Applying: arch/cris/arch-v10/kernel/irq.c:239: error: implicit declaration of function 'kgdb_init'
Applying: There's a code path in pmcraid that can be reached via device ioctl that
Applying: The out_msi_disable label should be before cleanup_nomem to additionally
Applying: Most smartarrays tolerate it, but a few new ones don't.
Applying: My load tests on PowerPC freeze within minutes in __slab_free().  I
Applying: The parameter's origin type is long.  On an i386 architecture, it can
Applying: kernel/time.c:578: error: conflicting types for 'jiffies_to_clock_t'
Applying: It's about time to revert 16d752397301b9 ("thermal: Create
Applying: We'll soon need to reuse it.
Applying: THERMAL_HWMON is implemented inside the thermal_sys driver and has no
Applying: b552a8c56db8 ("ACPI: remove NID_INVAL") removed the left over uses of
Applying: Linux supports some optional features, but it should notify the BIOS about
Applying: Add support for Aspire 1410 BIOS v1.3314.  Fixes the following error:
Applying: This makes the iris driver use the platform API, so it is properly exposed
Applying: - remove commented-out code
Applying: There was one code block that I commented to be able to test the patch dnd
Applying: On x86_32 casting the unsigned int result of get_random_int() to long may
Applying: This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
Applying: Replace the bubble sort in sanitize_e820_map() with a call to the generic
Applying: In response to new device tree code in the kernel, OLPC will start using
Applying: Move these definitions into the relevant header file.  This was requested
CONFLICT (delete/modify): arch/x86/platform/olpc/olpc-xo1.c deleted in HEAD and modified in Move these definitions into the relevant header file.  This was requested. Version Move these definitions into the relevant header file.  This was requested of arch/x86/platform/olpc/olpc-xo1.c left in tree.
CONFLICT (content): Merge conflict in include/linux/cs5535.h
Applying: Based on earlier review comments, we'll no longer try to stick all of our
CONFLICT (rename/delete): Rename arch/x86/platform/olpc/olpc-xo1.c->arch/x86/platform/olpc/olpc-xo1-pm.c in Based on earlier review comments, we'll no longer try to stick all of our and deleted in HEAD
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/platform/olpc/Makefile
Applying: Add code needed for basic suspend/resume of the XO-1 laptop.  Based on
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/include/asm/olpc.h
CONFLICT (content): Merge conflict in arch/x86/platform/olpc/Makefile
Applying: The System Control Interrupt is used in the OLPC XO-1 to control various
CONFLICT (content): Merge conflict in arch/x86/platform/olpc/Makefile
CONFLICT (add/add): Merge conflict in arch/x86/platform/olpc/olpc-xo1-sci.c
CONFLICT (content): Merge conflict in include/linux/cs5535.h
Applying: Update the EC SCI masks with recent additions.
CONFLICT (content): Merge conflict in arch/x86/platform/olpc/olpc.c
Applying: The EC in the OLPC XO-1 delivers GPE events to provide various
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/platform/olpc/olpc-xo1-sci.c
Applying: Configure the XO-1's lid switch GPIO to trigger an SCI interrupt, and
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/platform/olpc/olpc-xo1-sci.c
Applying: EC events indicate change in AC power connectivity, battery state of
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Applying: Add a driver to configure the XO-1 RTC via CS5536 MSRs, to be used as a
CONFLICT (add/add): Merge conflict in arch/x86/platform/olpc/olpc-xo1-rtc.c
Applying: Add a driver for the ACPI-based EC event interface found on the OLPC
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (add/add): Merge conflict in arch/x86/platform/olpc/olpc-xo15-sci.c
Applying: Don't allow everybody to use a modem.
Applying: The address limit is already set in flush_old_exec() so this
Applying: A call to va_copy() should always be followed by a call to va_end() in the
Applying: Don't dereference em if it's NULL or an error pointer.
Applying: The buffer 'sc.cpu_mask' is a kernel buffer.  If bitmap_parse is used
Applying: The camera there identifies itself as being manufactured by Cheng Uei
Applying: fb_set_suspend() must be called with the console semaphore held, which
Applying: Unless I'm very much missing something these tests are intended to check
Applying: The address limit is already set in flush_old_exec() so this
Applying: The address limit is already set in flush_old_exec() so this
Applying: Mike McLagan hasn't contributed in many years and his email bounces.
Applying: proc_fork_connector() uses ->real_parent lockless.  This is not safe if
Applying: backlight_device_register() returns ERR_PTR() on error.
Applying: 1. current implementation tests wrong value for setting aat2870_bl->max_current.
Applying: i386 allmodconfig:
Applying: ext4_{set,clear}_bit() is defined as __test_and_{set,clear}_bit_le() for
Applying: The dqc_bitmap field of struct ocfs2_local_disk_chunk is 32-bit aligned,
Applying: The address limit is already set in flush_old_exec() so those calls to
Applying: When do pci remove/rescan on system that have more iommus, got
Applying: The current implementation of dmi_name_in_vendors() is an invitation to
Applying: fix comment layout
Applying: The address limit is already set in flush_old_exec() so those calls to
Applying: For headers that get exported to userland and make use of u32 style
Applying: Fix sparse warnings of right shift bigger than source value size:
Applying: We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :
Applying: brd_make_request() always returns 0, which doesn't make much sense.
Applying: Remove the (unsigned long long) cast in diskstats_show() and adjusts the
Applying: The report has an ISO which has a very long manufacturer ID.  It seems
Applying: The address limit is already set in flush_old_exec() so this assignment of
Applying: x86_64 allmodconfig:
Applying: alpha allmodconfig:
CONFLICT (content): Merge conflict in drivers/staging/dt3155v4l/dt3155v4l.c
Applying: alpha allmodconfig:
Applying: alpha allmodconfig:
Applying: alpha allmodconfig:
Applying: Cc: Greg KH <greg@kroah.com>
Applying: Use the nice enumerated constant.
Applying: A patchset to extend tmpfs to MAX_LFS_FILESIZE by abandoning its peculiar
Applying: If swap entries are to be stored along with struct page pointers in a
Applying: The maximum size of a shmem/tmpfs file has been limited by the maximum
Applying: While it's at its least, make a number of boring nitpicky cleanups to
Applying: Bring truncate.c's code for truncate_inode_pages_range() inline into
Applying: Disable the toy swapping implementation in shmem_writepage() - it's hard
Applying: Convert shmem_unuse_inode() to use a lockless gang lookup of the radix
Applying: Convert shmem_getpage_gfp(), the engine-room of shmem, to expect page or
Applying: Remove mem_cgroup_shmem_charge_fallback(): it was only required when we
Applying: Convert shmem_writepage() to use shmem_delete_from_page_cache() to use
Applying: But we've not yet removed the old swp_entry_t i_direct[16] from
Applying: Remove PageSwapBacked (!page_is_file_cache) cases from
Applying: Fix NULL dereference I introduced in mincore_page().
Applying: Expand the fs/Kconfig "help" info to clarify why it's a bad idea to
Applying: Expand the fs/Kconfig "help" info to clarify why you might need to select
Applying: Dev_opp initial value shoule be ERR_PTR(), IS_ERR() is used to check
Applying: The address limit is already set in flush_old_exec() so this
Applying: smp_call_function() only lets all other CPUs execute a specific function,
Applying: auto_demotion_disable is called only for online CPUs.  For hotplugged
Applying: Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following warning:
Applying: Strict user copy checks are only really supported on x86_32 even though
Applying: The help text for this config is duplicated across the x86, parisc, and
Applying: The code checks the correctness of the parameters, but unconditionally
CONFLICT (content): Merge conflict in drivers/rtc/interface.c
Applying: Due to the hrtimer self rearming mode a user can DoS the machine simply
Applying: Ben reported a lockup related to rtc. The lockup happens due to:
Applying: Each memory cgroup has a 'swappiness' value which can be accessed by
CONFLICT (content): Merge conflict in include/linux/swap.h
CONFLICT (content): Merge conflict in mm/memcontrol.c
CONFLICT (content): Merge conflict in mm/vmscan.c
Applying: In mm/memcontrol.c, there are many lru stat functions as..
Applying: mm/vmscan.c: In function 'zone_nr_lru_pages':
Applying: Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Applying: 867578cb ("memcg: fix oom kill behavior") introduced oom_lock counter
CONFLICT (content): Merge conflict in mm/memcontrol.c
Applying: memcg_oom_mutex is used to protect memcg OOM path and eventfd interface
Applying: 246e87a ("memcg: fix get_scan_count() for small targets") fixes the
Applying: 22a668d7 ("memcg: fix behavior under memory.limit equals to memsw.limit")
Applying: The commit log of 0ae5e89 ("memcg: count the soft_limit reclaim in...")
Applying: drain_all_stock_async tries to optimize a work to be done on the work
CONFLICT (content): Merge conflict in mm/memcontrol.c
Applying: Currently we have two ways how to drain per-CPU caches for charges.
CONFLICT (content): Merge conflict in mm/memcontrol.c
Applying: We are checking whether a given two groups are same or at least in the
Applying: percpu_charge_mutex protects from multiple simultaneous per-cpu charge
Applying: [This patch has already been accepted as 0ac0c0d but later reverted
CONFLICT (content): Merge conflict in include/linux/nodemask.h
CONFLICT (content): Merge conflict in kernel/fork.c
Applying: fix CONFIG_NUMA=y, MAX_NUMNODES>1 build
Applying: Kosaki Motohiro raised a concern that copy_process is hot path and we do
CONFLICT (content): Merge conflict in kernel/cpuset.c
Applying: make David happy
Applying: Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applying: No need to declare show_regs() in ptrace.h, sched.h does this.
Applying: sys_ssetmask(), sys_rt_sigsuspend() and compat_sys_rt_sigsuspend()
Applying: If we don't know the file corresponding to the binary (i.e.  exe_file is
CONFLICT (content): Merge conflict in fs/exec.c
Applying: Change every occurence of / in comm and hostname to !.  If the process
Applying: do_coredump() assumes that if format_corename() fails it should return
Applying: Signed-off-by: Daniel Rebelo de Oliveira <psykon@gmail.com>
Applying: a8bef8ff ("mm: migration: avoid race between shift_arg_pages() and
Applying: Currently, search_binary_handler() tries to load binary loader module
Applying: If CONFIG_MODULES=n, it makes no sense to retry the list of binary formats
Applying: acct_arg_size() takes ->page_table_lock around add_mm_counter() if
Applying: If new_inode fails to allocate an inode we need only to return with NULL.
CONFLICT (content): Merge conflict in ipc/mqueue.c
Applying: We return ENOMEM from mqueue_get_inode even when we have enough memory.
Applying: Add support for the shm_rmid_forced sysctl.  If set to 1, all
CONFLICT (content): Merge conflict in Documentation/sysctl/kernel.txt
CONFLICT (content): Merge conflict in include/linux/ipc_namespace.h
CONFLICT (content): Merge conflict in include/linux/shm.h
CONFLICT (content): Merge conflict in ipc/ipc_sysctl.c
CONFLICT (content): Merge conflict in ipc/shm.c
Applying: fix documentation, per Randy
Applying: include/linux/shm.h: In function 'exit_shm':
Applying: readability/conventionality tweaks
Applying: shm_may_destroy() and ipc_namespace.shm_forced_rmid lack comments.
CONFLICT (content): Merge conflict in include/linux/ipc_namespace.h
CONFLICT (content): Merge conflict in ipc/shm.c
Applying: - fix shm_rmid_forced/shm_forced_rmid confusion
Applying: Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Applying: Expand root=PARTUUID=UUID syntax to support selecting a root partition by
Applying: Update kernel-parameters.txt to point users to the authoritative comment
Applying: Parameter offset_in_page in edac_mc_handle_ce() should mask the higher
Applying: When kernel BUG or oops occurs, ChromeOS intends to panic and immediately
Applying: Don't force output if you intend to reboot immediately.
Applying: With the arrival of concurrency-managed workqueues there is no need for
CONFLICT (content): Merge conflict in drivers/misc/vmw_balloon.c
Applying: fix comment layout & grammar
Applying: Use generic module parameters instead of platform data, if platform data
CONFLICT (content): Merge conflict in drivers/char/ramoops.c
Applying: ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8
Applying: Add new line to each print.
CONFLICT (content): Merge conflict in drivers/char/ramoops.c
Applying: The platform driver currently allows setting the mem_size and mem_address.
CONFLICT (content): Merge conflict in drivers/char/ramoops.c
CONFLICT (content): Merge conflict in include/linux/ramoops.h
Applying: The size of the dump is currently set using the RECORD_SIZE macro which is
Applying: While ramoops writes to ram, accessing the dump requires using /dev/mem
Applying: No need to include linux/kallsyms.h.
Applying: should_fail_srandom() does not exist.
Applying: Minor cosmetic changes for simple attribute of stacktrace_depth:
CONFLICT (content): Merge conflict in lib/fault-inject.c
Applying: Use debugfs_remove_recursive() to simplify initialization and
CONFLICT (content): Merge conflict in mm/failslab.c
CONFLICT (content): Merge conflict in mm/page_alloc.c
Applying: Now cleanup_fault_attr_dentries() recursively removes a directory, So we
Applying: Now cleanup_fault_attr_dentries() recursively removes a directory, So we
Applying: This changes should_fail_request() to more usable wrapper function of
Applying: The majority of architectures implement ext2 atomic bitops as
Applying: This allows us to move duplicated code in <asm/atomic.h>
CONFLICT (content): Merge conflict in include/asm-generic/atomic.h
CONFLICT (content): Merge conflict in include/linux/atomic.h
CONFLICT (content): Merge conflict in include/linux/crypto.h
CONFLICT (content): Merge conflict in include/net/lib80211.h
Applying: This is in preparation for more generic atomic
Applying: After changing all consumers of atomics to include
Applying: This clarifies the differences between <linux/atomic.h> and
Applying: We already declared inc/dec helpers, so we don't need to call the
Applying: The atomic helpers are supposed to take an atomic_t pointer, not a random
CONFLICT (content): Merge conflict in include/asm-generic/atomic.h
Applying: Since arches are expected to implement this guy, add a common version for
Applying: Only a few core funcs need to be implemented for SMP systems, so allow the
CONFLICT (content): Merge conflict in include/asm-generic/atomic.h
Merging akpm
Applying: pci/of: include export.h for EXPORT_SYMBOL_GPL
Applying: powerpc32: include export.h for EXPORT_SYMBOL
Applying: ksysfs: include stat.h for S_IRUGO
Applying: powerpc/44x: include export.h for EXPORT_SYMBOL
Applying: dmaengine.h needs bitmap.h

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2011-07-29  7:38 Stephen Rothwell
@ 2011-07-30 11:38 ` Sedat Dilek
  2011-07-30 16:08   ` Arnaud Lacombe
  0 siblings, 1 reply; 26+ messages in thread
From: Sedat Dilek @ 2011-07-30 11:38 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, Randy Dunlap

On Fri, Jul 29, 2011 at 9:38 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Just in case anyone needs reminding:  Please do not add anything destined
> for v3.2 into linux-next included trees until after v3.1-rc1.
>
> The powerpc allyesconfig and sparc defconfig build (at least) fail today.
>
> Changes since 20110728:
>
> New tree: moduleh
>

See all those followup/fixup patches the last day, might be not such a
good idea to include this tree :-).
I wait for next Monday's linux-next.

- Sedat -

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2011-07-30 11:38 ` Sedat Dilek
@ 2011-07-30 16:08   ` Arnaud Lacombe
  2011-07-30 16:16     ` Sedat Dilek
  0 siblings, 1 reply; 26+ messages in thread
From: Arnaud Lacombe @ 2011-07-30 16:08 UTC (permalink / raw)
  To: sedat.dilek; +Cc: Stephen Rothwell, linux-next, LKML, Randy Dunlap

Hi,

On Sat, Jul 30, 2011 at 7:38 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> On Fri, Jul 29, 2011 at 9:38 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> Just in case anyone needs reminding:  Please do not add anything destined
>> for v3.2 into linux-next included trees until after v3.1-rc1.
>>
>> The powerpc allyesconfig and sparc defconfig build (at least) fail today.
>>
>> Changes since 20110728:
>>
>> New tree: moduleh
>>
>
> See all those followup/fixup patches the last day, might be not such a
> good idea to include this tree :-).
In the opposite, that is all the point of including a tree in -next:
give expose to code :)

 - Arnaud

> I wait for next Monday's linux-next.
>
> - Sedat -
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: linux-next: Tree for July 29
  2011-07-30 16:08   ` Arnaud Lacombe
@ 2011-07-30 16:16     ` Sedat Dilek
  0 siblings, 0 replies; 26+ messages in thread
From: Sedat Dilek @ 2011-07-30 16:16 UTC (permalink / raw)
  To: Arnaud Lacombe; +Cc: Stephen Rothwell, linux-next, LKML, Randy Dunlap

On Sat, Jul 30, 2011 at 6:08 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Sat, Jul 30, 2011 at 7:38 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>> On Fri, Jul 29, 2011 at 9:38 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi all,
>>>
>>> Just in case anyone needs reminding:  Please do not add anything destined
>>> for v3.2 into linux-next included trees until after v3.1-rc1.
>>>
>>> The powerpc allyesconfig and sparc defconfig build (at least) fail today.
>>>
>>> Changes since 20110728:
>>>
>>> New tree: moduleh
>>>
>>
>> See all those followup/fixup patches the last day, might be not such a
>> good idea to include this tree :-).
> In the opposite, that is all the point of including a tree in -next:
> give expose to code :)
>

Agreed... and I know about the risks of linux-next (even as a
Debian/sid user) :-).
- Sedat -

>  - Arnaud
>
>> I wait for next Monday's linux-next.
>>
>> - Sedat -
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2011-07-30 16:16 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-29  7:23 linux-next: Tree for July 29 Stephen Rothwell
2008-07-29  7:48 ` Fernando Luis Vázquez Cao
2008-07-29 14:45 ` Dominik Brodowski
2008-08-03 14:56   ` Stephen Rothwell
2008-08-04  7:58     ` Dominik Brodowski
2008-07-29 16:25 ` Bartlomiej Zolnierkiewicz
2008-07-29 18:16   ` Greg KH
2008-07-29 20:49     ` Hugh Dickins
2008-07-30  4:48       ` Greg KH
2008-07-30  7:06         ` Bernhard Walle
2008-07-30  9:19           ` Andrew Morton
2008-07-30 19:27             ` Bartlomiej Zolnierkiewicz
2008-07-30 20:04               ` Andrew Morton
2008-07-30 23:41                 ` Stephen Rothwell
2008-07-30 23:44                   ` Greg KH
2008-08-07  1:08                     ` Stephen Rothwell
2008-08-07  3:40                       ` Greg KH
2008-08-07  6:10                         ` Stephen Rothwell
2008-07-30  1:05   ` linux-next: usb tree fix (Was: Re: linux-next: Tree for July 29) Stephen Rothwell
2008-07-30 19:38     ` Bartlomiej Zolnierkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2009-07-29  7:36 linux-next: Tree for July 29 Stephen Rothwell
2010-07-29  4:32 Stephen Rothwell
2011-07-29  7:38 Stephen Rothwell
2011-07-30 11:38 ` Sedat Dilek
2011-07-30 16:08   ` Arnaud Lacombe
2011-07-30 16:16     ` Sedat Dilek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).