From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mmc: add wrappers for MMC block_{read, write, erase}
Date: Mon, 02 Jun 2014 10:30:34 -0600 [thread overview]
Message-ID: <538CA6AA.4040105@wwwdotorg.org> (raw)
In-Reply-To: <A5467F08-FBD4-40D5-9B53-65D79740F7ED@antoniou-consulting.com>
On 06/02/2014 12:42 AM, Pantelis Antoniou wrote:
> Hi Steve,
>
> I wanted the discussion to settle a bit before I reply to this series.
> On May 29, 2014, at 1:15 AM, Steve Rae wrote:
>
>> Each wrapper function:
>> - switches to the specified physical partition, then
>> - performs the original function, and then
>> - switches back to the original physical partition
>> where the physical partition (aka HW partition) is
>> 0=User, 1=Boot1, 2=Boot2, etc.
>>
>> Signed-off-by: Steve Rae <srae@broadcom.com>
>> ---
>
> [snip]
>
>> /**
>> * Start device initialization and return immediately; it does not block on
>> * polling OCR (operation condition register) status. Then you should call
>> --
>> 1.8.5
>>
>
> The thing IMO should be modeled in the same way that block devices work in
> Linux.
>
> TBH I'm not very fond of the way block devices/partitions and the block_ops
> are intermixed in block_dev_t. This part of code could use some refactoring
> to make it operate more like a regular linux block device (with each partition
> being it's own block device), but I don't know if we have enough votes to change
> it ATM.
Refactoring that would make sense to me. That way, any client code could
just pass the user's command-line (or whatever) parameters to some
lookup function, which could return something that accesses whatever the
user wants, without the code that accesses the data caring whether it's
a complete block device, a complete HW partition, or a SW partition
within one of those. Of course, I guess that's already the case, it's
just that the information is split across block_dev_desc_t and
disk_partition_t, when it doesn't really need to be.
prev parent reply other threads:[~2014-06-02 16:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 22:15 [U-Boot] [PATCH] mmc: add wrappers for MMC block_{read, write, erase} Steve Rae
2014-05-29 5:47 ` Jaehoon Chung
2014-05-29 7:03 ` Jaehoon Chung
2014-05-29 17:24 ` Steve Rae
2014-05-29 16:25 ` Stephen Warren
2014-05-29 17:58 ` Steve Rae
2014-05-29 18:51 ` Stephen Warren
2014-05-29 19:44 ` Steve Rae
2014-05-29 20:30 ` Stephen Warren
2014-05-29 22:03 ` Steve Rae
2014-05-30 15:58 ` Stephen Warren
2014-05-30 16:56 ` Steve Rae
2014-05-30 17:07 ` Stephen Warren
2014-05-30 18:39 ` Steve Rae
2014-06-02 6:42 ` Pantelis Antoniou
2014-06-02 16:30 ` Stephen Warren [this message]
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=538CA6AA.4040105@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.