1. 04 11月, 2013 1 次提交
  2. 02 11月, 2013 13 次提交
  3. 01 11月, 2013 3 次提交
  4. 31 10月, 2013 13 次提交
  5. 30 10月, 2013 10 次提交
    • M
      Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies" · ab122590
      Mika Westerberg 提交于
      Commit 2dc41281 (ACPI / hotplug / PCI: Avoid doing too much for
      spurious notifies) changed the enable_slot() to check return value of
      pci_scan_slot() and if it is zero return early from the function. It
      means that there were no new devices in this particular slot.
      
      However, if a device appeared deeper in the hierarchy the code now
      ignores it causing things like Thunderbolt chaining fail to recognize
      new devices.
      
      The problem with Alex Williamson's machine was solved with commit
      a47d8c8e (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious
      device checks) and hence we should be able to restore the original
      functionality that we always rescan on bus check notification.
      
      On a device check notification we still check what acpiphp_rescan_slot()
      returns and on zero bail out early.
      
      Fixes: 2dc41281 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies)
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ab122590
    • D
      drm: allow DRM_IOCTL_VERSION on render-nodes · 3d3b78c0
      David Herrmann 提交于
      DRM_IOCTL_VERSION is a reliable way to get the driver-name and version
      information. It's not related to the interface-version (SET_VERSION ioctl)
      so we can safely enable it on render-nodes.
      
      Note that gbm uses udev-BUSID to load the correct mesa driver. However,
      the VERSION ioctl should be the more reliable way to do this (in case we
      add new DRM-bus drivers which have no BUSID or similar).
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3d3b78c0
    • N
      bgmac: don't update slot on skb alloc/dma mapping error · b757a62e
      Nathan Hintz 提交于
      Don't update the slot in "bgmac_dma_rx_skb_for_slot" unless both the
      skb alloc and dma mapping are successful; and free the newly allocated
      skb if a dma mapping error occurs.  This relieves the caller of the need
      to deduce/execute the appropriate cleanup action required when an error
      occurs.
      Signed-off-by: NNathan Hintz <nlhintz@hotmail.com>
      Acked-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b757a62e
    • A
      ibm emac: Fix locking for enable/disable eob irq · 32663b8b
      Alistair Popple 提交于
      Calls to mal_enable_eob_irq perform a read-write-modify of a dcr to
      enable device irqs which is protected by a spin lock. However calls to
      mal_disable_eob_irq do not take the corresponding lock.
      
      This patch resolves the problem by ensuring that calls to
      mal_disable_eob_irq also take the lock.
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32663b8b
    • A
      ibm emac: Don't call napi_complete if napi_reschedule failed · b4dfd326
      Alistair Popple 提交于
      This patch fixes a bug which would trigger the BUG_ON() at
      net/core/dev.c:4156. It was found that this was due to continuing
      processing in the current poll call even when the call to
      napi_reschedule failed, indicating the device was already on the
      polling list. This resulted in an extra call to napi_complete which
      triggered the BUG_ON().
      
      This patch ensures that we only contine processing rotting packets in
      the current mal_poll call if we are not already on the polling list.
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4dfd326
    • J
      virtio-net: correctly handle cpu hotplug notifier during resuming · ec9debbd
      Jason Wang 提交于
      commit 3ab098df (virtio-net: don't respond to
      cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug
      notifier by checking the config_enable and does nothing is it was false. So it
      need to try to hold the config_lock mutex which may happen in atomic
      environment which leads the following warnings:
      
      [  622.944441] CPU0 attaching NULL sched-domain.
      [  622.944446] CPU1 attaching NULL sched-domain.
      [  622.944485] CPU0 attaching NULL sched-domain.
      [  622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616
      [  622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1
      [  622.950796] no locks held by migration/1/10.
      [  622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317
      [  622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [  622.950802]  0000000000000000 ffff88001d42dba0 ffffffff81a32f22 ffff88001bfb9c70
      [  622.950803]  ffff88001d42dbb0 ffffffff810edb02 ffff88001d42dc38 ffffffff81a396ed
      [  622.950805]  0000000000000046 ffff88001d42dbe8 ffffffff810e861d 0000000000000000
      [  622.950805] Call Trace:
      [  622.950810]  [<ffffffff81a32f22>] dump_stack+0x54/0x74
      [  622.950815]  [<ffffffff810edb02>] __might_sleep+0x112/0x114
      [  622.950817]  [<ffffffff81a396ed>] mutex_lock_nested+0x3c/0x3c6
      [  622.950818]  [<ffffffff810e861d>] ? up+0x39/0x3e
      [  622.950821]  [<ffffffff8153ea7c>] ? acpi_os_signal_semaphore+0x21/0x2d
      [  622.950824]  [<ffffffff81565ed1>] ? acpi_ut_release_mutex+0x5e/0x62
      [  622.950828]  [<ffffffff816d04ec>] virtnet_cpu_callback+0x33/0x87
      [  622.950830]  [<ffffffff81a42576>] notifier_call_chain+0x3c/0x5e
      [  622.950832]  [<ffffffff810e86a8>] __raw_notifier_call_chain+0xe/0x10
      [  622.950835]  [<ffffffff810c5556>] __cpu_notify+0x20/0x37
      [  622.950836]  [<ffffffff810c5580>] cpu_notify+0x13/0x15
      [  622.950838]  [<ffffffff81a237cd>] take_cpu_down+0x27/0x3a
      [  622.950841]  [<ffffffff81136289>] stop_machine_cpu_stop+0x93/0xf1
      [  622.950842]  [<ffffffff81136167>] cpu_stopper_thread+0xa0/0x12f
      [  622.950844]  [<ffffffff811361f6>] ? cpu_stopper_thread+0x12f/0x12f
      [  622.950847]  [<ffffffff81119710>] ? lock_release_holdtime.part.7+0xa3/0xa8
      [  622.950848]  [<ffffffff81135e4b>] ? cpu_stop_should_run+0x3f/0x47
      [  622.950850]  [<ffffffff810ea9b0>] smpboot_thread_fn+0x1c5/0x1e3
      [  622.950852]  [<ffffffff810ea7eb>] ? lg_global_unlock+0x67/0x67
      [  622.950854]  [<ffffffff810e36b7>] kthread+0xd8/0xe0
      [  622.950857]  [<ffffffff81a3bfad>] ? wait_for_common+0x12f/0x164
      [  622.950859]  [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
      [  622.950861]  [<ffffffff81a45ffc>] ret_from_fork+0x7c/0xb0
      [  622.950862]  [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
      [  622.950876] smpboot: CPU 1 is now offline
      [  623.194556] SMP alternatives: lockdep: fixing up alternatives
      [  623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1
      ...
      
      A correct fix is to unregister the hotcpu notifier during restore and register a
      new one in resume.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Tested-by: NFengguang Wu <fengguang.wu@intel.com>
      Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec9debbd
    • B
      usb: cdc-wdm: ignore speed change notifications · 9983d6dc
      Bjørn Mork 提交于
      The only notification supported by the Device Management class is
      Response Available. But this driver is also used as a subdriver of
      other CDC classes, allowing notifications like Speed Change and
      Network Connection. This results in log messages which are only
      confusing to an end user:
      
       [66255.801874] cdc_mbim 1-3:1.5: unknown notification 42 received: index 5 len 8
      
      These drivers use cdc-wdm as a subdriver to allow access to an
      embedded management protocol, and all management is expected to
      use this protocol. There is therefore no need to handle any of
      these optional CDC notifications. Instead we can let the cdc-wdm
      driver recognize them and log a debug level message instead of an
      error.
      Reported-by: NRob Gardner <robmatic@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9983d6dc
    • G
      USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications · 73e06865
      Greg Suarez 提交于
      Some MBIM devices send back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications
      when sending a message over multiple fragments or when there are unsolicited
      messages available.
      
      Count up the number of USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications received
      and decrement the count and submit the urb for the next response each time userspace
      completes a read the response.
      Signed-off-by: NGreg Suarez <gsuarez@smithmicro.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73e06865
    • M
      d27f25c9
    • M
      w1-gpio: Detect of_gpio_error for first gpio · 7cf1a122
      Markus Pargmann 提交于
      The first DT gpio is necessary for this driver, but errors returned for
      of_get_gpio are ignored.
      
      This patch adds a return value check for the first of_get_gpio.
      Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
      Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cf1a122