1. 24 6月, 2013 8 次提交
  2. 23 6月, 2013 8 次提交
  3. 22 6月, 2013 7 次提交
  4. 21 6月, 2013 13 次提交
  5. 20 6月, 2013 4 次提交
    • 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
    • S
      irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case · 8b6fd652
      Shawn Guo 提交于
      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: NShawn Guo <shawn.guo@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: NJoseph Lo <josephl@nvidia.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      8b6fd652
    • 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