summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/mmc.c
Commit message (Collapse)AuthorAgeFilesLines
* mmc: Print send_cmd response only when return value is zeroBin Meng2016-03-271-38/+42
| | | | | | | | send_cmd response is valid only when no error happened. If an error occured, let mmc_send_cmd() print the return value to aid debugging. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* mmc: Fix switch..case indentionBin Meng2016-03-271-70/+70
| | | | | | | Correct the indention level of switch..case statements. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* dm: block: Rename device number member dev to devnumSimon Glass2016-03-141-4/+4
| | | | | | | | | This is a device number, and we want to use 'dev' to mean a driver model device. Rename the member. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
* dm: part: Rename some partition functionsSimon Glass2016-03-141-1/+1
| | | | | | | | Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com>
* dm: Drop the block_dev_desc_t typedefSimon Glass2016-03-141-2/+2
| | | | | | | | | Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
* dm: mmc: Try to honour the sequence orderSimon Glass2016-01-201-5/+15
| | | | | | | | | | | | At present we add driver-model MMC devices in the order we find them. The 'alias' order is not honoured. It is difficult to fix this for the case where we have holes in the sequence. But for the common case where the devices are numbered from 0 without any gaps, we can add the devices to the internal data structures in this order. Signed-off-by: Simon Glass <sjg@chromium.org>
* mmc: store hwpart in the block deviceStephen Warren2016-01-131-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow us to have multiple block device structs each referring to the same eMMC device, yet different HW partitions. For now, there is still a single block device per eMMC device. As before, this block device always accesses whichever HW partition was most recently selected. Clients wishing to make use of multiple block devices referring to different HW partitions can simply take a copy of this block device once it points at the correct HW partition, and use each one as they wish. This feature will be used by the next patch. In the future, perhaps get_device() could be enhanced to return a dynamically allocated block device struct, to avoid the client needing to copy it in order to maintain multiple block devices. However, this would require all users to be updated to free those block device structs at some point, which is rather a large change. Most callers of mmc_switch_part() wish to permanently switch the default MMC block device's HW partition. Enhance mmc_switch_part() so that it does this. This removes the need for callers to do this. However, common/env_mmc.c needs to save and restore the current HW partition. Make it do this more explicitly. Replace use of mmc_switch_part() with mmc_select_hwpart() in order to remove duplicate code that skips the call if that HW partition is already selected. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* block: pass block dev not num to read/write/erase()Stephen Warren2016-01-131-1/+3
| | | | | | | | | | | This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* mmc: mmc: Don't use sprintf when using tiny-printfSjoerd Simons2015-12-131-1/+3
| | | | | | | There is no sprintf implementation in tiny-printf, so don't try to use it when tiny-printf if used. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
* Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h headerSimon Glass2015-09-111-0/+1
| | | | | | | Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org>
* mmc: Probe DM based mmc devices in u-bootSjoerd Simons2015-09-021-4/+39
| | | | | | | | | During mmc initialize probe all devices with the MMC Uclass if build with CONFIG_DM_MMC Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* mmc: Protect `mmc_initialize` from initialising mmc multiple timesDaniel Kochmański2015-07-241-0/+5
| | | | | | | | | | | | | `mmc_initialize` might be called multiple times leading to the mmc-controllers being initialised twice, and initialising the `mmc_devices` list head twice which may lead to memory leaks. Signed-off-by: Daniel Kochmański <dkochmanski@turtle-solutions.eu> CC: Roy Spliet <r.spliet@ultimaker.com> Cc: Ian Campbell <ijc@hellion.org.uk> CC: Pantelis Antoniou <panto@antoniou-consulting.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* mmc: Add debug() output on read errorsSimon Glass2015-07-211-2/+6
| | | | | | Allow read errors to be diagnosed more easily. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: mmc: Add an MMC uclassSimon Glass2015-07-211-0/+2
| | | | | | | Add basic support for MMC, providing a uclass which can set up an MMC device. This allows MMC drivers to move to using driver model. Signed-off-by: Simon Glass <sjg@chromium.org>
* Merge git://git.denx.de/u-boot-mpc85xxTom Rini2015-05-051-0/+6
|\
| * mmc: fsl_esdhc: Add adapter card type identification supportYangbo Lu2015-05-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Add adapter card type identification support by reading FPGA STAT_PRES1 register SDHC Card ID[0:2] bits. To use this function, define CONFIG_FSL_ESDHC_ADAPTER_IDENT. Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com> Cc: York Sun <yorksun@freescale.com> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> [York Sun: resolve conflicts in README.fsl-esdhc] Reviewed-by: York Sun <yorksun@freescale.com>
* | mmc: remove the MMC_MODE_HC flagRob Herring2015-05-051-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | High capacity support is not a host capability, but a device capability that is queried via the OCR. The flag in the operating conditions request argument can just be set unconditionally. This matches the Linux implementation. [panto] Hand merged and renumbering MMC_MODE_DDR_52MHz. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
* | mmc: Fix splitting device initializationAndrew Gabbasov2015-05-051-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting part of device initialization sets the init_in_progress flag only if the MMC card did not yet come to ready state and needs to continue polling. If the card is SD or if the MMC card became ready quickly, the flag is not set and (if using pre-initialization) the starting phase will be re-executed from mmc_init function. Set the init_in_progress flag in all non-error cases. Also, move flags setting statements around so that the flags are not set in error paths. Also, IN_PROGRESS return status becomes unnecessary, so get rid of it. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* | mmc: Restructure polling loops to avoid extra delaysAndrew Gabbasov2015-05-051-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The polling loops in sd_send_op_cond and mmc_complete_op_cond functions check the ready flag state at the end of the loop, that is after executing a delay inside the loop, which, in case of exiting with no error, is not needed. Also, one of these loops, as well as the loop in mmc_send_status, have the delay just before exiting on timeout conditions. Restructure all these loops to check the respective conditions before making a delay for the next loop pass, and to appropriately exit without the delay. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* | mmc: Continue polling MMC card for OCR only if it is still not readyAndrew Gabbasov2015-05-051-9/+11
| | | | | | | | | | | | | | | | | | | | Some MMC cards come to ready state quite quickly, so that the respective flag appears to be set in mmc_send_op_cond already. In this case trying to continue polling the card with CMD1 in mmc_complete_op_cond is incorrect and may lead to unpredictable results. So check the flag before polling and skip it appropriately. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* | mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter()Andrew Gabbasov2015-05-051-13/+11
| | | | | | | | | | | | | | | | | | | | The previous change to use 'ocr' structure field for storing send_op_cond command response also stopped using command response directly outside of mmc_send_op_cond_iter(). Now it becomes possible to use command structure in mmc_send_op_cond_iter() locally, removing a necessity to pass it as an argument from the caller. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* | mmc: Avoid extra duplicate entry in mmc device structureAndrew Gabbasov2015-05-051-6/+7
|/ | | | | | | | | | | | | The 'op_cond_response' field in mmc structure contains the response from the last SEND_OP_COND MMC command while making iterational polling of the card. Later it is copied to 'ocr' field, designed to contain the OCR register value, which is actually the same response from the same command. So, these fields have actually the same data, just in different time periods. It's easier to use the same 'ocr' field in both cases at once, without temporary using of the 'op_cond_response' field. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* mmc: print SD/eMMC type for inited mmc devicesPrzemyslaw Marczak2015-02-231-0/+8
| | | | | | | | | | | | Depending on the boot priority, the eMMC/SD cards, can be initialized with the same numbers for each boot. To be sure which mmc device is SD and which is eMMC, this info is printed by 'mmc list' command, when the init is done. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
* mmc: Skip changing bus width for MMC cards earlier than version 4.0Andrew Gabbasov2015-01-191-2/+5
| | | | | | | | | | | Wider bus widths (larger than default 1 bit) appeared in MMC standard version 4.0. So, for MMC cards of any earlier version trying to change the bus width (including ext_csd comparison) does not make any sense. It may work incorrectly and at least cause unnecessary timeouts. So, just skip the entire bus width related activity for earlier versions. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
* mmc: Avoid redundant switching to 1-bit bus width for MMC cardsAndrew Gabbasov2015-01-191-0/+12
| | | | | | | | | | | | | | | | | | | | If all the commands switching an MMC card to 4- or 8-bit bus width fail, and the bus width for the controller and the driver is still set to default 1 bit, there is no need to send one more command to switch the card to 1-bit bus width. Also, if the card or host controller do not support wider bus widths, there is no need to send a switch command at all. However, if one of switch commands succeeds, but the subsequent ext_csd fields comparison fails, the card should be switched to some other bus width (next in the list for the loop), or to default 1-bit bus width as a last resort. That's why it would be incorrect to just remove the 1-bit bus width case from the list, it should still be processed in some cases. panto: Minor cosmetic edit removing superfluous parentheses. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Tested-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
* mmc: extend mmcinfo output to show partition write reliability settingsDiego Santa Cruz2015-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extends the mmcinfo hardware partition info output to show partitions with write reliability enabled with the "WRREL" string. If the partition does not have write reliability enabled the "WRREL" string is omitted; this is analogous to the ehhanced attribute. Example output: Device: OMAP SD/MMC Manufacturer ID: fe OEM: 14e Name: MMC16 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.41 High Capacity: Yes Capacity: 13.8 GiB Bus Width: 4-bit Erase Group Size: 8 MiB HC WP Group Size: 16 MiB User Capacity: 13.8 GiB ENH WRREL User Enhanced Start: 0 Bytes User Enhanced Size: 512 MiB Boot Capacity: 16 MiB ENH RPMB Capacity: 128 KiB ENH GP1 Capacity: 64 MiB ENH WRREL GP2 Capacity: 64 MiB ENH WRREL Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: extend the mmc hardware partitioning API with write reliabilityDiego Santa Cruz2015-01-191-0/+39
| | | | | | | | | The eMMC partition write reliability settings are to be set while partitioning a device, as per the eMMC spec, so changes to these attributes needs to be done in the hardware partitioning API. This commit adds such support. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: add API to do eMMC hardware partitioningDiego Santa Cruz2015-01-191-0/+155
| | | | | | | | | | | | | | | | | | This adds an API to do hardware partitioning on eMMC devices. The new mmc_hwpart_config() function does the partitioning in one go. As the different attributes and partitioning options on eMMC may be interdependent validation has to be done based on the complete partitioning configuration. The function accepts three modes: - MMC_HWPART_CONF_CHECK: just validates that the configuration is valid. - MMC_HWPART_CONF_SET: validates and sets all the fields in EXT_CSD but without setting the "partitioning completed" bit, and thus is reversible. - MMC_HWPART_CONF_COMPLETE: does everything and is thus not reversible. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: the ext_csd data may be used during init even if reading failedDiego Santa Cruz2015-01-191-1/+3
| | | | | | | | | | The mmc_startup() function uses the ext_csd data even if reading it from the mmc device failed. This bug was introduced in commit bc897b1d4d86597311430dbe7b3e6c807c8c53e5. We now bail out if reading it fails, this should not be a problem as ext_csd was introduced in MMC 4.0 and this code is conditional on MMC >= 4.0. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: eMMC partitioning data is not effective till partitioning completedDiego Santa Cruz2015-01-191-23/+35
| | | | | | | | | | | | | | | | | The eMMC spec says that partitioning is only effective after the PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power cycle was done, but that we cannot know). Thus the partition sizes and attributes should be ignored when that bit is not set, otherwise the various capacities are not coherent (e.g., the user data capacity will be that of the unpartitioned device while partition sizes would be non-zero). Prescence of non-zero partitioning data is nevertheless still used to activate the high-capacity size definitions (EXT_CSD_ERASE_GROUP_DEF) as it is necessary to set that to write any of the partitioning fields in EXT_CSD, so having partitioning data means someone previously activated that and we should keep it activated. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: read the high capacity WP group size for eMMCDiego Santa Cruz2015-01-191-0/+6
| | | | | | | | Read the eMMC high capacity write protect group size at mmc device initialization. This is useful to correctly partition an eMMC device, as partitions need to be aligned to this size. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: fix erase_grp_size computation with high-capacity size definitionDiego Santa Cruz2015-01-191-2/+1
| | | | | | | | | The erase_grp_size in struct mmc is to be a size in 512-byte sectors but the code used to compute it for eMMC when EXT_CSD_ERASE_GROUP_DEF is enabled computed it as bytes, leading to erase sizes and alignment much larger than what is actually required by the mmc device. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: read the size of eMMC enhanced user data areaDiego Santa Cruz2015-01-191-0/+15
| | | | | | | | This modification reads the size of the eMMC enhanced user data area upon initialization of an mmc device, it will be used later by mmcinfo. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: computation of eMMC GP partition size was missing 512 KiB factorDiego Santa Cruz2015-01-191-0/+1
| | | | Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: incomplete test to switch to high-capacity group size definitionsDiego Santa Cruz2015-01-191-22/+30
| | | | | | | | | | | | | | | | | The eMMC spec mandates that the high-capacity group size definitions should be enabled when the device is partitioned (by setting ERASE_GROUP_DEF in EXT_CSD). The current test to determine when this is required misses a few cases. In particular a device may have been partitioned without setting the enhanced attribute on any partition or partitioning may be completed without creating any extra partitions. This change moves the code to set ERASE_GROUP_DEF to after reading all partition information. It is also enabled when PARTITIONING_SETTING_COMPLETED is set as it is necessary to enable ERASE_GROUP_DEF before setting that bit, so it means that the user previously switched to the high capacity definitions. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: extend mmcinfo to show enhanced partition attributeDiego Santa Cruz2015-01-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This extends the mmcinfo command's output to show which eMMC partitions have the enhanced attribute set. Note that the eMMC spec says that if the enhanced attribute is supported then the boot and RPMB partitions are of the enhanced type. The output of mmcinfo becomes: Device: OMAP SD/MMC Manufacturer ID: fe OEM: 14e Name: MMC16 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.41 High Capacity: Yes Capacity: 13.8 GiB Bus Width: 4-bit User Capacity: 13.8 GiB ENH Boot Capacity: 16 MiB ENH RPMB Capacity: 128 KiB ENH GP1 Capacity: 64 MiB ENH GP2 Capacity: 64 MiB ENH Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: Fix block length for DDR modeAndrew Gabbasov2014-12-121-0/+6
| | | | | | | | | Block length for write and read commands is fixed to 512 bytes when the card is in Dual Data Rate mode. If block length read from CSD is different, make sure the driver will use correct length in all further calculations and settings. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* mmc: Fix Dual Data Rate capability recognitionAndrew Gabbasov2014-12-121-1/+1
| | | | | | | | | Since the driver doesn't work in 1.2V or 1.8V signaling level modes, Dual Data Rate mode can be supported by the driver only if it is supported by the card in regular 3.3V mode. So, check for a particular single bit in card type field. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* mmc: Fix handling of bus widths and DDR card capabilitiesAndrew Gabbasov2014-12-121-21/+31
| | | | | | | | | | | | | | | | | | | | | | | If the MMC_MODE_DDR_52MHz flag is set in card capabilities bitmask, it is never cleared, even if switching to DDR mode fails, and if the controller driver uses this flag to check the DDR mode, it can take incorrect actions. Also, DDR related checks in mmc_startup() incorrectly handle the case when the host controller does not support some bus widths (e.g. can't support 8 bits), since the host_caps is checked for DDR bit, but not bus width bits. This fix clearly separates using of card_caps bitmask, having there the flags for the capabilities, that the card can support, and actual operation mode, described outside of card_caps (i.e. bus_width and ddr_mode fields in mmc structure). Separate host controller drivers may need to be updated to use the actual flags. Respectively, the capabilities checks in mmc_startup are made more correct and clear. Also, some clean up is made with errors handling and code syntax layout. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* MMC: add MMC_VERSION_5_0Markus Niebel2014-12-121-0/+3
| | | | | Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
* MMC: fix user capacity for partitioned eMMC cardMarkus Niebel2014-12-121-0/+15
| | | | | | | | | | if the card claims to be high capacity and the card is partitioned the capacity shall still be read from ext_csd SEC_COUNT even if the resulting capacity is smaller than 2 GiB Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
* mmc: Cosmetic fix for nicer, aligned device list printoutLubomir Popov2014-12-121-2/+5
| | | | | | | | If print_mmc_devices() was called with a '\n' separator (as done for example by the "mmc list" command), it offset the 2-nd and all subsequent lines by one space. Fixing this. Signed-off-by: Lubomir Popov <l-popov@ti.com>
* mmc: Board-specific MMC power initializationsPaul Kocialkowski2014-12-041-0/+7
| | | | | | | | | Some devices may use non-standard combinations of regulators to power MMC: this allows these devices to provide a board-specific MMC power init function to set everything up in their own way. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com>
* mmc: Fix mmc bus widthMario Schuknecht2014-10-031-2/+3
| | | | | | | | | | | | | After setting the bus width, the extended CSD register is read. Some selected fields are compared with previously read extended CSD register fields. In this comparison the EXT_CSD_ERASE_GROUP_DEF field is compared. But this field is previously written under certain circumstances. And then the comparison fails. Only compare read-only fields. Therefore compare field EXT_CSD_HC_WP_GRP_SIZE instead of field EXT_CSD_ERASE_GROUP_DEF. Signed-off-by: Mario Schuknecht <mario.schuknecht@dresearch-fe.de> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* mmc: restore capacity when switching to partition 0Peter Bigot2014-10-031-3/+8
| | | | | | | | | | | | | The capacity and lba for an MMC device with part_num 0 reflects the whole device. When mmc_switch_part() successfully switches to a partition, the capacity is changed to that partition. As partition 0 does not physically exist, attempts to switch back to the whole device will indicate an error, but the capacity setting for the whole device must still be restored to match the partition. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Tested-by: Tom Rini <trini@ti.com> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* mmc: fix ERASE_GRP_DEF handlingHannes Petermaier2014-10-031-0/+2
| | | | | | | | | | | if we set manually this bit on the eMMC card using mmc_switch(...), we also have to set it within our (before read) internal structure 'ext_csd'. Otherwise following checks on this will fail. Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com> Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
* mmc: prevent some warnings with make W=1Jeroen Hofstee2014-07-181-3/+3
| | | | | | | | Add missing prototypes for global functions and make local functions static. cc: panto@antoniou-consulting.com Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
* dirvers: mmc: use __weakJeroen Hofstee2014-07-181-11/+9
| | | | | use weak instead of alias to prevent some clang warnings. Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
* mmc: return meaningful error codes from mmc_select_hwpartStephen Warren2014-06-121-3/+4
| | | | | | | | | | | | Rather than just returning -1 everywhere, try to return something meaningful from mmc_select_hwpart(). Note that most other MMC functions don't do this, including functions called from mmc_select_hwpart(), so I'm not sure how effective this will be. Still, it's one less place with hard-coded -1. Suggested-by: Pantelis Antoniou <panto@antoniou-consulting.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'Albert ARIBAUD2014-06-021-3/+13
|\
OpenPOWER on IntegriCloud