[RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC

[AKASHI Takahiro]

On Tue, Oct 12, 2021 at 03:30:26PM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 10/12/21 05:26, AKASHI Takahiro wrote:
> > Simon, Heinrich,
> > 
> > On Mon, Oct 11, 2021 at 10:14:02AM -0600, Simon Glass wrote:
> > > Hi Heinrich,
> > > 
> > > On Mon, 11 Oct 2021 at 09:09, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > 
> > > > 
> > > > 
> > > > On 10/11/21 16:32, Simon Glass wrote:
> > > > > Hi Heinrich,
> > > > > 
> > > > > On Mon, 11 Oct 2021 at 04:07, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 10/1/21 13:48, Peter Robinson wrote:
> > > > > > > On Fri, Oct 1, 2021 at 6:03 AM AKASHI Takahiro
> > > > > > > <takahiro.akashi at linaro.org> wrote:
> > > > > > > > 
> > > > > > > > In blk_get_device_by_str(), the comment says: "Updates the partition table
> > > > > > > > for the specified hw partition."
> > > > > > > > Since hw partition is supported only on MMC, it makes no sense to do so
> > > > > > > > for other devices.
> > > > > > > 
> > > > > > > Is it not also supported on UFS, and I believe it may also be an
> > > > > > > option in the NVME spec too.
> > > > > > 
> > > > > > An NVMe device may expose multiple namespaces. blk_create_devicef() is
> > > > > > called for each namespace.
> > > > > > 
> > > > > > A SCSI device may have multiple LUNs. blk_create_devicef() is called for
> > > > > > each LUN.
> > > > > > 
> > > > > > This is what the tree shown by 'dm tree' with on NVMe namespace and one LUN.
> > > > > > 
> > > > > > Class  Index Driver         Name
> > > > > > ---------------------------------------------------------------------
> > > > > > root       0 root_driver    root_driver
> > > > > > simple_bus 0 simple_bus     |- soc
> > > > > > spi        1 sifive_spi     |  |- spi at 10050000
> > > > > > mmc        0 mmc_spi        |  |  `- mmc at 0
> > > > > > blk        0 mmc_blk        |  |     `- mmc at 0.blk
> > > > > > pci        0 pcie_sifive    |  |- pcie at e00000000
> > > > > > pci        1 pci_bridge_drv |  |  `- pci_0:0.0
> > > > > > pci        2 pci_bridge_drv |  |     `- pci_1:0.0
> > > > > > pci        5 pci_bridge_drv |  |        |- pci_2:3.0
> > > > > > ahci       0 ahci_pci       |  |        |  `- ahci_pci
> > > > > > scsi       0 ahci_scsi      |  |        |     `- ahci_scsi
> > > > > > blk        2 scsi_blk       |  |        |        `- ahci_scsi.id0lun0
> > > > > > pci        6 pci_bridge_drv |  |        |- pci_2:4.0
> > > > > > nvme       0 nvme           |  |        |  `- nvme#0
> > > > > > blk        1 nvme-blk       |  |        |     `- nvme#0.blk#1
> > > > > > 
> > > > > > Namespaces and LUNs are modeled as block devices (class = 'blk').
> > > > > 
> > > > > So multiple block devices per NVMe device? I did not know that was supported.
> > > > > 
> > > > > We need a sandbox driver for NVMe as it has no tests at present. Since
> > > > > it has no tests, I don't think we can expect people to know how to
> > > > > maintain whatever functionality is there.
> > > > 
> > > > NVMe drives with multiple namespaces exist for servers but not for
> > > > consumer NVMe drives.
> > > > 
> > > > In QEMU you can define an NVMe device with multiple namespaces. Cf.
> > > > https://qemu.readthedocs.io/en/latest/system/devices/nvme.html?highlight=namespace#additional-namespaces
> > > > 
> > > > So for a first glimpse at the handling I suggest to use QEMU.
> > > 
> > > Well that's fine, but every uclass must have a test and a sandbox
> > > emulator as well.
> > 
> > Wait, it seems that you're discussing a different thing from my patch.
> > 
> > While I don't know whether NVMe namespaces are a kind of "HW partitions",
> > we don't care much here as long as any namespace can be handled simply
> > as a normal block device, like scsi LUN's, in terms of U-Boot driver model.
> > 
> > # On the other hand, we have to explicitly switch "hw partitions"
> > # with blk_select_hwpart_devnum() on MMC devices even though we use
> > # the *same* udevice(blk_desc).
> > # See do_mmcrpmb() in cmd/mmc.c
> 
> Each hardware partition should be a block device (class blk) which is
> mirrored in the UEFI world by a CTRL() device.

Yes, whether it is mirrored or not, a hw partition is to be
a separate udevice from its associated raw device.

> It is not necessary for
> parent device to be a block device.

I'm not sure what 'parent device' means here, but I guess that it is
the raw MMC device (as a controller handle in UEFI terminology which
is set to provide BLOCK_IO_PROTOCOL), isn't it?


-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> > So I hope that *your* discussion doesn't make any difference to my patch.
> > Right?
> > 
> > -Takahiro Akashi
> > 
> > 
> > > Regards,
> > > Simon