1. 19 Sep, 2017 1 commit
  2. 13 Sep, 2017 4 commits
  3. 09 Sep, 2017 5 commits
    • Robert P. J. Day's avatar
      drivers/pps: aesthetic tweaks to PPS-related content · a2d81803
      Robert P. J. Day authored
      Collection of aesthetic adjustments to various PPS-related files,
      directories and Documentation, some quite minor just for the sake of
      consistency, including:
      
       * Updated example of pps device tree node (courtesy Rodolfo G.)
       * "PPS-API" -> "PPS API"
       * "pps_source_info_s" -> "pps_source_info"
       * "ktimer driver" -> "pps-ktimer driver"
       * "ppstest /dev/pps0" -> "ppstest /dev/pps1" to match example
       * Add missing PPS-related entries to MAINTAINERS file
       * Other trivialities
      
      Link: http://lkml.kernel.org/r/alpine.LFD.2.20.1708261048220.8106@localhost.localdomainSigned-off-by: default avatarRobert P. J. Day <rpjday@crashcourse.ca>
      Acked-by: default avatarRodolfo Giometti <giometti@enneenne.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a2d81803
    • Luis R. Rodriguez's avatar
      kmod: split off umh headers into its own file · c1f3fa2a
      Luis R. Rodriguez authored
      In the future usermode helper users do not need to carry in all the of
      kmod headers declarations.
      
      Since kmod.h still includes umh.h this change has no functional changes,
      each umh user can be cleaned up separately later and with time.
      
      Link: http://lkml.kernel.org/r/20170810180618.22457-4-mcgrof@kernel.orgSigned-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c1f3fa2a
    • Luis R. Rodriguez's avatar
      MAINTAINERS: clarify kmod is just a kernel module loader · 00653d3a
      Luis R. Rodriguez authored
      This should make it clearer what the kmod code is now that
      the umh code is split out separately.
      
      Link: http://lkml.kernel.org/r/20170810180618.22457-3-mcgrof@kernel.orgSigned-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00653d3a
    • Luis R. Rodriguez's avatar
      kmod: split out umh code into its own file · 23558693
      Luis R. Rodriguez authored
      Patch series "kmod: few code cleanups to split out umh code"
      
      The usermode helper has a provenance from the old usb code which first
      required a usermode helper.  Eventually this was shoved into kmod.c and
      the kernel's modprobe calls was converted over eventually to share the
      same code.  Over time the list of usermode helpers in the kernel has grown
      -- so kmod is just but one user of the API.
      
      This series is a simple logical cleanup which acknowledges the code
      evolution of the usermode helper and shoves the UMH API into its own
      dedicated file.  This way users of the API can later just include umh.h
      instead of kmod.h.
      
      Note despite the diff state the first patch really is just a code shove,
      no functional changes are done there.  I did use git format-patch -M to
      generate the patch, but in the end the split was not enough for git to
      consider it a rename hence the large diffstat.
      
      I've put this through 0-day and it gives me their machine compilation
      blessings with all tests as OK.
      
      This patch (of 4):
      
      There's a slew of usermode helper users and kmod is just one of them.
      Split out the usermode helper code into its own file to keep the logic and
      focus split up.
      
      This change provides no functional changes.
      
      Link: http://lkml.kernel.org/r/20170810180618.22457-2-mcgrof@kernel.orgSigned-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23558693
    • Jérôme Glisse's avatar
      hmm: heterogeneous memory management documentation · bffc33ec
      Jérôme Glisse authored
      Patch series "HMM (Heterogeneous Memory Management)", v25.
      
      Heterogeneous Memory Management (HMM) (description and justification)
      
      Today device driver expose dedicated memory allocation API through their
      device file, often relying on a combination of IOCTL and mmap calls.
      The device can only access and use memory allocated through this API.
      This effectively split the program address space into object allocated
      for the device and useable by the device and other regular memory
      (malloc, mmap of a file, share memory, â) only accessible by
      CPU (or in a very limited way by a device by pinning memory).
      
      Allowing different isolated component of a program to use a device thus
      require duplication of the input data structure using device memory
      allocator.  This is reasonable for simple data structure (array, grid,
      image, â) but this get extremely complex with advance data
      structure (list, tree, graph, â) that rely on a web of memory
      pointers.  This is becoming a serious limitation on the kind of work
      load that can be offloaded to device like GPU.
      
      New industry standard like C++, OpenCL or CUDA are pushing to remove
      this barrier.  This require a shared address space between GPU device
      and CPU so that GPU can access any memory of a process (while still
      obeying memory protection like read only).  This kind of feature is also
      appearing in various other operating systems.
      
      HMM is a set of helpers to facilitate several aspects of address space
      sharing and device memory management.  Unlike existing sharing mechanism
      that rely on pining pages use by a device, HMM relies on mmu_notifier to
      propagate CPU page table update to device page table.
      
      Duplicating CPU page table is only one aspect necessary for efficiently
      using device like GPU.  GPU local memory have bandwidth in the TeraBytes/
      second range but they are connected to main memory through a system bus
      like PCIE that is limited to 32GigaBytes/second (PCIE 4.0 16x).  Thus it
      is necessary to allow migration of process memory from main system memory
      to device memory.  Issue is that on platform that only have PCIE the
      device memory is not accessible by the CPU with the same properties as
      main memory (cache coherency, atomic operations, ...).
      
      To allow migration from main memory to device memory HMM provides a set of
      helper to hotplug device memory as a new type of ZONE_DEVICE memory which
      is un-addressable by CPU but still has struct page representing it.  This
      allow most of the core kernel logic that deals with a process memory to
      stay oblivious of the peculiarity of device memory.
      
      When page backing an address of a process is migrated to device memory the
      CPU page table entry is set to a new specific swap entry.  CPU access to
      such address triggers a migration back to system memory, just like if the
      page was swap on disk.  HMM also blocks any one from pinning a ZONE_DEVICE
      page so that it can always be migrated back to system memory if CPU access
      it.  Conversely HMM does not migrate to device memory any page that is pin
      in system memory.
      
      To allow efficient migration between device memory and main memory a new
      migrate_vma() helpers is added with this patchset.  It allows to leverage
      device DMA engine to perform the copy operation.
      
      This feature will be use by upstream driver like nouveau mlx5 and probably
      other in the future (amdgpu is next suspect in line).  We are actively
      working on nouveau and mlx5 support.  To test this patchset we also worked
      with NVidia close source driver team, they have more resources than us to
      test this kind of infrastructure and also a bigger and better userspace
      eco-system with various real industry workload they can be use to test and
      profile HMM.
      
      The expected workload is a program builds a data set on the CPU (from
      disk, from network, from sensors, â).  Program uses GPU API (OpenCL,
      CUDA, ...) to give hint on memory placement for the input data and also
      for the output buffer.  Program call GPU API to schedule a GPU job, this
      happens using device driver specific ioctl.  All this is hidden from
      programmer point of view in case of C++ compiler that transparently
      offload some part of a program to GPU.  Program can keep doing other stuff
      on the CPU while the GPU is crunching numbers.
      
      It is expected that CPU will not access the same data set as the GPU while
      GPU is working on it, but this is not mandatory.  In fact we expect some
      small memory object to be actively access by both GPU and CPU concurrently
      as synchronization channel and/or for monitoring purposes.  Such object
      will stay in system memory and should not be bottlenecked by system bus
      bandwidth (rare write and read access from both CPU and GPU).
      
      As we are relying on device driver API, HMM does not introduce any new
      syscall nor does it modify any existing ones.  It does not change any
      POSIX semantics or behaviors.  For instance the child after a fork of a
      process that is using HMM will not be impacted in anyway, nor is there any
      data hazard between child COW or parent COW of memory that was migrated to
      device prior to fork.
      
      HMM assume a numbers of hardware features.  Device must allow device page
      table to be updated at any time (ie device job must be preemptable).
      Device page table must provides memory protection such as read only.
      Device must track write access (dirty bit).  Device must have a minimum
      granularity that match PAGE_SIZE (ie 4k).
      
      Reviewer (just hint):
      Patch 1  HMM documentation
      Patch 2  introduce core infrastructure and definition of HMM, pretty
               small patch and easy to review
      Patch 3  introduce the mirror functionality of HMM, it relies on
               mmu_notifier and thus someone familiar with that part would be
               in better position to review
      Patch 4  is an helper to snapshot CPU page table while synchronizing with
               concurrent page table update. Understanding mmu_notifier makes
               review easier.
      Patch 5  is mostly a wrapper around handle_mm_fault()
      Patch 6  add new add_pages() helper to avoid modifying each arch memory
               hot plug function
      Patch 7  add a new memory type for ZONE_DEVICE and also add all the logic
               in various core mm to support this new type. Dan Williams and
               any core mm contributor are best people to review each half of
               this patchset
      Patch 8  special case HMM ZONE_DEVICE pages inside put_page() Kirill and
               Dan Williams are best person to review this
      Patch 9  allow to uncharge a page from memory group without using the lru
               list field of struct page (best reviewer: Johannes Weiner or
               Vladimir Davydov or Michal Hocko)
      Patch 10 Add support to uncharge ZONE_DEVICE page from a memory cgroup (best
               reviewer: Johannes Weiner or Vladimir Davydov or Michal Hocko)
      Patch 11 add helper to hotplug un-addressable device memory as new type
               of ZONE_DEVICE memory (new type introducted in patch 3 of this
               serie). This is boiler plate code around memory hotplug and it
               also pick a free range of physical address for the device memory.
               Note that the physical address do not point to anything (at least
               as far as the kernel knows).
      Patch 12 introduce a new hmm_device class as an helper for device driver
               that want to expose multiple device memory under a common fake
               device driver. This is usefull for multi-gpu configuration.
               Anyone familiar with device driver infrastructure can review
               this. Boiler plate code really.
      Patch 13 add a new migrate mode. Any one familiar with page migration is
               welcome to review.
      Patch 14 introduce a new migration helper (migrate_vma()) that allow to
               migrate a range of virtual address of a process using device DMA
               engine to perform the copy. It is not limited to do copy from and
               to device but can also do copy between any kind of source and
               destination memory. Again anyone familiar with migration code
               should be able to verify the logic.
      Patch 15 optimize the new migrate_vma() by unmapping pages while we are
               collecting them. This can be review by any mm folks.
      Patch 16 add unaddressable memory migration to helper introduced in patch
               7, this can be review by anyone familiar with migration code
      Patch 17 add a feature that allow device to allocate non-present page on
               the GPU when migrating a range of address to device memory. This
               is an helper for device driver to avoid having to first allocate
               system memory before migration to device memory
      Patch 18 add a new kind of ZONE_DEVICE memory for cache coherent device
               memory (CDM)
      Patch 19 add an helper to hotplug CDM memory
      
      Previous patchset posting :
      v1 http://lwn.net/Articles/597289/
      v2 https://lkml.org/lkml/2014/6/12/559
      v3 https://lkml.org/lkml/2014/6/13/633
      v4 https://lkml.org/lkml/2014/8/29/423
      v5 https://lkml.org/lkml/2014/11/3/759
      v6 http://lwn.net/Articles/619737/
      v7 http://lwn.net/Articles/627316/
      v8 https://lwn.net/Articles/645515/
      v9 https://lwn.net/Articles/651553/
      v10 https://lwn.net/Articles/654430/
      v11 http://www.gossamer-threads.com/lists/linux/kernel/2286424
      v12 http://www.kernelhub.org/?msg=972982&p=2
      v13 https://lwn.net/Articles/706856/
      v14 https://lkml.org/lkml/2016/12/8/344
      v15 http://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg1304107.html
      v16 http://www.spinics.net/lists/linux-mm/msg119814.html
      v17 https://lkml.org/lkml/2017/1/27/847
      v18 https://lkml.org/lkml/2017/3/16/596
      v19 https://lkml.org/lkml/2017/4/5/831
      v20 https://lwn.net/Articles/720715/
      v21 https://lkml.org/lkml/2017/4/24/747
      v22 http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05176.html
      v23 https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1404788.html
      v24 https://lwn.net/Articles/726691/
      
      This patch (of 19):
      
      This adds documentation for HMM (Heterogeneous Memory Management).  It
      presents the motivation behind it, the features necessary for it to be
      useful and and gives an overview of how this is implemented.
      
      Link: http://lkml.kernel.org/r/20170817000548.32038-2-jglisse@redhat.comSigned-off-by: default avatarJérôme Glisse <jglisse@redhat.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: David Nellans <dnellans@nvidia.com>
      Cc: Balbir Singh <bsingharora@gmail.com>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Evgeny Baskakov <ebaskakov@nvidia.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Mark Hairgrove <mhairgrove@nvidia.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Sherry Cheung <SCheung@nvidia.com>
      Cc: Subhash Gutti <sgutti@nvidia.com>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Bob Liu <liubo95@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bffc33ec
  4. 05 Sep, 2017 2 commits
  5. 04 Sep, 2017 1 commit
  6. 01 Sep, 2017 2 commits
  7. 31 Aug, 2017 7 commits
  8. 30 Aug, 2017 2 commits
  9. 29 Aug, 2017 6 commits
    • Paul Burton's avatar
      MIPS: generic: Allow filtering enabled boards by requirements · 27e0d4b0
      Paul Burton authored
      Up until now when configuring a generic kernel all board config
      fragments have been merged by default unless boards are explicitly
      selected by the user specifying BOARDS=.
      
      In many cases this is sub-optimal, since some boards don't make sense to
      include in some kernels. For example the MIPS SEAD-3 development board
      has only ever been used with 32 bit CPUs, so including support for the
      SEAD-3 in a 64 bit kernel is wasteful.
      
      This patch introduces support for specifying requirements in board
      config fragments, using comments formatted like so:
      
        # require CONFIG_BLA=y
      
      For example the SEAD-3 board could specify that it should only be merged
      for 32 bit kernels using a requirement line like the following:
      
        # require CONFIG_32BIT=y
      
      A new generic-board-config.sh script is introduced to handle selecting
      the board config fragments to merge & calling merge_config.sh to merge
      them. In order to allow requirements to check Kconfig symbols that are
      implicitly selected, rather than explicitly specified by
      generic_defconfig or one of the ISA config fragments, an intermediate
      .config file is saved & used as a reference when checking requirements.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16943/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      27e0d4b0
    • Greg Kroah-Hartman's avatar
      staging: irda: update MAINTAINERS · 6c766db6
      Greg Kroah-Hartman authored
      Now that the IRDA code has moved under drivers/staging/irda/, update the
      MAINTAINERS file with the new location.
      Reported-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c766db6
    • Aleksandar Markovic's avatar
      MIPS: math-emu: RINT.<D|S>: Fix several problems by reimplementation · 3ec404d8
      Aleksandar Markovic authored
      Reimplement RINT.<D|S> kernel emulation so that all RINT.<D|S>
      specifications are met.
      
      For the sake of simplicity, let's analyze RINT.S only. Prior to
      this patch, RINT.S emulation was essentially implemented as (in
      pseudocode) <output> = ieee754sp_flong(ieee754sp_tlong(<input>)),
      where ieee754sp_tlong() and ieee754sp_flong() are functions
      providing conversion from double to integer, and from integer
      to double, respectively. On surface, this implementation looks
      correct, but actually fails in many cases. Following problems
      were detected:
      
      1. NaN and infinity cases will not be handled properly. The
         function ieee754sp_flong() never returns NaN nor infinity.
      2. For RINT.S, for all inputs larger than LONG_MAX, and smaller
         than FLT_MAX, the result will be wrong, and the overflow
         exception will be erroneously set. A similar problem for
         negative inputs exists as well.
      3. For some rounding modes, for some negative inputs close to zero,
         the return value will be zero, and should be -zero. This is
         because ieee754sp_flong() never returns -zero.
      
      This patch removes the problems above by implementing dedicated
      functions for RINT.<D|S> emulation.
      
      The core of the new function functionality is adapted version of
      the core of the function ieee754sp_tlong(). However, there are many
      details that are implemented to match RINT.<D|S> specification. It
      should be said that the functionality of ieee754sp_tlong() actually
      closely corresponds to CVT.L.S instruction, and it is used while
      emulating CVT.L.S. However, RINT.S and CVT.L.S instructions differ
      in many aspects. This patch fulfills missing support for RINT.<D|S>.
      Signed-off-by: default avatarMiodrag Dinic <miodrag.dinic@imgtec.com>
      Signed-off-by: default avatarGoran Ferenc <goran.ferenc@imgtec.com>
      Signed-off-by: default avatarAleksandar Markovic <aleksandar.markovic@imgtec.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Douglas Leung <douglas.leung@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Hans Verkuil <hans.verkuil@cisco.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Maciej W. Rozycki <macro@imgtec.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Petar Jovanovic <petar.jovanovic@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/17141/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      3ec404d8
    • Harvey Hunt's avatar
      MIPS: Add Onion Omega2+ board · 323ac96d
      Harvey Hunt authored
      The Onion Omega2+ is an MT7688A based board that has 128MB RAM and
      multiple peripherals.
      
      The MT7688A is pin compatible with the MT7628A, although the former
      supports a 1T1R antenna whereas the MT7628A supports a 2R2T antenna.
      Signed-off-by: default avatarHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: robh+dt@kernel.org
      Cc: mark.rutland@arm.com
      Cc: john@phrozen.org
      Cc: linux-kernel@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17137/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      323ac96d
    • Harvey Hunt's avatar
      MIPS: dts: Add Vocore2 board · d48faef7
      Harvey Hunt authored
      The VoCore2 board is a low cost MT7628A based board with 128MB RAM, 16MB
      flash and multiple external peripherals.
      
      This initial DTS provides enough support to get to userland and use the USB
      port.
      Signed-off-by: default avatarHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: robh+dt@kernel.org
      Cc: mark.rutland@arm.com
      Cc: john@phrozen.org
      Cc: linux-kernel@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17134/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      d48faef7
    • Hans de Goede's avatar
      MAINTAINERS: Add entry for drivers/i2c/busses/i2c-cht-wc.c · d596f2b8
      Hans de Goede authored
      Add an entry for drivers/i2c/busses/i2c-cht-wc.c and add myself as
      maintainer of this driver.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      d596f2b8
  10. 28 Aug, 2017 2 commits
  11. 27 Aug, 2017 2 commits
  12. 26 Aug, 2017 1 commit
  13. 25 Aug, 2017 1 commit
  14. 24 Aug, 2017 1 commit
  15. 23 Aug, 2017 1 commit
  16. 22 Aug, 2017 2 commits