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

Simon Glass
2021-10-11T16:14:36Z

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.

Regards,
Simon