From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 01/11] DM: add block device core
Date: Sat, 22 Sep 2012 02:09:15 +0200 [thread overview]
Message-ID: <201209220209.15672.marex@denx.de> (raw)
In-Reply-To: <13906221.Xfz2zQeyUe@bloomfield>
Dear Pavel Herrmann,
[...]
> > > one or none - requests on USB flashes should not pass through
> > > block_controller_driver.
> >
> > Uh, what do they pass into then ?
>
> their parent (an USB hub)
block_device instance (aka. partition/disk) directly connected to USB hub
instance does not seem right.
> > > every child of block_controller should be a block_device (not
> > > necessarily the other way around
> >
> > I doubt it's even possible to be the other way around.
> >
> > > ), so there is no way you pass more instances
> > > block_controller on your way up.
> >
> > Ok, let me explain again. Let's look at the USB case to make it more
> > real-world- ish. Imagine you have a thumb drive with 2 partitions. Thus
> > you have two instances of struct block_device [denote BDp] for the
> > partitions and one more for the whole disc [denote BDd]. When you read
> > from partition, you end up poking BDp, which pushes the request up into
> > BDd. This in turn calls USB-flashdisc- block_controller_driver [call it
> > UFc]. For flash disc to read data, it needs to do some USB transfers.
> > These are provided by USB host controller [UHC]. Thus you need some glue
> > between UHC and UFc ... this is what I'm talking about.
>
> there should be no "UFc", your "BDd" driver should talk directly to your
> "UHC"
So my generic partition implementation (BDd) would have to implement USB
flashdisc stuff, correct? This makes no sense.
> (a driver that has blockdev API on one end, USB on the other)
Ok, so how would this work, every partition implementation implements upcalls
for all USB, SCSI, SATA, IDE, SD, ... and gazilion other types of drive it can
sit on?
> > Ok, I see the issue at hand. In case of a "regular drive", this
> > implements the IO directly. In case of SD, this is a proxy object which
> > interfaces with some SD-library and prepares the SD commands and then
> > pushes that up into the controller to do the job? Same thing for USB
> > flashes ?
>
> not every block device will have a block controller as a parent (or
> parent-of- parent in case of a partition). there would be a blockdev-usb
> that has a USB hub as a parent, and a blockdev-mmc, that has a mmc/sdio
> controller as a parent.
So you would have a specific partition implementation for SD, SATA, IDE, SCSI,
USB ... ? This is flawed.
The partition should be a generic "thing" which knows nothing about where it's
sitting at. So is the whole drive, same thing, it just has partitions hooked
under it.
I'd expect a "block_controller" to be the proxy object under which the
block_device representing the disc is connected. And this "block_controller" to
be proxifying the requests to the respective drivers (be it SD, SATA, whatever).
> so basically what you mean, without the block_controller in the middle -
> please note that the block_device API is actually richer than the
> block_controller API (has erase) for exactly this reason.
>
> Pavel Herrmann
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-09-22 0:09 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-20 19:37 [U-Boot] [PATCH 00/11] Add DM blockdev subsystem Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 01/11] DM: add block device core Pavel Herrmann
2012-09-20 19:58 ` Marek Vasut
2012-09-21 7:11 ` Pavel Herrmann
2012-09-21 12:39 ` Marek Vasut
2012-09-21 13:27 ` Pavel Herrmann
2012-09-21 13:53 ` Marek Vasut
2012-09-21 14:57 ` Pavel Herrmann
2012-09-21 15:34 ` Marek Vasut
2012-09-21 15:48 ` Pavel Herrmann
2012-09-21 15:55 ` Marek Vasut
2012-09-21 17:19 ` Pavel Herrmann
2012-09-21 18:00 ` Marek Vasut
2012-09-21 18:53 ` Pavel Herrmann
2012-09-21 19:17 ` Marek Vasut
2012-09-21 19:29 ` Pavel Herrmann
2012-09-21 21:11 ` Marek Vasut
2012-09-21 23:43 ` Pavel Herrmann
2012-09-22 0:09 ` Marek Vasut [this message]
2012-09-22 9:39 ` Pavel Herrmann
2012-09-22 13:33 ` Marek Vasut
2012-09-22 13:59 ` Pavel Herrmann
2012-09-24 12:23 ` Pavel Herrmann
2012-09-20 20:49 ` [U-Boot] [U-Boot-DM] " Vikram Narayanan
2012-09-21 7:09 ` Pavel Herrmann
2012-09-21 12:39 ` Marek Vasut
2012-09-20 19:37 ` [U-Boot] [PATCH 02/11] DM: add support for scanning DOS partitions to blockdev core Pavel Herrmann
2012-09-20 20:03 ` Marek Vasut
2012-09-21 7:22 ` Pavel Herrmann
2012-09-21 12:47 ` Marek Vasut
2012-09-21 13:18 ` Pavel Herrmann
2012-09-21 13:54 ` Marek Vasut
2012-09-20 19:37 ` [U-Boot] [PATCH 03/11] DM: add block controller core Pavel Herrmann
2012-09-20 20:05 ` Marek Vasut
2012-09-21 7:21 ` Pavel Herrmann
2012-09-21 12:51 ` Marek Vasut
2012-09-21 13:14 ` Pavel Herrmann
2012-09-21 13:56 ` Marek Vasut
2012-09-21 15:04 ` Pavel Herrmann
2012-09-21 13:33 ` Pavel Herrmann
2012-09-21 13:58 ` Marek Vasut
2012-09-21 15:09 ` Pavel Herrmann
2012-09-21 15:39 ` Marek Vasut
2012-09-21 15:46 ` Pavel Herrmann
2012-09-21 16:08 ` Marek Vasut
2012-09-21 17:22 ` Pavel Herrmann
2012-09-21 18:01 ` Marek Vasut
2012-09-21 19:15 ` Pavel Herrmann
2012-09-21 19:22 ` Marek Vasut
2012-09-20 19:37 ` [U-Boot] [PATCH 04/11] DM: add sata_legacy driver for blockctrl Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 05/11] DM: add ata and partition blockdev drivers Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 06/11] DM: add cmd_block command Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 07/11] DM: use new blockdev API in FAT Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 08/11] DM: use new blockdev API in ext2 Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 09/11] DM: use new blockdev API in reiserfs Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 10/11] DM: use new blockdev API in ZFS Pavel Herrmann
2012-09-20 19:37 ` [U-Boot] [PATCH 11/11] DM: switch sandbox to DM blockdev Pavel Herrmann
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=201209220209.15672.marex@denx.de \
--to=marex@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