#
#
# 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";