gmane.linux.kernel.next

Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree

Ming Lei — 2013-06-19T15:04:04

OK, I can send you one patch, but I am wondering the patch is against
today's next tree or your driver-core/driver-core-next?

If it is against your driver-core/driver-core-next, would you mind letting
me know how to generate the patch for the conflict?  Sorry for the stupid
question, because I seldom meet such problem, :-(


Thanks,
--
Ming Lei

Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree

Greg KH — 2013-06-19T14:39:18

I'll be pushing your patch for 3.10-final to Linus as it fixes a bug,
but I will need something to resolve the merge issue properly.  Can you
provide me that patch/merge?

thanks,

greg k-h

Re: linux-next: build warning after merge of the final tree (driver-core tree related)

Greg KH — 2013-06-19T14:38:14

Odd.  Ming, can you send me a patch for this?

thanks,

greg k-h

Re: linux-next: manual merge of the akpm tree with the ext4 tree

Theodore Ts'o — 2013-06-19T14:20:31

Is there some way we can avoid this conflict during the next merge
window?  Given that this is an API change, it may not be possible.
Failing that, what's the best merge strategy; should we try to make
sure your change goes first, and then I can defer the ext4 pull
request until a little bit later in the merge window?

Thanks,

- Ted

RE: linux-next: manual merge of the samsung tree with the usb tree

Kukjin Kim — 2013-06-19T11:53:05

Hi,

Looks good to me, thanks.

- Kukjin

Re: linux-next: build failure after merge of the final tree (staging tree related)

Peng Tao — 2013-06-19T09:26:57

Thanks for reporting!

It is a bug in Lustre code that it is missing NIPQUAD definition on
Linux platform. I will send fix later.

Sorry that Lustre is mostly tested only on x86 platform (and sadly I
don't have other architectures to test on.). We sincerely thank you
for your continuous help.

Cheers,
Tao

Re: linux-next: manual merge of the arm-mpidr tree with the armtree

Jonathan Austin — 2013-06-19T08:39:39

Sorry guys, this was my first pull request and I didn't realise that,
though Will was the author, I needed to sign off on the patch too as *I*
had become the committer (I thought that Russell would become the
committer as this was going 'via' him, as it does when it goes through
Russell's patch system).

Apologies. I'll make sure this doesn't happen again...

Jonny

Re: linux-next: manual merge of the arm-mpidr tree with the armtree

Russell King — 2013-06-19T08:26:19

Oh bloody hell.  Now what do I do about that.  The branch is a declared
stable branch, and the commit came in from someone elses tree.  So it's
immutable...

Is there any script around which checks that kind of stuff?

Re: linux-next: build failure after merge of the final tree (mfd tree related)

Samuel Ortiz — 2013-06-19T08:24:57

Hi Stephen,

On Tue, Jun 18, 2013 at 05:19:57PM +1000, Stephen Rothwell wrote:
Sorry about that. This is fixed now.

Cheers,
Samuel.

linux-next: Tree for Jun 19

Stephen Rothwell — 2013-06-19T08:21:15

Hi all,

Changes since 20130618:

The arm-mpidr tree gained a conflict against the arm tree.

The ceph tree gained a conflict against Linus' tree.

The mfd tree lost its build failure.

The block tree gained a conflict against the cgroup tree.

The leds tree still had its build failure, so I used the version from
next-20130607.

The driver-core tree gained a conflict against the driver-core.current
tree.

The staging tree gained a build failure for which I disabled some code.

The imx-mxs tree gained a conflict against the arm-soc tree.

The samsung tree gained a conflict against the usb tree.

The akpm tree gained conflicts against the ext4 and arm-current trees.  It
also lost a few patches that turned up elsewhere.

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

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/next/ ).  If you
are tracking the linux-next tree using gi

linux-next: build failure after merge of the final tree (staging tree related)

Stephen Rothwell — 2013-06-19T08:10:31

Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
                 from drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h:67,
                 from drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:41:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 'kiblnd_dev_need_failover':
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:215:16: error: implicit declaration of function 'NIPQUAD' [-Werror=implicit-function-declaration]
  static struct libcfs_debug_msg_data msgdata;      \
                ^
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:231:2: note: in expansion of macro '__CDEBUG'
  __CDEBUG(&cdls, mask, format, ## __VA_ARGS__);\
  ^
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:238:30: note: in expansion of macro 'CDEBUG_LIMIT'
 #define CERROR(format, ...)  CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)

linux-next: build warning after merge of the final tree (driver-core tree related)

Stephen Rothwell — 2013-06-19T08:00:27

Hi all,

After merging the final tree, today's linux-next build (powerpc
allnoconfig among others) produced these warnings:

drivers/base/firmware_class.c:1254:12: warning: 'cache_firmware' defined but not used [-Wunused-function]
 static int cache_firmware(const char *fw_name)
            ^
drivers/base/firmware_class.c:1281:12: warning: 'uncache_firmware' defined but not used [-Wunused-function]
 static int uncache_firmware(const char *fw_name)
            ^

Revealed by commit 93232e46b209 ("firmware loader: don't export
cache_firmware and uncache_firmware") from the driver-core tree.  These
are only used if CONFIG_PM_SLEEP is set.

Re: linux-next: manual merge of the akpm tree with the ext4 tree

Zheng Liu — 2013-06-19T07:48:55

Hi Stephen,

On Jun 19, 2013, at 3:27 PM, Stephen Rothwell <sfr< at >canb.auug.org.au> wrote:


The patch looks good to me.  Thanks for fixing it.

Regards,
- Zheng

Re: linux-next: manual merge of the akpm tree with the ext4 tree

Stephen Rothwell — 2013-06-19T07:45:59

Hi,

On Wed, 19 Jun 2013 11:44:04 +0400 Glauber Costa <glommer< at >gmail.com> wrote:

Thanks for checking.

Re: linux-next: manual merge of the akpm tree with the ext4 tree

Glauber Costa — 2013-06-19T07:44:04

This comes straight from ext4, so no problem.

Now we just need to make sure that the shrinker is clearly separated
between a count part and a scan part.

The count seems okay.

They are sorting the list, but that doesn't change the ammount of items they report.
So far it is fine. My only concern here would be locking, but it seems to be all
protected by the s_es_lru_lock.

This part also seems fine.


And so does this.

I believe the resolution is okay, at least from our PoV.

linux-next: manual merge of the akpm tree with the arm-current tree

Stephen Rothwell — 2013-06-19T07:38:30

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/arm/kernel/process.c between commit 19ab428f4b79 ("ARM: 7759/1:
decouple CPU offlining from reboot/shutdown") from the  tree and commit
("reboot: move arch/x86 reboot= handling to generic kernel") from the
akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

linux-next: manual merge of the akpm tree with the ext4 tree

Stephen Rothwell — 2013-06-19T07:27:21

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
fs/ext4/extents_status.c between commit 6480bad916be ("ext4: improve
extent cache shrink mechanism to avoid to burn CPU time") from the ext
tree and commit 1f42d0934b4e ("fs: convert fs shrinkers to new scan/count
API") from the akpm tree.

I fixed it up (I am not sure if the result makes complete sense - see
below) and can carry the fix as necessary (no action is required).

Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree

Ming Lei — 2013-06-19T07:21:52

I think it is OK to merge, then I can add the 'more' part about the original
fix(875979368eb4) against today's change.

Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree

Stephen Rothwell — 2013-06-19T07:12:21

Hi Greg,

On Wed, 19 Jun 2013 15:32:25 +1000 Stephen Rothwell <sfr< at >canb.auug.org.au> wrote:

I missed the bit below (at least) and have now added this as a merge fix
for the driver-core tree.

From: Stephen Rothwell <sfr< at >canb.auug.org.au>
Date: Wed, 19 Jun 2013 17:08:01 +1000
Subject: [PATCH] fix up for fw_load_abort API change

Signed-off-by: Stephen Rothwell <sfr< at >canb.auug.org.au>
---
 drivers/base/firmware_class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 57aa842..fdacd77 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
< at >< at > -812,7 +812,7 < at >< at > static void firmware_class_timeout_work(struct work_struct *work)
 struct firmware_priv, timeout_work.work);
 
 mutex_lock(&fw_lock);
-fw_load_abort(fw_priv);
+fw_load_abort(fw_priv->buf);
 mutex_unlock(&fw_lock);
 }

Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree

Ming Lei — 2013-06-19T06:58:39

Hmm, maybe the most important part in the commit 875979368eb4
("firmware loader: fix use-after-free by double abort") has been removed, :-)

In fact, the commit 87597936 is for linus tree only because it is a fix,
so the conflict is caused by merging it with other firmware loader patches
in -next tree.

Greg, I can figure out one patch for -next easily, but it depends you
push it on 3.10-rc or 3.11-rc.


Thanks,
--
Ming Lei

linux-next: manual merge of the samsung tree with the usb tree

Stephen Rothwell — 2013-06-19T06:45:21

Hi Kukjin,

Today's linux-next merge of the samsung tree got a conflict in
drivers/usb/Kconfig between commit d9ea21a77927 ("usb: host: make
USB_ARCH_HAS_?HCI obsolete") from the usb tree and commit 58d5b72088cc
("USB: Check for ARCH_EXYNOS separately") from the samsung tree.

I fixed it up (USB_ARCH_HAS_EHCI is no longer used) and can carry the fix
as necessary (no action is required).