Skip to content
  1. Jun 27, 2013
    • Paul Gortmaker's avatar
      modpost: remove all traces of cpuinit/cpuexit sections · e24f6628
      Paul Gortmaker authored 
      

Delete all audit rules that were checking how the .cpuXYZ
related sections were inter-operating with other __init
like sections, now that __cpuinit is gone.  Update the linker
script to not have any knowledge of .cpuinit sections.

[lds.h update courtesy of Ralf Baechle <ralf@linux-mips.org>]

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      e24f6628
    • Paul Gortmaker's avatar
      init.h: remove __cpuinit sections from the kernel · 22f0a273
      Paul Gortmaker authored 
      The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

As an interim step, we can dummy out the macros to be no-ops, and
this will allow us to avoid a giant tree-wide patch, and instead
we can feed in smaller chunks mainly via the arch/ trees.  This
is in keeping with commit 78d86c21
("init.h: Remove __dev* sections from the kernel")

We don't strictly need to dummy out the macros to do this, but if
we don't then some harmless section mismatch warnings may temporarily
result.  For example, notify_cpu_starting() and cpu_up() are arch
independent (kernel/cpu.c) and are flagged as __cpuinit.  And hence
the calling functions in the arch specific code are also expected
to be __cpuinit -- if not, then we get the section mismatch warning.

Two of the three __CPUINIT variants are not used whatsoever, and
so they are simply removed directly at this point in time.

[1] https://lkml.org/lkml/2013/5/20/589



Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      22f0a273
  3. Jun 23, 2013
  5. Jun 22, 2013
  7. Jun 21, 2013
  9. Jun 20, 2013
    • Al Viro's avatar
      splice: don't pass the address of ->f_pos to methods · 7995bd28
      Al Viro authored 
      

Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      7995bd28
    • Mauro Carvalho Chehab's avatar
      [media] Fix build when drivers are builtin and frontend modules · bb69ee27
      Mauro Carvalho Chehab authored 
      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: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      bb69ee27
    • Shawn Guo's avatar
      irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case · 8b6fd652
      Shawn Guo authored 
      Commit c0114709

 (irqchip: gic: Perform the gic_secondary_init() call via
CPU notifier) moves gic_secondary_init() that used to be called in
.smp_secondary_init hook into a notifier call.  But it changes the
system behavior a little bit.  Before the commit, gic_cpu_init()
is called not only when kernel brings up the secondary cores but also
when system resuming procedure hot-plugs the cores back to kernel.
While after the commit, the function will not be called in the latter
case, where the 'action' will not be CPU_STARTING but
CPU_STARTING_FROZEN.  This behavior difference at least causes the
following suspend/resume regression on imx6q.

$ echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc1: card e624 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
PM: suspend of devices complete after 5.930 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.343 msecs
PM: noirq suspend of devices complete after 0.828 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Enabling non-boot CPUs ...
CPU1: Booted secondary processor
INFO: rcu_sched detected stalls on CPUs/tasks: { 1 2 3} (detected by 0, t=2102 jiffies, g=4294967169, c=4294967168, q=17)
Task dump for CPU 1:
swapper/1       R running      0     0      1 0x00000000
Backtrace:
[<bf895ff4>] (0xbf895ff4) from [<00000000>] (  (null))
Backtrace aborted due to bad frame pointer <8007ccdc>
Task dump for CPU 2:
swapper/2       R running      0     0      1 0x00000000
Backtrace:
[<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
Backtrace aborted due to bad frame pointer <00000002>
Task dump for CPU 3:
swapper/3       R running      0     0      1 0x00000000
Backtrace:
[<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))

Fix the regression by checking 'action' being CPU_STARTING_FROZEN to
have gic_cpu_init() called for secondary cores when system resumes.

Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
Tested-by: default avatarJoseph Lo <josephl@nvidia.com>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      8b6fd652
    • Michel Lespinasse's avatar
      x86: Fix trigger_all_cpu_backtrace() implementation · b52e0a7c
      Michel Lespinasse authored 
      

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: default avatarMichel 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.com


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b52e0a7c
    • Jed Davis's avatar
      perf: arm64: Record the user-mode PC in the call chain. · abc41254
      Jed Davis authored 
      

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: default avatarJed Davis <jld@mozilla.com>
Acked-by: default avatarIngo Molnar <mingo@kernel.org>
Acked-by: default avatarWill Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      abc41254
    • Mauro Carvalho Chehab's avatar
      [media] s5p makefiles: don't override other selections on obj-[ym] · 5f63adbb
      Mauro Carvalho Chehab authored 
      

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: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      5f63adbb
    • Aneesh Kumar K.V's avatar
      powerpc: Fix bad pmd error with book3E config · 8bbd9f04
      Aneesh Kumar K.V authored 
      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: default avatarScott Wood <scottwood@freescale.com>
Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8bbd9f04
    • Anders Hammarquist's avatar
      USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable · 35a2fbc9
      Anders Hammarquist authored 
      

Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.

Signed-off-by: default avatarAnders Hammarquist <iko@iko.pp.se>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35a2fbc9
    • Rafael J. Wysocki's avatar
      ACPI / LPSS: Power up LPSS devices during enumeration · b9e95fc6
      Rafael J. Wysocki authored 
      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: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b9e95fc6
    • Rafael J. Wysocki's avatar
      ACPI / PM: Fix error code path for power resources initialization · 6ee22e9d
      Rafael J. Wysocki authored 
      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: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: default avatarLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      6ee22e9d