1. 04 Apr, 2018 15 commits
  2. 03 Apr, 2018 6 commits
    • Bjorn Helgaas's avatar
      fm10k: Report PCIe link properties with pcie_print_link_status() · 170648fd
      Bjorn Helgaas authored
      Previously the driver used pcie_get_minimum_link() to warn when the NIC
      is in a slot that can't supply as much bandwidth as the NIC could use.
      
      pcie_get_minimum_link() can be misleading because it finds the slowest link
      and the narrowest link (which may be different links) without considering
      the total bandwidth of each link.  For a path with a 16 GT/s x1 link and a
      2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
      bandwidth, not the true available bandwidth of about 1969 MB/s for a
      16 GT/s x1 link.
      
      Use pcie_print_link_status() to report PCIe link speed and possible
      limitations instead of implementing this in the driver itself.  This finds
      the slowest link in the path to the device by computing the total bandwidth
      of each link and compares that with the capabilities of the device.
      
      Note that the driver previously used dev_warn() to suggest using a
      different slot, but pcie_print_link_status() uses dev_info() because if the
      platform has no faster slot available, the user can't do anything about the
      warning and may not want to be bothered with it.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      170648fd
    • Tal Gilboa's avatar
      net/mlx5e: Use pcie_bandwidth_available() to compute bandwidth · 33523a36
      Tal Gilboa authored
      Use the new pci_bandwidth_available() function to calculate maximum
      available bandwidth through the PCI chain instead of computing it ourselves
      with mlx5e_get_pci_bw().
      
      This is used to detect when the device is capable of more bandwidth than is
      available in the current slot.  The driver may adjust compression settings
      accordingly.
      
      Note that pci_bandwidth_available() accounts for PCIe encoding overhead, so
      it is more accurate than mlx5e_get_pci_bw() was.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      [bhelgaas: remove mlx5e_get_pci_bw() wrapper altogether]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      33523a36
    • Tal Gilboa's avatar
      net/mlx5: Report PCIe link properties with pcie_print_link_status() · 00c6bcb0
      Tal Gilboa authored
      Use pcie_print_link_status() to report PCIe link speed and possible
      limitations.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      [bhelgaas: changelog]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      00c6bcb0
    • Tal Gilboa's avatar
      net/mlx4_core: Report PCIe link properties with pcie_print_link_status() · 190b509c
      Tal Gilboa authored
      Use pcie_print_link_status() to report PCIe link speed and possible
      limitations instead of implementing this in the driver itself.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      [bhelgaas: changelog]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      190b509c
    • Tal Gilboa's avatar
      PCI: Add pcie_print_link_status() to log link speed and whether it's limited · 9e506a7b
      Tal Gilboa authored
      Add pcie_print_link_status().  This logs the current settings of the link
      (speed, width, and total available bandwidth).
      
      If the device is capable of more bandwidth but is limited by a slower
      upstream link, we include information about the link that limits the
      device's performance.
      
      The user may be able to move the device to a different slot for better
      performance.
      
      This provides a unified method for all PCI devices to report status and
      issues, instead of each device reporting in a different way, using
      different code.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      [bhelgaas: changelog, reword log messages, print device capabilities when
      not limited, print bandwidth in Gb/s]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      9e506a7b
    • Tal Gilboa's avatar
      PCI: Add pcie_bandwidth_available() to compute bandwidth available to device · 6db79a88
      Tal Gilboa authored
      Add pcie_bandwidth_available() to compute the bandwidth available to a
      device.  This may be limited by the device itself or by a slower upstream
      link leading to the device.
      
      The available bandwidth at each link along the path is computed as:
      
        link_width * link_speed * (1 - encoding_overhead)
      
      2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth
      available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which
      reduces it by about 1.5%.
      
      The result is in Mb/s, i.e., megabits/second, of raw bandwidth.
      
      Also return the device with the slowest link and the speed and width of
      that link.
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      [bhelgaas: changelog, leave pcie_get_minimum_link() alone for now, return
      bw directly, use pci_upstream_bridge(), check "next_bw <= bw" to find
      uppermost limiting device, return speed/width of the limiting device]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      6db79a88
  3. 30 Mar, 2018 3 commits
  4. 23 Mar, 2018 1 commit
    • Mika Westerberg's avatar
      ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status() · 13d3047c
      Mika Westerberg authored
      Mike Lothian reported that plugging in a USB-C device does not work
      properly in his Dell Alienware system.  This system has an Intel Alpine
      Ridge Thunderbolt controller providing USB-C functionality.  In these
      systems the USB controller (xHCI) is hotplugged whenever a device is
      connected to the port using ACPI-based hotplug.
      
      The ACPI description of the root port in question is as follows:
      
        Device (RP01)
        {
            Name (_ADR, 0x001C0000)
      
            Device (PXSX)
            {
                Name (_ADR, 0x02)
      
                Method (_RMV, 0, NotSerialized)
                {
                    // ...
                }
            }
      
      Here _ADR 0x02 means device 0, function 2 on the bus under root port (RP01)
      but that seems to be incorrect because device 0 is the upstream port of the
      Alpine Ridge PCIe switch and it has no functions other than 0 (the bridge
      itself).  When we get ACPI Notify() to the root port resulting from
      connecting a USB-C device, Linux tries to read PCI_VENDOR_ID from device 0,
      function 2 which of course always returns 0xffffffff because there is no
      such function and we never find the device.
      
      In Windows this works fine.
      
      Now, since we get ACPI Notify() to the root port and not to the PXSX device
      we should actually start our scan from there as well and not from the
      non-existent PXSX device.  Fix this by checking presence of the slot itself
      (function 0) if we fail to do that otherwise.
      
      While there use pci_bus_read_dev_vendor_id() in get_slot_status(), which is
      the recommended way to read Device and Vendor IDs of devices on PCI buses.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=198557Reported-by: default avatarMike Lothian <mike@fireburn.co.uk>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org
      13d3047c
  5. 21 Mar, 2018 2 commits
  6. 28 Feb, 2018 3 commits
  7. 22 Feb, 2018 1 commit
  8. 16 Feb, 2018 2 commits
  9. 11 Feb, 2018 7 commits
    • Linus Torvalds's avatar
      Linux 4.16-rc1 · 7928b2cb
      Linus Torvalds authored
      7928b2cb
    • Al Viro's avatar
      unify {de,}mangle_poll(), get rid of kernel-side POLL... · 7a163b21
      Al Viro authored
      except, again, POLLFREE and POLL_BUSY_LOOP.
      
      With this, we finally get to the promised end result:
      
       - POLL{IN,OUT,...} are plain integers and *not* in __poll_t, so any
         stray instances of ->poll() still using those will be caught by
         sparse.
      
       - eventpoll.c and select.c warning-free wrt __poll_t
      
       - no more kernel-side definitions of POLL... - userland ones are
         visible through the entire kernel (and used pretty much only for
         mangle/demangle)
      
       - same behavior as after the first series (i.e. sparc et.al. epoll(2)
         working correctly).
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7a163b21
    • Linus Torvalds's avatar
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds authored
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
    • Linus Torvalds's avatar
      Merge branch 'work.poll2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · ee5daa13
      Linus Torvalds authored
      Pull more poll annotation updates from Al Viro:
       "This is preparation to solving the problems you've mentioned in the
        original poll series.
      
        After this series, the kernel is ready for running
      
            for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
                  L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
                  for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
            done
      
        as a for bulk search-and-replace.
      
        After that, the kernel is ready to apply the patch to unify
        {de,}mangle_poll(), and then get rid of kernel-side POLL... uses
        entirely, and we should be all done with that stuff.
      
        Basically, that's what you suggested wrt KPOLL..., except that we can
        use EPOLL... instead - they already are arch-independent (and equal to
        what is currently kernel-side POLL...).
      
        After the preparations (in this series) switch to returning EPOLL...
        from ->poll() instances is completely mechanical and kernel-side
        POLL... can go away. The last step (killing kernel-side POLL... and
        unifying {de,}mangle_poll() has to be done after the
        search-and-replace job, since we need userland-side POLL... for
        unified {de,}mangle_poll(), thus the cherry-pick at the last step.
      
        After that we will have:
      
         - POLL{IN,OUT,...} *not* in __poll_t, so any stray instances of
           ->poll() still using those will be caught by sparse.
      
         - eventpoll.c and select.c warning-free wrt __poll_t
      
         - no more kernel-side definitions of POLL... - userland ones are
           visible through the entire kernel (and used pretty much only for
           mangle/demangle)
      
         - same behavior as after the first series (i.e. sparc et.al. epoll(2)
           working correctly)"
      
      * 'work.poll2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        annotate ep_scan_ready_list()
        ep_send_events_proc(): return result via esed->res
        preparation to switching ->poll() to returning EPOLL...
        add EPOLLNVAL, annotate EPOLL... and event_poll->event
        use linux/poll.h instead of asm/poll.h
        xen: fix poll misannotation
        smc: missing poll annotations
      ee5daa13
    • Linus Torvalds's avatar
      Merge tag 'xtensa-20180211' of git://github.com/jcmvbkbc/linux-xtensa · 3fc928dc
      Linus Torvalds authored
      Pull xtense fix from Max Filippov:
       "Build fix for xtensa architecture with KASAN enabled"
      
      * tag 'xtensa-20180211' of git://github.com/jcmvbkbc/linux-xtensa:
        xtensa: fix build with KASAN
      3fc928dc
    • Linus Torvalds's avatar
      Merge tag 'nios2-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2 · 60d7a21a
      Linus Torvalds authored
      Pull nios2 update from Ley Foon Tan:
      
       - clean up old Kconfig options from defconfig
      
       - remove leading 0x and 0s from bindings notation in dts files
      
      * tag 'nios2-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2:
        nios2: defconfig: Cleanup from old Kconfig options
        nios2: dts: Remove leading 0x and 0s from bindings notation
      60d7a21a
    • Max Filippov's avatar
      xtensa: fix build with KASAN · f8d0cbf2
      Max Filippov authored
      The commit 917538e2 ("kasan: clean up KASAN_SHADOW_SCALE_SHIFT
      usage") removed KASAN_SHADOW_SCALE_SHIFT definition from
      include/linux/kasan.h and added it to architecture-specific headers,
      except for xtensa. This broke the xtensa build with KASAN enabled.
      Define KASAN_SHADOW_SCALE_SHIFT in arch/xtensa/include/asm/kasan.h
      
      Reported by: kbuild test robot <fengguang.wu@intel.com>
      Fixes: 917538e2 ("kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage")
      Acked-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      f8d0cbf2