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.g...@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.g...@gmx.de> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 10/1/21 13:48, Peter Robinson wrote: > > > > > > > On Fri, Oct 1, 2021 at 6:03 AM AKASHI Takahiro > > > > > > > <takahiro.aka...@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@10050000 > > > > > > mmc 0 mmc_spi | | `- mmc@0 > > > > > > blk 0 mmc_blk | | `- m...@0.blk > > > > > > pci 0 pcie_sifive | |- pcie@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