1. 22 Sep, 2016 4 commits
  2. 21 Sep, 2016 7 commits
    • Arnd Bergmann's avatar
      lightnvm: propagate device_add() error code · 1e3aeae4
      Arnd Bergmann authored
      device_add() may fail, and all callers are supposed to check the
      return value, but one new user in lightnvm doesn't:
      
      drivers/lightnvm/sysfs.c: In function 'nvm_sysfs_register_dev':
      drivers/lightnvm/sysfs.c:184:2: error: ignoring return value of 'device_add',
        declared with attribute warn_unused_result [-Werror=unused-result]
      
      This changes the caller to propagate any error codes, which avoids
      the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 38c9e260b9f9 ("lightnvm: expose device geometry through sysfs")
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      1e3aeae4
    • Simon A. F. Lund's avatar
      lightnvm: expose device geometry through sysfs · 40267efd
      Simon A. F. Lund authored
      For a host to access an Open-Channel SSD, it has to know its geometry,
      so that it writes and reads at the appropriate device bounds.
      
      Currently, the geometry information is kept within the kernel, and not
      exported to user-space for consumption. This patch exposes the
      configuration through sysfs and enables user-space libraries, such as
      liblightnvm, to use the sysfs implementation to get the geometry of an
      Open-Channel SSD.
      
      The sysfs entries are stored within the device hierarchy, and can be
      found using the "lightnvm" device type.
      
      An example configuration looks like this:
      
      /sys/class/nvme/
      └── nvme0n1
         ├── capabilities: 3
         ├── device_mode: 1
         ├── erase_max: 1000000
         ├── erase_typ: 1000000
         ├── flash_media_type: 0
         ├── media_capabilities: 0x00000001
         ├── media_type: 0
         ├── multiplane: 0x00010101
         ├── num_blocks: 1022
         ├── num_channels: 1
         ├── num_luns: 4
         ├── num_pages: 64
         ├── num_planes: 1
         ├── page_size: 4096
         ├── prog_max: 100000
         ├── prog_typ: 100000
         ├── read_max: 10000
         ├── read_typ: 10000
         ├── sector_oob_size: 0
         ├── sector_size: 4096
         ├── media_manager: gennvm
         ├── ppa_format: 0x380830082808001010102008
         ├── vendor_opcode: 0
         ├── max_phys_secs: 64
         └── version: 1
      Signed-off-by: default avatarSimon A. F. Lund <slund@cnexlabs.com>
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      40267efd
    • Matias Bjørling's avatar
      lightnvm: control life of nvm_dev in driver · b0b4e09c
      Matias Bjørling authored
      LightNVM compatible device drivers does not have a method to expose
      LightNVM specific sysfs entries.
      
      To enable LightNVM sysfs entries to be exposed, lightnvm device
      drivers require a struct device to attach it to. To allow both the
      actual device driver and lightnvm sysfs entries to coexist, the device
      driver tracks the lifetime of the nvm_dev structure.
      
      This patch refactors NVMe and null_blk to handle the lifetime of struct
      nvm_dev, which eliminates the need for struct gendisk when a lightnvm
      compatible device is provided.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      b0b4e09c
    • Matias Bjørling's avatar
      blk-mq: register device instead of disk · b21d5b30
      Matias Bjørling authored
      Enable devices without a gendisk instance to register itself with blk-mq
      and expose the associated multi-queue sysfs entries.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      b21d5b30
    • Matias Bjørling's avatar
      null_blk: refactor to support non-gendisk devices · 9ae2d0aa
      Matias Bjørling authored
      With LightNVM enabled devices, the gendisk structure is not exposed
      to the user. This hides the device driver specific sysfs entries, and
      prevents binding of LightNVM geometry information to the device.
      
      Refactor the device registration process, so that gendisk and
      non-gendisk devices are easily managed.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      9ae2d0aa
    • Matias Bjørling's avatar
      nvme: refactor namespaces to support non-gendisk devices · ac81bfa9
      Matias Bjørling authored
      With LightNVM enabled namespaces, the gendisk structure is not exposed
      to the user. This prevents LightNVM users from accessing the NVMe device
      driver specific sysfs entries, and LightNVM namespace geometry.
      
      Refactor the revalidation process, so that a namespace, instead of a
      gendisk, is revalidated. This later allows patches to wire up the
      sysfs entries up to a non-gendisk namespace.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      ac81bfa9
    • Geert Uytterhoeven's avatar
      lightnvm: NVM should depend on HAS_DMA · e105ddb4
      Geert Uytterhoeven authored
      If NO_DMA=y:
      
          drivers/built-in.o: In function `nvme_nvm_dev_dma_free':
          lightnvm.c:(.text+0x23df1a): undefined reference to `dma_pool_free'
          drivers/built-in.o: In function `nvme_nvm_dev_dma_alloc':
          lightnvm.c:(.text+0x23df38): undefined reference to `dma_pool_alloc'
          drivers/built-in.o: In function `nvme_nvm_destroy_dma_pool':
          lightnvm.c:(.text+0x23df4c): undefined reference to `dma_pool_destroy'
          drivers/built-in.o: In function `nvme_nvm_create_dma_pool':
          lightnvm.c:(.text+0x23df7e): undefined reference to `dma_pool_create'
      
      and
      
          ERROR: "dma_pool_destroy" [drivers/nvme/host/nvme-core.ko] undefined!
          ERROR: "dma_pool_free" [drivers/nvme/host/nvme-core.ko] undefined!
          ERROR: "dma_pool_alloc" [drivers/nvme/host/nvme-core.ko] undefined!
          ERROR: "dma_pool_create" [drivers/nvme/host/nvme-core.ko] undefined!
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      e105ddb4
  3. 19 Sep, 2016 1 commit
  4. 17 Sep, 2016 7 commits
  5. 16 Sep, 2016 1 commit
    • Jens Axboe's avatar
      blk-mq: account higher order dispatch · 703fd1c0
      Jens Axboe authored
      We currently account a '0' dispatch, and anything above that still falls
      below the range set by BLK_MQ_MAX_DISPATCH_ORDER. If we dispatch more,
      we don't account it.
      
      Change the last bucket to be inclusive of anything above the range we
      track, and have the sysfs file reflect that by including a '+' in the
      output:
      
      $ cat /sys/block/nvme0n1/mq/0/dispatched
              0	1006
              1	20229
              2	1
              4	0
              8	0
             16	0
             32+	0
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Reviewed-by: default avatarOmar Sandoval <osandov@fb.com>
      703fd1c0
  6. 14 Sep, 2016 12 commits
  7. 08 Sep, 2016 4 commits
  8. 29 Aug, 2016 4 commits