u-boot.git/drivers/block, branch v2020.01 Unnamed repository; edit this file 'description' to name the repository. blk: Make use of CONFIG_HAVE_BLOCK_DEVICE more 2019-12-03T13:43:24+00:00 Tom Rini trini@konsulko.com 2019-12-02T15:52:31+00:00 4df23e58a460cf246f9e76f79d572182d9d0f9bd When we do not have CONFIG_BLK (or SPL/TPL) enabled there are very few cases where we need the blk_legacy code linked in. To catch these, build when we have CONFIG_HAVE_BLOCK_DEVICE set. In addition, we only need cmd/blk_common.o to be linked in when we have CONFIG_HAVE_BLOCK_DEVICE set, so make use of that directly. Signed-off-by: Tom Rini <trini@konsulko.com> 
When we do not have CONFIG_BLK (or SPL/TPL) enabled there are very few
cases where we need the blk_legacy code linked in. To catch these, build
when we have CONFIG_HAVE_BLOCK_DEVICE set.  In addition, we only need
cmd/blk_common.o to be linked in when we have CONFIG_HAVE_BLOCK_DEVICE
set, so make use of that directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
blk: set log2blksz in blk_create_device() 2019-10-30T16:49:40+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2019-10-25T10:15:31+00:00 ee5041451e467711b9a4b0e679ba9cc18d93400e The ext4 file system requires log2blksz to be set. So when setting the block size on the block descriptor we should fill this field too. This fixes a problem with EFI block devices providing ext4 partitions, cf. https://lists.denx.de/pipermail/u-boot/2019-October/387702.html. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> 
The ext4 file system requires log2blksz to be set. So when setting the
block size on the block descriptor we should fill this field too.

This fixes a problem with EFI block devices providing ext4 partitions, cf.
https://lists.denx.de/pipermail/u-boot/2019-October/387702.html.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
dm: core: Add device_foreach_child() 2019-10-08T05:57:39+00:00 Simon Glass sjg@chromium.org 2019-09-25T14:55:56+00:00 e5f739045890eef2e97488c9c2a7d036ab908e58 We have a 'safe' version of this function but sometimes it is not needed. Add a normal version too and update a few places that can use it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
We have a 'safe' version of this function but sometimes it is not needed.
Add a normal version too and update a few places that can use it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Revert "blk: Invalidate block cache when switching hwpart" 2019-08-30T18:17:11+00:00 Weijie Gao weijie.gao@mediatek.com 2019-08-27T07:32:18+00:00 1ce884797cb382c26afce8a62e4cc790dba6bb24 This reverts commit 0ebe112d09b48230ba4be833cd3504b06997d9a4. Most block devices have only one hwpart. Multiple hwparts only found used by eMMC devices in u-boot. The mmc driver do blk_dselect_hwpart() at the beginning of mmc_bread() which causes block cache being invalidated too frequently and makes block cache useless. So it's not a good idea to put blkcache_invalidate() in the common functions. It should be called inside mmc_select_hwpart(). Signed-off-by: Weijie Gao <weijie.gao@mediatek.com> Tested-by: Felix Brack <fb@ltec.ch> 
This reverts commit 0ebe112d09b48230ba4be833cd3504b06997d9a4.

Most block devices have only one hwpart. Multiple hwparts only found used
by eMMC devices in u-boot. The mmc driver do blk_dselect_hwpart() at the
beginning of mmc_bread() which causes block cache being invalidated too
frequently and makes block cache useless.

So it's not a good idea to put blkcache_invalidate() in the common
functions. It should be called inside mmc_select_hwpart().

Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Tested-by: Felix Brack <fb@ltec.ch>
blk: Invalidate block cache when switching hwpart 2019-07-18T15:31:31+00:00 Weijie Gao weijie.gao@mediatek.com 2019-07-11T07:10:23+00:00 0ebe112d09b48230ba4be833cd3504b06997d9a4 Some storage devices have multiple hw partitions and both address from zero, for example eMMC. However currently block cache invalidation only applies to block write/erase. This can cause a problem that data of current hw partition is cached before switching to another hw partition. And the following read operation of the latter hw partition will get wrong data when reading from the addresses that have been cached previously. To solve this problem, invalidate block cache after a successful select_hwpart operation. Signed-off-by: Weijie Gao <weijie.gao@mediatek.com> 
Some storage devices have multiple hw partitions and both address from
zero, for example eMMC.
However currently block cache invalidation only applies to block
write/erase.
This can cause a problem that data of current hw partition is cached
before switching to another hw partition. And the following read
operation of the latter hw partition will get wrong data when reading
from the addresses that have been cached previously.

To solve this problem, invalidate block cache after a successful
select_hwpart operation.

Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
blk: Allow control of the block cache in TPL 2019-07-10T22:52:58+00:00 Simon Glass sjg@chromium.org 2019-05-18T17:59:53+00:00 731ba3c0beaf4318cc97ece1e422a61fc5721f5b Generally block devices are not enabled in TPL, but in case they are, add a Kconfig option for the block cache. This allows the setting (default off) to be found with CONFIG_IS_ENABLED(). Signed-off-by: Simon Glass <sjg@chromium.org> 
Generally block devices are not enabled in TPL, but in case they are,
add a Kconfig option for the block cache. This allows the setting (default
off) to be found with CONFIG_IS_ENABLED().

Signed-off-by: Simon Glass <sjg@chromium.org>
blk: Increase cache element size 2019-01-15T20:28:53+00:00 Marek Vasut marex@denx.de 2018-08-08T11:20:29+00:00 2e89bbefdc9c1d2ec03e2a5320a56fb1129da916 Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet the underlying block layer devices usually report support for 512B . In most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks etc.) and the real block size of those devices is much bigger. To avoid performance degradation with such devices and FS setup, bump the maximum cache entry size to 4 kiB. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> 
Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
the underlying block layer devices usually report support for 512B . In
most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
etc.) and the real block size of those devices is much bigger.

To avoid performance degradation with such devices and FS setup, bump
the maximum cache entry size to 4 kiB.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
blk: Rework guard around part_init call 2018-12-12T17:14:22+00:00 Tom Rini trini@konsulko.com 2018-12-05T13:23:38+00:00 91ff6865629c81b8643b4ef6130e3e2130c60400 The function part_init() will only be built when we have both CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to this function with both of these tests now. Cc: Simon Glass <sjg@chromium.org> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: York Sun <york.sun@nxp.com> Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Cc: Mingkai Hu <mingkai.hu@nxp.com> Cc: Stefan Roese <sr@denx.de> Cc: Marek Behún <marek.behun@nic.cz> Cc: Vanessa Maegima <vanessa.maegima@nxp.com> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Adam Ford <aford173@gmail.com> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Tom Warren <twarren@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
The function part_init() will only be built when we have both
CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set.  Protect the call to
this function with both of these tests now.

Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Cc: Mingkai Hu <mingkai.hu@nxp.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Vanessa Maegima <vanessa.maegima@nxp.com>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Adam Ford <aford173@gmail.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
blk: Introduce IF_TYPE_VIRTIO 2018-11-14T17:16:27+00:00 Tuomas Tynkkynen tuomas.tynkkynen@iki.fi 2018-10-15T09:21:10+00:00 4ad54ec4d5c98a297f8df2fe9a630a534557f717 This adds a new block interface type for VirtIO block devices. 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> 
This adds a new block interface type for VirtIO block devices.

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>
blk: Make blk_next_free_devnum() public 2018-11-14T17:16:27+00:00 Bin Meng bmeng.cn@gmail.com 2018-10-15T09:21:09+00:00 c879eeb7aa95d753d4d9e39f43004943ed9d93b7 blk_next_free_devnum() can be helpful in some cases. Make it a public API. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
blk_next_free_devnum() can be helpful in some cases. Make it
a public API.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>