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

[Marek Vasut <marex@denx.de>]

Dear Pavel Herrmann,

[...]

> > I mean the particular block_controller_driver instance routes the
> > "read/write block" request from downstream block_device through
> > SATA/SD/SCSI/whatever "library" or "layer" back into itself. But the
> > later "itself" is the implementation of the "library" or "layer" API.
> > Once the library call returns, the "read/write block" operation is
> > complete and the result can be passed back to the downstream
> > "block_device". Yes?
> 
> in that case no, the block controller should directly take care of the
> call, without it being translated into some form it likes better for its
> particular interface.

This is entirely wrong. This would mean for example for SD drivers, to implement 
whole SD stack.

> the translation is udes as a mechanism to support old code, but eventually
> there should be none, and the drivers should take a request from
> block_device and take care of it (probably by using memory-mapped access,
> or however you communicate with that chip).
> 
> there might be a shared library for old IDE drivers though, as they are
> more like a shared code with driver (and board)-specific hooks.
> 
> > > > Now block_device (blockdev) is either a whole disc, partition, or
> > > > subpartition. It exports read/write block operations, but to complete
> > > > them, it uses upcalls into it's parent, yes?
> > > 
> > > yes
> > > 
> > > > These upcalls stop at first block_controller_driver, correct?
> > > 
> > > in case of a hard disk, yes. in case of a USB flash, it uses USB calls
> > > to its parent (USB hub or whatever) to complete the task at hand
> > 
> > Let me reformulate -- there is only single block_controller_driver
> > instance the request crosses on it's way up the driver tree. Yes?
> 
> one or none - requests on USB flashes should not pass through
> block_controller_driver.

Uh, what do they pass into then ?

> 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.

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 ?

Best regards,
Marek Vasut