On 05/21/2014 07:41 PM, Jaehoon Chung wrote: > On 05/22/2014 01:18 AM, Stephen Warren wrote: >> On 05/20/2014 11:40 PM, Jaehoon Chung wrote: >>> Hi, Stephen. >>> >>> i didn't apply your patch. Which repository do you use? >> >> It's based on u-boot.git master branch. The latest u-boot-mmc.git master >> branch is already included in that branch, and it looks like some >> changes have been applied to cmd_mmc.c in u-boot/master that aren't in >> u-boot-mmc/master. > > I have pulled the latest u-boot.git, but it didn't apply this patch. > If i missed something, let me know plz.
Ah, I guess I hadn't noticed there's an interaction (context changes) with some other MMC-related patches that I sent: http://patchwork.ozlabs.org/patch/346771/ [U-Boot,1/4] cmd_part: fix type in part command help text http://patchwork.ozlabs.org/patch/346770/ [U-Boot,2/4] disk: support devices with HW partitions http://patchwork.ozlabs.org/patch/346768/ [U-Boot,3/4] mmc: provide a select_hwpart implementation for get_device() http://patchwork.ozlabs.org/patch/346769/ [U-Boot,4/4] cmd_mmc: use new mmc_select_hwpart() function So, you can either apply those first, or use "git am -3" rather than "git am", plus declare "int ret"; patch 4/4 above does that. >>> Well, if you want to check, can be used "if (mmc_init(mmc))". >>> >>> And i'm not sure whether this code is really need or not. >> >> Why not? This code is required to solve the problem described in the >> commit description: > > I will try to reproduce the problem described in the commit-msg. > Because, i didn't reproduce it, so i'm not sure. > But to control the return value, it's reasonable, right? Yes, I think so. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot