[U-Boot] [PATCH 01/11] DM: add block device core

[Marek Vasut]

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