Conflicts:
drivers/net/ethernet/emulex/benet/be.h
drivers/net/netconsole.c
net/bridge/br_private.h
Three mostly trivial conflicts.
The net/bridge/br_private.h conflict was a function signature (argument
addition) change overlapping with the extern removals from Joe Perches.
In drivers/net/netconsole.c we had one change adjusting a printk message
whilst another changed "printk(KERN_INFO" into "pr_info(".
Lastly, the emulex change was a new inline function addition overlapping
with Joe Perches's extern removals.
Signed-off-by: David S. Miller <davem@davemloft.net>
The GIC interrupt offsets are calculated based on the value of NR_CPUS.
However, this is wrong because NR_CPUS may or may not contain the real
number of the actual cpus present in the system. We fix that by using
the 'nr_cpu_ids' variable which contains the real number of cpus in
the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if
NR_CPUS was > 8 with the following errors:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:670 __irq_set_handler+0x15c/0x164()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.12.0-rc5-00087-gced5633 5
Stack : 00000006 00000004 00000000 00000000 00000000 00000000 807a4f36 00000053
807a0000 00000000 80173218 80565aa8 00000000 00000000 00000000 0000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000
00000000 00000000 00000000 8054fd00 8054fd94 80500514 805657a7 8016eb4
807a0000 80500514 00000000 00000000 80565aa8 8079a5d8 80565766 8054fd0
...
Call Trace:
[<801098c0>] show_stack+0x64/0x7c
[<8049c6b0>] dump_stack+0x64/0x84
[<8012efc4>] warn_slowpath_common+0x84/0xb4
[<8012f00c>] warn_slowpath_null+0x18/0x24
[<80173218>] __irq_set_handler+0x15c/0x164
[<80587cf4>] arch_init_ipiirq+0x2c/0x3c
[<805880c8>] arch_init_irq+0x3c4/0x4bc
[<80588e28>] init_IRQ+0x3c/0x50
[<805847e8>] start_kernel+0x230/0x3d8
---[ end trace 4eaa2a86a8e2da26 ]---
This is now fixed and the Malta board can boot with any NR_CPUS value
which also helps supporting more processors in a single kernel binary.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6091/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Conflicts:
drivers/net/usb/qmi_wwan.c
include/net/dst.h
Trivial merge conflicts, both were overlapping changes.
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull gcc "asm goto" miscompilation workaround from Ingo Molnar:
"This is the fix for the GCC miscompilation discussed in the following
lkml thread:
[x86] BUG: unable to handle kernel paging request at 00740060
The bug in GCC has been fixed by Jakub and the fix will be part of the
GCC 4.8.2 release expected to be released next week - so the quirk's
version test checks for <= 4.8.1.
The quirk is only added to compiler-gcc4.h and not to the higher level
compiler.h because all asm goto uses are behind a feature check"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
compiler/gcc4: Add quirk for 'asm goto' miscompilation bug
Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).
This was observed to cause a fault and panic:
CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24 : 139fea20 1e1f7cb6
...
Call Trace:
[<8000cc0c>] resume+0xac/0x118
[<8034f2a4>] __schedule+0x5f8/0x78c
[<8034f4e0>] schedule_preempt_disabled+0x20/0x2c
[<80348eec>] rest_init+0x74/0x84
[<804dc990>] start_kernel+0x43c/0x454
Code: 3c18804b 8f184030 8cb901f8 <af190000> 00c0e021 8cb002f0 8cb102f4 8cb202f8 8cb302fc
This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.
Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.
Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Gregory Fong <gregory.0xf0@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Conflicts:
drivers/net/ethernet/emulex/benet/be.h
drivers/net/usb/qmi_wwan.c
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
include/net/netfilter/nf_conntrack_synproxy.h
include/net/secure_seq.h
The conflicts are of two varieties:
1) Conflicts with Joe Perches's 'extern' removal from header file
function declarations. Usually it's an argument signature change
or a function being added/removed. The resolutions are trivial.
2) Some overlapping changes in qmi_wwan.c and be.h, one commit adds
a new value, another changes an existing value. That sort of
thing.
Signed-off-by: David S. Miller <davem@davemloft.net>
As mentioned in commit afe4fd0624 ("pkt_sched: fq: Fair Queue packet
scheduler"), this patch adds a new socket option.
SO_MAX_PACING_RATE offers the application the ability to cap the
rate computed by transport layer. Value is in bytes per second.
u32 val = 1000000;
setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val));
To be effectively paced, a flow must use FQ packet scheduler.
Note that a packet scheduler takes into account the headers for its
computations. The effective payload rate depends on MSS and retransmits
if any.
I chose to make this pacing rate a SOL_SOCKET option instead of a
TCP one because this can be used by other protocols.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steinar H. Gunderson <sesse@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The check cpu_needs_post_dma_flush() in mips_dma_sync_sg_for_cpu() and
the check !plat_device_is_coherent() in mips_dma_sync_sg_for_device()
can be moved outside the for loop.
As a side effect, this also avoids a GCC bug that caused kernel compile
to fail with the error:
arch/mips/mm/dma-default.c: In function 'mips_dma_sync_sg_for_cpu':
arch/mips/mm/dma-default.c:316:1: internal compiler error: in add_insn_before, at emit-rtl.c:3852
This gcc failure is seen in Code Sourcery toolchains [e.g. gcc version
4.7.2 (Sourcery CodeBench Lite 2012.09-99)] after commit "MIPS: Optimize
current_cpu_type() for better code."
Signed-off-by: Jayachandran C <jchandra@broadcom.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5907/
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Tested-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It's needed for the MAX_NR_CONSOLES macro.
Fixes the following build problem on a randconfig:
arch/mips/pci/pci-bcm1480.c: In function 'bcm1480_pcibios_init':
arch/mips/pci/pci-bcm1480.c:261:36: error: 'MAX_NR_CONSOLES'
undeclared (first use in this function)
arch/mips/pci/pci-bcm1480.c:261:36: note: each undeclared
identifier is reported only once for each function it appears in
make[1]: *** [arch/mips/pci/pci-bcm1480.o] Error 1
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5858/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Currently the kernel will always use the FR=0 register model for O32. If
an O32 application did enable FR=1 mode, some data from another application
might be leaked in the extra registers becoming visible.
Iow, this patch is meant to make the kernel MIPS R5 tolerant but leaves
proper MIPS R5 support to a future patchset.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[ralf@linux-mips.org: This only matters to Alchemy platforms. On other
platforms fixup_bigphys_addr is just an identidy mapping.]
Signed-off-by: Wolfgang Grandegger <wg@denx.de>
Cc: tiejun.chen <tiejun.chen@windriver.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/1868/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Use the CKSEG1ADDR macro when calculating VGA_MAP_MEM.
[ralf@linux-mips.org: Include <asm/addrspace.h for CKSEG1ADDR.]
Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5814/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This essentially reverts commit efb9ca08b5
(kernel.org) / 58020a106879a8b372068741c81f0015c9b0b96dbv [[MIPS] Change
get_cycles to always return 0.]
Most users of get_cycles() invoke it as a timing interface. That's why
in modern kernels it was never very much missed for. /dev/random however
uses get_cycles() in the how the jitter in the interrupt timing contains
some useful entropy.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
o Move current_cpu_type() to a separate header file
o #ifdefing on supported CPU types lets modern GCC know that certain
code in callers may be discarded ideally turning current_cpu_type() into
a function returning a constant.
o Use current_cpu_type() rather than direct access to struct cpuinfo_mips.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5833/
