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

[Heinrich Schuchardt]

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.

Best regards

Heinrich