From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [PATCH] mvebu: bubt: Drop dead code
Date: Thu, 30 Jul 2020 08:50:05 +0200 [thread overview]
Message-ID: <b0de6479-cb8f-a63c-0dbf-a12db574abc0@denx.de> (raw)
In-Reply-To: <20200725125904.GD5204@bill-the-cat>
Hi Tom,
On 25.07.20 14:59, Tom Rini wrote:
> On Sat, Jul 25, 2020 at 01:38:12PM +0200, Stefan Roese wrote:
>> Hi Tom,
>>
>> On 24.07.20 23:13, Tom Rini wrote:
>>> The code around CONFIG_SYS_MMC_ENV_PART has been untested since merge.
>>> This can be seen by it referencing 'mmc->part_num' which was migrated
>>> elsewhere prior to this code being merged.
>>
>> I'm seeing that CONFIG_SYS_MMC_ENV_PART is also mentioned in the
>> documentation for this MVEBU cmd:
>>
>> doc/mvebu/cmd/bubt.txt
>>
>> So I hesitate a bit to remove it completely from this command (even
>> though I personally have never used it). Could you perhaps send me a
>> link a patch / commit, where 'mmc->part_num' has been migrated?
>
> It was changed in:
> commit 873cc1d7775ed5de07e6722c7ff423080c2e8f71
> Author: Stephen Warren <swarren@nvidia.com>
> AuthorDate: Mon Dec 7 11:38:49 2015 -0700
> Commit: Tom Rini <trini@konsulko.com>
> CommitDate: Wed Jan 13 21:05:19 2016 -0500
>
> mmc: store hwpart in the block device
>
> 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>
>
> Which is before cmd/mvebu/bubt.c was added to mainline. So while I'm
> sure the command worked in the downstream tree, it wasn't ever tested in
> mainline. It also means that changing it to mmc->block_dev.hwpart
> instead of mmc->part_num would also work, but the code would remain
> untested.
I see. Thanks for the update here. In this case:
Acked-by: Stefan Roese <sr@denx.de>
Thanks,
Stefan
next prev parent reply other threads:[~2020-07-30 6:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 21:13 [PATCH] mvebu: bubt: Drop dead code Tom Rini
2020-07-25 11:38 ` Stefan Roese
2020-07-25 12:59 ` Tom Rini
2020-07-30 6:50 ` Stefan Roese [this message]
2020-08-06 12:08 ` Stefan Roese
2020-08-06 14:27 ` Stefan Roese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0de6479-cb8f-a63c-0dbf-a12db574abc0@denx.de \
--to=sr@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox