“ebec3f8f5271139df618ebdf8427e24ba102ba94”上不存在“git@gitcode.net:openeuler/kernel.git”
  1. 10 3月, 2016 1 次提交
  2. 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
  3. 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
  4. 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
  5. 27 8月, 2015 1 次提交
  6. 04 8月, 2015 1 次提交
  7. 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
  8. 01 7月, 2015 1 次提交
  9. 27 2月, 2015 1 次提交
  10. 08 10月, 2014 1 次提交
  11. 20 6月, 2014 1 次提交
  12. 24 1月, 2014 1 次提交
  13. 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
  14. 27 6月, 2013 1 次提交
  15. 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
  16. 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
  17. 14 8月, 2012 1 次提交
  18. 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
  19. 10 5月, 2012 1 次提交
  20. 21 3月, 2012 1 次提交
  21. 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
  22. 16 2月, 2012 1 次提交
  23. 05 1月, 2012 1 次提交
  24. 05 11月, 2011 1 次提交
  25. 13 9月, 2011 1 次提交
  26. 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
  27. 10 6月, 2011 1 次提交
  28. 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
  29. 20 5月, 2011 1 次提交
  30. 22 3月, 2011 1 次提交
  31. 03 2月, 2011 2 次提交
  32. 14 1月, 2011 1 次提交
  33. 29 12月, 2010 3 次提交
  34. 21 10月, 2010 1 次提交
  35. 06 10月, 2010 1 次提交
  36. 04 8月, 2010 1 次提交
    • J
      Documentation: update broken web addresses. · 0ea6e611
      Justin P. Mattock 提交于
      Below you will find an updated version from the original series bunching all patches into one big patch
      updating broken web addresses that are located in Documentation/*
      Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
      the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
      Now there are also some addresses pointing to .spec files some are located, but some(after searching
      on the companies site)where still no where to be found. In this case I just changed the address
      to the company site this way the users can contact the company and they can locate them for the users.
      Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Michael Neuling <mikey@neuling.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0ea6e611
  37. 27 7月, 2010 1 次提交