Paul Bolle [Wed, 19 Jun 2013 00:05:28 +0000 (10:05 +1000)]
drivers/video/acornfb.c: remove dead code
acornfb checks for HAS_VIDC while support for that macro was removed in
v2.6.23 (when the arm26 port was removed). So we can remove a bit of dead
code.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jeff Mahoney [Wed, 19 Jun 2013 00:05:25 +0000 (10:05 +1000)]
drm/nouveau: make vga_switcheroo code depend on VGA_SWITCHEROO
Commit 8116188fdef594 ("nouveau/acpi: hook up to the MXM method for mux
switching.") broke the build on non-x86 architectures due to the new
dependency on MXM and MXM being an x86 platform driver.
It built previously since the vga switcheroo registration routines were
zereod out on !X86. The code was built in but unused.
This patch makes all of the DSM code depend on CONFIG_VGA_SWITCHEROO,
allowing it to build on non-x86 and shrinking the module size as well.
Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Takashi Iwai [Wed, 19 Jun 2013 00:05:25 +0000 (10:05 +1000)]
drm/cirrus: correct register values for 16bpp
When the mode is set with 16bpp on QEMU, the output gets totally broken.
The culprit is the bogus register values set for 16bpp, which was likely
copied from from a wrong place.
Daniel Vetter [Wed, 19 Jun 2013 00:05:24 +0000 (10:05 +1000)]
drm/fb-helper: don't sleep for screen unblank when an oops is in progress
Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.
Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out. Inspired by a patch from
Konstantin Khlebnikov. The callchain leading to this, cut&pasted from
Konstantin's original patch:
Note that the entire locking in the fb helper around panic/sysrq and kdbg
is ... non-existant. So we have a decent change of blowing up
everything. But since reworking this ties in with funny concepts like the
fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Chen Gang [Wed, 19 Jun 2013 00:05:23 +0000 (10:05 +1000)]
kernel/auditfilter.c: fix leak in audit_add_rule() error path
If both 'tree' and 'watch' are valid we must call audit_put_tree(), just
like the preceding code within audit_add_rule().
Signed-off-by: Chen Gang <gang.chen@asianux.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
kernel/auditfilter.c:426: warning: this decimal constant is unsigned only in ISO C90
Signed-off-by: Raphael S. Carvalho <raphael.scarv@gmail.com> Cc: Eric Paris <eparis@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Both of these look wrong to me. As Steve Grubb pointed out:
"What we need is 1 PATH record that identifies the MQ. The other PATH
records probably should not be there."
Fix it to record the mq root as a parent, and flag it such that it should
be hidden from view when the names are logged, since the root of the mq
filesystem isn't terribly interesting. With this change, we get a single
PATH record that looks more like this:
In order to do this, a new audit_inode_parent_hidden() function is added.
If we do it this way, then we avoid having the existing callers of
audit_inode needing to do any sort of flag conversion if auditing is
inactive.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reported-by: Jiri Jaburek <jjaburek@redhat.com> Cc: Steve Grubb <sgrubb@redhat.com> Cc: Eric Paris <eparis@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Wen Congyang [Wed, 19 Jun 2013 00:05:22 +0000 (10:05 +1000)]
x86: make 'mem=' option to work for efi platform
Current mem boot option only can work for non efi environment. If the
user specifies add_efi_memmap, it cannot work for efi environment. In the
efi environment, we call e820_add_region() to add the memory map. So we
can modify __e820_add_region() and the mem boot option can work for efi
environment.
Note: Only E820_RAM is limited, and BOOT_SERVICES_{CODE,DATA} are always
mapped(If its address >= mem_limit, the memory won't be freed in
efi_free_boot_services()).
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Rob Landley <rob@landley.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Yasuaki ISIMATU <isimatu.yasuaki@jp.fujitsu.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Fix the x86 implementation of trigger_all_cpu_backtrace(), which was
previously (accidentally, as far as I can tell) disabled to always return
false as on architectures that do not implement this function.
trigger_all_cpu_backtrace(), as defined in include/linux/nmi.h, should
call arch_trigger_all_cpu_backtrace() if available, or return false if the
underlying arch doesn't implement this function.
x86 did provide a suitable arch_trigger_all_cpu_backtrace()
implementation, but it wasn't actually being used because it was declared
in asm/nmi.h, which linux/nmi.h doesn't include. Also, linux/nmi.h
couldn't easily be fixed by including asm/nmi.h, because that file is not
available on all architectures.
I am proposing to fix this by moving the x86 definition of
arch_trigger_all_cpu_backtrace() to asm/irq.h.
Tested: echo l > /proc/sysrq-trigger
Before the change, this uses a fallback implementation which shows
backtraces on active CPUs (using smp_call_function_interrupt()).
After the change, this shows NMI backtraces on all CPUs.
Signed-off-by: Michel Lespinasse <walken@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Wed, 19 Jun 2013 00:05:21 +0000 (10:05 +1000)]
include/linux/smp.h:on_each_cpu(): switch back to a macro
f21afc25f9ed4 ("smp.h: Use local_irq_{save,restore}() in !SMP version of
on_each_cpu()") converted on_each_cpu() to a C function. This required
inclusion of irqflags.h, which broke ia64 and mn10300 (at least) due to
header ordering hell.
Switch on_each_cpu() back to a macro to fix this.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: David Daney <david.daney@cavium.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
James Hogan [Wed, 19 Jun 2013 00:05:20 +0000 (10:05 +1000)]
metag: fix mm/hugetlb.c build breakage
Commit 106c992a5ebef ("mm/hugetlb: add more arch-defined huge_pte
functions") merged in v3.10-rc1.
The above commit added an include of <asm-generic/hugetlb.h> to each
architecture's <asm/hugetlb.h> (except s390). Unfortunately metag was
missed which resulted in build errors when hugetlbfs is enabled (see
below). Add the include for metag too to fix the build errors.
mm/hugetlb.c In function 'make_huge_pte':
mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkwrite'
mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkdirty'
mm/hugetlb.c +2250 : error: implicit declaration of function 'mk_huge_pte'
mm/hugetlb.c +2251 : error: incompatible types in assignment
mm/hugetlb.c +2254 : error: incompatible type for argument 1 of 'huge_pte_wrprotect'
mm/hugetlb.c In function 'set_huge_ptep_writable':
mm/hugetlb.c +2268 : error: incompatible types in assignment
mm/hugetlb.c In function '__unmap_hugepage_range':
mm/hugetlb.c +2383 : error: implicit declaration of function 'huge_pte_clear'
mm/hugetlb.c +2407 : error: implicit declaration of function 'huge_pte_dirty'
mm/hugetlb.c In function 'hugetlb_fault':
mm/hugetlb.c +2860 : error: implicit declaration of function 'huge_pte_write'
mm/hugetlb.c +2895 : error: incompatible types in assignment
mm/hugetlb.c In function 'hugetlb_change_protection':
mm/hugetlb.c +3047 : error: implicit declaration of function 'huge_pte_modify'
mm/hugetlb.c +3047 : error: incompatible type for argument 1 of 'pte_mkhuge'
make[1]: *** [mm/hugetlb.o] Error 1
make: *** [mm/hugetlb.o] Error 2
Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>