1. 27 6月, 2013 6 次提交
  2. 21 6月, 2013 3 次提交
  3. 20 6月, 2013 8 次提交
    • 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
      [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
      USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable · 35a2fbc9
      Anders Hammarquist 提交于
      Add product id for Abbott strip port cable for Precision meter which
      uses the TI 3410 chip.
      Signed-off-by: NAnders Hammarquist <iko@iko.pp.se>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35a2fbc9
    • 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
  4. 19 6月, 2013 5 次提交
  5. 18 6月, 2013 3 次提交
  6. 17 6月, 2013 2 次提交
  7. 15 6月, 2013 1 次提交
  8. 14 6月, 2013 8 次提交
    • R
      tcm_qla2xxx: Fix residual for underrun commands that fail · b5aff3d2
      Roland Dreier 提交于
      Suppose an initiator sends a DATA IN command with an allocation length
      shorter than the FC transfer length -- we get a target message like
      
          TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB Length: 0 for SAM Opcode: 0x12
      
      In that case, the target core adjusts the data_length and sets
      se_cmd->residual_count for the underrun.  But now suppose that command
      fails and we end up in tcm_qla2xxx_queue_status() -- that function
      unconditionally overwrites residual_count with the already adjusted
      data_length, and the initiator will burp with a message like
      
          qla2xxx [0000:00:06.0]-301d:0: Dropped frame(s) detected (0x100 of 0x100 bytes).
      
      Fix this by adding on to the existing underflow residual count instead.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Cc: Chad Dupuis <chad.dupuis@qlogic.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      b5aff3d2
    • J
      target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer() · 574780fd
      Jörn Engel 提交于
      Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
      almost two years ago.  I have no idea why we only started seeing it now,
      but we did.
      
      Rough callgraph:
      core_tpg_set_initiator_node_queue_depth()
      `-> spin_lock_irqsave(&tpg->session_lock, flags);
      `-> lio_tpg_shutdown_session()
          `-> iscsit_stop_time2retain_timer()
              `-> spin_unlock_bh(&se_tpg->session_lock);
              `-> spin_lock_bh(&se_tpg->session_lock);
      `-> spin_unlock_irqrestore(&tpg->session_lock, flags);
      
      core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
      but 140854cb changed that to spin_lock_irqsave().  However,
      lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
      held, as does iscsit_stop_time2retain_timer():
       *      Called with spin_lock_bh(&struct se_portal_group->session_lock) held
      
      Stale documentation is mostly annoying, but in this case the dropping
      the lock with the _bh variant is plain wrong.  It is also wrong to drop
      locks two functions below the lock-holder, but I will ignore that bit
      for now.
      
      After some more locking and unlocking we eventually hit this backtrace:
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
      Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
      Call Trace:
       [<ffffffff8103e5ff>] warn_slowpath_common+0x7f/0xc0
       [<ffffffffa040ae37>] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
       [<ffffffff8103e65a>] warn_slowpath_null+0x1a/0x20
       [<ffffffff810472f8>] local_bh_enable_ip+0xe8/0x100
       [<ffffffff815b8365>] _raw_spin_unlock_bh+0x15/0x20
       [<ffffffffa040ae37>] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
       [<ffffffffa041149a>] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
       [<ffffffffa0417fab>] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
       [<ffffffffa033ede4>] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
       [<ffffffffa0409032>] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
       [<ffffffffa0415c29>] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
       [<ffffffffa0331b49>] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
       [<ffffffff811b857d>] configfs_write_file+0xbd/0x120
       [<ffffffff81148f36>] vfs_write+0xc6/0x180
       [<ffffffff81149251>] sys_write+0x51/0x90
       [<ffffffff815c0969>] system_call_fastpath+0x16/0x1b
      ---[ end trace 3747632b9b164652 ]---
      
      As a pure band-aid, this patch drops the _bh.
      Signed-off-by: NJoern Engel <joern@logfs.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      574780fd
    • T
      mei: me: clear interrupts on the resume path · 42f132fe
      Tomas Winkler 提交于
      We need to clear pending interrupts on the resume
      path. This brings the device into defined state
      before starting the reset flow
      
      This should solve suspend/resume issues:
      
      mei_me : wait hw ready failed. status = 0x0
      mei_me : version message write failed
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42f132fe
    • T
      mei: nfc: fix nfc device freeing · 2753ff53
      Tomas Winkler 提交于
      The nfc_dev is a static variable and is not cleaned properly upon reset
      mainly ndev->cl and ndev->cl_info are not set to NULL after freeing which
      
      mei_stop:198: mei_me 0000:00:16.0: stopping the device.
      [  404.253427] general protection fault: 0000 [#2] SMP
      [  404.253437] Modules linked in: mei_me(-) binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave fuse loop dm_mod hid_generic usbhid hid coretemp acpi_cpufreq mperf kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul snd_hda_codec_hdmi glue_helper aes_x86_64 e1000e snd_hda_intel snd_hda_codec ehci_pci iTCO_wdt iTCO_vendor_support ehci_hcd snd_hwdep xhci_hcd snd_pcm usbcore ptp mei sg microcode snd_timer pps_core i2c_i801 snd pcspkr battery rtc_cmos lpc_ich mfd_core soundcore usb_common snd_page_alloc ac ext3 jbd mbcache drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt i2c_core sd_mod crc_t10dif thermal fan video button processor thermal_sys hwmon ahci libahci libata scsi_mod [last unloaded: mei_me]
      [  404.253591] CPU: 0 PID: 5551 Comm: modprobe Tainted: G      D W    3.10.0-rc3 #1
      [  404.253611] task: ffff880143cd8300 ti: ffff880144a2a000 task.ti: ffff880144a2a000
      [  404.253619] RIP: 0010:[<ffffffff81334e5d>]  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
      [  404.253638] RSP: 0018:ffff880144a2bcf8  EFLAGS: 00010206
      [  404.253645] RAX: 2020302e30202030 RBX: ffff880144fdb000 RCX: 0000000000000086
      [  404.253652] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffff880144fdb000
      [  404.253659] RBP: ffff880144a2bd18 R08: 0000000000000651 R09: 0000000000000006
      [  404.253666] R10: 0000000000000651 R11: 0000000000000006 R12: ffff880144fdb000
      [  404.253673] R13: ffff880149371098 R14: ffff880144482c00 R15: ffffffffa04710e0
      [  404.253681] FS:  00007f251c59a700(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
      [  404.253689] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  404.253696] CR2: ffffffffff600400 CR3: 0000000145319000 CR4: 00000000001407f0
      [  404.253703] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  404.253710] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  404.253716] Stack:
      [  404.253720]  ffff880144fdb000 ffff880143ffe000 ffff880149371098 ffffffffa0471000
      [  404.253732]  ffff880144a2bd38 ffffffff8133502d ffff88014e20cf48 ffff880143ffe1d8
      [  404.253744]  ffff880144a2bd48 ffffffffa02a4749 ffff880144a2bd58 ffffffffa02a4ba1
      [  404.253755] Call Trace:
      [  404.253766]  [<ffffffff8133502d>] device_unregister+0x1d/0x60
      [  404.253787]  [<ffffffffa02a4749>] mei_cl_remove_device+0x9/0x10 [mei]
      [  404.253804]  [<ffffffffa02a4ba1>] mei_nfc_host_exit+0x21/0x30 [mei]
      [  404.253819]  [<ffffffffa029c2dd>] mei_stop+0x3d/0x90 [mei]
      [  404.253830]  [<ffffffffa046e220>] mei_me_remove+0x60/0xe0 [mei_me]
      [  404.253843]  [<ffffffff81278f37>] pci_device_remove+0x37/0xb0
      [  404.253855]  [<ffffffff81337c68>] __device_release_driver+0x98/0x100
      [  404.253865]  [<ffffffff81337d80>] driver_detach+0xb0/0xc0
      [  404.253876]  [<ffffffff81336b4f>] bus_remove_driver+0x8f/0x120
      [  404.253891]  [<ffffffff81075990>] ? try_to_wake_up+0x2b0/0x2b0
      [  404.253903]  [<ffffffff81338a48>] driver_unregister+0x58/0x90
      [  404.253913]  [<ffffffff8127906b>] pci_unregister_driver+0x2b/0xb0
      [  404.253924]  [<ffffffffa046f244>] mei_me_driver_exit+0x10/0xdcc [mei_me]
      [  404.253936]  [<ffffffff810a50d8>] SyS_delete_module+0x198/0x2b0
      [  404.253949]  [<ffffffff814850d9>] ? do_page_fault+0x9/0x10
      [  404.253961]  [<ffffffff81489692>] system_call_fastpath+0x16/0x1b
      [  404.253967] Code: 41 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc 53 48 8b 87 88 00 00 00 4c 8b 37 48 85 c0 74 18 <48> 8b 78 78 4c 89 e2 be 02 00 00 00 48 81 c7 f8 00 00 00 e8 3b
      [  404.254048] RIP  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2753ff53
    • S
      mei: init: Flush scheduled work before resetting the device · 5e85b364
      Samuel Ortiz 提交于
      Flushing pending work items before resetting the device makes more
      sense than doing so afterwards. Some of them, like e.g. the NFC
      initialization one, find themselves with client IDs changed after
      the reset, eventually leading to trigger a client.c:mei_me_cl_by_id()
      warning after a few modprobe/rmmod cycles.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e85b364
    • B
      netiucv: Hold rtnl between name allocation and device registration. · aaf9522d
      Benjamin Poirier 提交于
      fixes a race condition between concurrent initializations of netiucv devices
      that try to use the same name.
      
      sysfs: cannot create duplicate filename '/devices/iucv/netiucv2'
      [...]
      Call Trace:
      ([<00000000002edea4>] sysfs_add_one+0xb0/0xdc)
       [<00000000002eecd4>] create_dir+0x80/0xfc
       [<00000000002eee38>] sysfs_create_dir+0xe8/0x118
       [<00000000003835a8>] kobject_add_internal+0x120/0x2d0
       [<00000000003839d6>] kobject_add+0x62/0x9c
       [<00000000003d9564>] device_add+0xcc/0x510
       [<000003e00212c7b4>] netiucv_register_device+0xc0/0x1ec [netiucv]
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
      Tested-by: NUrsula Braun <braunu@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aaf9522d
    • N
      tulip: Properly check dma mapping result · c9bfbb31
      Neil Horman 提交于
      Tulip throws an error when dma debugging is enabled, as it doesn't properly
      check dma mapping results with dma_mapping_error() durring tx ring refills.
      
      Easy fix, just add it in, and drop the frame if the mapping is bad
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Grant Grundler <grundler@parisc-linux.org>
      CC: "David S. Miller" <davem@davemloft.net>
      Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9bfbb31
    • B
      of: Fix locking vs. interrupts · d25d8694
      Benjamin Herrenschmidt 提交于
      The OF code uses irqsafe locks everywhere except in a handful of functions
      for no obvious reasons. Since the conversion from the old rwlocks, this
      now triggers lockdep warnings when used at interrupt time. At least one
      driver (ibmvscsi) seems to be doing that from softirq context.
      
      This converts the few non-irqsafe locks into irqsafe ones, making them
      consistent with the rest of the code.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      d25d8694
  9. 13 6月, 2013 4 次提交