1. 02 2月, 2018 1 次提交
  2. 05 12月, 2017 2 次提交
    • D
      tools/testing/nvdimm: smart alarm/threshold control · ed07c433
      Dan Williams 提交于
      Allow the smart_threshold values to be changed via the 'set smart
      threshold command' and trigger notifications when the thresholds are
      met.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ed07c433
    • D
      nfit, libnvdimm: deprecate the generic SMART ioctl · cdd77d3e
      Dan Williams 提交于
      The kernel's ND_IOCTL_SMART_THRESHOLD command is based on a payload
      definition that has become broken / out-of-sync with recent versions of
      the NVDIMM_FAMILY_INTEL definition. Deprecate the use of the
      ND_IOCTL_SMART_THRESHOLD command in favor of the ND_CMD_CALL approach
      taken by NVDIMM_FAMILY_{HPE,MSFT}, where we can manage the per-vendor
      variance in userspace.
      
      In a couple years, when the new scheme is widely deployed in userspace
      packages, the ND_IOCTL_SMART_THRESHOLD support can be removed. For now
      we prevent new binaries from compiling against the kernel header
      definitions, but kernel still compatible with old binaries. The
      libndctl.h [1] header is now the authoritative interface definition for
      NVDIMM SMART.
      
      [1]: https://github.com/pmem/ndctlSigned-off-by: NDan Williams <dan.j.williams@intel.com>
      cdd77d3e
  3. 14 11月, 2017 1 次提交
  4. 09 11月, 2017 1 次提交
  5. 03 11月, 2017 2 次提交
  6. 08 10月, 2017 1 次提交
  7. 19 9月, 2017 1 次提交
  8. 01 9月, 2017 1 次提交
    • R
      libnvdimm, nd_blk: remove mmio_flush_range() · 5deb67f7
      Robin Murphy 提交于
      mmio_flush_range() suffers from a lack of clearly-defined semantics,
      and is somewhat ambiguous to port to other architectures where the
      scope of the writeback implied by "flush" and ordering might matter,
      but MMIO would tend to imply non-cacheable anyway. Per the rationale
      in 67a3e8fe ("nd_blk: change aperture mapping from WC to WB"), the
      only existing use is actually to invalidate clean cache lines for
      ARCH_MEMREMAP_PMEM type mappings *without* writeback. Since the recent
      cleanup of the pmem API, that also now happens to be the exact purpose
      of arch_invalidate_pmem(), which would be a far more well-defined tool
      for the job.
      
      Rather than risk potentially inconsistent implementations of
      mmio_flush_range() for the sake of one callsite, streamline things by
      removing it entirely and instead move the ARCH_MEMREMAP_PMEM related
      definitions up to the libnvdimm level, so they can be shared by NFIT
      as well. This allows NFIT to be enabled for arm64.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      5deb67f7
  9. 16 6月, 2017 1 次提交
    • Y
      tools/testing/nvdimm: fix nfit_test buffer overflow · a117699c
      Yasunori Goto 提交于
      The root cause of panic is the num_pm of nfit_test1 is wrong.
      Though 1 is specified for num_pm at nfit_test_init(), it must be 2,
      because nfit_test1->spa_set[] array has 2 elements.
      
      Since the array is smaller than expected, the driver breaks other area.
      (it is often the link list of devres).
      
      As a result, panic occurs like the following example.
      
          CPU: 4 PID: 2233 Comm: lt-libndctl Tainted: G           O    4.12.0-rc1+ #12
          RIP: 0010:__list_del_entry_valid+0x6c/0xa0
          Call Trace:
           release_nodes+0x76/0x260
           devres_release_all+0x3c/0x50
           device_release_driver_internal+0x159/0x200
           device_release_driver+0x12/0x20
           bus_remove_device+0xfd/0x170
           device_del+0x1e8/0x330
           platform_device_del+0x28/0x90
           platform_device_unregister+0x12/0x30
           nfit_test_exit+0x2a/0x93b [nfit_test]
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      a117699c
  10. 07 6月, 2017 1 次提交
  11. 19 4月, 2017 2 次提交
  12. 18 4月, 2017 1 次提交
  13. 01 3月, 2017 1 次提交
  14. 07 12月, 2016 1 次提交
    • D
      tools/testing/nvdimm: unit test acpi_nfit_ctl() · a7de92da
      Dan Williams 提交于
      A recent flurry of bug discoveries in the nfit driver's DSM marshalling
      routine has highlighted the fact that we do not have unit test coverage
      for this routine. Add a self-test of acpi_nfit_ctl() routine before
      probing the "nfit_test.0" device. This mocks stimulus to acpi_nfit_ctl()
      and if any of the tests fail "nfit_test.0" will be unavailable causing
      the rest of the tests to not run / fail.
      
      This unit test will also be a place to land reproductions of quirky BIOS
      behavior discovered in the field and ensure the kernel does not regress
      against implementations it has seen in practice.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      a7de92da
  15. 19 10月, 2016 1 次提交
  16. 08 10月, 2016 1 次提交
  17. 22 9月, 2016 1 次提交
  18. 20 9月, 2016 1 次提交
  19. 02 9月, 2016 1 次提交
  20. 23 8月, 2016 1 次提交
  21. 11 8月, 2016 1 次提交
    • D
      tools/testing/nvdimm: fix SIGTERM vs hotplug crash · d8d378fa
      Dan Williams 提交于
      The unit tests crash when hotplug races the previous probe. This race
      requires that the loading of the nfit_test module be terminated with
      SIGTERM, and the module to be unloaded while the ars scan is still
      running.
      
      In contrast to the normal nfit driver, the unit test calls
      acpi_nfit_init() twice to simulate hotplug, whereas the nominal case
      goes through the acpi_nfit_notify() event handler.  The
      acpi_nfit_notify() path is careful to flush the previous region
      registration before servicing the hotplug event. The unit test was
      missing this guarantee.
      
       BUG: unable to handle kernel NULL pointer dereference at           (null)
       IP: [<ffffffff810cdce7>] pwq_activate_delayed_work+0x47/0x170
       [..]
       Call Trace:
        [<ffffffff810ce186>] pwq_dec_nr_in_flight+0x66/0xa0
        [<ffffffff810ce490>] process_one_work+0x2d0/0x680
        [<ffffffff810ce331>] ? process_one_work+0x171/0x680
        [<ffffffff810ce88e>] worker_thread+0x4e/0x480
        [<ffffffff810ce840>] ? process_one_work+0x680/0x680
        [<ffffffff810ce840>] ? process_one_work+0x680/0x680
        [<ffffffff810d5343>] kthread+0xf3/0x110
        [<ffffffff8199846f>] ret_from_fork+0x1f/0x40
        [<ffffffff810d5250>] ? kthread_create_on_node+0x230/0x230
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      d8d378fa
  22. 23 7月, 2016 1 次提交
  23. 22 7月, 2016 4 次提交
  24. 12 7月, 2016 1 次提交
  25. 28 6月, 2016 1 次提交
  26. 06 5月, 2016 1 次提交
  27. 29 4月, 2016 1 次提交
    • D
      nfit, libnvdimm: clarify "commands" vs "_DSMs" · e3654eca
      Dan Williams 提交于
      Clarify the distinction between "commands", the ioctls userspace calls
      to request the kernel take some action on a given dimm device, and
      "_DSMs", the actual function numbers used in the firmware interface to
      the DIMM.  _DSMs are ACPI specific whereas commands are Linux kernel
      generic.
      
      This is in preparation for breaking the 1:1 implicit relationship
      between the kernel ioctl number space and the firmware specific function
      numbers.
      
      Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      e3654eca
  28. 12 4月, 2016 1 次提交
  29. 06 3月, 2016 6 次提交