1. 23 Sep, 2014 1 commit
  2. 19 Sep, 2014 3 commits
    • Bjorn Helgaas's avatar
      Revert "PCI: Make sure bus number resources stay within their parents bounds" · 12d87069
      Bjorn Helgaas authored
      This reverts commit 1820ffdc ("PCI: Make sure bus number resources stay
      within their parents bounds") because it breaks some systems with LSI Logic
      FC949ES Fibre Channel Adapters, apparently by exposing a defect in those
      adapters.
      
      Dirk tested a Tyan VX50 (B4985) with this device that worked like this
      prior to 1820ffdc:
      
          bus: [bus 00-7f] on node 0 link 1
          ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07])
          pci 0000:00:0e.0: PCI bridge to [bus 0a]
          pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07])
          pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter)
      
      Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS
      defect in the PCI0 _CRS method.  But prior to 1820ffdc, we didn't
      enforce that aperture, and the FC adapter worked fine at 0a:00.0.
      
      After 1820ffdc, we notice that 00:0e.0's aperture is not contained in
      the root bridge's aperture, so we reconfigure it so it *is* contained:
      
          pci 0000:00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring
          pci 0000:00:0e.0: PCI bridge to [bus 06-07]
      
      This effectively moves the FC device from 0a:00.0 to 07:00.0, which should
      be legal.  But when we enumerate bus 06, the FC device doesn't respond, so
      we don't find anything.  This is probably a defect in the FC device.
      
      Possible fixes (due to Yinghai):
      
          1) Add a quirk to fix the _CRS information based on what amd_bus.c read
             from the hardware
      
          2) Reset the FC device after we change its bus number
      
          3) Revert 1820ffdc
      
      Fix 1 would be relatively easy, but it does sweep the LSI FC issue under
      the rug.  We might want to reconfigure bus numbers in the future for some
      other reason, e.g., hotplug, and then we could trip over this again.
      
      For that reason, I like fix 2, but we don't know whether it actually works,
      and we don't have a patch for it yet.
      
      This revert is fix 3, which also sweeps the LSI FC issue under the rug.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84281Reported-by: default avatarDirk Gouders <dirk@gouders.net>
      Tested-by: default avatarDirk Gouders <dirk@gouders.net>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.15+
      CC: Yinghai Lu <yinghai@kernel.org>
      12d87069
    • Bjorn Helgaas's avatar
      Revert "PCI: Don't scan random busses in pci_scan_bridge()" · 7a0b33d4
      Bjorn Helgaas authored
      This reverts commit fc1b2531 ("PCI: Don't scan random busses in
      pci_scan_bridge()") because it breaks CardBus on some machines.
      
      David tested a Dell Latitude D505 that worked like this prior to
      fc1b2531:
      
          pci 0000:00:1e.0: PCI bridge to [bus 01]
          pci 0000:01:01.0: CardBus bridge to [bus 02-05]
      
      Note that the 01:01.0 CardBus bridge has a bus number aperture of
      [bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus
      number aperture, so accesses to buses 02-05 never reach CardBus.  This is
      later patched up by yenta_fixup_parent_bridge(), which changes the
      subordinate bus number of the 00:1e.0 PCI bridge:
      
          pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05
      
      With fc1b2531, pci_scan_bridge() fails immediately when it notices that
      we can't allocate a valid secondary bus number for the CardBus bridge, and
      CardBus doesn't work at all:
      
          pci 0000:01:01.0: can't allocate child bus 01 from [bus 01]
      
      I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic
      into pci_scan_bridge() so we fix the bus number apertures up front.  But
      I don't think we can do that before v3.17, so I'm going to revert this to
      avoid the problem while we're working on the long-term fix.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=83441
      Link: http://lkml.kernel.org/r/1409303414-5196-1-git-send-email-david.henningsson@canonical.comReported-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Tested-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.15+
      7a0b33d4
    • Bjorn Helgaas's avatar
      Merge branch 'pci/vga'; commit '6a73336b' into for-linus · 649ae752
      Bjorn Helgaas authored
      * pci/vga:
        vgaarb: Drop obsolete #ifndef
        vgaarb: Don't default exclusively to first video device with mem+io
      
      * commit '6a73336b':
        PCI: Remove "no hotplug settings from platform" warning
      649ae752
  3. 16 Sep, 2014 2 commits
    • Bruno Prémont's avatar
      vgaarb: Drop obsolete #ifndef · ce6eacb0
      Bruno Prémont authored
      Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
      initialization to pci_vga_fixup()") moved boot video device detection from
      efifb to x86 and ia64 pci/fixup.c.
      
      Remove the left-over #ifndef check that will always match since the
      corresponding arch-specific define is gone with above patch.
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Matthew Garrett <matthew.garrett@nebula.com>
      ce6eacb0
    • Bruno Prémont's avatar
      vgaarb: Don't default exclusively to first video device with mem+io · 86fd887b
      Bruno Prémont authored
      Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
      initialization to pci_vga_fixup()") moved boot video device detection from
      efifb to x86 and ia64 pci/fixup.c.
      
      For dual-GPU Apple computers above change represents a regression as code
      in efifb did forcefully override vga_default_device while the merge did not
      (vgaarb happens prior to PCI fixup).
      
      To improve on initial device selection by vgaarb (it cannot know if PCI
      device not behind bridges see/decode legacy VGA I/O or not), move the
      screen_info based check from pci_video_fixup() to vgaarb's init function and
      use it to refine/override decision taken while adding the individual PCI
      VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
      anymore but can depend on its value for flagging shadowed VBIOS.
      
      This has the nice benefit of removing duplicated code but does introduce a
      #if defined() block in vgaarb.  Not all architectures have screen_info and
      would cause compile to fail without it.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461Reported-and-Tested-By: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Matthew Garrett <matthew.garrett@nebula.com>
      CC: stable@vger.kernel.org # v3.5+
      86fd887b
  4. 15 Sep, 2014 2 commits
  5. 12 Sep, 2014 1 commit
  6. 10 Sep, 2014 1 commit
    • Bjorn Helgaas's avatar
      PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device · b440bde7
      Bjorn Helgaas authored
      Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
      normally generates a hot-remove event that unbinds the driver.
      
      Some drivers expect to remain bound to a device even while they power it
      off and back on again.  This can be dangerous, because if the device is
      removed or replaced while it is powered off, the driver doesn't know that
      anything changed.  But some drivers accept that risk.
      
      Add pci_ignore_hotplug() for use by drivers that know their device cannot
      be removed.  Using pci_ignore_hotplug() tells the PCI core that hot-plug
      events for the device should be ignored.
      
      The radeon and nouveau drivers use this to switch between a low-power,
      integrated GPU and a higher-power, higher-performance discrete GPU.  They
      power off the unused GPU, but they want to remain bound to it.
      
      This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau:
      Fix VGA switcheroo problem related to hotplug") but extends it to work with
      both acpiphp and pciehp.
      
      This fixes a problem where systems with dual GPUs using the radeon drivers
      become unusable, freezing every few seconds (see bugzillas below).  The
      resume of the radeon device may also fail, e.g.,
      
      This fixes problems on dual GPU systems where the radeon driver becomes
      unusable because of problems while suspending the device, as in bug 79701:
      
          [drm] radeon: finishing device.
          radeon 0000:01:00.0: Userspace still has active objects !
          radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
          ...
          WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
          trying to unbind memory from uninitialized GART !
      
      or while resuming it, as in bug 77261:
      
          radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
          radeon 0000:01:00.0: GPU lockup ...
          radeon 0000:01:00.0: GPU pci config reset
          pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
          radeon 0000:01:00.0: GPU reset succeeded, trying to resume
          *ERROR* radeon: dpm resume failed
          radeon 0000:01:00.0: Wait for MC idle timedout !
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: default avatarShawn Starr <shawn.starr@rogers.com>
      Reported-by: default avatarJose P. <lbdkmjdf@sharklasers.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Acked-by: default avatarRajat Jain <rajatxjain@gmail.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarDave Airlie <airlied@redhat.com>
      CC: stable@vger.kernel.org	# v3.15+
      b440bde7
  7. 04 Sep, 2014 3 commits
  8. 25 Aug, 2014 5 commits
    • Linus Torvalds's avatar
      Linux 3.17-rc2 · 52addcf9
      Linus Torvalds authored
      52addcf9
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · f01bfc97
      Linus Torvalds authored
      Pull NFS client fixes from Trond Myklebust:
       "Highlights:
      
         - more fixes for read/write codepath regressions
           * sleeping while holding the inode lock
           * stricter enforcement of page contiguity when coalescing requests
           * fix up error handling in the page coalescing code
      
         - don't busy wait on SIGKILL in the file locking code"
      
      * tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
        nfs: can_coalesce_requests must enforce contiguity
        nfs: disallow duplicate pages in pgio page vectors
        nfs: don't sleep with inode lock in lock_and_join_requests
        nfs: fix error handling in lock_and_join_requests
        nfs: use blocking page_group_lock in add_request
        nfs: fix nonblocking calls to nfs_page_group_lock
        nfs: change nfs_page_group_lock argument
      f01bfc97
    • Linus Torvalds's avatar
      Merge tag 'renesas-sh-drivers-for-v3.17' of... · dd5957b7
      Linus Torvalds authored
      Merge tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas
      
      Pull SH driver fix from Simon Horman:
       "Confine SH_INTC to platforms that need it"
      
      * tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
        sh: intc: Confine SH_INTC to platforms that need it
      dd5957b7
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 497c01dd
      Linus Torvalds authored
      Pull MIPS fixes from Ralf Baechle:
       "Pretty much all across the field so with this we should be in
        reasonable shape for the upcoming -rc2"
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: OCTEON: make get_system_type() thread-safe
        MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores
        MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init'
        MIPS: EVA: Add new EVA header
        MIPS: scall64-o32: Fix indirect syscall detection
        MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64
        MIPS: Loongson: Fix COP2 usage for preemptible kernel
        MIPS: NL: Fix nlm_xlp_defconfig build error
        MIPS: Remove race window in page fault handling
        MIPS: Malta: Improve system memory detection for '{e, }memsize' >= 2G
        MIPS: Alchemy: Fix db1200 PSC clock enablement
        MIPS: BCM47XX: Fix reboot problem on BCM4705/BCM4785
        MIPS: Remove duplicated include from numa.c
        MIPS: Add common plat_irq_dispatch declaration
        MIPS: MSP71xx: remove unused plat_irq_dispatch() argument
        MIPS: GIC: Remove useless parens from GICBIS().
        MIPS: perf: Mark pmu interupt IRQF_NO_THREAD
      497c01dd
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v3.17-rc1' of... · 01e9982a
      Linus Torvalds authored
      Merge tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull fix for ftrace function tracer/profiler conflict from Steven Rostedt:
       "The rewrite of the ftrace code that makes it possible to allow for
        separate trampolines had a design flaw with the interaction between
        the function and function_graph tracers.
      
        The main flaw was the simplification of the use of multiple tracers
        having the same filter (like function and function_graph, that use the
        set_ftrace_filter file to filter their code).  The design assumed that
        the two tracers could never run simultaneously as only one tracer can
        be used at a time.  The problem with this assumption was that the
        function profiler could be implemented on top of the function graph
        tracer, and the function profiler could run at the same time as the
        function tracer.  This caused the assumption to be broken and when
        ftrace detected this failed assumpiton it would spit out a nasty
        warning and shut itself down.
      
        Instead of using a single ftrace_ops that switches between the
        function and function_graph callbacks, the two tracers can again use
        their own ftrace_ops.  But instead of having a complex hierarchy of
        ftrace_ops, the filter fields are placed in its own structure and the
        ftrace_ops can carefully use the same filter.  This change took a bit
        to be able to allow for this and currently only the global_ops can
        share the same filter, but this new design can easily be modified to
        allow for any ftrace_ops to share its filter with another ftrace_ops.
      
        The first four patches deal with the change of allowing the ftrace_ops
        to share the filter (and this needs to go to 3.16 as well).
      
        The fifth patch fixes a bug that was also caused by the new changes
        but only for archs other than x86, and only if those archs implement a
        direct call to the function_graph tracer which they do not do yet but
        will in the future.  It does not need to go to stable, but needs to be
        fixed before the other archs update their code to allow direct calls
        to the function_graph trampoline"
      
      * tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        ftrace: Use current addr when converting to nop in __ftrace_replace_code()
        ftrace: Fix function_profiler and function tracer together
        ftrace: Fix up trampoline accounting with looping on hash ops
        ftrace: Update all ftrace_ops for a ftrace_hash_ops update
        ftrace: Allow ftrace_ops to use the hashes from other ops
      01e9982a
  9. 24 Aug, 2014 12 commits
  10. 23 Aug, 2014 5 commits
    • Heiko Stuebner's avatar
      MAINTAINERS: add new Rockchip SoC list · 00250b52
      Heiko Stuebner authored
      Add the new list that Rockchip-specific patches should also be directed to.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      00250b52
    • Heiko Stuebner's avatar
      ARM: dts: rockchip: readd missing mmc0 pinctrl settings · 1302d32c
      Heiko Stuebner authored
      During the restructuring of the Rockchip Cortex-A9 dtsi files it seems
      like the pinctrl settings vanished at some point from the mmc0 support.
      
      This of course renders them unusable, so readd the necessary pinctrl
      properties.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      1302d32c
    • Olof Johansson's avatar
      Merge tag 'sunxi-dt-for-3.17-2' of... · 2136edf3
      Olof Johansson authored
      Merge tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
      
      Merge "Allwinner DT changes, take 2" from Maxime Ripard:
      
      Only a single patch in here that fixes a DTC warning.
      
      * tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
        ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      2136edf3
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Use current addr when converting to nop in __ftrace_replace_code() · 39b5552c
      Steven Rostedt (Red Hat) authored
      In __ftrace_replace_code(), when converting the call to a nop in a function
      it needs to compare against the "curr" (current) value of the ftrace ops, and
      not the "new" one. It currently does not affect x86 which is the only arch
      to do the trampolines with function graph tracer, but when other archs that do
      depend on this code implement the function graph trampoline, it can crash.
      
      Here's an example when ARM uses the trampolines (in the future):
      
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 9 at kernel/trace/ftrace.c:1716 ftrace_bug+0x17c/0x1f4()
       Modules linked in: omap_rng rng_core ipv6
       CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.16.0-test-10959-gf0094b28-dirty #52
       [<c02188f4>] (unwind_backtrace) from [<c021343c>] (show_stack+0x20/0x24)
       [<c021343c>] (show_stack) from [<c095a674>] (dump_stack+0x78/0x94)
       [<c095a674>] (dump_stack) from [<c02532a0>] (warn_slowpath_common+0x7c/0x9c)
       [<c02532a0>] (warn_slowpath_common) from [<c02532ec>] (warn_slowpath_null+0x2c/0x34)
       [<c02532ec>] (warn_slowpath_null) from [<c02cbac4>] (ftrace_bug+0x17c/0x1f4)
       [<c02cbac4>] (ftrace_bug) from [<c02cc44c>] (ftrace_replace_code+0x80/0x9c)
       [<c02cc44c>] (ftrace_replace_code) from [<c02cc658>] (ftrace_modify_all_code+0xb8/0x164)
       [<c02cc658>] (ftrace_modify_all_code) from [<c02cc718>] (__ftrace_modify_code+0x14/0x1c)
       [<c02cc718>] (__ftrace_modify_code) from [<c02c7244>] (multi_cpu_stop+0xf4/0x134)
       [<c02c7244>] (multi_cpu_stop) from [<c02c6e90>] (cpu_stopper_thread+0x54/0x130)
       [<c02c6e90>] (cpu_stopper_thread) from [<c0271cd4>] (smpboot_thread_fn+0x1ac/0x1bc)
       [<c0271cd4>] (smpboot_thread_fn) from [<c026ddf0>] (kthread+0xe0/0xfc)
       [<c026ddf0>] (kthread) from [<c020f318>] (ret_from_fork+0x14/0x20)
       ---[ end trace dc9ce72c5b617d8f ]---
      [   65.047264] ftrace failed to modify [<c0208580>] asm_do_IRQ+0x10/0x1c
      [   65.054070]  actual: 85:1b:00:eb
      
      Fixes: 7413af1f "ftrace: Make get_ftrace_addr() and get_ftrace_addr_old() global"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      39b5552c
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Fix function_profiler and function tracer together · 5f151b24
      Steven Rostedt (Red Hat) authored
      The latest rewrite of ftrace removed the separate ftrace_ops of
      the function tracer and the function graph tracer and had them
      share the same ftrace_ops. This simplified the accounting by removing
      the multiple layers of functions called, where the global_ops func
      would call a special list that would iterate over the other ops that
      were registered within it (like function and function graph), which
      itself was registered to the ftrace ops list of all functions
      currently active. If that sounds confusing, the code that implemented
      it was also confusing and its removal is a good thing.
      
      The problem with this change was that it assumed that the function
      and function graph tracer can never be used at the same time.
      This is mostly true, but there is an exception. That is when the
      function profiler uses the function graph tracer to profile.
      The function profiler can be activated the same time as the function
      tracer, and this breaks the assumption and the result is that ftrace
      will crash (it detects the error and shuts itself down, it does not
      cause a kernel oops).
      
      To solve this issue, a previous change allowed the hash tables
      for the functions traced by a ftrace_ops to be a pointer and let
      multiple ftrace_ops share the same hash. This allows the function
      and function_graph tracer to have separate ftrace_ops, but still
      share the hash, which is what is done.
      
      Now the function and function graph tracers have separate ftrace_ops
      again, and the function tracer can be run while the function_profile
      is active.
      
      Cc: stable@vger.kernel.org # 3.16 (apply after 3.17-rc4 is out)
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      5f151b24
  11. 22 Aug, 2014 5 commits