[RFC 07/22] dm: blk: add UCLASS_PARTITION
AKASHI Takahiro
takahiro.akashi at linaro.org
Tue Nov 16 00:51:10 CET 2021
On Mon, Nov 15, 2021 at 08:16:25PM +0100, Heinrich Schuchardt wrote:
> On 11/15/21 20:05, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Sun, 14 Nov 2021 at 18:43, AKASHI Takahiro
> > <takahiro.akashi at linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sat, Nov 13, 2021 at 02:32:20PM -0700, Simon Glass wrote:
> > > > Hi Heinrich,
> > > >
> > > > On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > >
> > > > > Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg at chromium.org>:
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg at chromium.org> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
> > > > > > > <ilias.apalodimas at linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi chiming in a little late but
> > > > > > > >
> > > > > > > > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi at linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > > > > > > > > > Hi Takahiro,
> > > > > > > > > >
> > > > > > > > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi at linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 11/1/21 03:14, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Takahiro,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > > > > > > > > > > > > <takahiro.akashi at linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Sun, Oct 31, 2021 at 07:15:17PM -0600, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Takahiro,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro
> > > > > > > > > > > > > > > > <takahiro.akashi at linaro.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass <sjg at chromium.org>:
> > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro <takahiro.akashi at linaro.org>:
> > > > > > > > > > > > > > > > > > > > > On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Please be careful about "accessed through" which is a quite confusing
> > > > > > > > > > > > > > > > > > > > > expression. I don't always agree with this view.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Are you talking about UEFI world or U-Boot?
> > > > > > > > > > > > > > > > > > > > > Definitely, a hw partitions can provide a file system
> > > > > > > > > > > > > > > > > > > > > if you want.
> > > > > > > > > > > > > > > > > > > > > It's a matter of usage.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I remember that we had some discussion about whether block devices
> > > > > > > > > > > > > > > > > > > > > on UEFI system should always have a (sw) partition table or not.
> > > > > > > > > > > > > > > > > > > > > But it is a different topic.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 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) (A)
> > > > > > > > > > > > > > > > > > > > > > | | |-- Partition table (UCLASS_PARTITION_TABLE) (B)
> > > > > > > > > > > > > > > > > > > > > > | | |-- Software Partition (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > > | | |-- File system (UCLASS_FS)
> > > > > > > > > > > > > > > > > > > > > > | |
> > > > > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > > | |-- File system (UCLASS_FS)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I don't know why we expect PARTITION_TABLE and FS to appear in DM tree.
> > > > > > > > > > > > > > > > > > > > > What is the benefit?
> > > > > > > > > > > > > > > > > > > > > (A) and (B) always have 1:1 relationship.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > No. You can have a bare device without a partition table.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I can have a DOS partition that covers the whole device, without a
> > > > > > > > > > > > > > > > > > > partition table. This is supported in U-Boot and Linux.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > We have several partition table drivers: DOS, GPT, OSX, ... . In future we should also have one for the NOR Flash partitions. All of these drivers have a common interface. As the partition table type is mostly independent of the block device type we should use separate uclasses and udevices.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I also remember that you claimed that not all efi objects(handles and
> > > > > > > > > > > > > > > > > > > > > protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding
> > > > > > > > > > > > > > > > > > > > > U-Boot counterparts in our 2019 discussion.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE,
> > > > > > > > > > > > > > > > > > > > > which should support other type of hw partitions as well?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > How hardware partitions, LUNs, ATA drives are enumerated is specific to the type of controller while the type of software partition table is independent of the block device.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > |-- eMMC controller (UCLASS_MMC)
> > > > > > > > > > > > > > > > > > > > > | |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?)
> > > > > > > > > > > > > > > > > > > > > | |-- Block device / HW Partition:user data (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > | | |-- Partition table (UCLASS_PARTITION_TABLE)
> > > > > > > > > > > > > > > > > > > > > | | |-- Software Partition (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > | | |-- File system (UCLASS_FS)
> > > > > > > > > > > > > > > > > > > > > | |
> > > > > > > > > > > > > > > > > > > > > | |-- Block device / HW Partition:boot0 (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > | |-- Block device / HW Partition:boot1 (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > > > > > > | |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > |-- scsi controller (UCLASS_SCSI)
> > > > > > > > > > > > > > > > > > > > > | |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?)
> > > > > > > > > > > > > > > > > > > > > | |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?)
> > > > > > > > > > > > > > > > > > > > > | | |-- Partition table (UCLASS_PARTITION_TABLE)
> > > > > > > > > > > > > > > > > > > > > | | |-- Software Partition (UCLASS_BLK)
> > > > > > > > > > > > > > > > > > > > > | |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?)
> > > > > > > > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > (Here I ignored scsi buses/channels which make things more complicated.)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This kind of complex hierarchy doesn't benefit anybody.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > All these levels exist already. We simply do not model them yet in the DM way.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The device tree depth is the outcome of the udevice exposing always only a single interface defined by the uclass.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The UEFI design allows installing multiple protocol interfaces on a single handle. This may result in simpler device trees in some cases.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, the complexity has to go somewhere. With driver model I chose to
> > > > > > > > > > > > > > > > > > > have a single interface per uclass, since it is simpler to understand,
> > > > > > > > > > > > > > > > > > > no need to request a protocol for a device, etc.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Our current setup is similar to this
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > |-- Controller (UCLASS_MMC)
> > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - 'usual' HW partition
> > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - e.g. for a different HW partition*
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > * although I don't think the MMC code actually supports it - SCSI does though
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > We want to add devices for the partition table and the filesystem, so could do:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > |-- Controller (UCLASS_MMC)
> > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - 'usual' HW partition (the whole device)
> > > > > > > > > > > > > > > > > > > | | |-- Partition table (UCLASS_PART) - DOS partition (or EFI)
> > > > > > > > > > > > > > > > > > > | | | |-- Block device (UCLASS_BLK) - partition 1
> > > > > > > > > > > > > > > > > > > | | | | |-- Filesystem (UCLASS_FS) - DOS filesystem
> > > > > > > > > > > > > > > > > > > | | | |-- Block device (UCLASS_BLK) - partition 2
> > > > > > > > > > > > > > > > > > > | | | | |-- Filesystem (UCLASS_FS) - ext5 filesystem
> > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - e.g. for a different HW
> > > > > > > > > > > > > > > > > > > partition (the whole device)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This is similar to Heinrich's, but without the top-level
> > > > > > > > > > > > > > > > > > > UCLASS_HW_PARTITION_TABLE which I am not sure is necessary.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Are further MMC hw partitions, multiple SCSI LUNs and multiple NVME namespaces already treated as separate BLK devices?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > > > > > What I meant to say is that, if we don't need a partition table 'udevice'
> > > > > > > > > > > > > > > > > for hw partitions, we don't need such a device for sw partitions neither.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Meanwhile, what about UCLASS_FS? Why do we need this?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > We don't need it for our current discussion, but if we want to 'open'
> > > > > > > > > > > > > > > > the filesystem and keep the metadata around, rather than reading it
> > > > > > > > > > > > > > > > again every time we access a file, we might find it useful. Open files
> > > > > > > > > > > > > > > > could be children of the FS uclass, perhaps, if we go a step further
> > > > > > > > > > > > > > > > and create devices for them.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Do you want to invent linux-like mount-point concepts or procfs?
> > > > > > > > > > > > > > > I remember that you didn't want to have child nodes under BLK devices.
> > > > > > > > > > > > > > > I'm getting confused about our goal.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think we are all a bit unsure.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think BLK devices can have children, sorry if I said the wrong thing
> > > > > > > > > > > > > > somewhere along the way. For example, a partition would be under a BLK
> > > > > > > > > > > > > > device, or a FS.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > What should DM represent in U-Boot world?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > That is what we are trying to figure out.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think the minimum is to have a a way to represent partitions (s/w
> > > > > > > > > > > > > > and hw/). As I understand it, that's what we've been discussing.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The discovery of hardware partitions is specific to the block device
> > > > > > > > > > > > > controller SCSI/MMC/ATA/NVMe. We currently do not provide any
> > > > > > > > > > > > > manipulation commands to create hardware partitions (e.g. NVMe
> > > > > > > > > > > > > namespaces, SCSI LUNs). This is why extracting a uclass for hardware
> > > > > > > > > > > > > partitions does not seem necessary.
> > > > > > > > > > > >
> > > > > > > > > > > > I can see the reasoning here. It might not stand the test of time but
> > > > > > > > > > > > how about we go with it for now? For MMC hardware partition we would
> > > > > > > > > > > > just end up with multiple BLK devices, like we do with SCSI LUNs at
> > > > > > > > > > > > present, which seems like it should work (with some code tweaks).
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Software partitioning (MBR, GPT, ...) is independent of the harboring
> > > > > > > > > > > > > block device.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We already have a set of drivers for software partition tables in disk/.
> > > > > > > > > > > > > Currently the available methods of the drivers are defined in
> > > > > > > > > > > > > U_BOOT_PART_TYPE referring to struct part_driver.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Currently struct part_driver knows only the following methods:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - get_info()
> > > > > > > > > > > > > - print()
> > > > > > > > > > > > > - test()
> > > > > > > > > > > > >
> > > > > > > > > > > > > These drivers should be ome a uclass.
> > > > > > > > > > > > >
> > > > > > > > > > > > > gpt.c and mbr.c allow to create and delete partitions. I think we should add
> > > > > > > > > > > > >
> > > > > > > > > > > > > - create_partition()
> > > > > > > > > > > > > - delete_partition()
> > > > > > > > > > > > >
> > > > > > > > > > > > > to the uclass methods.
> > > > > > > > > > > >
> > > > > > > > > > > > That sounds good to me, although since it is a partition uclass, we
> > > > > > > > > > > > can just use create() and delete().
> > > > > > > > > > >
> > > > > > > > > > > I don't know why we need a "partition table" device in the middle
> > > > > > > > > > > of DM hierarchy.
> > > > > > > > > > > I believe that it simply makes the view of DM tree complicated
> > > > > > > > > > > without any explicit benefit.
> > > > > > > > > >
> > > > > > > > > > Well we clearly have an API here. The partition uclass can:
> > > > > > > > > >
> > > > > > > > > > - hold the partition table in dev_get_uclass_priv()
> > > > > > > > > > - support a read() operation to read the partition
> > > > > > > > > > - support create() to rewrite the partition table
> > > > > > > > > > - support delete() to overwrite/erase the partition table
> > > > > > > > > >
> > > > > > > > > > Then it means that filesystems have the partition table as a parent
> > > > > > > > > > (unless they are whole-device filesystems), which makes sense
> > > > > > > > > >
> > > > > > > > > > So that's why I like the idea.
> > > > > > > > > >
> > > > > > > > > > Other than the extra complexity, is there anything else wrong with it?
> > > > > > > > >
> > > > > > > > > - First of all, a partition table doesn't look like a 'device' at all.
> > > > > > > > > - Second, a partition table is just static data for block devices.
> > > > > > > > > IMO, even if we want to have this data, we can simply hold it
> > > > > > > > > as some sort of attribute of the device, or maybe as a 'tag' which
> > > > > > > > > I will introduce in the next version.
> > > > > > > > >
> > > > > > > > > -Takahiro Akashi
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't know how this affect the code, but I agree with Akashi-san
> > > > > > > > here. It's indeed useful to keep the partition table stored
> > > > > > > > somewhere, but I think not showing them as part of the device tree is
> > > > > > > > more intuitive.
> > > > > > >
> > > > > > > Well I think I'm easy either way. I just thought that Heinrich made a
> > > > > > > good case for having a partition uclass.
> > > > > > >
> > > > > > > But as Takahiro says, we can use a tag to attach the partition table
> > > > > > > to the device. But it should be attached to the device's children (the
> > > > > > > BLK device) not the media device itself, right?
> > > > > >
> > > > > > As there has been no discussion in 5 days and Takahiro is writing
> > > > > > this, let's go with no uclass for the partition table.
> > > > > >
> > > > >
> > > > > Without uclass you cannot bring the partition table drivers into th driver model.
> > >
> > > This transition may be able to be done later when really necessary
> > > as long as we agree that a partition table be hold within a "raw" disk
> > > object (with a tag support).
> > > # I don't think we need it for now.
> > >
> > > > > No clue what a tag should be in the driver model.
> > > >
> > > > A tag is a way to associate data with a device. At present we do this
> > > > with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.)
> > > > but with tags you can add something else.
> > >
> > > Since this discussion thread is getting too long, I would like
> > > to respin my RFC. How should I deal with your "event notification"
> > > proposal?
> >
> > Is the patch good enough to include in the series?
> >
> > If not, you could reply to it with what needs doing.
? I have already replied to your patch :)
Basically, it seems to be fine to me.
> > Regards,
> > Simon
> >
> The patch is not usable as is. It assumes only GPT partioning is used.
@Heinrich
I don't get your point. Either my patch or Simon's is not specific
to GPT at all.
So I'm going to start respinning my patch for a next round of discussion.
-Takahiro Akashi
> Instead all partition table drivers need to be converted to drivers for
> the new uclass.
>
> Best regards
>
> Heinrich
More information about the U-Boot
mailing list