Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 23 6月, 2013 4 次提交
  3. 22 6月, 2013 7 次提交
  5. 21 6月, 2013 13 次提交
  7. 20 6月, 2013 16 次提交
    • A
      splice: don't pass the address of ->f_pos to methods · 7995bd28
      由 Al Viro 提交于 
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7995bd28
    • M
      [media] Fix build when drivers are builtin and frontend modules · bb69ee27
      由 Mauro Carvalho Chehab 提交于 
      There are a large number of reports that the media build is
not compiling when some drivers are compiled as builtin, while
the needed frontends are compiled as module.

On the last one of such reports:
	From: kbuild test robot <fengguang.wu@intel.com>
	Subject: saa7134-dvb.c:undefined reference to `zl10039_attach'

The .config file has:

	CONFIG_VIDEO_SAA7134=y
	CONFIG_VIDEO_SAA7134_DVB=y
	# CONFIG_MEDIA_ATTACH is not set
	CONFIG_DVB_ZL10039=m

And it produces all those errors:

   drivers/built-in.o: In function `set_type':
   tuner-core.c:(.text+0x2f263e): undefined reference to `tea5767_attach'
   tuner-core.c:(.text+0x2f273e): undefined reference to `tda9887_attach'
   drivers/built-in.o: In function `tuner_probe':
   tuner-core.c:(.text+0x2f2d20): undefined reference to `tea5767_autodetection'
   drivers/built-in.o: In function `av7110_attach':
   av7110.c:(.text+0x330bda): undefined reference to `ves1x93_attach'
   av7110.c:(.text+0x330bf7): undefined reference to `stv0299_attach'
   av7110.c:(.text+0x330c63): undefined reference to `tda8083_attach'
   av7110.c:(.text+0x330d09): undefined reference to `ves1x93_attach'
   av7110.c:(.text+0x330d33): undefined reference to `tda8083_attach'
   av7110.c:(.text+0x330d5d): undefined reference to `stv0297_attach'
   av7110.c:(.text+0x330dbe): undefined reference to `stv0299_attach'
   drivers/built-in.o: In function `tuner_attach_dtt7520x':
   ngene-cards.c:(.text+0x3381cb): undefined reference to `dvb_pll_attach'
   drivers/built-in.o: In function `demod_attach_lg330x':
   ngene-cards.c:(.text+0x33828a): undefined reference to `lgdt330x_attach'
   drivers/built-in.o: In function `demod_attach_stv0900':
   ngene-cards.c:(.text+0x3383d5): undefined reference to `stv090x_attach'
   drivers/built-in.o: In function `cineS2_probe':
   ngene-cards.c:(.text+0x338b7f): undefined reference to `drxk_attach'
   drivers/built-in.o: In function `configure_tda827x_fe':
   saa7134-dvb.c:(.text+0x346ae7): undefined reference to `tda10046_attach'
   drivers/built-in.o: In function `dvb_init':
   saa7134-dvb.c:(.text+0x347283): undefined reference to `mt352_attach'
   saa7134-dvb.c:(.text+0x3472cd): undefined reference to `mt352_attach'
   saa7134-dvb.c:(.text+0x34731c): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x34733c): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x34735c): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x347378): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x3473db): undefined reference to `tda10046_attach'
   drivers/built-in.o:saa7134-dvb.c:(.text+0x347502): more undefined references to `tda10046_attach' follow
   drivers/built-in.o: In function `dvb_init':
   saa7134-dvb.c:(.text+0x347812): undefined reference to `mt352_attach'
   saa7134-dvb.c:(.text+0x347951): undefined reference to `mt312_attach'
   saa7134-dvb.c:(.text+0x3479a9): undefined reference to `mt312_attach'
>> saa7134-dvb.c:(.text+0x3479c1): undefined reference to `zl10039_attach'

This is happening because a builtin module can't use directly a symbol
found on a module. By enabling CONFIG_MEDIA_ATTACH, the configuration
becomes valid, as dvb_attach() macro loads the module if needed, making
the symbol available to the builtin module.

While this bug started to appear after the patches that use IS_DEFINED
macro (like changeset 7b34be71), this
bug is a way ancient than that.

The thing is that, before the IS_DEFINED() patches, the logic used to be:

       && defined(MODULE))
struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
					u8 i2c_addr,
					struct i2c_adapter *i2c);
static inline struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
					u8 i2c_addr,
					struct i2c_adapter *i2c)
{
	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
	return NULL;
}

The above code, with the .config file used, was evoluting to FALSE
(instead of TRUE as it should be, as CONFIG_DVB_ZL10039 is 'm'),
and were adding the static inline code at saa7134-dvb, instead
of the external call. So, while it weren't producing any compilation
error, the code weren't working either.

So, as the overhead for using CONFIG_MEDIA_ATTACH is minimal, just
enable it, if MODULES is defined.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      bb69ee27
    • M
      x86: Fix trigger_all_cpu_backtrace() implementation · b52e0a7c
      由 Michel Lespinasse 提交于 
      The following change fixes 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 via: 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: NMichel Lespinasse <walken@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1370518875-1346-1-git-send-email-walken@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b52e0a7c
    • J
      perf: arm64: Record the user-mode PC in the call chain. · abc41254
      由 Jed Davis 提交于 
      With this change, we no longer lose the innermost entry in the user-mode
part of the call chain.  See also the x86 port, which includes the ip,
and the corresponding change in arch/arm.
Signed-off-by: NJed Davis <jld@mozilla.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      abc41254
    • M
      [media] s5p makefiles: don't override other selections on obj-[ym] · 5f63adbb
      由 Mauro Carvalho Chehab 提交于 
      The $obj-m/$obj-y vars should be adding new modules to build, not
overriding it. So, it should never use
	$obj-y := foo.o
instead, it should use:
	$obj-y += foo.o

Failing to do that is very bad, as it will suppress needed modules.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5f63adbb
    • A
      powerpc: Fix bad pmd error with book3E config · 8bbd9f04
      由 Aneesh Kumar K.V 提交于 
      Book3E uses the hugepd at PMD level and don't encode pte directly
at the pmd level. So it will find the lower bits of pmd set
and the pmd_bad check throws error. Infact the current code
will never take the free_hugepd_range call at all because it will
clear the pmd if it find a hugepd pointer. Fix this by clearing
bad pmd only if it is not a hugepd pointer.

This is regression introduced by e2b3d202
"powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format"
Reported-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8bbd9f04
    • R
      ACPI / LPSS: Power up LPSS devices during enumeration · b9e95fc6
      由 Rafael J. Wysocki 提交于 
      Commit 7cd8407d (ACPI / PM: Do not execute _PS0 for devices without
_PSC during initialization) introduced a regression on some systems
with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
need to be powered up during initialization, but their device objects
in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
resources).

To work around this problem, make the ACPI LPSS driver power up
devices it knows about by using a new helper function
acpi_device_fix_up_power() that does all of the necessary
sanity checks and calls acpi_dev_pm_explicit_set() to put the
device into D0.
Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b9e95fc6
    • R
      ACPI / PM: Fix error code path for power resources initialization · 6ee22e9d
      由 Rafael J. Wysocki 提交于 
      Commit 781d737c (ACPI: Drop power resources driver) introduced a
bug in the power resources initialization error code path causing
a NULL pointer to be referenced in acpi_release_power_resource()
if there's an error triggering a jump to the 'err' label in
acpi_add_power_resource().  This happens because the list_node
field of struct acpi_power_resource has not been initialized yet
at this point and doing a list_del() on it is a bad idea.

To prevent this problem from occuring, initialize the list_node
field of struct acpi_power_resource upfront.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      6ee22e9d
    • R
      ACPI / dock: Take ACPI scan lock in write_undock() · 8112006f
      由 Rafael J. Wysocki 提交于 
      Since commit 3757b948 (ACPI / hotplug: Fix concurrency issues and
memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
called under acpi_scan_lock, but currently the following scenario
violating that requirement is possible:

 write_undock()
  handle_eject_request()
   hotplug_dock_devices()
    dock_remove_acpi_device()
     acpi_bus_trim()

Fix that by making write_undock() acquire acpi_scan_lock before
calling handle_eject_request() as appropriate (begin_undock() is
under the lock too in analogy with acpi_dock_deferred_cb()).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>
      8112006f
    • M
      ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources · 204ebc0a
      由 Mika Westerberg 提交于 
      acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ.  The
commit that added the workaround was 61fd47e0 (ACPI: fix two
IRQ8 issues in IOAPIC mode).

With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:

	ACPI: IRQ 6 override to edge, high
	ACPI: IRQ 7 override to edge, high
	ACPI: IRQ 7 override to edge, high
	ACPI: IRQ 13 override to edge, high

Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:

	7:          4          0          0          0   IO-APIC-edge INT33C2:00, INT33C3:00

The _CSR method for INT33C2 (and INT33C3) device returns following
resource:

	Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
	{
		0x00000007,
	}

which states that this is supposed to be level triggered, active low,
shared IRQ instead.

Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.

While we are there, correct pr_warning() to print the right triggering
value.

This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).

[rjw: Changelog]
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      204ebc0a
    • P
      x86: Fix section mismatch on load_ucode_ap · 94978599
      由 Paul Gortmaker 提交于 
      We are in the process of removing all the __cpuinit annotations.
While working on making that change, an existing problem was
made evident:

  WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
  in reference from the function cpu_init() to the function
  .init.text:load_ucode_ap()   The function cpu_init() references
  the function __init load_ucode_ap().  This is often because cpu_init
  lacks a __init annotation or the annotation of load_ucode_ap is wrong.

This now appears because in my working tree, cpu_init() is no longer
tagged as __cpuinit, and so the audit picks up the mismatch.  The 2nd
hypothesis from the audit is the correct one, as there was an incorrect
__init tag on the prototype in the header (but __cpuinit was used on
the function itself.)

The audit is telling us that the prototype's __init annotation took
effect and the function did land in the .init.text section.  Checking
with objdump on a mainline tree that still has __cpuinit shows that
the __cpuinit on the function takes precedence over the __init on the
prototype, but that won't be true once we make __cpuinit a no-op.

Even though we are removing __cpuinit, we temporarily align both
the function and the prototype on __cpuinit so that the changeset
can be applied to stable trees  if desired.

[ hpa: build fix only, no object code change ]

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: stable <stable@vger.kernel.org> # 3.9+
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      94978599
    • D
      mn10300: Fix include dependency in irqflags.h et al. · c0691143
      由 David Daney 提交于 
      We need to pick up the definition of raw_smp_processor_id() from
asm/smp.h.  For the !SMP case, we need to supply a definition of
raw_smp_processor_id().

Because of the include dependencies we cannot use smp_call_func_t in
asm/smp.h, but we do need linux/thread_info.h
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c0691143
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · b9e763cd
      由 Linus Torvalds 提交于 
      Pull sparc fixes from David Miller:
 "Various sparc bug fixes, in particular:

  1) TSB hashes have to be flushed before TLB on sparc64, from Dave
     Kleikamp.

  2) LEON timer interrupts can get stuck, from Andreas Larsson.

  3) Sparc64 needs to handle lack of address-congruence devicetree
     property, from Bob Picco"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc: tsb must be flushed before tlb
  sparc,leon: Convert to use devm_ioremap_resource
  sparc64 address-congruence property
  sparc32, leon: Enable interrupts before going idle to avoid getting stuck
  sparc32, leon: Remove separate "ticker" timer for SMP
  sparc: kernel: using strlcpy() instead of strcpy()
  arch: sparc: prom: looping issue, need additional length check in the outside looping
  sparc: remove inline marking of EXPORT_SYMBOL functions
  sparc: Switch to asm-generic/linkage.h
      b9e763cd
    • L
      Merge branch 'parisc-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · aa4927b9
      由 Linus Torvalds 提交于 
      Pull parisc fixes from Helge Deller:
 "This contains a kernel segfault fix when reading /proc/kpageflags or
  /proc/kpagecount, two fixes for the serial port and PCI graphic card
  support on C8000 workstations and a fix to use unshadowed registers
  for flushing D- and I-caches."

* 'parisc-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Use unshadowed index register for flush instructions in flush_dcache_page_asm and flush_icache_page_asm
  parisc: provide pci_mmap_page_range() for parisc
  parisc: fix serial ports on C8000 workstation
  parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50 (part 2)
      aa4927b9
    • J
      metag: fix mm/hugetlb.c build breakage · 418a133b
      由 James Hogan 提交于 
      Commit 106c992a ("mm/hugetlb: add more arch-defined huge_pte
functions") 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'
  ...
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      418a133b
    • L
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 262fd6ff
      由 Linus Torvalds 提交于 
      Pull ARM fixes from Russell King:
 "The larger changes this time are

   - "ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page"
     which fixes more data corruption problems with O_DIRECT

   - "ARM: 7759/1: decouple CPU offlining from reboot/shutdown" which
     gets us back to working shutdown/reboot on SMP platforms

   - "ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect"
     which fixes a shutdown regression found in v3.10 on Versatile
     Express platforms.

  The remainder are the quite small, maybe one or two line changes"

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7759/1: decouple CPU offlining from reboot/shutdown
  ARM: 7756/1: zImage/virt: remove hyp-stub.S during distclean
  ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page
  ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B
  ARM: 7753/1: map_init_section flushes incorrect pmd
  ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect
      262fd6ff