[RFC 07/22] dm: blk: add UCLASS_PARTITION

[Heinrich Schuchardt]

> I agree with Heinrich that we are better to leave BLK as it is, both
> in name and meaning. I think maybe I am missing the gist of your
> argument.
>
> If we use UCLASS_PART, for example, can we have that refer to both s/w
> and h/w partitions, as Herinch seems to allude to below? What would
> the picture look like the, and would it get us closer to agreement?

In the driver model:

A UCLASS is a class of drivers that share the same interface.
A UDEVICE is a logical device that belongs to exactly one UCLASS and is
accessed through this UCLASS's interface.

A hardware partition is an object that exposes only a single interface
for block IO.

A software partition is an object that may expose two interfaces: one
for block IO, the other for file IO.

The UEFI model does not have a problem with this because on a handle you
can install as many different protocols as you wish. But U-Boot's driver
model only allows a single interface per device. Up to now U-Boot has
overcome this limitation by creating child devices for the extra interfaces.

We have the following logical levels:

Controller      | Block device | Software Partition| File system
----------------+--------------+-------------------+------------
NVMe Drive      | Namespace    | Partition 1..n    | FAT, EXT4
ATA Controller  | ATA-Drive    |                   |
SCSI Controller | LUN          |                   |
MMC Controller  | HW-Partition |                   |
MMC Controller  | SD-Card      |                   |
USB-Node        | USB-Drive    |                   |

In the device tree this could be modeled as:

|-- Controller (UCLASS_CTRL)
| |-- Block device / HW Partition (UCLASS_BLK)
| | |-- Partition table (UCLASS_PARTITION_TABLE)
| |   |-- Software Partition (UCLASS_BLK)
| |     |-- File system (UCLASS_FS)
| |
| |-- Block device (UCLASS_BLK)
|   |-- File system (UCLASS_FS)

UCLASS_PARTITION_TABLE would be for the drivers in disk/.
UCLASS_FS would be for the drivers in fs/.
UCLASS_BLK will be for any objects exposing raw block IO. A software
partition does the same. It is created by the partition table driver as
child of the partition table udevice.

In this model an eMMC device will not be a UCLASS_BLK device because it
does not expose block IO. It is the hardware partition that exposes this
interface.

The suggested model will allow a clean description of nested partition
tables.

In the UEFI world the software partition and its file system must be
mapped to a single handle with device path node type HD(). For the
parent block device we may create a child handle with partition number 0
(HD(0)). For the partition table we will not create a handle.

Best regards

Heinrich