<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/linux/lightnvm.h, branch linux-6.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2021-08-14T21:54:09Z</updated>
<entry>
<title>remove the lightnvm subsystem</title>
<updated>2021-08-14T21:54:09Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-08-12T13:23:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9ea9b9c48387edc101d56349492ad9c0492ff78d'/>
<id>urn:sha1:9ea9b9c48387edc101d56349492ad9c0492ff78d</id>
<content type='text'>
Lightnvm supports the OCSSD 1.x and 2.0 specs which were early attempts
to produce Open Channel SSDs and never made it into the NVMe spec
proper.  They have since been superceeded by NVMe enhancements such
as ZNS support.  Remove the support per the deprecation schedule.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Link: https://lore.kernel.org/r/20210812132308.38486-1-hch@lst.de
Reviewed-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Reviewed-by: Javier González &lt;javier@javigon.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: remove duplicate include in lightnvm.h</title>
<updated>2021-04-13T15:16:12Z</updated>
<author>
<name>Zhang Yunkai</name>
<email>zhang.yunkai@zte.com.cn</email>
</author>
<published>2021-04-13T10:52:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=655cdafdec1105d0552aa19ffb5ffef7aead1548'/>
<id>urn:sha1:655cdafdec1105d0552aa19ffb5ffef7aead1548</id>
<content type='text'>
'linux/blkdev.h' and 'uapi/linux/lightnvm.h' included in 'lightnvm.h'
is duplicated.It is also included in the 5th and 7th line.

Signed-off-by: Zhang Yunkai &lt;zhang.yunkai@zte.com.cn&gt;
Signed-off-by: Matias Bjørling &lt;matias.bjorling@wdc.com&gt;
Link: https://lore.kernel.org/r/20210413105257.159260-4-matias.bjorling@wdc.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>block: move -&gt;make_request_fn to struct block_device_operations</title>
<updated>2020-07-01T13:27:24Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2020-07-01T08:59:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c62b37d96b6eb3ec5ae4cbe00db107bf15aebc93'/>
<id>urn:sha1:c62b37d96b6eb3ec5ae4cbe00db107bf15aebc93</id>
<content type='text'>
The make_request_fn is a little weird in that it sits directly in
struct request_queue instead of an operation vector.  Replace it with
a block_device_operations method called submit_bio (which describes much
better what it does).  Also remove the request_queue argument to it, as
the queue can be derived pretty trivially from the bio.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: move metadata mapping to lower level driver</title>
<updated>2019-08-06T14:20:10Z</updated>
<author>
<name>Hans Holmberg</name>
<email>hans@owltronix.com</email>
</author>
<published>2019-07-31T09:41:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=48e5da725581c1f7444e45cccbafc33e11430b48'/>
<id>urn:sha1:48e5da725581c1f7444e45cccbafc33e11430b48</id>
<content type='text'>
Now that blk_rq_map_kern can map both kmem and vmem, move internal
metadata mapping down to the lower level driver.

Reviewed-by: Javier González &lt;javier@javigon.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Hans Holmberg &lt;hans@owltronix.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: remove nvm_submit_io_sync_fn</title>
<updated>2019-08-06T14:20:09Z</updated>
<author>
<name>Hans Holmberg</name>
<email>hans@owltronix.com</email>
</author>
<published>2019-07-31T09:41:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=98d87f70f4ab84b9e50e16b7848937ae07518cd4'/>
<id>urn:sha1:98d87f70f4ab84b9e50e16b7848937ae07518cd4</id>
<content type='text'>
Move the redundant sync handling interface and wait for a completion in
the lightnvm core instead.

Reviewed-by: Javier González &lt;javier@javigon.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Hans Holmberg &lt;hans@owltronix.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: track inflight target creations</title>
<updated>2019-05-06T16:19:19Z</updated>
<author>
<name>Igor Konopko</name>
<email>igor.j.konopko@intel.com</email>
</author>
<published>2019-05-04T18:38:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e69397ea05ce0263e3ee72fa8f6f70d2d9a561a7'/>
<id>urn:sha1:e69397ea05ce0263e3ee72fa8f6f70d2d9a561a7</id>
<content type='text'>
When creation process is still in progress, target is not yet on
targets list. This causes a chance for removing whole lightnvm
subsystem by calling nvm_unregister() in the meantime and finally by
causing kernel panic inside target init function.

This patch changes the behaviour by adding kref variable which tracks
all the users of nvm_dev structure. When nvm_dev is allocated, kref
value is set to 1. Then before every target creation the value is
increased and decreased after target removal. The extra reference
is decreased when nvm subsystem is unregistered.

Signed-off-by: Igor Konopko &lt;igor.j.konopko@intel.com&gt;
Reviewed-by: Javier González &lt;javier@javigon.com&gt;
Signed-off-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: Inherit mdts from the parent nvme device</title>
<updated>2019-05-06T16:19:17Z</updated>
<author>
<name>Igor Konopko</name>
<email>igor.j.konopko@intel.com</email>
</author>
<published>2019-05-04T18:37:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a14669ebc0e294f19b2290c294958b7741559d9d'/>
<id>urn:sha1:a14669ebc0e294f19b2290c294958b7741559d9d</id>
<content type='text'>
Current lightnvm and pblk implementation does not care about NVMe max
data transfer size, which can be smaller than 64*K=256K. There are
existing NVMe controllers which NVMe max data transfer size is lower
that 256K (for example 128K, which happens for existing NVMe
controllers which are NVMe spec compliant). Such a controllers are not
able to handle command which contains 64 PPAs, since the the size of
DMAed buffer will be above the capabilities of such a controller.

Signed-off-by: Igor Konopko &lt;igor.j.konopko@intel.com&gt;
Reviewed-by: Hans Holmberg &lt;hans.holmberg@cnexlabs.com&gt;
Reviewed-by: Javier González &lt;javier@javigon.com&gt;
Signed-off-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: disable interleaved metadata</title>
<updated>2018-12-11T19:22:35Z</updated>
<author>
<name>Igor Konopko</name>
<email>igor.j.konopko@intel.com</email>
</author>
<published>2018-12-11T19:16:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a16816b9e462e8ee86a908606bde54b53cfeca80'/>
<id>urn:sha1:a16816b9e462e8ee86a908606bde54b53cfeca80</id>
<content type='text'>
Currently pblk only check the size of I/O metadata and does not take
into account if this metadata is in a separate buffer or interleaved
in a single metadata buffer.

In reality only the first scenario is supported, where second mode will
break pblk functionality during any IO operation.

This patch prevents pblk to be instantiated in case device only
supports interleaved metadata.

Reviewed-by: Javier González &lt;javier@cnexlabs.com&gt;
Signed-off-by: Igor Konopko &lt;igor.j.konopko@intel.com&gt;
Signed-off-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: dynamic DMA pool entry size</title>
<updated>2018-12-11T19:22:35Z</updated>
<author>
<name>Igor Konopko</name>
<email>igor.j.konopko@intel.com</email>
</author>
<published>2018-12-11T19:16:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=24828d0536bbedc9b265f2b01ffca99de3f6a7c7'/>
<id>urn:sha1:24828d0536bbedc9b265f2b01ffca99de3f6a7c7</id>
<content type='text'>
Currently lightnvm and pblk uses single DMA pool, for which the entry
size always is equal to PAGE_SIZE. The contents of each entry allocated
from the DMA pool consists of a PPA list (8bytes * 64), leaving
56bytes * 64 space for metadata. Since the metadata field can be bigger,
such as 128 bytes, the static size does not cover this use-case.

This patch adds support for I/O metadata above 56 bytes by changing DMA
pool size based on device meta size and allows pblk to use OOB metadata
&gt;=16B.

Reviewed-by: Javier González &lt;javier@cnexlabs.com&gt;
Signed-off-by: Igor Konopko &lt;igor.j.konopko@intel.com&gt;
Signed-off-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>lightnvm: pblk: fix mapping issue on failed writes</title>
<updated>2018-10-09T14:25:07Z</updated>
<author>
<name>Hans Holmberg</name>
<email>hans.holmberg@cnexlabs.com</email>
</author>
<published>2018-10-09T11:11:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bf82fa2f584f1c6e12df8c04fca715d53e7f32d5'/>
<id>urn:sha1:bf82fa2f584f1c6e12df8c04fca715d53e7f32d5</id>
<content type='text'>
On 1.2-devices, the mapping-out of remaning sectors in the
failed-write's block can result in an infinite loop,
stalling the write pipeline, fix this.

Fixes: 6a3abf5beef6 ("lightnvm: pblk: rework write error recovery path")
Signed-off-by: Hans Holmberg &lt;hans.holmberg@cnexlabs.com&gt;
Signed-off-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
</feed>
