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

Heinrich Schuchardt
2021-10-12T13:30:50Z

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@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@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@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 | | `- mmc@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. It is not necessary for
parent device to be a block device.

Best regards

Heinrich

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