1. 08 Dec, 2015 1 commit
    • Krzysztof Kozlowski's avatar
      power: Fix unmet dependency on POWER_SUPPLY by POWER_RESET by uncoupling them · f96576bd
      Krzysztof Kozlowski authored
      Currently the reset/power off handlers (POWER_RESET) and Adaptive Voltage
      Scaling class (POWER_AVS) are not built when POWER_SUPPLY is disabled.
      The POWER_RESET is also not visible in drivers main section of config.
      
      However they do not really depend on power supply so they can be built
      always. The objects for power supply drivers already depend on
      particular Kconfig symbols so there is no need for any changes in
      drivers/power/Makefile.
      
      This allows selecting POWER_RESET from main drivers config section and
      fixes following build warning (encountered on ARM exynos defconfig when
      POWER_SUPPLY is disabled manually):
      
      warning: (ARCH_HISI && ARCH_INTEGRATOR && ARCH_EXYNOS && ARCH_VEXPRESS && REALVIEW_DT) selects POWER_RESET which has unmet direct dependencies (POWER_SUPPLY)
      warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON which has unmet direct dependencies (POWER_SUPPLY && POWER_RESET && OF)
      warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON_POWEROFF which has unmet direct dependencies (POWER_SUPPLY && POWER_RESET && OF)
      Reported-by: default avatarPavel Fedin <p.fedin@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      f96576bd
  2. 16 Nov, 2015 1 commit
    • Matias Bjørling's avatar
      null_blk: register as a LightNVM device · b2b7e001
      Matias Bjørling authored
      Add support for registering as a LightNVM device. This allows us to
      evaluate the performance of the LightNVM subsystem.
      
      In /drivers/Makefile, LightNVM is moved above block device drivers
      to make sure that the LightNVM media managers have been initialized
      before drivers under /drivers/block are initialized.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Fix by Jens Axboe to remove unneeded slab cache and the following
      memory leak.
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      b2b7e001
  3. 29 Oct, 2015 1 commit
    • Matias Bjørling's avatar
      lightnvm: Support for Open-Channel SSDs · cd9e9808
      Matias Bjørling authored
      Open-channel SSDs are devices that share responsibilities with the host
      in order to implement and maintain features that typical SSDs keep
      strictly in firmware. These include (i) the Flash Translation Layer
      (FTL), (ii) bad block management, and (iii) hardware units such as the
      flash controller, the interface controller, and large amounts of flash
      chips. In this way, Open-channels SSDs exposes direct access to their
      physical flash storage, while keeping a subset of the internal features
      of SSDs.
      
      LightNVM is a specification that gives support to Open-channel SSDs
      LightNVM allows the host to manage data placement, garbage collection,
      and parallelism. Device specific responsibilities such as bad block
      management, FTL extensions to support atomic IOs, or metadata
      persistence are still handled by the device.
      
      The implementation of LightNVM consists of two parts: core and
      (multiple) targets. The core implements functionality shared across
      targets. This is initialization, teardown and statistics. The targets
      implement the interface that exposes physical flash to user-space
      applications. Examples of such targets include key-value store,
      object-store, as well as traditional block devices, which can be
      application-specific.
      
      Contributions in this patch from:
      
        Javier Gonzalez <jg@lightnvm.io>
        Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
        Jesper Madsen <jmad@itu.dk>
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      cd9e9808
  4. 09 Oct, 2015 1 commit
  5. 07 Oct, 2015 1 commit
    • Alan Tull's avatar
      add FPGA manager core · 6a8c3be7
      Alan Tull authored
      API to support programming FPGA's.
      
      The following functions are exported as GPL:
      * fpga_mgr_buf_load
         Load fpga from image in buffer
      
      * fpga_mgr_firmware_load
         Request firmware and load it to the FPGA.
      
      * fpga_mgr_register
      * fpga_mgr_unregister
         FPGA device drivers can be added by calling
         fpga_mgr_register() to register a set of
         fpga_manager_ops to do device specific stuff.
      
      * of_fpga_mgr_get
      * fpga_mgr_put
         Get/put a reference to a fpga manager.
      
      The following sysfs files are created:
      * /sys/class/fpga_manager/<fpga>/name
        Name of low level driver.
      
      * /sys/class/fpga_manager/<fpga>/state
        State of fpga manager
      Signed-off-by: default avatarAlan Tull <atull@opensource.altera.com>
      Acked-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a8c3be7
  6. 04 Oct, 2015 2 commits
    • Alexander Shishkin's avatar
      intel_th: Add driver infrastructure for Intel(R) Trace Hub devices · 39f40346
      Alexander Shishkin authored
      Intel(R) Trace Hub (TH) is a set of hardware blocks (subdevices) that
      produce, switch and output trace data from multiple hardware and
      software sources over several types of trace output ports encoded
      in System Trace Protocol (MIPI STPv2) and is intended to perform
      full system debugging.
      
      For these subdevices, we create a bus, where they can be discovered
      and configured by userspace software.
      
      This patch creates this bus infrastructure, three types of devices
      (source, output, switch), resource allocation, some callback mechanisms
      to facilitate communication between the subdevices' drivers and some
      common sysfs attributes.
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39f40346
    • Alexander Shishkin's avatar
      stm class: Introduce an abstraction for System Trace Module devices · 7bd1d409
      Alexander Shishkin authored
      A System Trace Module (STM) is a device exporting data in System Trace
      Protocol (STP) format as defined by MIPI STP standards. Examples of such
      devices are Intel(R) Trace Hub and Coresight STM.
      
      This abstraction provides a unified interface for software trace sources
      to send their data over an STM device to a debug host. In order to do
      that, such a trace source needs to be assigned a pair of master/channel
      identifiers that all the data from this source will be tagged with. The
      STP decoder on the debug host side will use these master/channel tags to
      distinguish different trace streams from one another inside one STP
      stream.
      
      This abstraction provides a configfs-based policy management mechanism
      for dynamic allocation of these master/channel pairs based on trace
      source-supplied string identifier. It has the flexibility of being
      defined at runtime and at the same time (provided that the policy
      definition is aligned with the decoding end) consistency.
      
      For userspace trace sources, this abstraction provides write()-based and
      mmap()-based (if the underlying stm device allows this) output mechanism.
      
      For kernel-side trace sources, we provide "stm_source" device class that
      can be connected to an stm device at run time.
      
      Cc: linux-api@vger.kernel.org
      Reviewed-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bd1d409
  7. 05 Aug, 2015 1 commit
  8. 31 Jul, 2015 1 commit
    • Mark Rutland's avatar
      arm: perf: factor arm_pmu core out to drivers · fa8ad788
      Mark Rutland authored
      To enable sharing of the arm_pmu code with arm64, this patch factors it
      out to drivers/perf/. A new drivers/perf directory is added for
      performance monitor drivers to live under.
      
      MAINTAINERS is updated accordingly. Files added previously without a
      corresponsing MAINTAINERS update (perf_regs.c, perf_callchain.c, and
      perf_event.h) are also added.
      
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      [will: augmented Kconfig help slightly]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fa8ad788
  9. 16 Jul, 2015 1 commit
  10. 25 Jun, 2015 1 commit
  11. 24 May, 2015 1 commit
  12. 03 Apr, 2015 1 commit
  13. 22 Dec, 2014 1 commit
    • Oded Gabbay's avatar
      drivers: Move iommu/ before gpu/ in Makefile · 1bacc894
      Oded Gabbay authored
      AMD GPU devices are dependent on AMD IOMMU controller functionality to allow
      the GPU to access a process's virtual memory address space, without the need
      for pinning the memory.
      
      This patch changes the order in the drivers makefile, so iommu/ subsystem is
      linked before gpu/ subsystem. That way, if the gpu and iommu drivers are
      compiled inside the kernel image (not as modules), the correct order of device
      loading is still maintained (iommu module is loaded before gpu module).
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      1bacc894
  14. 07 Nov, 2014 1 commit
    • Pratik Patel's avatar
      coresight: add CoreSight core layer framework · a06ae860
      Pratik Patel authored
      CoreSight components are compliant with the ARM CoreSight
      architecture specification and can be connected in various
      topologies to suit a particular SoC tracing needs. These trace
      components can generally be classified as sources, links and
      sinks. Trace data produced by one or more sources flows through
      the intermediate links connecting the source to the currently
      selected sink.
      
      The CoreSight framework provides an interface for the CoreSight trace
      drivers to register themselves with. It's intended to build up a
      topological view of the CoreSight components and configure the
      correct serie of components on user input via sysfs.
      
      For eg., when enabling a source, the framework builds up a path
      consisting of all the components connecting the source to the
      currently selected sink(s) and enables all of them.
      
      The framework also supports switching between available sinks
      and provides status information to user space applications
      through the debugfs interface.
      Signed-off-by: default avatarPratik Patel <pratikp@codeaurora.org>
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a06ae860
  15. 20 Oct, 2014 1 commit
  16. 08 Jul, 2014 1 commit
  17. 23 Jun, 2014 1 commit
  18. 19 Jun, 2014 1 commit
    • Andreas Noever's avatar
      thunderbolt: Add initial cactus ridge NHI support · 16603153
      Andreas Noever authored
      Thunderbolt hotplug is supposed to be handled by the firmware. But Apple
      decided to implement thunderbolt at the operating system level. The
      firmare only initializes thunderbolt devices that are present at boot
      time. This driver enables hotplug of thunderbolt of non-chained
      thunderbolt devices on Apple systems with a cactus ridge controller.
      
      This first patch adds the Kconfig file as well the parts of the driver
      which talk directly to the hardware (that is pci device setup, interrupt
      handling and RX/TX ring management).
      Signed-off-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16603153
  19. 27 May, 2014 1 commit
  20. 23 May, 2014 1 commit
  21. 12 May, 2014 1 commit
    • Geert Uytterhoeven's avatar
      drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI · 3c90c55d
      Geert Uytterhoeven authored
      If the kernel is built to support multi-ARM configuration with shmobile
      support built in, then drivers/sh is not built. This contains the PM
      runtime code in drivers/sh/pm_runtime.c, which implicitly enables the
      module clocks for all devices, and thus is quite essential.
      Without this, the state of clocks depends on implicit reset state, or on
      the bootloader.
      
      If ARCH_SHMOBILE_MULTI then build the drivers/sh directory, but ensure that
      bits that may conflict (drivers/sh/clk if the common clock framework is
      enabled) or are not used (drivers/sh/intc), are not built.
      Also, only enable the PM runtime code when actually running on a shmobile
      SoCs that needs it.
      
      ARCH_SHMOBILE_MULTI was added a while ago by commit
      efacfce5 ("ARM: shmobile: Introduce
      ARCH_SHMOBILE_MULTI"), but drivers/sh was compiled for both
      ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI until commit
      bf98c1ea ("ARM: Rename ARCH_SHMOBILE to
      ARCH_SHMOBILE_LEGACY").
      
      Inspired by a patch from Ben Dooks <ben.dooks@codethink.co.uk>.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      3c90c55d
  22. 17 Apr, 2014 1 commit
  23. 28 Feb, 2014 1 commit
  24. 15 Feb, 2014 1 commit
  25. 10 Dec, 2013 1 commit
  26. 16 Oct, 2013 1 commit
  27. 28 Sep, 2013 1 commit
  28. 17 Jun, 2013 1 commit
  29. 11 Jun, 2013 1 commit
  30. 12 Apr, 2013 1 commit
  31. 25 Mar, 2013 2 commits
  32. 20 Mar, 2013 1 commit
  33. 18 Mar, 2013 1 commit
    • Felipe Balbi's avatar
      usb: phy: make it a menuconfig · edc7cb2e
      Felipe Balbi authored
      We already have a considerable amount of USB
      PHY drivers, making it a menuconfig just
      prevents us from adding too much churn to
      USB's menuconfig.
      
      While at that, also select USB_OTG_UTILS from
      this new menuconfig just to keep backwards
      compatibility until we manage to remove
      that symbol.
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      edc7cb2e
  34. 01 Feb, 2013 1 commit
  35. 18 Jan, 2013 1 commit
    • Jon Mason's avatar
      PCI-Express Non-Transparent Bridge Support · fce8a7bb
      Jon Mason authored
      A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
      connecting 2 systems, providing electrical isolation between the two subsystems.
      A non-transparent bridge is functionally similar to a transparent bridge except
      that both sides of the bridge have their own independent address domains.  The
      host on one side of the bridge will not have the visibility of the complete
      memory or I/O space on the other side of the bridge.  To communicate across the
      non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
      the local system.  Writes to these apertures are mirrored to memory on the
      remote system.  Communications can also occur through the use of doorbell
      registers that initiate interrupts to the alternate domain, and scratch-pad
      registers accessible from both sides.
      
      The NTB device driver is needed to configure these memory windows, doorbell, and
      scratch-pad registers as well as use them in such a way as they can be turned
      into a viable communication channel to the remote system.  ntb_hw.[ch]
      determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
      the underlying hardware to provide access and a common interface to the doorbell
      registers, scratch pads, and memory windows.  These hardware interfaces are
      exported so that other, non-mainlined kernel drivers can access these.
      ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
      communication channel(s) and provide a reliable way of transferring data from
      one side to the other, which it then exports so that "client" drivers can access
      them.  These client drivers are used to provide a standard kernel interface
      (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
      system to the other in a standard way.
      Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
      Reviewed-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fce8a7bb
  36. 03 Jan, 2013 1 commit
  37. 16 Nov, 2012 1 commit
  38. 17 Oct, 2012 1 commit