1. 31 8月, 2013 1 次提交
  2. 29 8月, 2013 1 次提交
    • D
      dev-core: fix build break when DEBUG is enabled · 8ef2d651
      Dmitry Kasatkin 提交于
      When DEBUG is defined, dev_dbg_ratelimited uses dynamic debug data
      structures even when CONFIG_DYNAMIC_DEBUG is not defined.
      It leads to build break.
      For example, when I try to use dev_dbg_ratelimited in USB code and
      CONFIG_USB_DEBUG is enabled, but CONFIG_DYNAMIC_DEBUG is not, I get:
      
        CC [M]  drivers/usb/host/xhci-ring.o
        drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_intr_tx’:
        drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function ‘DEFINE_DYNAMIC_DEBUG_METADATA’ [-Werror=implicit-function-declaration]
        drivers/usb/host/xhci-ring.c:3059:3: error: ‘descriptor’ undeclared (first use in this function)
        drivers/usb/host/xhci-ring.c:3059:3: note: each undeclared identifier is reported only once for each function it appears in
        drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function ‘__dynamic_pr_debug’ [-Werror=implicit-function-declaration]
        drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_isoc_tx_prepare’:
        drivers/usb/host/xhci-ring.c:3847:3: error: ‘descriptor’ undeclared (first use in this function)
        cc1: some warnings being treated as errors
        make[2]: *** [drivers/usb/host/xhci-ring.o] Error 1
        make[1]: *** [drivers/usb/host] Error 2
        make: *** [drivers/usb/] Error 2
      
      This patch separates definition for CONFIG_DYNAMIC_DEBUG and DEBUG cases.
      
      [Note, Sarah moved the comment above the macro to avoid checkpatch
      warnings.]
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ef2d651
  3. 16 8月, 2013 3 次提交
    • L
      Fix TLB gather virtual address range invalidation corner cases · 2b047252
      Linus Torvalds 提交于
      Ben Tebulin reported:
      
       "Since v3.7.2 on two independent machines a very specific Git
        repository fails in 9/10 cases on git-fsck due to an SHA1/memory
        failures.  This only occurs on a very specific repository and can be
        reproduced stably on two independent laptops.  Git mailing list ran
        out of ideas and for me this looks like some very exotic kernel issue"
      
      and bisected the failure to the backport of commit 53a59fc6 ("mm:
      limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT").
      
      That commit itself is not actually buggy, but what it does is to make it
      much more likely to hit the partial TLB invalidation case, since it
      introduces a new case in tlb_next_batch() that previously only ever
      happened when running out of memory.
      
      The real bug is that the TLB gather virtual memory range setup is subtly
      buggered.  It was introduced in commit 597e1c35 ("mm/mmu_gather:
      enable tlb flush range in generic mmu_gather"), and the range handling
      was already fixed at least once in commit e6c495a9 ("mm: fix the TLB
      range flushed when __tlb_remove_page() runs out of slots"), but that fix
      was not complete.
      
      The problem with the TLB gather virtual address range is that it isn't
      set up by the initial tlb_gather_mmu() initialization (which didn't get
      the TLB range information), but it is set up ad-hoc later by the
      functions that actually flush the TLB.  And so any such case that forgot
      to update the TLB range entries would potentially miss TLB invalidates.
      
      Rather than try to figure out exactly which particular ad-hoc range
      setup was missing (I personally suspect it's the hugetlb case in
      zap_huge_pmd(), which didn't have the same logic as zap_pte_range()
      did), this patch just gets rid of the problem at the source: make the
      TLB range information available to tlb_gather_mmu(), and initialize it
      when initializing all the other tlb gather fields.
      
      This makes the patch larger, but conceptually much simpler.  And the end
      result is much more understandable; even if you want to play games with
      partial ranges when invalidating the TLB contents in chunks, now the
      range information is always there, and anybody who doesn't want to
      bother with it won't introduce subtle bugs.
      
      Ben verified that this fixes his problem.
      Reported-bisected-and-tested-by: NBen Tebulin <tebulin@googlemail.com>
      Build-testing-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Build-testing-by: NRichard Weinberger <richard.weinberger@gmail.com>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b047252
    • T
      USB: WUSBCORE: clear RPIPE stall for control endpoints · 6d33f7bb
      Thomas Pugliese 提交于
      When the HWA encounters a STALL on a control endpoint, it should clear the
      RPIPE_STALL feature on the RPIPE before processing the next transfer
      request.  Otherwise, all transfer requests on that endpoint after the
      first STALL will fail because the RPIPE is still in the halted state.
      This also removes the unneccessary call to spin_lock_irqsave for a nested
      lock that was present in the first patch.
      Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d33f7bb
    • M
      net/mlx5_core: Support MANAGE_PAGES and QUERY_PAGES firmware command changes · 0a324f31
      Moshe Lazer 提交于
      In the previous QUERY_PAGES command version we used one command to get the
      required amount of boot, init and post init pages.  The new version uses the
      op_mod field to specify whether the query is for the required amount of boot,
      init or post init pages. In addition the output field size for the required
      amount of pages increased from 16 to 32 bits.
      
      In MANAGE_PAGES command the input_num_entries and output_num_entries fields
      sizes changed from 16 to 32 bits and the PAS tables offset changed to 0x10.
      
      In the pages request event the num_pages field also changed to 32 bits.
      
      In the HCA-capabilities-layout the size and location of max_qp_mcg field has
      been changed to support 24 bits.
      
      This patch isn't compatible with firmware versions < 5; however, it  turns out that the
      first GA firmware we will publish will not support previous versions so this should be OK.
      Signed-off-by: NMoshe Lazer <moshel@mellanox.com>
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a324f31
  4. 15 8月, 2013 4 次提交
  5. 14 8月, 2013 5 次提交
  6. 13 8月, 2013 6 次提交
    • O
      sched: fix the theoretical signal_wake_up() vs schedule() race · e0acd0a6
      Oleg Nesterov 提交于
      This is only theoretical, but after try_to_wake_up(p) was changed
      to check p->state under p->pi_lock the code like
      
      	__set_current_state(TASK_INTERRUPTIBLE);
      	schedule();
      
      can miss a signal. This is the special case of wait-for-condition,
      it relies on try_to_wake_up/schedule interaction and thus it does
      not need mb() between __set_current_state() and if(signal_pending).
      
      However, this __set_current_state() can move into the critical
      section protected by rq->lock, now that try_to_wake_up() takes
      another lock we need to ensure that it can't be reordered with
      "if (signal_pending(current))" check inside that section.
      
      The patch is actually one-liner, it simply adds smp_wmb() before
      spin_lock_irq(rq->lock). This is what try_to_wake_up() already
      does by the same reason.
      
      We turn this wmb() into the new helper, smp_mb__before_spinlock(),
      for better documentation and to allow the architectures to change
      the default implementation.
      
      While at it, kill smp_mb__after_lock(), it has no callers.
      
      Perhaps we can also add smp_mb__before/after_spinunlock() for
      prepare_to_wait().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e0acd0a6
    • M
      USBNET: support DMA SG · 638c5115
      Ming Lei 提交于
      This patch introduces support of DMA SG if the USB host controller
      which usbnet device is attached to is capable of building packet from
      discontinuous buffers.
      
      The patch supports passing the skb fragment buffers to usb stack directly
      via urb->sg.
      
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Cc: Grant Grundler <grundler@google.com>
      Cc: Freddy Xin <freddy@asix.com.tw>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      638c5115
    • M
      USB: introduce usb_device_no_sg_constraint() helper · bcc48f1a
      Ming Lei 提交于
      Some host controllers(such as xHCI) can support building
      packet from discontinuous buffers, so introduce one flag
      and helper for this kind of host controllers, then the
      feature can help some applications(such as usbnet) by
      supporting arbitrary length of sg buffers.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcc48f1a
    • M
      USB: HCD: support giveback of URB in tasklet context · 94dfd7ed
      Ming Lei 提交于
      This patch implements the mechanism of giveback of URB in
      tasklet context, so that hardware interrupt handling time for
      usb host controller can be saved much, and HCD interrupt handling
      can be simplified.
      
      Motivations:
      
      1), on some arch(such as ARM), DMA mapping/unmapping is a bit
      time-consuming, for example: when accessing usb mass storage
      via EHCI on pandaboard, the common length of transfer buffer is 120KB,
      the time consumed on DMA unmapping may reach hundreds of microseconds;
      even on A15 based box, the time is still about scores of microseconds
      
      2), on some arch, reading DMA coherent memoery is very time-consuming,
      the most common example is usb video class driver[1]
      
      3), driver's complete() callback may do much things which is driver
      specific, so the time is consumed unnecessarily in hardware irq context.
      
      4), running driver's complete() callback in hardware irq context causes
      that host controller driver has to release its lock in interrupt handler,
      so reacquiring the lock after return may busy wait a while and increase
      interrupt handling time. More seriously, releasing the HCD lock makes
      HCD becoming quite complicated to deal with introduced races.
      
      So the patch proposes to run giveback of URB in tasklet context, then
      time consumed in HCD irq handling doesn't depend on drivers' complete and
      DMA mapping/unmapping any more, also we can simplify HCD since the HCD
      lock isn't needed to be released during irq handling.
      
      The patch should be reasonable and doable:
      
      1), for drivers, they don't care if the complete() is called in hard irq
      context or softirq context
      
      2), the biggest change is the situation in which usb_submit_urb() is called
      in complete() callback, so the introduced tasklet schedule delay might be a
      con, but it shouldn't be a big deal:
      
      	- control/bulk asynchronous transfer isn't sensitive to schedule
      	  delay
      
      	- the patch schedules giveback of periodic URBs using
      	  tasklet_hi_schedule, so the introduced delay should be very
      	  small
      
      	- for ISOC transfer, generally, drivers submit several URBs
      	  concurrently to avoid interrupt delay, so it is OK with the
      	  little schedule delay.
      
      	- for interrupt transfer, generally, drivers only submit one URB
      	  at the same time, but interrupt transfer is often used in event
      	  report, polling, ... situations, and a little delay should be OK.
      
      Considered that HCDs may optimize on submitting URB in complete(), the
      patch may cause the optimization not working, so introduces one flag to mark
      if the HCD supports to run giveback URB in tasklet context. When all HCDs
      are ready, the flag can be removed.
      
      [1], http://marc.info/?t=136438111600010&r=1&w=2
      
      Cc: Oliver Neukum <oliver@neukum.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94dfd7ed
    • T
      usb: phy: tegra: Program new PHY parameters · e497a24d
      Tuomas Tynkkynen 提交于
      The Tegra30 TRM recommends configuration of certain PHY parameters for
      optimal quality. Program the following registers based on device tree
      parameters:
      
      - UTMIP_XCVR_HSSLEW: HS slew rate control.
      - UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
      - UTMIP_HSDISCON_LEVEL: HS disconnect detector level.
      
      These registers exist in Tegra20, but programming them hasn't been
      necessary, so these parameters won't be set on Tegra20 to keep the
      device trees backward compatible.
      
      Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses
      instead of a software-programmed value, as the optimal value can
      vary between invidual boards. The boolean property
      nvidia,xcvr-setup-use-fuses can be used to enable this behaviour.
      Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e497a24d
    • T
      usb: phy: tegra: Tegra30 support · 3e635202
      Tuomas Tynkkynen 提交于
      The Tegra30 USB PHY is a bit different than the Tegra20 PHY:
      
      - The EHCI controller supports the HOSTPC register extension, and some
        of the fields that the PHY needs to modify (PHCD and PTS) have moved
        to the new HOSTPC register.
      - Some of the UTMI PLL configuration registers have moved from the USB
        register space to the Clock-And-Reset controller space. In Tegra30
        the clock driver is responsible for configuring the UTMI PLL.
      - The USBMODE register must be explicitly written to enter host mode.
      - Certain PHY parameters need to be programmed for optimal signal
        quality. Support for this will be added in the next patch.
      
      The new tegra_phy_soc_config structure is added to describe the
      differences between the SoCs.
      Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      3e635202
  7. 10 8月, 2013 1 次提交
  8. 09 8月, 2013 2 次提交
  9. 08 8月, 2013 2 次提交
    • T
      SUNRPC: If the rpcbind channel is disconnected, fail the call to unregister · 786615bc
      Trond Myklebust 提交于
      If rpcbind causes our connection to the AF_LOCAL socket to close after
      we've registered a service, then we want to be careful about reconnecting
      since the mount namespace may have changed.
      
      By simply refusing to reconnect the AF_LOCAL socket in the case of
      unregister, we avoid the need to somehow save the mount namespace. While
      this may lead to some services not unregistering properly, it should
      be safe.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Nix <nix@esperi.org.uk>
      Cc: Jeff Layton <jlayton@redhat.com>
      Cc: stable@vger.kernel.org # 3.9.x
      786615bc
    • R
      ACPI: Try harder to resolve _ADR collisions for bridges · 60f75b8e
      Rafael J. Wysocki 提交于
      In theory, under a given ACPI namespace node there should be only
      one child device object with _ADR whose value matches a given bus
      address exactly.  In practice, however, there are systems in which
      multiple child device objects under a given parent have _ADR matching
      exactly the same address.  In those cases we use _STA to determine
      which of the multiple matching devices is enabled, since some systems
      are known to indicate which ACPI device object to associate with the
      given physical (usually PCI) device this way.
      
      Unfortunately, as it turns out, there are systems in which many
      device objects under the same parent have _ADR matching exactly the
      same bus address and none of them has _STA, in which case they all
      should be regarded as enabled according to the spec.  Still, if
      those device objects are supposed to represent bridges (e.g. this
      is the case for device objects corresponding to PCIe ports), we can
      try harder and skip the ones that have no child device objects in the
      ACPI namespace.  With luck, we can avoid using device objects that we
      are not expected to use this way.
      
      Although this only works for bridges whose children also have ACPI
      namespace representation, it is sufficient to address graphics
      adapter detection issues on some systems, so rework the code finding
      a matching device ACPI handle for a given bus address to implement
      this idea.
      
      Introduce a new function, acpi_find_child(), taking three arguments:
      the ACPI handle of the device's parent, a bus address suitable for
      the device's bus type and a bool indicating if the device is a
      bridge and make it work as outlined above.  Reimplement the function
      currently used for this purpose, acpi_get_child(), as a call to
      acpi_find_child() with the last argument set to 'false' and make
      the PCI subsystem use acpi_find_child() with the bridge information
      passed as the last argument to it.  [Lan Tianyu notices that it is
      not sufficient to use pci_is_bridge() for that, because the device's
      subordinate pointer hasn't been set yet at this point, so use
      hdr_type instead.]
      
      This change fixes a regression introduced inadvertently by commit
      33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which
      overlooked the fact that for acpi_walk_namespace() "post-order" means
      "after all children have been visited" rather than "on the way back",
      so for device objects without children and for namespace walks of
      depth 1, as in the acpi_get_child() case, the "post-order" callbacks
      ordering is actually the same as the ordering of "pre-order" ones.
      Since that commit changed the namespace walk in acpi_get_child() to
      terminate after finding the first matching object instead of going
      through all of them and returning the last one, it effectively
      changed the result returned by that function in some rare cases and
      that led to problems (the switch from a "pre-order" to a "post-order"
      callback was supposed to prevent that from happening, but it was
      ineffective).
      
      As it turns out, the systems where the change made by commit
      33f767d7 actually matters are those where there are multiple ACPI
      device objects representing the same PCIe port (which effectively
      is a bridge).  Moreover, only one of them, and the one we are
      expected to use, has child device objects in the ACPI namespace,
      so the regression can be addressed as described above.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by: NPeter Wu <lekensteyn@gmail.com>
      Tested-by: NVladimir Lalov <mail@vlalov.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
      60f75b8e
  10. 07 8月, 2013 1 次提交
  11. 06 8月, 2013 2 次提交
  12. 05 8月, 2013 1 次提交
  13. 03 8月, 2013 3 次提交
  14. 02 8月, 2013 3 次提交
    • C
      net: rename CONFIG_NET_LL_RX_POLL to CONFIG_NET_RX_BUSY_POLL · e0d1095a
      Cong Wang 提交于
      Eliezer renames several *ll_poll to *busy_poll, but forgets
      CONFIG_NET_LL_RX_POLL, so in case of confusion, rename it too.
      
      Cc: Eliezer Tamir <eliezer.tamir@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0d1095a
    • C
      net: fix a compile error when CONFIG_NET_LL_RX_POLL is not set · dfcefb0b
      Cong Wang 提交于
      When CONFIG_NET_LL_RX_POLL is not set, I got:
      
      net/socket.c: In function ‘sock_poll’:
      net/socket.c:1165:4: error: implicit declaration of function ‘sk_busy_loop’ [-Werror=implicit-function-declaration]
      
      Fix this by adding a nop when !CONFIG_NET_LL_RX_POLL.
      
      Cc: Eliezer Tamir <eliezer.tamir@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dfcefb0b
    • M
      ipv6: prevent fib6_run_gc() contention · 2ac3ac8f
      Michal Kubeček 提交于
      On a high-traffic router with many processors and many IPv6 dst
      entries, soft lockup in fib6_run_gc() can occur when number of
      entries reaches gc_thresh.
      
      This happens because fib6_run_gc() uses fib6_gc_lock to allow
      only one thread to run the garbage collector but ip6_dst_gc()
      doesn't update net->ipv6.ip6_rt_last_gc until fib6_run_gc()
      returns. On a system with many entries, this can take some time
      so that in the meantime, other threads pass the tests in
      ip6_dst_gc() (ip6_rt_last_gc is still not updated) and wait for
      the lock. They then have to run the garbage collector one after
      another which blocks them for quite long.
      
      Resolve this by replacing special value ~0UL of expire parameter
      to fib6_run_gc() by explicit "force" parameter to choose between
      spin_lock_bh() and spin_trylock_bh() and call fib6_run_gc() with
      force=false if gc_thresh is reached but not max_size.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ac3ac8f
  15. 01 8月, 2013 5 次提交
新手
引导
客服 返回
顶部