1. 16 3月, 2018 1 次提交
    • A
      arch: remove tile port · bb9d8126
      Arnd Bergmann 提交于
      The Tile architecture port was added by Chris Metcalf in 2010, and
      maintained until early 2018 when he orphaned it due to his departure
      from Mellanox, and nobody else stepped up to maintain it. The product
      line is still around in the form of the BlueField SoC, but no longer
      uses the Tile architecture.
      
      There are also still products for sale with Tile-GX SoCs, notably the
      Mikrotik CCR router family. The products all use old (linux-3.3) kernels
      with lots of patches and won't be upgraded by their manufacturers. There
      have been efforts to port both OpenWRT and Debian to these, but both
      projects have stalled and are very unlikely to be continued in the future.
      
      Given that we are reasonably sure that nobody is still using the port
      with an upstream kernel any more, it seems better to remove it now while
      the port is in a good shape than to let it bitrot for a few years first.
      
      Cc: Chris Metcalf <chris.d.metcalf@gmail.com>
      Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Link: http://www.mellanox.com/page/npu_multicore_overview
      Link: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      bb9d8126
  2. 27 1月, 2018 1 次提交
  3. 27 6月, 2017 1 次提交
  4. 28 4月, 2017 1 次提交
  5. 13 4月, 2017 1 次提交
  6. 09 3月, 2017 1 次提交
    • J
      tee: generic TEE subsystem · 967c9cca
      Jens Wiklander 提交于
      Initial patch for generic TEE subsystem.
      This subsystem provides:
      * Registration/un-registration of TEE drivers.
      * Shared memory between normal world and secure world.
      * Ioctl interface for interaction with user space.
      * Sysfs implementation_id of TEE driver
      
      A TEE (Trusted Execution Environment) driver is a driver that interfaces
      with a trusted OS running in some secure environment, for example,
      TrustZone on ARM cpus, or a separate secure co-processor etc.
      
      The TEE subsystem can serve a TEE driver for a Global Platform compliant
      TEE, but it's not limited to only Global Platform TEEs.
      
      This patch builds on other similar implementations trying to solve
      the same problem:
      * "optee_linuxdriver" by among others
        Jean-michel DELORME<jean-michel.delorme@st.com> and
        Emmanuel MICHEL <emmanuel.michel@st.com>
      * "Generic TrustZone Driver" by Javier González <javier@javigon.com>
      Acked-by: NAndreas Dannenberg <dannenberg@ti.com>
      Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
      Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
      Tested-by: NScott Branden <scott.branden@broadcom.com>
      Reviewed-by: NJavier González <javier@javigon.com>
      Signed-off-by: NJens Wiklander <jens.wiklander@linaro.org>
      967c9cca
  7. 19 1月, 2017 1 次提交
    • B
      rpmsg: Driver for user space endpoint interface · c0cdc19f
      Bjorn Andersson 提交于
      This driver allows rpmsg instances to expose access to rpmsg endpoints
      to user space processes. It provides a control interface, allowing
      userspace to export endpoints and an endpoint interface for each exposed
      endpoint.
      
      The implementation is based on prior art by Texas Instrument, Google,
      PetaLogix and was derived from a FreeRTOS performance statistics driver
      written by Michal Simek.
      
      The control interface provides a "create endpoint" ioctl, which is fed a
      name, source and destination address. The three values are used to
      create the endpoint, in a backend-specific way, and a rpmsg endpoint
      device is created - with the three parameters are available in sysfs for
      udev usage.
      
      E.g. to create an endpoint device for one of the Qualcomm SMD channel
      related to DIAG one would issue:
      
        struct rpmsg_endpoint_info info = { "DIAG_CNTL", 0, 0 };
        int fd = open("/dev/rpmsg_ctrl0", O_RDWR);
        ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info);
      
      Each created endpoint device shows up as an individual character device
      in /dev, allowing permission to be controlled on a per-endpoint basis.
      The rpmsg endpoint will be created and destroyed following the opening
      and closing of the endpoint device, allowing rpmsg backends to open and
      close the physical channel, if supported by the wire protocol.
      
      Cc: Marek Novak <marek.novak@nxp.com>
      Cc: Matteo Sartori <matteo.sartori@t3lab.it>
      Cc: Michal Simek <monstr@monstr.eu>
      Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      c0cdc19f
  8. 03 8月, 2016 1 次提交
  9. 25 6月, 2016 1 次提交
  10. 10 3月, 2016 1 次提交
  11. 29 10月, 2015 1 次提交
    • M
      lightnvm: Support for Open-Channel SSDs · cd9e9808
      Matias Bjørling 提交于
      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: NMatias Bjørling <m@bjorling.me>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      cd9e9808
  12. 05 10月, 2015 1 次提交
    • A
      stm class: Introduce an abstraction for System Trace Module devices · 7bd1d409
      Alexander Shishkin 提交于
      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: NMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bd1d409
  13. 05 9月, 2015 1 次提交
    • A
      userfaultfd: uAPI · 1038628d
      Andrea Arcangeli 提交于
      Defines the uAPI of the userfaultfd, notably the ioctl numbers and protocol.
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Acked-by: NPavel Emelyanov <xemul@parallels.com>
      Cc: Sanidhya Kashyap <sanidhya.gatech@gmail.com>
      Cc: zhang.zhanghailiang@huawei.com
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: Andres Lagar-Cavilla <andreslc@google.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Peter Feiner <pfeiner@google.com>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: "Huangpeng (Peter)" <peter.huangpeng@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1038628d
  14. 27 8月, 2015 1 次提交
  15. 04 8月, 2015 1 次提交
  16. 25 7月, 2015 1 次提交
    • A
      toshiba_acpi: Add /dev/toshiba_acpi device · fc5462f8
      Azael Avalos 提交于
      There were previous attempts to "merge" the toshiba SMM module to the
      toshiba_acpi one, they were trying to imitate what the old toshiba
      module does, however, some models (TOS1900 devices) come with a
      "crippled" implementation and do not provide all the "features" a
      "genuine" Toshiba BIOS does.
      
      This patch adds a new device called toshiba_acpi, which aim is to
      enable userspace to access the SMM on Toshiba laptops via ACPI calls.
      
      Creating a new convenience _IOWR command to access the SCI functions
      by opening/closing the SCI internally to avoid buggy BIOS, while at
      the same time providing backwards compatibility.
      
      Older programs (and new) who wish to access the SMM on newer models
      can do it by pointing their path to /dev/toshiba_acpi (instead of
      /dev/toshiba) as the toshiba.h header was modified to reflect these
      changes as well as adds all the toshiba_acpi paths and command,
      however, it is strongly recommended to use the new IOCTL for any
      SCI command to avoid any buggy BIOS.
      Signed-off-by: NAzael Avalos <coproscefalo@gmail.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      fc5462f8
  17. 01 7月, 2015 1 次提交
  18. 27 2月, 2015 1 次提交
  19. 08 10月, 2014 1 次提交
  20. 20 6月, 2014 1 次提交
  21. 24 1月, 2014 1 次提交
  22. 18 10月, 2013 1 次提交
    • C
      ALSA: add DICE driver · 82fbb4f7
      Clemens Ladisch 提交于
      As a start point for further development, this is an incomplete driver
      for DICE devices:
      - only playback (so no clock source except the bus clock)
      - only 44.1 kHz
      - no MIDI
      - recovery after bus reset is slow
      - hwdep device is created, but not actually implemented
      
      Contains compilation fixes by Stefan Richter.
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      82fbb4f7
  23. 27 6月, 2013 1 次提交
  24. 26 3月, 2013 1 次提交
    • B
      USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND · 3edce1cf
      Bjørn Mork 提交于
      Userspace applications need to know the maximum supported message
      size.
      
      The cdc-wdm driver translates between a character device stream
      and a message based protocol.  Each message is transported as a
      usb control message with no further encapsulation or syncronization.
      Each read or write on the character device should translate to
      exactly one usb control message to ensure that message boundaries
      are kept intact.  That means that the userspace application must
      know the maximum message size supported by the device and driver,
      making this size a vital part of the cdc-wdm character device API.
      
      CDC WDM and CDC MBIM functions export the maximum supported
      message size through CDC functional descriptors.  The cdc-wdm and
      cdc_mbim drivers will parse these descriptors and use the value
      chosen by the device.  The only current way for a userspace
      application to retrive the value is by duplicating the descriptor
      parsing. This is an unnecessary complex task, and application
      writers are likely to postpone it, using a fixed value and adding
      a "todo" item.
      
      QMI functions have no way to tell the host what message size they
      support.  The qmi_wwan driver use a fixed value based on protocol
      recommendations and observed device behaviour.  Userspace
      applications must know and hard code the same value.  This scheme
      will break if we ever encounter a QMI device needing a device
      specific message size quirk.  We are currently unable to support
      such a device because using a non default size would break the
      implicit userspace API.
      
      The message size is currently a hidden attribute of the cdc-wdm
      userspace API.  Retrieving it is unnecessarily complex, increasing
      the possibility of drivers and applications using different limits.
      The resulting errors are hard to debug, and can only be replicated
      on identical hardware.
      
      Exporting the maximum message size from the driver simplifies the
      task for the userspace application, and creates a unified
      information source independent of device and function class. It also
      serves to document that the message size is part of the cdc-wdm
      userspace API.
      
      This proposed API extension has been presented for the authors of
      userspace applications and libraries using the current API: libmbim,
      libqmi, uqmi, oFono and ModemManager.  The replies were:
      
      Aleksander Morgado:
       "We do really need max message size for MBIM; and as you say, it may be
        good to have the max message size info also for QMI, so the new ioctl
        seems a good addition. So +1 from my side, for what it's worth."
      
      Dan Williams:
       "Yeah, +1 here.  I'd prefer the sysfs file, but the fact that that
        doesn't work for fd passing pretty much kills it."
      
      No negative replies are so far received.
      
      Cc: Aleksander Morgado <aleksander@lanedo.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Acked-by: NOliver Neukum <oliver@neukum.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3edce1cf
  25. 01 2月, 2013 1 次提交
    • P
      wanrouter: completely decouple obsolete code from kernel. · a786a7c0
      Paul Gortmaker 提交于
      The original suggestion to delete wanrouter started earlier
      with the mainline commit f0d1b3c2
      ("net/wanrouter: Deprecate and schedule for removal") in May 2012.
      
      More importantly, Dan Carpenter found[1] that the driver had a
      fundamental breakage introduced back in 2008, with commit
      7be6065b ("netdevice wanrouter: Convert directly reference of
      netdev->priv").  So we know with certainty that the code hasn't been
      used by anyone willing to at least take the effort to send an e-mail
      report of breakage for at least 4 years.
      
      This commit does a decouple of the wanrouter subsystem, by going
      after the Makefile/Kconfig and similar files, so that these mainline
      files that we are keeping do not have the big wanrouter file/driver
      deletion commit tied into their history.
      
      Once this commit is in place, we then can remove the obsolete cyclomx
      drivers and similar that have a dependency on CONFIG_WAN_ROUTER_DRIVERS.
      
      [1] http://www.spinics.net/lists/netdev/msg218670.htmlOriginally-by: NJoe Perches <joe@perches.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      a786a7c0
  26. 14 8月, 2012 1 次提交
  27. 31 7月, 2012 1 次提交
    • A
      vfio: VFIO core · cba3345c
      Alex Williamson 提交于
      VFIO is a secure user level driver for use with both virtual machines
      and user level drivers.  VFIO makes use of IOMMU groups to ensure the
      isolation of devices in use, allowing unprivileged user access.  It's
      intended that VFIO will replace KVM device assignment and UIO drivers
      (in cases where the target platform includes a sufficiently capable
      IOMMU).
      
      New in this version of VFIO is support for IOMMU groups managed
      through the IOMMU core as well as a rework of the API, removing the
      group merge interface.  We now go back to a model more similar to
      original VFIO with UIOMMU support where the file descriptor obtained
      from /dev/vfio/vfio allows access to the IOMMU, but only after a
      group is added, avoiding the previous privilege issues with this type
      of model.  IOMMU support is also now fully modular as IOMMUs have
      vastly different interface requirements on different platforms.  VFIO
      users are able to query and initialize the IOMMU model of their
      choice.
      
      Please see the follow-on Documentation commit for further description
      and usage example.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      cba3345c
  28. 10 5月, 2012 1 次提交
  29. 21 3月, 2012 1 次提交
  30. 05 3月, 2012 1 次提交
    • P
      ppp: Move ioctl definitions from if_ppp.h to new ppp-ioctl.h · bf7daebb
      Paul Mackerras 提交于
      This moves the definitions of the ioctls, constants and structures
      relating to the ppp_generic interface to userspace out from if_ppp.h
      to a new file, ppp-ioctl.h.  The new file has my copyright since I
      designed and implemented the ppp_generic interface in the late 1990s.
      None of the contents of this file comes from the original if_ppp.h
      published by Carnegie Mellon University.
      
      Of the remainder of if_ppp.h, only the PPP_MTU definition was being
      used, and this replaces the uses of it with PPP_MRU (which is identical).
      Therefore, this replaces the entire file with the single line
      
      #include <linux/ppp-ioctl.h>
      
      which clearly doesn't contain any CMU code.  Thus I have removed the
      CMU copyright notice with its problematic advertising clause, and in
      fact since it's only one trivial line I have not added any other
      copyright notice.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf7daebb
  31. 16 2月, 2012 1 次提交
  32. 05 1月, 2012 1 次提交
  33. 05 11月, 2011 1 次提交
  34. 13 9月, 2011 1 次提交
  35. 08 7月, 2011 1 次提交
    • T
      drivers/virt: introduce Freescale hypervisor management driver · 6db71994
      Timur Tabi 提交于
      Add the drivers/virt directory, which houses drivers that support
      virtualization environments, and add the Freescale hypervisor management
      driver.
      
      The Freescale hypervisor management driver provides several services to
      drivers and applications related to the Freescale hypervisor:
      
      1. An ioctl interface for querying and managing partitions
      
      2. A file interface to reading incoming doorbells
      
      3. An interrupt handler for shutting down the partition upon receiving the
         shutdown doorbell from a manager partition
      
      4. A kernel interface for receiving callbacks when a managed partition
         shuts down.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      6db71994
  36. 10 6月, 2011 1 次提交
  37. 25 5月, 2011 1 次提交
    • J
      mmc: core: Add mmc CMD+ACMD passthrough ioctl · cb87ea28
      John Calixto 提交于
      Allows appropriately-privileged applications to send CMD (normal) and ACMD
      (application-specific; preceded with CMD55) commands to cards/devices on
      the mmc bus.  This is primarily useful for enabling the security
      functionality built in to every SD card.
      
      It can also be used as a generic passthrough (e.g. to enable virtual
      machines to control mmc bus devices directly).  However, this use case has
      not been tested rigorously.  Generic passthrough testing was only conducted
      for a few non-security opcodes to prove the feasibility of the passthrough.
      
      Since any opcode can be sent using this passthrough, it is very possible to
      render the card/device unusable.  Applications that use this ioctl must
      have CAP_SYS_RAWIO.
      
      Security commands tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC,
      TI OMAP3621/OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC.
      Signed-off-by: NJohn Calixto <john.calixto@modsystems.com>
      Reviewed-by: NAndrei Warkentin <andreiw@motorola.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      cb87ea28
  38. 20 5月, 2011 1 次提交
  39. 22 3月, 2011 1 次提交
  40. 03 2月, 2011 1 次提交