With commit c85b8071e7d3 ("virtio: blk: support block sizes exceeding 512
bytes") logic was added to detect the VIRTIO_BLK_F_BLK_SIZE capability and
to copy the block size reported by QEMU to the block device descriptor.
The logical block size can be set when invoking QEMU:
-drive if=none,file=4096.img,format=raw,id=vda \
-device virtio-blk-device,drive=vda,physical_block_size=4096,logical_block_size=4096
In U-Boot the logical block size is shown by command `virtio info`:
=> virtio info
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 1024.0 MB = 1.0 GB (262144 x 4096)
There where two flaws which together hid that the logic was incorrect:
* VIRTIO_BLK_F_BLK_SIZE was missing in the driver capabilities and the bit
was filtered out.
* The result of the call to virtio_has_feature() was negated.
The problem became apparent when using ARM FVP as emulator which does not set
VIRTIO_BLK_F_BLK_SIZE.
Fixes: c85b8071e7d3 ("virtio: blk: support block sizes exceeding 512 bytes")
Reported-by: Debbie Horsfall <debbie.horsfall@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
QEMU allows to specify the logical block size via parameter
logical_block_size of a virtio-blk-device.
The communication channel via virtqueues remains based on 512 byte blocks
even if the logical_block_size is larger.
Consider the logical block size in the block device driver.
Reported-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
'log2blksz' in blk_desc structure must always be initialized, otherwise
it will cause a lot of weird failures in file operations.
For example, fs_set_blk_dev[_with_part]() examines a block device against
every file system with its probe function. In particular, ext4 file
system's ext4_probe() will calls fs_devread() to fetch a super block.
If log2blksz is 0, the actual 'read' size, i.e. block_len >> log2blksz, is
much bigger than a buffer's size, and it can end up with memory corruption.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Fixes: f4802209e59d ("virtio: Add block driver support")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This adds virtio block device driver support.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
