* Re: linux-next: build failure after merge of the net-next tree
From: Jeff Kirsher @ 2016-04-22 23:20 UTC (permalink / raw)
To: Mark Brown, David Miller
Cc: sfr, netdev, linux-next, linux-kernel, mark.d.rustad,
andrewx.bowers, kernel-build-reports, linaro-kernel
In-Reply-To: <20160422092017.GY3217@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote:
> On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote:
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
>
> > > After merging the net-next tree, today's linux-next build (arm
> > > allmodconfig) failed like thisi (this has actually been failing
> for a
> > > few days, now):
>
> > > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko]
> undefined!
>
> > > Caused by commit
>
> > > 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
>
> > > arm only allows udelay()s up to 2 milliseconds. This commit
> > > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.
>
> > Jeff, please have your folks look into this. Probably just a
> simple
> > conversion to mdelay().
>
> This is still present, it's been breaking ARM allmodconfig builds for
> about two weeks now.
Interesting that no one spoke up until just a week ago. I have a fix
and I ready to push it to David Miller.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
From: Yang Shi @ 2016-04-23 3:56 UTC (permalink / raw)
To: tj, mingo, peterz, lizefan
Cc: linux-kernel, linux-next, linaro-kernel, yang.shi
When kernel oops happens in some kernel thread, i.e. kcompactd in the test,
the below bug might be triggered by the oops handler:
BUG: sleeping function called from invalid context at include/linux/sched.h:2858
in_atomic(): 0, irqs_disabled(): 1, pid: 110, name: kcompactd0
CPU: 6 PID: 110 Comm: kcompactd0 Tainted: G D 4.6.0-rc4-next-20160420 #4
Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009
0000000000000000 ffff88036173f9e8 ffffffff8152666f 0000000000000000
ffff880361732680 ffff88036173fa08 ffffffff81088b13 ffffffff81ee3372
0000000000000b2a ffff88036173fa30 ffffffff81088bd9 ffff880361732680
Call Trace:
[<ffffffff8152666f>] dump_stack+0x67/0x98
[<ffffffff81088b13>] ___might_sleep+0x123/0x1a0
[<ffffffff81088bd9>] __might_sleep+0x49/0x80
[<ffffffff810706b4>] exit_signals+0x24/0x130
[<ffffffff81063cc4>] do_exit+0xc4/0xca0
[<ffffffff810201d9>] oops_end+0x89/0xc0
[<ffffffff810518c4>] no_context+0x144/0x390
[<ffffffff81542f17>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff81051c1d>] __bad_area_nosemaphore+0x10d/0x230
[<ffffffff811769e9>] ? free_hot_cold_page_list+0x49/0xd0
[<ffffffff81051d54>] bad_area_nosemaphore+0x14/0x20
[<ffffffff81051f97>] __do_page_fault+0x237/0x570
[<ffffffff810522f9>] do_page_fault+0x29/0x80
[<ffffffff81be7b22>] page_fault+0x22/0x30
[<ffffffff8119d2f8>] ? release_freepages+0x18/0xa0
[<ffffffff8119f13d>] compact_zone+0x55d/0x9f0
[<ffffffff81196239>] ? fragmentation_index+0x19/0x70
[<ffffffff8119f92f>] kcompactd_do_work+0x10f/0x230
[<ffffffff8119fae0>] kcompactd+0x90/0x1e0
[<ffffffff810a3a40>] ? wait_woken+0xa0/0xa0
[<ffffffff8119fa50>] ? kcompactd_do_work+0x230/0x230
[<ffffffff810801ed>] kthread+0xdd/0x100
[<ffffffff81be5ee2>] ret_from_fork+0x22/0x40
[<ffffffff81080110>] ? kthread_create_on_node+0x180/0x180
Since the code path may be called in interrupt disabled context, so
the might_sleep in threadgroup_change_begin() may be triggered.
Before calling exit_signals(), it already checked if it is in hard IRQ handler,
so it sounds safe to reenable interrupt at that point.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
---
kernel/exit.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/kernel/exit.c b/kernel/exit.c
index 9e6e135..c6f8e37 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -679,6 +679,14 @@ void do_exit(long code)
validate_creds_for_do_exit(tsk);
/*
+ * It is possible to get here with interrupt disabled when fault
+ * happens in kernel thread. Enable interrupt to make threadgroup
+ * happy.
+ */
+ if (irqs_disabled())
+ local_irq_enable();
+
+ /*
* We're taking recursive faults here in do_exit. Safest is to just
* leave this task alone and wait for reboot.
*/
--
2.0.2
^ permalink raw reply related
* Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
From: Peter Zijlstra @ 2016-04-23 9:14 UTC (permalink / raw)
To: Yang Shi; +Cc: tj, mingo, lizefan, linux-kernel, linux-next, linaro-kernel
In-Reply-To: <1461383788-15102-1-git-send-email-yang.shi@linaro.org>
On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote:
> When kernel oops happens in some kernel thread, i.e. kcompactd in the test,
> the below bug might be triggered by the oops handler:
What are you trying to fix? You already oopsed the thing is wrecked.
^ permalink raw reply
* Attention
From: Robert William @ 2016-04-23 15:01 UTC (permalink / raw)
To: dan.aragona
We finally sent you the first payment today, due to the restriction, we are limited to send $5,000, therefore, you will be receiving the same on daily basis until we finish sending all $2.5 Million. Below is the information:
Sender's name: Nathan Nussbaum
MTCN # 1594687129
Text question: in god
Answer: we trust
but you can not pick it up because you need to re-activate your payment file therefore, contact office director Mr. Robert William on +22999081119, his email: normalservicer@gmail.com
^ permalink raw reply
* qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Guenter Roeck @ 2016-04-23 17:53 UTC (permalink / raw)
To: linux-next@vger.kernel.org
Cc: Boris Brezillon, Stephen Rothwell, linux-kernel@vger.kernel.org,
Roger Quadros, Brian Norris
Hi,
since next-20160421, I get the following error and hang when trying to boot
an omap2plus_defconfig image with qemu, machine 'beagle' and omap3-beagle.dtb.
multi_v7_defconfig still works, as does machine 'beaglexm' with omap3-beagle-xm.dtb
and omap2plus_defconfig. This is with Linaro's version of qemu.
nand: timeout while waiting for chip to become ready
The message repeats until the test times out.
Bisect points to "Merge remote-tracking branch 'nand/nand/next'" as the offending
commit. However, the nand/nand/next branch itself is fine, as is the merge just
prior to the nand/nand/next merge ("Merge remote-tracking branch 'l2-mtd/master'").
After some digging, I found that reverting commit "mtd: nand: omap2: Implement
NAND ready using gpiolib" fixes the problem. What I don't know, though, is why
the problem is only seen with omap2plus_defconfig, but not with multi_v7_defconfig,
and why it is only seen with beagle/omap3-beagle.dtb but not with
beaglexm/omap3-beagle-xm.dtb.
The 'rb-gpios' property is only defined in omap3-beagle.dts, but not in
omap3-beagle-xm.dts, which may be part of the explanation. That still doesn't
explain, though, why multi_v7_defconfig still works, but not omap2plus_defconfig.
Any ideas, anyone ?
Thanks,
Guenter
^ permalink raw reply
* [PATCH] scripts/decode_stacktrace.sh: handle symbols in modules
From: Konstantin Khlebnikov @ 2016-04-23 19:03 UTC (permalink / raw)
To: Sasha Levin, Andrew Morton, linux-next, linux-kernel
Add third argument: path where script looks for file module.ko when
decode module symbol "func+0x0ff/0x5153 [module]" into something like
"func (foo/bar.c:123) module". Without argument or if file isn't found
script prints such symbols as is without decoding.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
---
scripts/decode_stacktrace.sh | 55 ++++++++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index 00d6d53c2681..c332684e1b5a 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -2,15 +2,17 @@
# (c) 2014, Sasha Levin <sasha.levin@oracle.com>
#set -x
-if [[ $# != 2 ]]; then
+if [[ $# < 2 ]]; then
echo "Usage:"
- echo " $0 [vmlinux] [base path]"
+ echo " $0 [vmlinux] [base path] [modules path]"
exit 1
fi
vmlinux=$1
basepath=$2
+modpath=$3
declare -A cache
+declare -A modcache
parse_symbol() {
# The structure of symbol at this point is:
@@ -19,6 +21,17 @@ parse_symbol() {
# For example:
# do_basic_setup+0x9c/0xbf
+ if [[ $module == "" ]] ; then
+ local objfile=$vmlinux
+ elif [[ "${modcache[$module]+isset}" == "isset" ]]; then
+ local objfile=${modcache[$module]}
+ else
+ [[ $modpath == "" ]] && return
+ local objfile=$(find "$modpath" -name $module.ko -print -quit)
+ [[ $objfile == "" ]] && return
+ modcache[$module]=$objfile
+ fi
+
# Remove the englobing parenthesis
symbol=${symbol#\(}
symbol=${symbol%\)}
@@ -29,11 +42,11 @@ parse_symbol() {
# Use 'nm vmlinux' to figure out the base address of said symbol.
# It's actually faster to call it every time than to load it
# all into bash.
- if [[ "${cache[$name]+isset}" == "isset" ]]; then
- local base_addr=${cache[$name]}
+ if [[ "${cache[$module,$name]+isset}" == "isset" ]]; then
+ local base_addr=${cache[$module,$name]}
else
- local base_addr=$(nm "$vmlinux" | grep -i ' t ' | awk "/ $name\$/ {print \$1}" | head -n1)
- cache["$name"]="$base_addr"
+ local base_addr=$(nm "$objfile" | grep -i ' t ' | awk "/ $name\$/ {print \$1}" | head -n1)
+ cache[$module,$name]="$base_addr"
fi
# Let's start doing the math to get the exact address into the
# symbol. First, strip out the symbol total length.
@@ -48,12 +61,12 @@ parse_symbol() {
local address=$(printf "%x\n" "$expr")
# Pass it to addr2line to get filename and line number
- # Could get more than one result
- if [[ "${cache[$address]+isset}" == "isset" ]]; then
- local code=${cache[$address]}
+ # Could get more than one result
+ if [[ "${cache[$module,$address]+isset}" == "isset" ]]; then
+ local code=${cache[$module,$address]}
else
- local code=$(addr2line -i -e "$vmlinux" "$address")
- cache[$address]=$code
+ local code=$(addr2line -i -e "$objfile" "$address")
+ cache[$module,$address]=$code
fi
# addr2line doesn't return a proper error code if it fails, so
@@ -105,13 +118,23 @@ handle_line() {
fi
done
- # The symbol is the last element, process it
- symbol=${words[$last]}
+ if [[ ${words[$last]} =~ \[([^]]+)\] ]]; then
+ module=${words[$last]}
+ module=${module#\[}
+ module=${module%\]}
+ symbol=${words[$last-1]}
+ unset words[$last-1]
+ else
+ # The symbol is the last element, process it
+ symbol=${words[$last]}
+ module=
+ fi
+
unset words[$last]
parse_symbol # modifies $symbol
# Add up the line number to the symbol
- echo "${words[@]}" "$symbol"
+ echo "${words[@]}" "$symbol $module"
}
while read line; do
@@ -121,8 +144,8 @@ while read line; do
handle_line "$line"
# Is it a code line?
elif [[ $line == *Code:* ]]; then
- decode_code "$line"
- else
+ decode_code "$line"
+ else
# Nothing special in this line, show it as is
echo "$line"
fi
^ permalink raw reply related
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Boris Brezillon @ 2016-04-23 19:46 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Roger Quadros, Brian Norris,
Tony Lindgren, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <571BB682.1010806@roeck-us.net>
Hi Guenter,
On Sat, 23 Apr 2016 10:53:06 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> Hi,
>
> since next-20160421, I get the following error and hang when trying to boot
> an omap2plus_defconfig image with qemu, machine 'beagle' and omap3-beagle.dtb.
> multi_v7_defconfig still works, as does machine 'beaglexm' with omap3-beagle-xm.dtb
> and omap2plus_defconfig. This is with Linaro's version of qemu.
>
> nand: timeout while waiting for chip to become ready
>
> The message repeats until the test times out.
>
> Bisect points to "Merge remote-tracking branch 'nand/nand/next'" as the offending
> commit. However, the nand/nand/next branch itself is fine, as is the merge just
> prior to the nand/nand/next merge ("Merge remote-tracking branch 'l2-mtd/master'").
>
> After some digging, I found that reverting commit "mtd: nand: omap2: Implement
> NAND ready using gpiolib" fixes the problem. What I don't know, though, is why
> the problem is only seen with omap2plus_defconfig, but not with multi_v7_defconfig,
> and why it is only seen with beagle/omap3-beagle.dtb but not with
> beaglexm/omap3-beagle-xm.dtb.
>
> The 'rb-gpios' property is only defined in omap3-beagle.dts, but not in
> omap3-beagle-xm.dts, which may be part of the explanation. That still doesn't
> explain, though, why multi_v7_defconfig still works, but not omap2plus_defconfig.
>
> Any ideas, anyone ?
I think you got it right for the DT changes: if rb-gpios is not
defined, it's working because the implementation fallback to "status
polling" mode, which is not relying on the new GPIO controller
implementation.
I don't know why it's working when using multi_v7_defconfig and not
with omap2_plus though (maybe a different probe order making
devm_gpiod_get_optional() return NULL instead of EPROBE_DEFER?).
And the other question I have for Roger is, do you see a reason why the
rb-gpio mode would not work?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Guenter Roeck @ 2016-04-24 16:42 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Roger Quadros, Brian Norris,
Tony Lindgren, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <20160423214617.4d0905d2@bbrezillon>
On 04/23/2016 12:46 PM, Boris Brezillon wrote:
> Hi Guenter,
>
> On Sat, 23 Apr 2016 10:53:06 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
>
>> Hi,
>>
>> since next-20160421, I get the following error and hang when trying to boot
>> an omap2plus_defconfig image with qemu, machine 'beagle' and omap3-beagle.dtb.
>> multi_v7_defconfig still works, as does machine 'beaglexm' with omap3-beagle-xm.dtb
>> and omap2plus_defconfig. This is with Linaro's version of qemu.
>>
>> nand: timeout while waiting for chip to become ready
>>
>> The message repeats until the test times out.
>>
>> Bisect points to "Merge remote-tracking branch 'nand/nand/next'" as the offending
>> commit. However, the nand/nand/next branch itself is fine, as is the merge just
>> prior to the nand/nand/next merge ("Merge remote-tracking branch 'l2-mtd/master'").
>>
>> After some digging, I found that reverting commit "mtd: nand: omap2: Implement
>> NAND ready using gpiolib" fixes the problem. What I don't know, though, is why
>> the problem is only seen with omap2plus_defconfig, but not with multi_v7_defconfig,
>> and why it is only seen with beagle/omap3-beagle.dtb but not with
>> beaglexm/omap3-beagle-xm.dtb.
>>
>> The 'rb-gpios' property is only defined in omap3-beagle.dts, but not in
>> omap3-beagle-xm.dts, which may be part of the explanation. That still doesn't
>> explain, though, why multi_v7_defconfig still works, but not omap2plus_defconfig.
>>
>> Any ideas, anyone ?
>
> I think you got it right for the DT changes: if rb-gpios is not
> defined, it's working because the implementation fallback to "status
> polling" mode, which is not relying on the new GPIO controller
> implementation.
> I don't know why it's working when using multi_v7_defconfig and not
> with omap2_plus though (maybe a different probe order making
> devm_gpiod_get_optional() return NULL instead of EPROBE_DEFER?).
>
> And the other question I have for Roger is, do you see a reason why the
> rb-gpio mode would not work?
>
Hi Boris,
Turns out MTD_NAND_OMAP2 is not enabled on multi_v7_defconfig, thus the issue
does not arise there. After reverting 'mtd: nand: omap2: Implement NAND ready
using gpiolib', the driver uses omap_wait(), which as far as I can see is never
called in my tests. Since dev_ready is NULL in that case, it is never called
either (the chip is just assumed to be always ready), and thus the problem
does not arise.
So the big difference is that the dev_info callback was not used prior to
commit 'mtd: nand: omap2: Implement NAND ready using gpiolib', and that
it is logically different to the wait function which was previously used.
In qemu, it looks like gpmc bit 0 is considered to be the NAND chip select,
which is distinctly different to a chip ready pin. Guess I would have to try
finding a chip datasheet to figure out what this pin is supposed to do, and
what is wrong. Since it is somewhat unlikely that I'll find the time to do that,
I just disabled MTD_NAND_OMAP2 in my qemu tests instead. Not an ideal solution,
of course, but the alternative would be to drop the beagle qemu tests entirely.
Guenter
^ permalink raw reply
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Boris Brezillon @ 2016-04-24 17:14 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Roger Quadros, Brian Norris,
Tony Lindgren, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <571CF780.1080308@roeck-us.net>
On Sun, 24 Apr 2016 09:42:40 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> On 04/23/2016 12:46 PM, Boris Brezillon wrote:
> > Hi Guenter,
> >
> > On Sat, 23 Apr 2016 10:53:06 -0700
> > Guenter Roeck <linux@roeck-us.net> wrote:
> >
> >> Hi,
> >>
> >> since next-20160421, I get the following error and hang when trying to boot
> >> an omap2plus_defconfig image with qemu, machine 'beagle' and omap3-beagle.dtb.
> >> multi_v7_defconfig still works, as does machine 'beaglexm' with omap3-beagle-xm.dtb
> >> and omap2plus_defconfig. This is with Linaro's version of qemu.
> >>
> >> nand: timeout while waiting for chip to become ready
> >>
> >> The message repeats until the test times out.
> >>
> >> Bisect points to "Merge remote-tracking branch 'nand/nand/next'" as the offending
> >> commit. However, the nand/nand/next branch itself is fine, as is the merge just
> >> prior to the nand/nand/next merge ("Merge remote-tracking branch 'l2-mtd/master'").
> >>
> >> After some digging, I found that reverting commit "mtd: nand: omap2: Implement
> >> NAND ready using gpiolib" fixes the problem. What I don't know, though, is why
> >> the problem is only seen with omap2plus_defconfig, but not with multi_v7_defconfig,
> >> and why it is only seen with beagle/omap3-beagle.dtb but not with
> >> beaglexm/omap3-beagle-xm.dtb.
> >>
> >> The 'rb-gpios' property is only defined in omap3-beagle.dts, but not in
> >> omap3-beagle-xm.dts, which may be part of the explanation. That still doesn't
> >> explain, though, why multi_v7_defconfig still works, but not omap2plus_defconfig.
> >>
> >> Any ideas, anyone ?
> >
> > I think you got it right for the DT changes: if rb-gpios is not
> > defined, it's working because the implementation fallback to "status
> > polling" mode, which is not relying on the new GPIO controller
> > implementation.
> > I don't know why it's working when using multi_v7_defconfig and not
> > with omap2_plus though (maybe a different probe order making
> > devm_gpiod_get_optional() return NULL instead of EPROBE_DEFER?).
> >
> > And the other question I have for Roger is, do you see a reason why the
> > rb-gpio mode would not work?
> >
>
> Hi Boris,
>
> Turns out MTD_NAND_OMAP2 is not enabled on multi_v7_defconfig, thus the issue
> does not arise there.
Okay, this explains why you don't see this problem with multi_v7.
> After reverting 'mtd: nand: omap2: Implement NAND ready
> using gpiolib', the driver uses omap_wait(), which as far as I can see is never
> called in my tests. Since dev_ready is NULL in that case, it is never called
> either (the chip is just assumed to be always ready), and thus the problem
> does not arise.
That's not entirely true: the NAND chip is not assumed to be always
ready, the core just uses a different method to get the R/B status (by
reading the STATUS register using the NAND_CMD_STATUS command). But
you're right in that when you revert this commit you end up not using
the new GPIO controller exposed by the GPMC driver.
>
> So the big difference is that the dev_info callback was not used prior to
> commit 'mtd: nand: omap2: Implement NAND ready using gpiolib', and that
> it is logically different to the wait function which was previously used.
Yes.
>
> In qemu, it looks like gpmc bit 0 is considered to be the NAND chip select,
> which is distinctly different to a chip ready pin.
Well, if you look at the GPIO controller implementation, you'll see
that gpichip->get() is adding 8 to the GPIO index, so the
implementation is actually testing bit 8 and not bit 0. Maybe this is
not emulated properly in qemu though...
> Guess I would have to try
> finding a chip datasheet to figure out what this pin is supposed to do, and
> what is wrong. Since it is somewhat unlikely that I'll find the time to do that,
> I just disabled MTD_NAND_OMAP2 in my qemu tests instead. Not an ideal solution,
> of course, but the alternative would be to drop the beagle qemu tests entirely.
Long time I haven't looked at qemu code, but IIRC there were no proper
support for the NAND layer (maybe this has changed since then though).
And the R/B pin status emulation is probably much more complicated to
implement than just returning a valid STATUS byte in a generic NAND chip
emulation layer (you have to emulate the GPMC block and all its
external interfaces like the R/B IOs as well as the R/B pin
emulation at the NAND chip emulation level)...
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Boris Brezillon @ 2016-04-24 17:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Roger Quadros, Brian Norris,
Tony Lindgren, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <571CF780.1080308@roeck-us.net>
On Sun, 24 Apr 2016 09:42:40 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> In qemu, it looks like gpmc bit 0 is considered to be the NAND chip select,
> which is distinctly different to a chip ready pin. Guess I would have to try
> finding a chip datasheet to figure out what this pin is supposed to do, and
> what is wrong. Since it is somewhat unlikely that I'll find the time to do that,
> I just disabled MTD_NAND_OMAP2 in my qemu tests instead. Not an ideal solution,
> of course, but the alternative would be to drop the beagle qemu tests entirely.
Here is a patch [1] which should fix your problem. It's obviously not
enough to handle the different use cases we have in in the wild, but
should fix your problem on the beagle board.
Regards,
Boris
[1]http://code.bulix.org/i5c4yc-97598
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Guenter Roeck @ 2016-04-24 18:10 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Roger Quadros, Brian Norris,
Tony Lindgren, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <20160424191429.48880fdd@bbrezillon>
Hi Boris,
On 04/24/2016 10:14 AM, Boris Brezillon wrote:
[ ... ]
>>
>> In qemu, it looks like gpmc bit 0 is considered to be the NAND chip select,
>> which is distinctly different to a chip ready pin.
>
> Well, if you look at the GPIO controller implementation, you'll see
> that gpichip->get() is adding 8 to the GPIO index, so the
> implementation is actually testing bit 8 and not bit 0. Maybe this is
> not emulated properly in qemu though...
>
That helps. The QEMU emulation always returns 0x0001 when reading gpmc register
0x54, which suggests that WAIT0STATUS reports as 0.
>> Guess I would have to try
>> finding a chip datasheet to figure out what this pin is supposed to do, and
>> what is wrong. Since it is somewhat unlikely that I'll find the time to do that,
>> I just disabled MTD_NAND_OMAP2 in my qemu tests instead. Not an ideal solution,
>> of course, but the alternative would be to drop the beagle qemu tests entirely.
>
> Long time I haven't looked at qemu code, but IIRC there were no proper
> support for the NAND layer (maybe this has changed since then though).
> And the R/B pin status emulation is probably much more complicated to
> implement than just returning a valid STATUS byte in a generic NAND chip
> emulation layer (you have to emulate the GPMC block and all its
> external interfaces like the R/B IOs as well as the R/B pin
> emulation at the NAND chip emulation level)...
>
Well enough for it to at least find the NAND chip.
So the qemu "fix" was to return 0x0101 instead of 0x0001 when reading gpmc
register 0x54.
Now I get "INFO: suspicious RCU usage" on reboot, but that is a separate issue.
Thanks a lot for the hints!
Guenter
^ permalink raw reply
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Guenter Roeck @ 2016-04-24 18:11 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Roger Quadros, Brian Norris,
Tony Lindgren, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org
In-Reply-To: <20160424193414.2bc82d47@bbrezillon>
On 04/24/2016 10:34 AM, Boris Brezillon wrote:
> On Sun, 24 Apr 2016 09:42:40 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
>
>> In qemu, it looks like gpmc bit 0 is considered to be the NAND chip select,
>> which is distinctly different to a chip ready pin. Guess I would have to try
>> finding a chip datasheet to figure out what this pin is supposed to do, and
>> what is wrong. Since it is somewhat unlikely that I'll find the time to do that,
>> I just disabled MTD_NAND_OMAP2 in my qemu tests instead. Not an ideal solution,
>> of course, but the alternative would be to drop the beagle qemu tests entirely.
>
> Here is a patch [1] which should fix your problem. It's obviously not
> enough to handle the different use cases we have in in the wild, but
> should fix your problem on the beagle board.
>
> Regards,
>
> Boris
>
> [1]http://code.bulix.org/i5c4yc-97598
>
Yep, I figured out that one a minute ago :-)
Thanks again!
Guenter
^ permalink raw reply
* Re: qemu:beagle no longer booting with omap2plus_defconfig in -next
From: Boris Brezillon @ 2016-04-24 19:28 UTC (permalink / raw)
To: Guenter Roeck, Roger Quadros
Cc: linux-next@vger.kernel.org, Stephen Rothwell,
linux-kernel@vger.kernel.org, Brian Norris, Tony Lindgren,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <20160423214617.4d0905d2@bbrezillon>
On Sat, 23 Apr 2016 21:46:17 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>
> And the other question I have for Roger is, do you see a reason why the
> rb-gpio mode would not work?
>
Forget that one, this bug appeared to be caused by partial emulation of
the GPMC block in qemu.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Mark Brown @ 2016-04-24 22:59 UTC (permalink / raw)
To: Jeff Kirsher
Cc: David Miller, sfr, netdev, linux-next, linux-kernel,
mark.d.rustad, andrewx.bowers, kernel-build-reports,
linaro-kernel
In-Reply-To: <1461367243.3018.42.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
On Fri, Apr 22, 2016 at 04:20:43PM -0700, Jeff Kirsher wrote:
> On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote:
> > > Jeff, please have your folks look into this. Probably just a
> > simple
> > > conversion to mdelay().
> > This is still present, it's been breaking ARM allmodconfig builds for
> > about two weeks now.
> Interesting that no one spoke up until just a week ago. I have a fix
> and I ready to push it to David Miller.
Like Stephen said it had been there for a couple of days already at the
time it was reported; I happened to be busy at the time it came up so
wasn't looking at the build reports myself. If you've got a fix please
get it submitted ASAP, having common test configurations broken for any
length of time does get disruptive.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
From: Shi, Yang @ 2016-04-25 17:35 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tj, mingo, lizefan, linux-kernel, linux-next, linaro-kernel
In-Reply-To: <20160423091447.GA3430@twins.programming.kicks-ass.net>
On 4/23/2016 2:14 AM, Peter Zijlstra wrote:
> On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote:
>> When kernel oops happens in some kernel thread, i.e. kcompactd in the test,
>> the below bug might be triggered by the oops handler:
>
> What are you trying to fix? You already oopsed the thing is wrecked.
Actually, I ran into the below kernel BUG:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff8119d2f8>] release_freepages+0x18/0xa0
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 6 PID: 110 Comm: kcompactd0 Not tainted 4.6.0-rc4-next-20160420 #4
Hardware name: Intel Corporation S5520HC/S5520HC, BIOS
S5500.86B.01.10.0025.030220091519 03/02/2009
task: ffff880361732680 ti: ffff88036173c000 task.ti: ffff88036173c000
RIP: 0010:[<ffffffff8119d2f8>] [<ffffffff8119d2f8>]
release_freepages+0x18/0xa0
RSP: 0018:ffff88036173fcf8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88036ffde7c0 RCX: 0000000000000009
RDX: 0000000000001bf1 RSI: 000000000000000f RDI: ffff88036173fdd0
RBP: ffff88036173fd20 R08: 0000000000000007 R09: 0000160000000000
R10: ffff88036ffde7c0 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88036173fdd0 R14: ffff88036173fdc0 R15: ffff88036173fdb0
FS: 0000000000000000(0000) GS:ffff880363cc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000002206000 CR4: 00000000000006e0
Stack:
ffff88036ffde7c0 0000000000000000 0000000000001a00 ffff88036173fdc0
ffff88036173fdb0 ffff88036173fda0 ffffffff8119f13d ffffffff81196239
0000000000000000 ffff880361732680 0000000000000001 0000000000100000
Call Trace:
[<ffffffff8119f13d>] compact_zone+0x55d/0x9f0
[<ffffffff81196239>] ? fragmentation_index+0x19/0x70
[<ffffffff8119f92f>] kcompactd_do_work+0x10f/0x230
[<ffffffff8119fae0>] kcompactd+0x90/0x1e0
[<ffffffff810a3a40>] ? wait_woken+0xa0/0xa0
[<ffffffff8119fa50>] ? kcompactd_do_work+0x230/0x230
[<ffffffff810801ed>] kthread+0xdd/0x100
[<ffffffff81be5ee2>] ret_from_fork+0x22/0x40
[<ffffffff81080110>] ? kthread_create_on_node+0x180/0x180
Code: c1 fa 06 31 f6 e8 a9 9b fd ff eb 98 0f 1f 80 00 00 00 00 66 66 66
66 90 55 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 8b 07 <48> 8b
10 48 8d 78 e0 49 39 c5 4c 8d 62 e0 74 70 49 be 00 00 00
RIP [<ffffffff8119d2f8>] release_freepages+0x18/0xa0
RSP <ffff88036173fcf8>
CR2: 0000000000000000
---[ end trace 2e96d09e0ba6342f ]---
Then the "schedule in atomic context" bug is triggered which cause the
system hang. But, the system is still alive without the "schedule in
atomic context" bug. The previous null pointer deference issue doesn't
bring the system down other than killing the compactd kthread.
Thanks,
Yang
>
^ permalink raw reply
* Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
From: Shi, Yang @ 2016-04-25 21:43 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tj, mingo, lizefan, linux-kernel, linux-next, linaro-kernel
In-Reply-To: <571E5571.7050106@linaro.org>
On 4/25/2016 10:35 AM, Shi, Yang wrote:
> On 4/23/2016 2:14 AM, Peter Zijlstra wrote:
>> On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote:
>>> When kernel oops happens in some kernel thread, i.e. kcompactd in the
>>> test,
>>> the below bug might be triggered by the oops handler:
>>
>> What are you trying to fix? You already oopsed the thing is wrecked.
>
> Actually, I ran into the below kernel BUG:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff8119d2f8>] release_freepages+0x18/0xa0
> PGD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 6 PID: 110 Comm: kcompactd0 Not tainted 4.6.0-rc4-next-20160420 #4
> Hardware name: Intel Corporation S5520HC/S5520HC, BIOS
> S5500.86B.01.10.0025.030220091519 03/02/2009
> task: ffff880361732680 ti: ffff88036173c000 task.ti: ffff88036173c000
> RIP: 0010:[<ffffffff8119d2f8>] [<ffffffff8119d2f8>]
> release_freepages+0x18/0xa0
> RSP: 0018:ffff88036173fcf8 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: ffff88036ffde7c0 RCX: 0000000000000009
> RDX: 0000000000001bf1 RSI: 000000000000000f RDI: ffff88036173fdd0
> RBP: ffff88036173fd20 R08: 0000000000000007 R09: 0000160000000000
> R10: ffff88036ffde7c0 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff88036173fdd0 R14: ffff88036173fdc0 R15: ffff88036173fdb0
> FS: 0000000000000000(0000) GS:ffff880363cc0000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000002206000 CR4: 00000000000006e0
> Stack:
> ffff88036ffde7c0 0000000000000000 0000000000001a00 ffff88036173fdc0
> ffff88036173fdb0 ffff88036173fda0 ffffffff8119f13d ffffffff81196239
> 0000000000000000 ffff880361732680 0000000000000001 0000000000100000
> Call Trace:
> [<ffffffff8119f13d>] compact_zone+0x55d/0x9f0
> [<ffffffff81196239>] ? fragmentation_index+0x19/0x70
> [<ffffffff8119f92f>] kcompactd_do_work+0x10f/0x230
> [<ffffffff8119fae0>] kcompactd+0x90/0x1e0
> [<ffffffff810a3a40>] ? wait_woken+0xa0/0xa0
> [<ffffffff8119fa50>] ? kcompactd_do_work+0x230/0x230
> [<ffffffff810801ed>] kthread+0xdd/0x100
> [<ffffffff81be5ee2>] ret_from_fork+0x22/0x40
> [<ffffffff81080110>] ? kthread_create_on_node+0x180/0x180
> Code: c1 fa 06 31 f6 e8 a9 9b fd ff eb 98 0f 1f 80 00 00 00 00 66 66 66
> 66 90 55 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 8b 07 <48> 8b
> 10 48 8d 78 e0 49 39 c5 4c 8d 62 e0 74 70 49 be 00 00 00
> RIP [<ffffffff8119d2f8>] release_freepages+0x18/0xa0
> RSP <ffff88036173fcf8>
> CR2: 0000000000000000
> ---[ end trace 2e96d09e0ba6342f ]---
>
> Then the "schedule in atomic context" bug is triggered which cause the
> system hang. But, the system is still alive without the "schedule in
> atomic context" bug. The previous null pointer deference issue doesn't
> bring the system down other than killing the compactd kthread.
BTW, I don't have "panic on oops" set. So, the kernel doesn't panic.
Thanks,
Yang
>
> Thanks,
> Yang
>
>>
>
^ permalink raw reply
* linux-next: build failure after merge of the arm-soc tree
From: Stephen Rothwell @ 2016-04-25 23:43 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Linus Walleij
Hi all,
After merging the arm-soc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "of_flash_probe_versatile" [drivers/mtd/maps/physmap_of.ko] undefined!
Caused by commit
b0afd44bc192 ("mtd: physmap_of: add a hook for Versatile write protection")
I used the arm-soc tree from next-20160422 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the arm-soc tree
From: Arnd Bergmann @ 2016-04-25 23:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Stephen Rothwell, Olof Johansson, Linus Walleij, linux-next,
linux-kernel
In-Reply-To: <20160426094331.64032731@canb.auug.org.au>
On Tuesday 26 April 2016 09:43:31 Stephen Rothwell wrote:
> Hi all,
>
> After merging the arm-soc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "of_flash_probe_versatile" [drivers/mtd/maps/physmap_of.ko] undefined!
>
> Caused by commit
>
> b0afd44bc192 ("mtd: physmap_of: add a hook for Versatile write protection")
>
> I used the arm-soc tree from next-20160422 for today.
>
Ah, sorry about that. I think I fixed it up just as you pulled it in.
If you don't mind, could you try pulling the tree once more on top
of what you have?
Arnd
^ permalink raw reply
* Re: linux-next: build failure after merge of the arm-soc tree
From: Stephen Rothwell @ 2016-04-26 0:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Olof Johansson, Linus Walleij, linux-next,
linux-kernel
In-Reply-To: <8018210.3MZgHs9g7Q@wuerfel>
Hi Arnd,
On Tue, 26 Apr 2016 01:54:20 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> Ah, sorry about that. I think I fixed it up just as you pulled it in.
> If you don't mind, could you try pulling the tree once more on top
> of what you have?
Sorry, but I need to keep going if I am to finish each day. I will
fetch it for tomorrow, though. If I finish early enough, I will see if
I can fetch and merge it at the end ...
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the pci tree
From: Stephen Rothwell @ 2016-04-26 1:13 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-next, linux-kernel, Jacek Lawrynowicz, Joerg Roedel
Hi Bjorn,
After merging the pci tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/iommu/amd_iommu.c: In function 'get_alias':
drivers/iommu/amd_iommu.c:266:22: error: 'PCI_DEV_FLAGS_DMA_ALIAS_DEVFN' undeclared (first use in this function)
pdev->dev_flags |= PCI_DEV_FLAGS_DMA_ALIAS_DEVFN;
^
drivers/iommu/amd_iommu.c:266:22: note: each undeclared identifier is reported only once for each function it appears in
drivers/iommu/amd_iommu.c:267:7: error: 'struct pci_dev' has no member named 'dma_alias_devfn'
pdev->dma_alias_devfn = ivrs_alias & 0xff;
^
Caused by commit
338c3149a221 ("PCI: Add support for multiple DMA aliases")
interacting with commit
e3156048346c ("iommu/amd: Fix checking of pci dma aliases")
from Linus' tree (added before v4.6-rc5).
I added the following merge fix patch (which makes it build, but may need
more work):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 26 Apr 2016 11:07:25 +1000
Subject: [PATCH] iommu/amd: fix up for aliases API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/iommu/amd_iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 5efadad4615b..3839fd2865a6 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -263,8 +263,7 @@ static u16 get_alias(struct device *dev)
*/
if (pci_alias == devid &&
PCI_BUS_NUM(ivrs_alias) == pdev->bus->number) {
- pdev->dev_flags |= PCI_DEV_FLAGS_DMA_ALIAS_DEVFN;
- pdev->dma_alias_devfn = ivrs_alias & 0xff;
+ pci_add_dma_alias(pdev, ivrs_alias & 0xff);
pr_info("AMD-Vi: Added PCI DMA alias %02x.%d for %s\n",
PCI_SLOT(ivrs_alias), PCI_FUNC(ivrs_alias),
dev_name(dev));
--
2.7.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* linux-next: manual merge of the pm tree with the renesas tree
From: Stephen Rothwell @ 2016-04-26 1:52 UTC (permalink / raw)
To: Rafael J. Wysocki, Simon Horman
Cc: linux-next, linux-kernel, Geert Uytterhoeven, Viresh Kumar
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in:
arch/arm/mach-shmobile/Makefile
between commit:
be32bcbbd182 ("soc: renesas: Move pm-rcar to drivers/soc/renesas/rcar-sysc")
from the renesas tree and commit:
a399dc9fc500 ("cpufreq: shmobile: Use generic platdev driver")
from the pm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-shmobile/Makefile
index ebb909c55b85,c9ea0e6ff4f9..000000000000
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@@ -38,7 -38,7 +38,6 @@@ smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.
# PM objects
obj-$(CONFIG_SUSPEND) += suspend.o
- obj-$(CONFIG_CPU_FREQ) += cpufreq.o
-obj-$(CONFIG_PM_RCAR) += pm-rcar.o
obj-$(CONFIG_PM_RMOBILE) += pm-rmobile.o
obj-$(CONFIG_ARCH_RCAR_GEN2) += pm-rcar-gen2.o
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-04-26 2:18 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Konstantin Khlebnikov
Hi all,
Today's linux-next merge of the net-next tree got conflicts in:
include/linux/ipv6.h
net/ipv6/addrconf.c
between commit:
841645b5f2df ("ipv6: Revert optional address flusing on ifdown.")
from the net tree and commits:
607ea7cda631 ("net/ipv6/addrconf: simplify sysctl registration")
5df1f77f65e1 ("net/ipv6/addrconf: fix sysctl table indentation")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/ipv6.h
index 4b2267e1b7c3,58d6e158755f..000000000000
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@@ -62,7 -62,9 +62,8 @@@ struct ipv6_devconf
struct in6_addr secret;
} stable_secret;
__s32 use_oif_addrs_only;
- void *sysctl;
- __s32 keep_addr_on_down;
+
+ struct ctl_table_header *sysctl_header;
};
struct ipv6_params {
diff --cc net/ipv6/addrconf.c
index d77ba395d593,f5a77a9dd34e..000000000000
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@@ -5506,323 -5637,322 +5507,314 @@@ int addrconf_sysctl_ignore_routes_with_
return ret;
}
- static struct addrconf_sysctl_table
- {
- struct ctl_table_header *sysctl_header;
- struct ctl_table addrconf_vars[DEVCONF_MAX+1];
- } addrconf_sysctl __read_mostly = {
- .sysctl_header = NULL,
- .addrconf_vars = {
- {
- .procname = "forwarding",
- .data = &ipv6_devconf.forwarding,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = addrconf_sysctl_forward,
- },
- {
- .procname = "hop_limit",
- .data = &ipv6_devconf.hop_limit,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = addrconf_sysctl_hop_limit,
- },
- {
- .procname = "mtu",
- .data = &ipv6_devconf.mtu6,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = addrconf_sysctl_mtu,
- },
- {
- .procname = "accept_ra",
- .data = &ipv6_devconf.accept_ra,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "accept_redirects",
- .data = &ipv6_devconf.accept_redirects,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "autoconf",
- .data = &ipv6_devconf.autoconf,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "dad_transmits",
- .data = &ipv6_devconf.dad_transmits,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "router_solicitations",
- .data = &ipv6_devconf.rtr_solicits,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "router_solicitation_interval",
- .data = &ipv6_devconf.rtr_solicit_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
- },
- {
- .procname = "router_solicitation_delay",
- .data = &ipv6_devconf.rtr_solicit_delay,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
- },
- {
- .procname = "force_mld_version",
- .data = &ipv6_devconf.force_mld_version,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "mldv1_unsolicited_report_interval",
- .data =
- &ipv6_devconf.mldv1_unsolicited_report_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_ms_jiffies,
- },
- {
- .procname = "mldv2_unsolicited_report_interval",
- .data =
- &ipv6_devconf.mldv2_unsolicited_report_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_ms_jiffies,
- },
- {
- .procname = "use_tempaddr",
- .data = &ipv6_devconf.use_tempaddr,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "temp_valid_lft",
- .data = &ipv6_devconf.temp_valid_lft,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "temp_prefered_lft",
- .data = &ipv6_devconf.temp_prefered_lft,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "regen_max_retry",
- .data = &ipv6_devconf.regen_max_retry,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "max_desync_factor",
- .data = &ipv6_devconf.max_desync_factor,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "max_addresses",
- .data = &ipv6_devconf.max_addresses,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "accept_ra_defrtr",
- .data = &ipv6_devconf.accept_ra_defrtr,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "accept_ra_min_hop_limit",
- .data = &ipv6_devconf.accept_ra_min_hop_limit,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "accept_ra_pinfo",
- .data = &ipv6_devconf.accept_ra_pinfo,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
+ static const struct ctl_table addrconf_sysctl[] = {
+ {
+ .procname = "forwarding",
+ .data = &ipv6_devconf.forwarding,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = addrconf_sysctl_forward,
+ },
+ {
+ .procname = "hop_limit",
+ .data = &ipv6_devconf.hop_limit,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = addrconf_sysctl_hop_limit,
+ },
+ {
+ .procname = "mtu",
+ .data = &ipv6_devconf.mtu6,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = addrconf_sysctl_mtu,
+ },
+ {
+ .procname = "accept_ra",
+ .data = &ipv6_devconf.accept_ra,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "accept_redirects",
+ .data = &ipv6_devconf.accept_redirects,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "autoconf",
+ .data = &ipv6_devconf.autoconf,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "dad_transmits",
+ .data = &ipv6_devconf.dad_transmits,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "router_solicitations",
+ .data = &ipv6_devconf.rtr_solicits,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "router_solicitation_interval",
+ .data = &ipv6_devconf.rtr_solicit_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_jiffies,
+ },
+ {
+ .procname = "router_solicitation_delay",
+ .data = &ipv6_devconf.rtr_solicit_delay,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_jiffies,
+ },
+ {
+ .procname = "force_mld_version",
+ .data = &ipv6_devconf.force_mld_version,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "mldv1_unsolicited_report_interval",
+ .data =
+ &ipv6_devconf.mldv1_unsolicited_report_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies,
+ },
+ {
+ .procname = "mldv2_unsolicited_report_interval",
+ .data =
+ &ipv6_devconf.mldv2_unsolicited_report_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies,
+ },
+ {
+ .procname = "use_tempaddr",
+ .data = &ipv6_devconf.use_tempaddr,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "temp_valid_lft",
+ .data = &ipv6_devconf.temp_valid_lft,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "temp_prefered_lft",
+ .data = &ipv6_devconf.temp_prefered_lft,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "regen_max_retry",
+ .data = &ipv6_devconf.regen_max_retry,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "max_desync_factor",
+ .data = &ipv6_devconf.max_desync_factor,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "max_addresses",
+ .data = &ipv6_devconf.max_addresses,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "accept_ra_defrtr",
+ .data = &ipv6_devconf.accept_ra_defrtr,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "accept_ra_min_hop_limit",
+ .data = &ipv6_devconf.accept_ra_min_hop_limit,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "accept_ra_pinfo",
+ .data = &ipv6_devconf.accept_ra_pinfo,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
#ifdef CONFIG_IPV6_ROUTER_PREF
- {
- .procname = "accept_ra_rtr_pref",
- .data = &ipv6_devconf.accept_ra_rtr_pref,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "router_probe_interval",
- .data = &ipv6_devconf.rtr_probe_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
- },
+ {
+ .procname = "accept_ra_rtr_pref",
+ .data = &ipv6_devconf.accept_ra_rtr_pref,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "router_probe_interval",
+ .data = &ipv6_devconf.rtr_probe_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_jiffies,
+ },
#ifdef CONFIG_IPV6_ROUTE_INFO
- {
- .procname = "accept_ra_rt_info_max_plen",
- .data = &ipv6_devconf.accept_ra_rt_info_max_plen,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
+ {
+ .procname = "accept_ra_rt_info_max_plen",
+ .data = &ipv6_devconf.accept_ra_rt_info_max_plen,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
#endif
#endif
- {
- .procname = "proxy_ndp",
- .data = &ipv6_devconf.proxy_ndp,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = addrconf_sysctl_proxy_ndp,
- },
- {
- .procname = "accept_source_route",
- .data = &ipv6_devconf.accept_source_route,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
+ {
+ .procname = "proxy_ndp",
+ .data = &ipv6_devconf.proxy_ndp,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = addrconf_sysctl_proxy_ndp,
+ },
+ {
+ .procname = "accept_source_route",
+ .data = &ipv6_devconf.accept_source_route,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
- {
- .procname = "optimistic_dad",
- .data = &ipv6_devconf.optimistic_dad,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
-
- },
- {
- .procname = "use_optimistic",
- .data = &ipv6_devconf.use_optimistic,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
-
- },
+ {
+ .procname = "optimistic_dad",
+ .data = &ipv6_devconf.optimistic_dad,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "use_optimistic",
+ .data = &ipv6_devconf.use_optimistic,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
#endif
#ifdef CONFIG_IPV6_MROUTE
- {
- .procname = "mc_forwarding",
- .data = &ipv6_devconf.mc_forwarding,
- .maxlen = sizeof(int),
- .mode = 0444,
- .proc_handler = proc_dointvec,
- },
+ {
+ .procname = "mc_forwarding",
+ .data = &ipv6_devconf.mc_forwarding,
+ .maxlen = sizeof(int),
+ .mode = 0444,
+ .proc_handler = proc_dointvec,
+ },
#endif
- {
- .procname = "disable_ipv6",
- .data = &ipv6_devconf.disable_ipv6,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = addrconf_sysctl_disable,
- },
- {
- .procname = "accept_dad",
- .data = &ipv6_devconf.accept_dad,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "force_tllao",
- .data = &ipv6_devconf.force_tllao,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec
- },
- {
- .procname = "ndisc_notify",
- .data = &ipv6_devconf.ndisc_notify,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec
- },
- {
- .procname = "suppress_frag_ndisc",
- .data = &ipv6_devconf.suppress_frag_ndisc,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec
- },
- {
- .procname = "accept_ra_from_local",
- .data = &ipv6_devconf.accept_ra_from_local,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "accept_ra_mtu",
- .data = &ipv6_devconf.accept_ra_mtu,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "stable_secret",
- .data = &ipv6_devconf.stable_secret,
- .maxlen = IPV6_MAX_STRLEN,
- .mode = 0600,
- .proc_handler = addrconf_sysctl_stable_secret,
- },
- {
- .procname = "use_oif_addrs_only",
- .data = &ipv6_devconf.use_oif_addrs_only,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "ignore_routes_with_linkdown",
- .data = &ipv6_devconf.ignore_routes_with_linkdown,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = addrconf_sysctl_ignore_routes_with_linkdown,
- },
- {
- .procname = "drop_unicast_in_l2_multicast",
- .data = &ipv6_devconf.drop_unicast_in_l2_multicast,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- .procname = "drop_unsolicited_na",
- .data = &ipv6_devconf.drop_unsolicited_na,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- /* sentinel */
- }
+ {
+ .procname = "disable_ipv6",
+ .data = &ipv6_devconf.disable_ipv6,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = addrconf_sysctl_disable,
+ },
+ {
+ .procname = "accept_dad",
+ .data = &ipv6_devconf.accept_dad,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "force_tllao",
+ .data = &ipv6_devconf.force_tllao,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
},
+ {
+ .procname = "ndisc_notify",
+ .data = &ipv6_devconf.ndisc_notify,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+ {
+ .procname = "suppress_frag_ndisc",
+ .data = &ipv6_devconf.suppress_frag_ndisc,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+ {
+ .procname = "accept_ra_from_local",
+ .data = &ipv6_devconf.accept_ra_from_local,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "accept_ra_mtu",
+ .data = &ipv6_devconf.accept_ra_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "stable_secret",
+ .data = &ipv6_devconf.stable_secret,
+ .maxlen = IPV6_MAX_STRLEN,
+ .mode = 0600,
+ .proc_handler = addrconf_sysctl_stable_secret,
+ },
+ {
+ .procname = "use_oif_addrs_only",
+ .data = &ipv6_devconf.use_oif_addrs_only,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "ignore_routes_with_linkdown",
+ .data = &ipv6_devconf.ignore_routes_with_linkdown,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = addrconf_sysctl_ignore_routes_with_linkdown,
+ },
+ {
+ .procname = "drop_unicast_in_l2_multicast",
+ .data = &ipv6_devconf.drop_unicast_in_l2_multicast,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "drop_unsolicited_na",
+ .data = &ipv6_devconf.drop_unsolicited_na,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
- .procname = "keep_addr_on_down",
- .data = &ipv6_devconf.keep_addr_on_down,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
-
- },
- {
+ /* sentinel */
+ }
};
static int __addrconf_sysctl_register(struct net *net, char *dev_name,
^ permalink raw reply
* linux-next: build failure after merge of the block tree
From: Stephen Rothwell @ 2016-04-26 3:38 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-next, linux-kernel, Jens Axboe, Michal Marek, Randy Dunlap
Hi Nicolas,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!
Caused by commit
089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")
from the kbuild-pite tree.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the xen-tip tree with the arm64 tree
From: Stephen Rothwell @ 2016-04-26 5:00 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Catalin Marinas
Cc: linux-next, linux-kernel, David Daney, Will Deacon, Shannon Zhao
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/arm64/kernel/setup.c
between commit:
3194ac6e66cc ("arm64: Move unflatten_device_tree() call earlier.")
from the arm64 tree and commit:
3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")
from the xen-tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/kernel/setup.c
index 65f515949baa,7cf992fe6684..000000000000
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@@ -277,13 -336,13 +278,11 @@@ void __init setup_arch(char **cmdline_p
early_ioremap_reset();
- if (acpi_disabled) {
- unflatten_device_tree();
+ if (acpi_disabled)
psci_dt_init();
- } else {
+ else
psci_acpi_init();
- }
- xen_early_init();
-
cpu_read_bootcpu_ops();
smp_init_cpus();
smp_build_mpidr_hash();
^ permalink raw reply
* linux-next: Tree for Apr 26
From: Stephen Rothwell @ 2016-04-26 7:21 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
Hi all,
Changes since 20160422:
New tree: kbuild-pitre
The arm-soc tree gained a build failure so I used the version from
next-20160422.
The pci tree lost its build failure but gained another for which I
applied a merg fix patch.
The pm tree gained a conflict against the renesas tree.
The net-next tree gained conflicts against the net tree.
The sound-asoc tree lost its build failure.
The block tree gained a build failure for which I reverted a commit from
the kbuild-pitre tree.
The xen-tip tree gained a conflict against the arm64 tree.
The akpm-current tree lost its build failures.
Non-merge commits (relative to Linus' tree): 5694
5220 files changed, 216537 insertions(+), 110283 deletions(-)
----------------------------------------------------------------------------
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 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" and checkout or reset to the new
master.
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 (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.
Below is a summary of the state of the merge.
I am currently merging 235 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
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. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (bcc981e9ed84 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install)
Merging arc-current/for-curr (da67e68c0e46 Documentation: dt: arc: fix spelling mistakes)
Merging arm-current/fixes (ac36a881b72a ARM: 8564/1: fix cpu feature extracting helper)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors)
Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits in scan_features())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (3d6d30d60abb cxgbi: fix uninitialized flowi6)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup with identical name)
Merging wireless-drivers/master (e2841ea91611 Merge tag 'iwlwifi-for-kalle-2016-04-12_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket release notification)
Merging sound-current/for-linus (3194ed497939 ALSA: hda - Fix possible race on regmap bypass flip)
Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read both VPD structures)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (02da2d72174c Linux 4.6-rc5)
Merging usb.current/usb-linus (02da2d72174c Linux 4.6-rc5)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix use-after-free)
Merging usb-serial-fixes/usb-linus (613ac23a46e1 USB: serial: cp210x: add Straizona Focusers device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4)
Merging input-current/for-linus (eb43335c4095 Input: atmel_mxt_ts - use mxt_acquire_irq in mxt_soft_reset)
Merging crypto-current/master (340ff60ae93a crypto: talitos - fix AEAD tcrypt tests)
Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the seccomp(2) signature)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct)
Merging mfd-fixes/for-mfd-fixes (1b52e50f2a40 mfd: max77843: Fix max77843_chg_init() return on error)
Merging drm-intel-fixes/for-linux-next-fixes (02da2d72174c Linux 4.6-rc5)
Merging asm-generic/master (987aedb5d6f6 generic syscalls: wire up preadv2 and pwritev2 syscalls)
Merging arc/for-next (767cb9d8abfa ARC: Add eznps platform to Kconfig and Makefile)
Merging arm/for-next (c6433ebdc184 Merge branch 'devel-stable' into for-next)
Merging arm-perf/for-next/perf (4ba2578fa7b5 arm64: perf: don't expose CHAIN event in sysfs)
Merging arm-soc/for-next (9c2c8a8d347c arm-soc: describe merges)
$ git reset --hard HEAD^
Merging next-20160422 version of arm-soc
Merging at91/at91-next (503057c24478 Merge branches 'at91-4.7-soc' and 'at91-4.7-dt' into at91-next)
Merging bcm2835-dt/bcm2835-dt-next (896ad420db8d dt/bindings: bcm2835: correct description for DMA-int)
Merging bcm2835-soc/bcm2835-soc-next (92e963f50fc7 Linux 4.5-rc1)
Merging bcm2835-drivers/bcm2835-drivers-next (92e963f50fc7 Linux 4.5-rc1)
Merging bcm2835-defconfig/bcm2835-defconfig-next (3652bb35abf6 ARM: bcm2835: Enable NFS root support.)
Merging berlin/berlin/for-next (9a7e06833249 Merge branch 'berlin/fixes' into berlin/for-next)
Merging cortex-m/for-next (f719a0d6a854 ARM: efm32: switch to vendor,device compatible strings)
Merging imx-mxs/for-next (6ffbe53bca8f Merge branch 'imx/defconfig' into for-next)
Merging keystone/next (02e15d234006 Merge branch 'for_4.7/kesytone' into next)
Merging mvebu/for-next (550cd80600c7 Merge branch 'mvebu/defconfig' into mvebu/for-next)
CONFLICT (content): Merge conflict in arch/arm/configs/multi_v7_defconfig
Merging omap/for-next (e07d8e39370c Merge branch 'omap-for-v4.7/soc' into for-next)
Merging omap-pending/for-next (c20c8f750d9f ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence)
Merging qcom/for-next (100b83d52f51 ARM: dts: msm8974: Add SCM firmware node)
Merging renesas/next (864683ba2f65 Merge branches 'heads/arm64-defconfig-for-v4.7', 'heads/arm64-dt-pm-domain-for-v4.7' and 'heads/pci-defconfig-for-v4.7' into next)
Merging rockchip/for-next (0c5549bbea98 Merge branch 'v4.7-clk/next' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (92e963f50fc7 Linux 4.5-rc1)
Merging samsung-krzk/for-next (3aac939e7523 Merge branch 'next/dt' into for-next)
Merging sunxi/sunxi/for-next (f1e9b6675c26 Merge branches 'sunxi/clocks-for-4.7', 'sunxi/dt-for-4.7' and 'sunxi/fixes-for-4.6' into sunxi/for-next)
Merging tegra/for-next (85eafb4bbfec Merge branch for-4.7/gpio into for-next)
Merging arm64/for-next/core (44dbcc93ab67 arm64: Fix behavior of maxcpus=N)
Merging blackfin/for-linus (391e74a51ea2 eth: bf609 eth clock: add pclk clock for stmmac driver probe)
CONFLICT (content): Merge conflict in arch/blackfin/mach-common/pm.c
Merging c6x/for-linux-next (ca3060d39ae7 c6x: Use generic clkdev.h header)
Merging cris/for-next (f9f3f864b5e8 cris: Fix section mismatches in architecture startup code)
Merging h8300/h8300-next (8cad489261c5 h8300: switch EARLYCON)
Merging hexagon/linux-next (02cc2ccfe771 Revert "Hexagon: fix signal.c compile error")
Merging ia64/next (7e26e9ff0a93 pstore: Fix return type of pstore_is_mounted())
Merging m68k/for-next (efbec135f11d m68k: Fix misspellings in comments.)
Merging m68knommu/for-next (c3b46c73264b Linux 4.6-rc4)
Merging metag/for-next (c8b6ad8b3f87 metag: ftrace: remove the misleading comment for ftrace_dyn_arch_init)
Merging microblaze/next (10f4b26deb41 microblaze/PCI: export isa_io_base to fix link errors)
Merging mips/mips-for-linux-next (7620fecf8342 Merge branch '4.6-fixes' into mips-for-linux-next)
Merging nios2/for-next (8fe889274c7a nios2: Replace fdt_translate_address with of_flat_dt_translate_address)
Merging parisc-hd/for-next (695499920489 parisc: Add native high-resolution sched_clock() implementation)
Merging powerpc/next (4aec6ec0da9c cxl: Increase timeout for detection of AFU mmio hang)
Merging powerpc-mpe/next (bc0195aad0da Linux 4.2-rc2)
Merging fsl/next (fba4e9f9898a powerpc/fsl/dts: Add "jedec,spi-nor" flash compatible)
Merging mpc5xxx/next (39e69f55f857 powerpc: Introduce the use of the managed version of kzalloc)
Merging s390/features (7072276e6c0e s390/Kconfig: make z196 the default processor type)
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tile/master (f98983bbba0d tile/defconfigs: Remove CONFIG_IPV6_PRIVACY)
Merging uml/linux-next (ad32a1f3c36b um: use %lx format specifiers for unsigned longs)
Merging unicore32/unicore32 (d670878e2c9a unicore32: Remove ARCH_HAS_CPUFREQ config option)
Merging xtensa/for_next (9da8320bb977 xtensa: add test_kc705_hifi variant)
Merging btrfs/next (bb7ab3b92e46 btrfs: Fix misspellings in comments.)
Merging btrfs-kdave/for-next (e93ed1818f75 Merge branch 'for-next-4.6-20160425' into for-next-20160425)
CONFLICT (content): Merge conflict in fs/btrfs/volumes.c
CONFLICT (content): Merge conflict in fs/btrfs/file.c
CONFLICT (content): Merge conflict in fs/btrfs/extent_io.c
Merging ceph/master (bdb7c4952bf3 rbd: report unsupported features to syslog)
Merging cifs/for-next (2b6c3239da3f cifs: remove any preceding delimiter from prefix_path)
Merging configfs/for-next (96c22a329351 configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions)
Merging ecryptfs/next (933c32fe0e42 ecryptfs: drop null test before destroy functions)
Merging ext3/for_next (8f9e8f5fcc05 ocfs2: Fix Q_GETNEXTQUOTA for filesystem without quotas)
Merging ext4/dev (86cf0011caf3 ext4: allow readdir()'s of large empty directories to be interrupted)
Merging f2fs/dev (4da7bf5a4345 f2fs: remove redundant condition check)
Merging fscache/fscache (b00c2ae2ed3c FS-Cache: Don't override netfs's primary_index if registering failed)
Merging fuse/for-next (2c932d4c9165 fuse: Fix return value from fuse_get_user_pages())
Merging gfs2/for-next (9c7fe83530a3 GFS2: Add calls to gfs2_holder_uninit in two error handlers)
Merging jfs/jfs-next (6ed71e9819ac jfs: Coalesce some formats)
Merging nfs/linux-next (02da2d72174c Linux 4.6-rc5)
Merging nfsd/nfsd-next (ac503e4a309a nfsd: use short read as well as i_size to set eof)
Merging orangefs/for-next (e56f49814250 orangefs: remove unused variable)
Merging overlayfs/overlayfs-next (e3608e3f68f6 Btrfs: fix crash/invalid memory access on fsync when using overlayfs)
Merging v9fs/for-next (a333e4bf2556 fs/9p: use fscache mutex rather than spinlock)
Merging ubifs/linux-next (c27cb97218b3 ubifs: Remove unused header)
Merging xfs/for-next (d8bdd04e309b Merge branch 'xfs-4.7-misc-fixes' into for-next)
Merging file-locks/linux-next (5af9c2e19da6 Merge branch 'akpm' (patches from Andrew))
Merging vfs/for-next (489eda8cd1a6 Merge branches 'work.acl', 'work.const-path' and 'work.misc' into for-next)
Merging pci/next (a8dd1a5cd502 Merge branches 'pci/host-designware', 'pci/host-imx6', 'pci/host-mvebu' and 'pci/host-vmd' into next)
Applying: iommu/amd: fix up for aliases API change
Merging hid/for-next (e686a7d8e470 Merge branch 'for-4.6/upstream-fixes' into for-next)
Merging i2c/i2c/for-next (408c91ad9d33 Merge branch 'i2c/for-4.7' into i2c/for-next)
Merging jdelvare-hwmon/master (f02de116250d Documentation/hwmon: Update links in max34440)
Merging dmi/master (c3db05ecf8ac firmware: dmi_scan: Save SMBIOS Type 9 System Slots)
Merging hwmon-staging/hwmon-next (71a9c23246fe hwmon: (it87) Add support for IT8628E)
Merging v4l-dvb/master (dcb7c0b9e2ad Merge branch 'patchwork' into to_next)
Merging libata/for-next (c5cf484d03f1 Merge branch 'for-4.6-fixes' into for-next)
Merging pm/linux-next (899566da44ee Merge branch 'pm-cpufreq' into linux-next)
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/Makefile
Merging idle/next (f55532a0c0b8 Linux 4.6-rc1)
Merging thermal/next (81ad4276b505 Thermal: Ignore invalid trip points)
Merging thermal-soc/next (9fe6d7e1417e Merge branch 'work-fixes' into work-next)
Merging ieee1394/for-next (384fbb96f926 firewire: nosy: Replace timeval with timespec64)
Merging dlm/next (82c7d823cc31 dlm: config: Fix ENOMEM failures in make_cluster())
Merging swiotlb/linux-next (386744425e35 swiotlb: Make linux/swiotlb.h standalone includible)
Merging slave-dma/next (1338727bc468 Merge branch 'topic/bcm' into next)
Merging net-next/master (5a5f0792e98b Merge branch 'pskb_extract')
CONFLICT (content): Merge conflict in net/ipv6/addrconf.c
CONFLICT (content): Merge conflict in include/linux/ipv6.h
Merging ipsec-next/master (cb866e3298cd xfrm: Increment statistic counter on inner mode error)
Merging ipvs-next/master (8fb04d9fc70a ipvs: don't alter conntrack in OPS mode)
Merging wireless-drivers-next/master (06d05463ee33 rtl8xxxu: hide unused tables)
Merging bluetooth/master (55441070ca1c Bluetooth: 6lowpan: Fix memory corruption of ipv6 destination address)
Merging mac80211-next/master (81948527fce5 cfg80211: Add option to report the bss entry in connect result)
Merging rdma/for-next (520a07bff6fb Merge branches 'i40iw', 'sriov' and 'hfi1' into k.o/for-4.6)
Merging rdma-leon/rdma-next (c3b46c73264b Linux 4.6-rc4)
Merging rdma-leon-test/testing/rdma-next (c3b46c73264b Linux 4.6-rc4)
Merging mtd/master (20c07a5bf094 mtd: nand: Drop mtd.owner requirement in nand_scan)
Merging l2-mtd/master (08922f644878 mtd: devices: m25p80: add support for mmap read request)
Merging nand/nand/next (5c62c5614bd1 mtd: mtd: drop NAND_ECC_SOFT_BCH enum value)
Merging crypto/master (79152e8d085f crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks)
Merging drm/drm-next (027b3f8ba927 drm/modes: stop handling framebuffer special)
Merging drm-panel/drm/panel/for-next (1ac3bac7c733 drm/panel: simple: Add support for Innolux AT070TN92)
Merging drm-intel/for-linux-next (ff5ec22dad15 drm/i915: Simplify i915_gem_obj_ggtt_bound_view)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.c
Merging drm-tegra/drm/tegra/for-next (3a9b33c6048a drm/tegra: Don't set a gamma table size)
Merging drm-misc/topic/drm-misc (5ff18e42ddfd MAINTAINERS: Update the files list for the GMA500 DRM driver)
Merging drm-exynos/exynos-drm/for-next (25364a9e54fb Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging drm-msm/msm-next (fcda50c8f484 drm/msm: rename hdmi symbols)
Merging hdlcd/for-upstream/hdlcd (69c2565a3cca drm: ARM HDLCD - fix an error code)
Merging drm-vc4/drm-vc4-next (5883980313af drm/vc4: Fix NULL deref in HDMI init error path)
Merging kbuild/for-next (4bf284b27780 Merge branch 'kbuild/misc' into kbuild/for-next)
Merging kbuild-pitre/kbuild (089095b8eef9 kbuild: better abstract vmlinux sequential prerequisites)
Merging kconfig/for-next (f55532a0c0b8 Linux 4.6-rc1)
Merging regmap/for-next (8eabbbb9c0c9 Merge remote-tracking branches 'regmap/topic/doc' and 'regmap/topic/flat' into regmap-next)
Merging sound/for-next (8d84c1973b69 ALSA: doc: fix spelling mistakes)
Merging sound-asoc/for-next (304d8d26825f Merge remote-tracking branches 'asoc/topic/wm8960' and 'asoc/topic/wm8962' into asoc-next)
Merging modules/modules-next (13771c666003 module: Issue warnings when tainting kernel)
Merging input/next (9e4cc255e6e1 Input: twl6040-vibra - remove mutex)
Merging block/for-next (e518fbe9ab03 Merge branch 'for-4.7/drivers' into for-next)
Applying: Revert "kbuild: better abstract vmlinux sequential prerequisites"
Merging device-mapper/for-next (3ff6a535b994 dm mpath: eliminate use of spinlock in IO fast-paths)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc-uh/next (00c479a5ba11 mmc: block: Convert to IDA for partition device indexes)
Merging md/for-next (9c573de3283a MD: make bio mergeable)
Merging mfd/for-mfd-next (ba5776ab6f09 mfd: cros_ec: Allow building for ARM64)
Merging backlight/for-backlight-next (60d613d6aef4 backlight: pwm_bl: Free PWM requested by legacy API on error path)
Merging battery/master (4a99fa06a8ca sbs-battery: fix power status when battery charging near dry)
Merging omap_dss2/for-next (32ad61951574 video: fbdev: sis: remove unused variable)
Merging regulator/for-next (e9eedc5a932c Merge remote-tracking branches 'regulator/topic/s2mps11', 'regulator/topic/supply', 'regulator/topic/tps6524x' and 'regulator/topic/twl' into regulator-next)
Merging security/next (9b091556a073 LSM: LoadPin for kernel file loading restrictions)
Merging integrity/next (f5f8f020b2da ima: add support for creating files using the mknodat syscall)
Merging keys/keys-next (1ea6102bba5f Merge branch 'keys-trust' into keys-next)
CONFLICT (content): Merge conflict in crypto/asymmetric_keys/pkcs7_parser.c
Merging selinux/next (1ac42476263e selinux: check ss_initialized before revalidating an inode label)
Merging tpmdd/next (0c61500a7f09 tpm/st33zp24: Remove unneeded tpm_reg in get_burstcount)
Merging watchdog/master (d1ed3ba4e3d7 watchdog: Ensure that wdd is not dereferenced if NULL)
Merging iommu/next (1229bc9a9973 Merge branches 'iommu/fixes', 'arm/io-pgtable', 'arm/rockchip', 'arm/omap', 'x86/vt-d', 'ppc/pamu' and 'x86/amd' into next)
Merging dwmw2-iommu/master (22e2f9fa63b0 iommu/vt-d: Use per-cpu IOVA caching)
Merging vfio/next (c4aec3101319 vfio/pci: return -EFAULT if copy_to_user fails)
Merging jc_docs/docs-next (78f3873decad Documentation: HOWTO: update git home URL in translations)
Merging trivial/for-next (dc5a533f9130 serial: mctrl_gpio: Grammar s/lines GPIOs/line GPIOs/, /sets/set/)
Merging audit/next (7ffb8e317bae audit: we don't need to __set_current_state(TASK_RUNNING))
Merging devicetree/devicetree/next (48a9b733e644 of/irq: Rename "intc_desc" to "of_intc_desc" to fix OF on sh)
Merging dt-rh/for-next (1c986e3643d2 of: document refcount incrementation of of_get_cpu_node())
Merging mailbox/mailbox-for-next (aca04ce5dbda Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging spi/for-next (dbf5c0531d71 Merge remote-tracking branches 'spi/topic/pic32-qspi', 'spi/topic/pxa2xx' and 'spi/topic/xlp' into spi-next)
Merging tip/auto-latest (388797294512 Merge branch 'WIP.futex')
CONFLICT (content): Merge conflict in drivers/cpufreq/longhaul.c
Merging clockevents/clockevents/next (cee77c2c5b57 clocksource/drivers/tango-xtal: Fix incorrect test)
Merging edac/linux_next (12f0721c5a70 sb_edac: correctly fetch DIMM width on Ivy Bridge and Haswell)
Merging edac-amd/for-next (c5fb04cc96c1 ARM: socfpga: Initialize Arria10 OCRAM ECC on startup)
Merging irqchip/irqchip/for-next (a66ce4b7d9d2 Merge branch 'irqchip/mvebu' into irqchip/for-next)
Merging ftrace/for-next (d50c744ecde7 tracing: Fix unsigned comparison to zero in hist trigger code)
Merging rcu/rcu/next (b862e9441a9c documentation: ACQUIRE applies to loads, RELEASE applies to stores)
Merging kvm/linux-next (05b1159e641f Merge tag 'kvms390-20160420' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into next)
Merging kvm-arm/next (02e0b7600f83 arm64: kvm: Add support for 16K pages)
Merging kvm-ppc/kvm-ppc-next (c63517c2e381 KVM: PPC: Book3S: correct width in XER handling)
Merging kvm-ppc-paulus/kvm-ppc-next (58ded4201ff0 KVM: PPC: Add support for 64bit TCE windows)
Merging kvms390/next (c87ff1433aca KVM: s390: add clear I/O irq operation for FLIC)
Merging xen-tip/linux-next (3a61cfdd47c4 xen/x86: don't lose event interrupts)
CONFLICT (content): Merge conflict in arch/arm64/kernel/setup.c
Merging percpu/for-next (18fc93fd6412 percpu: remove PERCPU_ENOUGH_ROOM which is stale definition)
Merging workqueues/for-next (22aceb317678 workqueue: Fix comment for work_on_cpu())
Merging drivers-x86/for-next (19d46ee1aec0 asus-laptop: correct error handling in sysfs_acpi_set)
Merging chrome-platform/for-next (1dc318166a9a platform/chrome: use to_platform_device())
Merging hsi/for-next (87d99063be01 HSI: ssi-protocol: Use handshake logic from n950)
Merging leds/for-next (f15c65afddbe leds: ss4200: add DMI data for FSC SCALEO Home Server)
Merging ipmi/for-next (42a018c63aee ipmi: do not probe ACPI devices if si_tryacpi is unset)
Merging driver-core/driver-core-next (5614e7725856 Merge 4.6-rc4 into driver-core-next)
Merging tty/tty-next (02da2d72174c Linux 4.6-rc5)
Merging usb/usb-next (69b4269eff5f Merge 4.6-rc5 into usb-next)
Merging usb-gadget/next (a2eb431fbd5c usb: dwc3: ep0: sanity check test mode selector)
CONFLICT (content): Merge conflict in drivers/usb/dwc3/debugfs.c
Merging usb-serial/usb-next (8c34d82e9dc6 USB: serial: use IS_ENABLED() instead of checking for FOO || FOO_MODULE)
Merging usb-chipidea-next/ci-for-usb-next (4e332df63487 usb: otg-fsm: support multiple instances)
Merging staging/staging-next (4145ba76b1f7 staging: unisys: visornic: prevent double-unlock of priv_lock)
Merging char-misc/char-misc-next (7553c7e68fd1 Merge 4.6-rc4 into char-misc-next)
Merging extcon/extcon-next (453fc627c7b5 extcon: usb-gpio: add support for ACPI gpio interface)
Merging cgroup/for-next (e0f00aff2dcc Merge branch 'for-4.6-fixes' into for-next)
Merging scsi/for-next (0237d1ea51f0 pm80xx: Remove bogus address masking in pm8001_ioremap())
Merging target-updates/for-next (5e47f1985d71 target: Fix target_release_cmd_kref shutdown comp leak)
Merging target-merge/for-next-merge (2994a7518317 cxgb4: update Kconfig and Makefile)
Merging pinctrl/for-next (1f5d93d96b06 Merge branch 'devel' into for-next)
Merging vhost/linux-next (c00bbcf86289 virtio: add VIRTIO_CONFIG_S_NEEDS_RESET device status bit)
Merging remoteproc/for-next (7a6271a80cae remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias)
Merging rpmsg/for-next (9735a22799b9 Linux 4.6-rc2)
Merging gpio/for-next (9c088f21bb5d Merge branch 'devel' into for-next)
Merging dma-mapping/dma-mapping-next (d770e558e219 Linux 4.2-rc1)
Merging pwm/for-next (f55532a0c0b8 Linux 4.6-rc1)
Merging dma-buf/for-next (12566cc35d0e Merge tag 'pci-v4.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging userns/for-next (f2ca379642d7 namei: permit linking with CAP_FOWNER in userns)
Merging ktest/for-next (f55532a0c0b8 Linux 4.6-rc1)
Merging clk/clk-next (58657d189a2f Merge branch 'clk-hw-register' (early part) into clk-next)
Merging aio/master (b562e44f507e Linux 4.5)
Merging kselftest/next (f55532a0c0b8 Linux 4.6-rc1)
Merging y2038/y2038 (477b8541b31f qla2xxx: Remove use of 'struct timeval')
Merging luto-misc/next (afd2ff9b7e1b Linux 4.4)
Merging borntraeger/linux-next (36f90b0a2ddd Linux 4.5-rc2)
Merging livepatching/for-next (4fe83e63352a Merge branch 'for-4.7/livepatching-ppc64' into for-next)
Merging coresight/next (b761fcde1231 coresight: etm4x: add tracer ID for A72 Maia processor.)
Merging rtc/rtc-next (820c5327d631 rtc: ds3232: fix call trace when rtc->ops_lock is used as NULL)
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (a390180291dd libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignment)
Merging akpm-current/current (b45cf173932e ipc/msg.c: use freezable blocking call)
CONFLICT (content): Merge conflict in arch/mips/kernel/process.c
CONFLICT (content): Merge conflict in arch/mips/Kconfig
Applying: mm-rename-_count-field-of-the-struct-page-to-_refcount-fix6
$ git checkout -b akpm remotes/origin/akpm/master
Applying: drivers/net/wireless/intel/iwlwifi/dvm/calib.c: simplfy min() expression
Merging akpm/master (b1cf656a1fba drivers/net/wireless/intel/iwlwifi/dvm/calib.c: simplfy min() expression)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox