public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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