u-boot.git/drivers/nvme, branch v2021.07

nvme: Don't clear nvme blk device's priv space

2021-06-23T09:21:14Z

A udevice's priv space is cleared in alloc_priv() in the DM core. Don't do it again in its probe() routine. Signed-off-by: Bin Meng

nvme: Drop useless members of 'struct nvme_ns'

2021-06-23T09:21:14Z

mode_select_num_blocks and mode_select_block_len in 'struct nvme_ns' are not useful. Drop them. Signed-off-by: Bin Meng

nvme: Eliminate the offset of one during block dev creation

2021-06-23T09:21:14Z

At present there is an offset of one added during the creation of block device. This can be very confusing as we wanted to encode the namespace id in the block device name but namespae id cannot be zero. This changes to use the namespace id directly in the block device name, eliminating the offset of one effectively. Suggested-by: Heinrich Schuchardt Signed-off-by: Bin Meng

nvme: Skip block device creation for inactive namespaces

2021-06-23T09:21:14Z

At present for each namespace there is a block device created for it. There is no issue if the number of supported namespaces reported from the NVMe device is only 1. Since QEMU commit 7f0f1acedf15 ("hw/block/nvme: support multiple namespaces"), the number of supported namespaces reported has been changed from 1 to 256, but not all of them are active namespaces. The actual active one depends on the QEMU command line parameters. A common case is that namespace 1 being active and all other 255 being inactive. If a namespace is inactive, the namespace identify command returns a zero filled data structure. We can use field NSZE (namespace size) to decide whether a block device should be created for it. Reported-by: Heinrich Schuchardt Signed-off-by: Bin Meng

nvme: Move block dev creation from uclass post_probe() to driver probe()

2021-06-23T09:21:14Z

At present the block device creation happens in the NVMe uclass driver post_probe() phase. In preparation to support multiple namespaces, we should issue namespace identify before creating block devices but that touches the underlying hardware hence it is not appropriate to do such in the uclass driver post_probe(). Let's move it to driver probe() phase instead. Signed-off-by: Bin Meng

nvme: Remove the redundant aqa value setting

2021-06-23T09:21:14Z

AQA (Admin Queue Attributes) register is a dword size with lower word of ASQS, and higher word of ACQS. The code set the variable aqa twice, but it is redundant. Signed-off-by: Wesley Sheng Reviewed-by: Bin Meng

nvme: Correct the prps per page calculation method

2021-06-23T09:21:14Z

Each prp is 8 bytes, calculate the number of prps per page should just divide page size by 8 there is no need to minus 1 Signed-off-by: Wesley Sheng Reviewed-by: Bin Meng

nvme: fix for big endian systems

2021-06-23T09:21:14Z

writel() and co. already include the endian swap; doing the swap twice is, er, unhelpful. Tested on a P4080DS, which boots perfectly fine off NVMe with this. Signed-off-by: David Lamparter Reviewed-by: Bin Meng

nvme: Elaborate on cache maintenance operation in get/set_features

2021-03-19T14:36:55Z

At the moment the nvme_get_features() and nvme_set_features() functions carry a (somewhat misleading) comment about missing cache maintenance. As it turns out, nvme_get_features() has no caller at all in the tree, and nvme_set_features' only user doesn't use a DMA buffer. Mention that in the comment, and leave some breadcrumbs for the future, should those functions attract more users. Signed-off-by: Andre Przywara Reviewed-by: Michael Trimarchi Reviewed-by: Bin Meng

nvme: Always invalidate whole cqes[] array

2021-03-19T14:36:53Z

At the moment nvme_read_completion_status() tries to invalidate a single member of the cqes[] array, which is shady as just a single entry is not cache line aligned. The structure is dictated by hardware, and with 16 bytes is smaller than any cache line we usually deal with. Also multiple entries need to be consecutive in memory, so we can't pad them to cover a whole cache line. As a consequence we can only always invalidate all of them - U-Boot just uses two of them anyway. This is fine, as they are only ever read by the CPU (apart from the initial zeroing), so they can't become dirty. Make this obvious by always invalidating the whole array, regardless of the entry number we are about to read. Also blow up the allocation size to cover whole cache lines, to avoid other heap allocations to sneak in. Signed-off-by: Andre Przywara Reviewed-by: Bin Meng Reviewed-by: Michael Trimarchi Tested-by: Neil Armstrong