1. 26 8月, 2015 1 次提交
  2. 31 7月, 2015 1 次提交
  3. 30 7月, 2015 1 次提交
  4. 27 7月, 2015 1 次提交
  5. 25 7月, 2015 1 次提交
  6. 24 7月, 2015 1 次提交
  7. 19 7月, 2015 1 次提交
    • D
      iio: ABI: Clarify proximity output value · 63fc4449
      Daniel Baluta 提交于
      Current description for proximity measurement is ambiguous. While
      the first part says that proximity is measured by observing
      reflectivity, the second part incorrectly infers that reported values
      should behave like a distance.
      
      This is because of AS3935 lightning sensor which uses the proximity
      API, while not being a true proximity sensor.
      
      Note this is marked for stable as it accompanies a fix in ABI usage
      to the sx9500 driver which would otherwise appear to be correct.
      
      Fixes:  614e8842 ("iio: ABI: add clarification for proximity")
      Signed-off-by: NDaniel Baluta <daniel.baluta@intel.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      63fc4449
  8. 18 7月, 2015 1 次提交
  9. 16 7月, 2015 2 次提交
  10. 10 7月, 2015 1 次提交
  11. 09 7月, 2015 2 次提交
  12. 08 7月, 2015 1 次提交
  13. 07 7月, 2015 1 次提交
  14. 06 7月, 2015 2 次提交
  15. 05 7月, 2015 10 次提交
  16. 03 7月, 2015 3 次提交
  17. 02 7月, 2015 2 次提交
  18. 01 7月, 2015 4 次提交
  19. 29 6月, 2015 1 次提交
  20. 26 6月, 2015 3 次提交
    • D
      libnvdimm: Non-Volatile Devices · bc30196f
      Dan Williams 提交于
      Maintainer information and documentation for drivers/nvdimm
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      bc30196f
    • V
      nd_btt: atomic sector updates · 5212e11f
      Vishal Verma 提交于
      BTT stands for Block Translation Table, and is a way to provide power
      fail sector atomicity semantics for block devices that have the ability
      to perform byte granularity IO. It relies on the capability of libnvdimm
      namespace devices to do byte aligned IO.
      
      The BTT works as a stacked blocked device, and reserves a chunk of space
      from the backing device for its accounting metadata. It is a bio-based
      driver because all IO is done synchronously, and there is no queuing or
      asynchronous completions at either the device or the driver level.
      
      The BTT uses 'lanes' to index into various 'on-disk' data structures,
      and lanes also act as a synchronization mechanism in case there are more
      CPUs than available lanes. We did a comparison between two lane lock
      strategies - first where we kept an atomic counter around that tracked
      which was the last lane that was used, and 'our' lane was determined by
      atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
      theoretically, no CPU would be blocked waiting for a lane. The other
      strategy was to use the cpu number we're scheduled on to and hash it to
      a lane number. Theoretically, this could block an IO that could've
      otherwise run using a different, free lane. But some fio workloads
      showed that the direct cpu -> lane hash performed faster than tracking
      'last lane' - my reasoning is the cache thrash caused by moving the
      atomic variable made that approach slower than simply waiting out the
      in-progress IO. This supports the conclusion that the driver can be a
      very simple bio-based one that does synchronous IOs instead of queuing.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      [jmoyer: fix nmi watchdog timeout in btt_map_init]
      [jmoyer: move btt initialization to module load path]
      [jmoyer: fix memory leak in the btt initialization path]
      [jmoyer: Don't overwrite corrupted arenas]
      Signed-off-by: NVishal Verma <vishal.l.verma@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      5212e11f
    • N
      coredump: use from_kuid/kgid when formatting corename · 5202efe5
      Nicolas Iooss 提交于
      When adding __printf attribute to cn_printf, gcc reports some issues:
      
        fs/coredump.c:213:5: warning: format '%d' expects argument of type
        'int', but argument 3 has type 'kuid_t' [-Wformat=]
             err = cn_printf(cn, "%d", cred->uid);
             ^
        fs/coredump.c:217:5: warning: format '%d' expects argument of type
        'int', but argument 3 has type 'kgid_t' [-Wformat=]
             err = cn_printf(cn, "%d", cred->gid);
             ^
      
      These warnings come from the fact that the value of uid/gid needs to be
      extracted from the kuid_t/kgid_t structure before being used as an
      integer.  More precisely, cred->uid and cred->gid need to be converted to
      either user-namespace uid/gid or to init_user_ns uid/gid.
      
      Use init_user_ns in order not to break existing ABI, and document this in
      Documentation/sysctl/kernel.txt.
      
      While at it, format uid and gid values with %u instead of %d because
      uid_t/__kernel_uid32_t and gid_t/__kernel_gid32_t are unsigned int.
      Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5202efe5