| Current File : //kernel/drv/nvme.conf |
#
#
# Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights reserved.
#
#
# "nvme-bay-labels":
#
# OVERVIEW:
# We define "nvme-bay-labels" compatible-derived property values to
# facilitate fmd(1M) libtopo bay.so enumeration of NVME storage.
#
# TESTING:
# Use 'diskinfo -o Rcs' and verify that the occupant-serial number
# reported matches the actual serial number of the device at that
# location.
#
# SFF: (Small-Form-Factor) 2.5" drives in platform-specific internal bays:
#
# NOTES:
#
# o Description is dependent on a specific IDT bridge/switch card
# (pciex111d,80b5.108e.426), not NVME end device. For SFF the
# 'nvme-switch' compatible-derived property is placed on the switch.
#
# o The NVME SFF function will also have an 'nvme-bay-labels' definition.
# This comes from the pciclass definition, intended for AIC, below. The
# libtopo bay.so enumerator ignores an 'nvme-bay-labels' property if a
# solaris device tree ancestor already defines the 'nvme-switch'
# property.
#
# o In SFF "<label>@<addr-info>" definitions, the <label> should align with
# a platform's NAC/ILOM names (as specified by platform's FMA portfolio).
# If that name includes a storage backplane, which is typical for sparc
# platforms via sun4vpi PRI/MD (/SYS/DBP/HDD0), then any <label>
# definitions below, associated with the same backplane, should also
# include the backplane NAC.
#
# o The <label> of an SFF bay should be 'absolute' (start with '/'): so
# that the bay is created as a child of the chassis.
#
# o The upstream and downstream bridge ports have the same 'compatible'
# values: solaris only adds compatible-derived properties to a node if
# that node's 'compatible' value is different than its parent's.
#
# o Limitation: The bay.so code currently only supports one bridge/switch
# per system. To support multiple, the recommendation is to define
# "name-bay-labels-<pcislot>" properties, and enhance bay.so to
# pre-process the devinfo snapshot: based on the <pcislot> of the IDT
# bridge/switch devinfo node that bay_enum() is called for, convert-
# truncate the "nvme-bay-labels-<pcislot>" property name in the
# devinfo snapshot to be just "nvme-bay-labels", and then proceed
# with executing current code.
#
# o For some platforms, we may need to have 'storage-variant' information
# available in the root devinfo node 'compatible' property.
#
compatible="pciex111d,80b5.108e.4268" nvme-switch="IDT";
#
# X5-2|X5-2L-8dbp: One bridge/switch card supported, but it can be in any PCIe slot:
# use absolute label and relative path.
#
# NVME shared-HDD
# bay bay <path> relative to switch upstream port
# ----- ----- ----------------------------------------
# NVME0 HDD2 ./pci111d,80b5@6/pci8086,3703@0/disk@1
# NVME1 HDD3 ./pci111d,80b5@7/pci8086,3703@0/disk@1
# NVME2 HDD4 ./pci111d,80b5@5/pci8086,3703@0/disk@1
# NVME3 HDD5 ./pci111d,80b5@4/pci8086,3703@0/disk@1
compatible="pciex111d,80b5.108e.4268"
ancestor-compatible="chassis.ORACLE-SERVER-X5-2"
nvme-bay-labels=
"/NVME0:@6/@0/@1", "/NVME1:@7/@0/@1",
"/NVME2:@5/@0/@1", "/NVME3:@4/@0/@1";
compatible="pciex111d,80b5.108e.4268"
ancestor-compatible="chassis.ORACLE-SERVER-X5-2L-8dbp"
nvme-bay-labels=
"/NVME0:@6/@0/@1", "/NVME1:@7/@0/@1",
"/NVME2:@5/@0/@1", "/NVME3:@4/@0/@1";
#
# X5-2L-24dbp: One bridge/switch card supported, but it can be in any PCIe slot:
# use absolute label and relative path.
#
# NVME shared-HDD
# bay bay <path> relative to switch upstream port
# ----- ----- ----------------------------------------
# NVME0 HDD3 ./pci111d,80b5@7/pci8086,3703@0/disk@1
# NVME1 HDD4 ./pci111d,80b5@6/pci8086,3703@0/disk@1
# NVME2 HDD19 ./pci111d,80b5@4/pci8086,3703@0/disk@1
# NVME3 HDD20 ./pci111d,80b5@5/pci8086,3703@0/disk@1
#
compatible="pciex111d,80b5.108e.4268"
ancestor-compatible="chassis.ORACLE-SERVER-X5-2L-24dbp"
nvme-bay-labels=
"/NVME0:@7/@0/@1", "/NVME1:@6/@0/@1",
"/NVME2:@4/@0/@1", "/NVME3:@5/@0/@1";
#
# X5-4: One bridge/switch card supported, but it can be in any PCIe slot:
# use absolute label and relative path.
#
# NVME shared-HDD
# bay bay <path> relative to switch upstream port
# ----- ----- ----------------------------------------
# NVME0 HDD2 ./pci111d,80b5@4/pci8086,3703@0/disk@1
# NVME1 HDD3 ./pci111d,80b5@5/pci8086,3703@0/disk@1
# NVME2 HDD4 ./pci111d,80b5@6/pci8086,3703@0/disk@1
# NVME3 HDD5 ./pci111d,80b5@7/pci8086,3703@0/disk@1
compatible="pciex111d,80b5.108e.4268"
ancestor-compatible="chassis.ORACLE-SERVER-X5-4"
nvme-bay-labels=
"/NVME0:@4/@0/@1", "/NVME1:@5/@0/@1",
"/NVME2:@6/@0/@1", "/NVME3:@7/@0/@1";
#
# NETRA-X5-2: One bridge/switch card supported, but it can be in any PCIe slot:
# use absolute label and relative path.
#
# NVME shared-HDD
# bay bay <path> relative to switch upstream port
# ----- ----- ----------------------------------------
# NVME0 HDD0 ./pci111d,80b5@6/pci8086,3703@0/disk@1
# NVME1 HDD1 ./pci111d,80b5@7/pci8086,3703@0/disk@1
# NVME2 HDD2 ./pci111d,80b5@5/pci8086,3703@0/disk@1
# NVME3 HDD3 ./pci111d,80b5@4/pci8086,3703@0/disk@1
compatible="pciex111d,80b5.108e.4268"
ancestor-compatible="chassis.NETRA-SERVER-X5-2"
nvme-bay-labels=
"/NVME0:@6/@0/@1", "/NVME1:@7/@0/@1",
"/NVME2:@5/@0/@1", "/NVME3:@4/@0/@1";
#
# AIC: (Add-In-Card) Self-contained embedded-storage PCIE cards:
#
# NOTES:
# o We use "pciclass,010802" NVME class code to get AIC "nvme-bay-labels"
# property definitions on *all* NVME PCI functions (including SFF). We
# then depend on the libtopo bay.so code to suppress bay enumeration,
# using these properties, for SFF devices. The bay.so detects SFF by
# seeing an ancestor (SFF IDT switch above) that already defines
# "nvme-bay-labels".
#
# o The <label> of an AIC bay should be 'relative' (not start with '/'):
# so that the bay is created as a child of PCI slot the AIC card
# is plugged into.
#
# o We only support single-namespace NVME devices (with @1 unit-address)
#
compatible="pciexclass,010802" nvme-bay-labels="NVME:@1";