1. 05 Dec, 2018 1 commit
  2. 26 Sep, 2018 1 commit
  3. 25 Jul, 2018 1 commit
  4. 02 Nov, 2017 1 commit
  5. 27 Jun, 2017 1 commit
    • Dan Williams's avatar
      libnvdimm, nfit: enable support for volatile ranges · c9e582aa
      Dan Williams authored
      Allow volatile nfit ranges to participate in all the same infrastructure
      provided for persistent memory regions. A resulting resulting namespace
      device will still be called "pmem", but the parent region type will be
      "nd_volatile". This is in preparation for disabling the dax ->flush()
      operation in the pmem driver when it is hosted on a volatile range.
      
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      c9e582aa
  6. 13 Apr, 2017 1 commit
    • Dave Jiang's avatar
      libnvdimm: fix clear poison locking with spinlock and GFP_NOWAIT allocation · b3b454f6
      Dave Jiang authored
      The following warning results from holding a lane spinlock,
      preempt_disable(), or the btt map spinlock and then trying to take the
      reconfig_mutex to walk the poison list and potentially add new entries.
      
      BUG: sleeping function called from invalid context at kernel/locking/mutex.
      c:747
      in_atomic(): 1, irqs_disabled(): 0, pid: 17159, name: dd
      [..]
      Call Trace:
      dump_stack+0x85/0xc8
      ___might_sleep+0x184/0x250
      __might_sleep+0x4a/0x90
      __mutex_lock+0x58/0x9b0
      ? nvdimm_bus_lock+0x21/0x30 [libnvdimm]
      ? __nvdimm_bus_badblocks_clear+0x2f/0x60 [libnvdimm]
      ? acpi_nfit_forget_poison+0x79/0x80 [nfit]
      ? _raw_spin_unlock+0x27/0x40
      mutex_lock_nested+0x1b/0x20
      nvdimm_bus_lock+0x21/0x30 [libnvdimm]
      nvdimm_forget_poison+0x25/0x50 [libnvdimm]
      nvdimm_clear_poison+0x106/0x140 [libnvdimm]
      nsio_rw_bytes+0x164/0x270 [libnvdimm]
      btt_write_pg+0x1de/0x3e0 [nd_btt]
      ? blk_queue_enter+0x30/0x290
      btt_make_request+0x11a/0x310 [nd_btt]
      ? blk_queue_enter+0xb7/0x290
      ? blk_queue_enter+0x30/0x290
      generic_make_request+0x118/0x3b0
      
      A spinlock is introduced to protect the poison list. This allows us to not
      having to acquire the reconfig_mutex for touching the poison list. The
      add_poison() function has been broken out into two helper functions. One to
      allocate the poison entry and the other to apppend the entry. This allows us
      to unlock the poison_lock in non-I/O path and continue to be able to allocate
      the poison entry with GFP_KERNEL. We will use GFP_NOWAIT in the I/O path in
      order to satisfy being in atomic context.
      Reviewed-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      b3b454f6
  7. 07 Oct, 2016 3 commits
    • Dan Williams's avatar
      libnvdimm, namespace: allow creation of multiple pmem-namespaces per region · 98a29c39
      Dan Williams authored
      Similar to BLK regions, publish new seed namespace devices to allow
      unused PMEM region capacity to be consumed by additional namespaces.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      98a29c39
    • Dan Williams's avatar
      libnvdimm, namespace: enable allocation of multiple pmem namespaces · 762d067d
      Dan Williams authored
      Now that we have nd_region_available_dpa() able to handle the presence
      of multiple PMEM allocations in aliased PMEM regions, reuse that same
      infrastructure to track allocations from free space.  In particular
      handle allocating from an aliased PMEM region in the case where there
      are dis-contiguous holes.  The allocation for BLK and PMEM are
      documented in the space_valid() helper:
      
          BLK-space is valid as long as it does not precede a PMEM
          allocation in a given region. PMEM-space must be contiguous
          and adjacent to an existing existing allocation (if one
          exists).
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      762d067d
    • Dan Williams's avatar
      libnvdimm, region: update nd_region_available_dpa() for multi-pmem support · a1f3e4d6
      Dan Williams authored
      The free dpa (dimm-physical-address) space calculation reports how much
      free space is available with consideration for aliased BLK + PMEM
      regions.  Recall that BLK capacity is allocated from high addresses and
      PMEM is allocated from low addresses in their respective regions.
      
      nd_region_available_dpa() accounts for the fact that the largest
      encroachment (lowest starting address) into PMEM capacity by a BLK
      allocation limits the available capacity to that point, regardless if
      there is BLK allocation hole at a higher address.  Similarly, for the
      multi-pmem case we need to track the largest encroachment (highest
       ending address) of a PMEM allocation in BLK capacity regardless of
      whether there is an allocation hole that a BLK allocation could fill at
      a lower address.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      a1f3e4d6
  8. 01 Oct, 2016 1 commit
  9. 21 Sep, 2016 1 commit
  10. 22 Jul, 2016 1 commit
  11. 11 Jul, 2016 1 commit
    • Dan Williams's avatar
      libnvdimm, nfit: move flush hint mapping to region-device driver-data · e5ae3b25
      Dan Williams authored
      In preparation for triggering flushes of a DIMM's writes-posted-queue
      (WPQ) via the pmem driver move mapping of flush hint addresses to the
      region driver.  Since this uses devm_nvdimm_memremap() the flush
      addresses will remain mapped while any region to which the dimm belongs
      is active.
      
      We need to communicate more information to the nvdimm core to facilitate
      this mapping, namely each dimm object now carries an array of flush hint
      address resources.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      e5ae3b25
  12. 08 Jul, 2016 1 commit
    • Dan Williams's avatar
      libnvdimm: introduce devm_nvdimm_memremap(), convert nfit_spa_map() users · 29b9aa0a
      Dan Williams authored
      In preparation for generically mapping flush hint addresses for both the
      BLK and PMEM use case, provide a generic / reference counted mapping
      api.  Given the fact that a dimm may belong to multiple regions (PMEM
      and BLK), the flush hint addresses need to be held valid as long as any
      region associated with the dimm is active.  This is similar to the
      existing BLK-region case where multiple BLK-regions may share an
      aperture mapping.  Up-level this shared / reference-counted mapping
      capability from the nfit driver to a core nvdimm capability.
      
      This eliminates the need for the nd_blk_region.disable() callback.  Note
      that the removal of nfit_spa_map() and related infrastructure is
      deferred to a later patch.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      29b9aa0a
  13. 21 May, 2016 2 commits
  14. 09 May, 2016 1 commit
    • Dan Williams's avatar
      libnvdimm, dax: introduce device-dax infrastructure · cd03412a
      Dan Williams authored
      Device DAX is the device-centric analogue of Filesystem DAX
      (CONFIG_FS_DAX).  It allows persistent memory ranges to be allocated and
      mapped without need of an intervening file system.  This initial
      infrastructure arranges for a libnvdimm pfn-device to be represented as
      a different device-type so that it can be attached to a driver other
      than the pmem driver.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      cd03412a
  15. 28 Apr, 2016 1 commit
    • Dan Williams's avatar
      nfit, libnvdimm: clarify "commands" vs "_DSMs" · e3654eca
      Dan Williams authored
      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: default avatarDan Williams <dan.j.williams@intel.com>
      e3654eca
  16. 09 Jan, 2016 2 commits
  17. 13 Dec, 2015 1 commit
  18. 29 Aug, 2015 1 commit
    • Dan Williams's avatar
      libnvdimm, pfn: 'struct page' provider infrastructure · e1455744
      Dan Williams authored
      Implement the base infrastructure for libnvdimm PFN devices. Similar to
      BTT devices they take a namespace as a backing device and layer
      functionality on top. In this case the functionality is reserving space
      for an array of 'struct page' entries to be handed out through
      pfn_to_page(). For now this is just the basic libnvdimm-device-model for
      configuring the base PFN device.
      
      As the namespace claiming mechanism for PFN devices is mostly identical
      to BTT devices drivers/nvdimm/claim.c is created to house the common
      bits.
      
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      e1455744
  19. 26 Jun, 2015 1 commit
  20. 25 Jun, 2015 12 commits
    • Dan Williams's avatar
      libnvdimm: infrastructure for btt devices · 8c2f7e86
      Dan Williams authored
      NVDIMM namespaces, in addition to accepting "struct bio" based requests,
      also have the capability to perform byte-aligned accesses.  By default
      only the bio/block interface is used.  However, if another driver can
      make effective use of the byte-aligned capability it can claim namespace
      interface and use the byte-aligned ->rw_bytes() interface.
      
      The BTT driver is the initial first consumer of this mechanism to allow
      adding atomic sector update semantics to a pmem or blk namespace.  This
      patch is the sysfs infrastructure to allow configuring a BTT instance
      for a namespace.  Enabling that BTT and performing i/o is in a
      subsequent patch.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      8c2f7e86
    • Dan Williams's avatar
      libnvdimm: write blk label set · 0ba1c634
      Dan Williams authored
      After 'uuid', 'size', 'sector_size', and optionally 'alt_name' have been
      set to valid values the labels on the dimm can be updated.  The
      difference with the pmem case is that blk namespaces are limited to one
      dimm and can cover discontiguous ranges in dpa space.
      
      Also, after allocating label slots, it is useful for userspace to know
      how many slots are left.  Export this information in sysfs.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      0ba1c634
    • Dan Williams's avatar
      libnvdimm: blk labels and namespace instantiation · 1b40e09a
      Dan Williams authored
      A blk label set describes a namespace comprised of one or more
      discontiguous dpa ranges on a single dimm.  They may alias with one or
      more pmem interleave sets that include the given dimm.
      
      This is the runtime/volatile configuration infrastructure for sysfs
      manipulation of 'alt_name', 'uuid', 'size', and 'sector_size'.  A later
      patch will make these settings persistent by writing back the label(s).
      
      Unlike pmem namespaces, multiple blk namespaces can be created per
      region.  Once a blk namespace has been created a new seed device
      (unconfigured child of a parent blk region) is instantiated.  As long as
      a region has 'available_size' != 0 new child namespaces may be created.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      1b40e09a
    • Dan Williams's avatar
      libnvdimm: pmem label sets and namespace instantiation. · bf9bccc1
      Dan Williams authored
      A complete label set is a PMEM-label per-dimm per-interleave-set where
      all the UUIDs match and the interleave set cookie matches the hosting
      interleave set.
      
      Present sysfs attributes for manipulation of a PMEM-namespace's
      'alt_name', 'uuid', and 'size' attributes.  A later patch will make
      these settings persistent by writing back the label.
      
      Note that PMEM allocations grow forwards from the start of an interleave
      set (lowest dimm-physical-address (DPA)).  BLK-namespaces that alias
      with a PMEM interleave set will grow allocations backward from the
      highest DPA.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      bf9bccc1
    • Dan Williams's avatar
      libnvdimm, nfit: add interleave-set state-tracking infrastructure · eaf96153
      Dan Williams authored
      On platforms that have firmware support for reading/writing per-dimm
      label space, a portion of the dimm may be accessible via an interleave
      set PMEM mapping in addition to the dimm's BLK (block-data-window
      aperture(s)) interface.  A label, stored in a "configuration data
      region" on the dimm, disambiguates which dimm addresses are accessed
      through which exclusive interface.
      
      Add infrastructure that allows the kernel to block modifications to a
      label in the set while any member dimm is active.  Note that this is
      meant only for enforcing "no modifications of active labels" via the
      coarse ioctl command.  Adding/deleting namespaces from an active
      interleave set is always possible via sysfs.
      
      Another aspect of tracking interleave sets is tracking their integrity
      when DIMMs in a set are physically re-ordered.  For this purpose we
      generate an "interleave-set cookie" that can be recorded in a label and
      validated against the current configuration.  It is the bus provider
      implementation's responsibility to calculate the interleave set cookie
      and attach it to a given region.
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      eaf96153
    • Dan Williams's avatar
      libnvdimm: support for legacy (non-aliasing) nvdimms · 3d88002e
      Dan Williams authored
      The libnvdimm region driver is an intermediary driver that translates
      non-volatile "region"s into "namespace" sub-devices that are surfaced by
      persistent memory block-device drivers (PMEM and BLK).
      
      ACPI 6 introduces the concept that a given nvdimm may simultaneously
      offer multiple access modes to its media through direct PMEM load/store
      access, or windowed BLK mode.  Existing nvdimms mostly implement a PMEM
      interface, some offer a BLK-like mode, but never both as ACPI 6 defines.
      If an nvdimm is single interfaced, then there is no need for dimm
      metadata labels.  For these devices we can take the region boundaries
      directly to create a child namespace device (nd_namespace_io).
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      3d88002e
    • Dan Williams's avatar
      libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory) · 1f7df6f8
      Dan Williams authored
      A "region" device represents the maximum capacity of a BLK range (mmio
      block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
      volatile memory), without regard for aliasing.  Aliasing, in the
      dimm-local address space (DPA), is resolved by metadata on a dimm to
      designate which exclusive interface will access the aliased DPA ranges.
      Support for the per-dimm metadata/label arrvies is in a subsequent
      patch.
      
      The name format of "region" devices is "regionN" where, like dimms, N is
      a global ida index assigned at discovery time.  This id is not reliable
      across reboots nor in the presence of hotplug.  Look to attributes of
      the region or static id-data of the sub-namespace to generate a
      persistent name.  However, if the platform configuration does not change
      it is reasonable to expect the same region id to be assigned at the next
      boot.
      
      "region"s have 2 generic attributes "size", and "mapping"s where:
      - size: the BLK accessible capacity or the span of the
        system physical address range in the case of PMEM.
      
      - mappingN: a tuple describing a dimm's contribution to the region's
        capacity in the format (<nmemX>,<dpa>,<size>).  For a PMEM-region
        there will be at least one mapping per dimm in the interleave set.  For
        a BLK-region there is only "mapping0" listing the starting DPA of the
        BLK-region and the available DPA capacity of that space (matches "size"
        above).
      
      The max number of mappings per "region" is hard coded per the
      constraints of sysfs attribute groups.  That said the number of mappings
      per region should never exceed the maximum number of possible dimms in
      the system.  If the current number turns out to not be enough then the
      "mappings" attribute clarifies how many there are supposed to be. "32
      should be enough for anybody...".
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      1f7df6f8
    • Dan Williams's avatar
      libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure · 4d88a97a
      Dan Williams authored
      * Implement the device-model infrastructure for loading modules and
        attaching drivers to nvdimm devices.  This is a simple association of a
        nd-device-type number with a driver that has a bitmask of supported
        device types.  To facilitate userspace bind/unbind operations 'modalias'
        and 'devtype', that also appear in the uevent, are added as generic
        sysfs attributes for all nvdimm devices.  The reason for the device-type
        number is to support sub-types within a given parent devtype, be it a
        vendor-specific sub-type or otherwise.
      
      * The first consumer of this infrastructure is the driver
        for dimm devices.  It simply uses control messages to retrieve and
        store the configuration-data image (label set) from each dimm.
      
      Note: nd_device_register() arranges for asynchronous registration of
            nvdimm bus devices by default.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      4d88a97a
    • Dan Williams's avatar
      libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices · 62232e45
      Dan Williams authored
      Most discovery/configuration of the nvdimm-subsystem is done via sysfs
      attributes.  However, some nvdimm_bus instances, particularly the
      ACPI.NFIT bus, define a small set of messages that can be passed to the
      platform.  For convenience we derive the initial libnvdimm-ioctl command
      formats directly from the NFIT DSM Interface Example formats.
      
          ND_CMD_SMART: media health and diagnostics
          ND_CMD_GET_CONFIG_SIZE: size of the label space
          ND_CMD_GET_CONFIG_DATA: read label space
          ND_CMD_SET_CONFIG_DATA: write label space
          ND_CMD_VENDOR: vendor-specific command passthrough
          ND_CMD_ARS_CAP: report address-range-scrubbing capabilities
          ND_CMD_ARS_START: initiate scrubbing
          ND_CMD_ARS_STATUS: report on scrubbing state
          ND_CMD_SMART_THRESHOLD: configure alarm thresholds for smart events
      
      If a platform later defines different commands than this set it is
      straightforward to extend support to those formats.
      
      Most of the commands target a specific dimm.  However, the
      address-range-scrubbing commands target the bus.  The 'commands'
      attribute in sysfs of an nvdimm_bus, or nvdimm, enumerate the supported
      commands for that object.
      
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reported-by: default avatarNicholas Moulin <nicholas.w.moulin@linux.intel.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      62232e45
    • Dan Williams's avatar
      libnvdimm, nfit: dimm/memory-devices · e6dfb2de
      Dan Williams authored
      Enable nvdimm devices to be registered on a nvdimm_bus.  The kernel
      assigned device id for nvdimm devicesis dynamic.  If userspace needs a
      more static identifier it should consult a provider-specific attribute.
      In the case where NFIT is the provider, the 'nmemX/nfit/handle' or
      'nmemX/nfit/serial' attributes may be used for this purpose.
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      e6dfb2de
    • Dan Williams's avatar
      libnvdimm: control character device and nvdimm_bus sysfs attributes · 45def22c
      Dan Williams authored
      The control device for a nvdimm_bus is registered as an "nd" class
      device.  The expectation is that there will usually only be one "nd" bus
      registered under /sys/class/nd.  However, we allow for the possibility
      of multiple buses and they will listed in discovery order as
      ndctl0...ndctlN.  This character device hosts the ioctl for passing
      control messages.  The initial command set has a 1:1 correlation with
      the commands listed in the by the "NFIT DSM Example" document [1], but
      this scheme is extensible to future command sets.
      
      Note, nd_ioctl() and the backing ->ndctl() implementation are defined in
      a subsequent patch.  This is simply the initial registrations and sysfs
      attributes.
      
      [1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      45def22c
    • Dan Williams's avatar
      libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support · b94d5230
      Dan Williams authored
      A struct nvdimm_bus is the anchor device for registering nvdimm
      resources and interfaces, for example, a character control device,
      nvdimm devices, and I/O region devices.  The ACPI NFIT (NVDIMM Firmware
      Interface Table) is one possible platform description for such
      non-volatile memory resources in a system.  The nfit.ko driver attaches
      to the "ACPI0012" device that indicates the presence of the NFIT and
      parses the table to register a struct nvdimm_bus instance.
      
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      b94d5230