[PATCH v3 0/5] Add general DVSEC/VSEC support

[PATCH v3 0/5] Add general DVSEC/VSEC support

[David E. Box]

This patch enables general support for Intel defined PCIe VSEC and DVSEC
capabilities in the Intel Platform Monitoring Technology (PMT) driver.
Though the driver was written exclusively for PMT capabilities, newer DVSEC
and VSEC IDs for other capabilities can exist on the same device requiring
that the driver handle them.

V3 is mostly a resend of V2. It drops a platform/x86 patch that was picked
up separately by Hans in the last cycle. It also adds a new patch to
support an upcoming capability.

David E. Box (5):
  PCI: Add #defines for accessing PCIE DVSEC fields
  MFD: intel_pmt: Support non-PMT capabilities
  MFD: intel_pmt: Add support for PCIe VSEC structures
  MFD: intel_pmt: Add DG2 support
  MFD: intel_extended_cap: Add support for Intel SDSi

 drivers/mfd/intel_pmt.c                    | 258 +++++++++++++++------
 drivers/platform/x86/intel/pmt/class.c     |   2 +
 drivers/platform/x86/intel/pmt/crashlog.c  |   2 +-
 drivers/platform/x86/intel/pmt/telemetry.c |   2 +-
 include/uapi/linux/pci_regs.h              |   4 +
 5 files changed, 191 insertions(+), 77 deletions(-)

-- 
2.25.1

[PATCH v3 1/5] PCI: Add #defines for accessing PCIE DVSEC fields

[David E. Box]

Add #defines for accessing Vendor ID, Revision, Length, and ID offsets
in the Designated Vendor Specific Extended Capability (DVSEC). Defined
in PCIe r5.0, sec 7.9.6.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---

v3:	No change

 include/uapi/linux/pci_regs.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e709ae8235e7..57ee51f19283 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -1080,7 +1080,11 @@
 
 /* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */
 #define PCI_DVSEC_HEADER1		0x4 /* Designated Vendor-Specific Header1 */
+#define  PCI_DVSEC_HEADER1_VID(x)	((x) & 0xffff)
+#define  PCI_DVSEC_HEADER1_REV(x)	(((x) >> 16) & 0xf)
+#define  PCI_DVSEC_HEADER1_LEN(x)	(((x) >> 20) & 0xfff)
 #define PCI_DVSEC_HEADER2		0x8 /* Designated Vendor-Specific Header2 */
+#define  PCI_DVSEC_HEADER2_ID(x)		((x) & 0xffff)
 
 /* Data Link Feature */
 #define PCI_DLF_CAP		0x04	/* Capabilities Register */
-- 
2.25.1

[PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[David E. Box]

Intel Platform Monitoring Technology (PMT) support is indicated by presence
of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
structures may also be used by Intel to indicate support for other
capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
and non-PMT capabilities. In order to support these capabilities it is
necessary to modify the intel_pmt driver to handle the creation of platform
devices more generically.

Currently PMT devices are named by their capability (e.g. pmt_telemetry).
Instead, generically name them by their capability ID (e.g.
intel-extended-cap-2). This allows the IDs to be created automatically,
minimizing the code needed to support future capabilities. However, to
ensure that unsupported devices aren't created, use an allow list to
specify supported capabilities.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
---

V3: 	No change

V2:	Drop new driver. Keep changes in intel_pmt.c


 drivers/mfd/intel_pmt.c                    | 95 ++++++++++++++--------
 drivers/platform/x86/intel/pmt/crashlog.c  |  2 +-
 drivers/platform/x86/intel/pmt/telemetry.c |  2 +-
 3 files changed, 62 insertions(+), 37 deletions(-)

diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
index dd7eb614c28e..08cd3357577e 100644
--- a/drivers/mfd/intel_pmt.c
+++ b/drivers/mfd/intel_pmt.c
@@ -27,9 +27,18 @@
 #define INTEL_DVSEC_ENTRY_SIZE		4
 
 /* PMT capabilities */
-#define DVSEC_INTEL_ID_TELEMETRY	2
-#define DVSEC_INTEL_ID_WATCHER		3
-#define DVSEC_INTEL_ID_CRASHLOG		4
+#define INTEL_EXT_CAP_ID_TELEMETRY	2
+#define INTEL_EXT_CAP_ID_WATCHER	3
+#define INTEL_EXT_CAP_ID_CRASHLOG	4
+
+#define INTEL_EXT_CAP_PREFIX		"intel_extnd_cap"
+#define FEATURE_ID_NAME_LENGTH		25
+
+static int intel_ext_cap_allow_list[] = {
+	INTEL_EXT_CAP_ID_TELEMETRY,
+	INTEL_EXT_CAP_ID_WATCHER,
+	INTEL_EXT_CAP_ID_CRASHLOG,
+};
 
 struct intel_dvsec_header {
 	u16	length;
@@ -84,42 +93,58 @@ static const struct pmt_platform_info dg1_info = {
 	.capabilities = dg1_capabilities,
 };
 
-static int pmt_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
-		       unsigned long quirks)
+static bool intel_ext_cap_allowed(u16 id)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(intel_ext_cap_allow_list); i++)
+		if (intel_ext_cap_allow_list[i] == id)
+			return true;
+
+	return false;
+}
+
+static bool intel_ext_cap_disabled(u16 id, unsigned long quirks)
+{
+	switch (id) {
+	case INTEL_EXT_CAP_ID_WATCHER:
+		return !!(quirks & PMT_QUIRK_NO_WATCHER);
+
+	case INTEL_EXT_CAP_ID_CRASHLOG:
+		return !!(quirks & PMT_QUIRK_NO_CRASHLOG);
+
+	default:
+		return false;
+	}
+}
+
+static int intel_ext_cap_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
+				 unsigned long quirks)
 {
 	struct device *dev = &pdev->dev;
 	struct resource *res, *tmp;
 	struct mfd_cell *cell;
-	const char *name;
+	char feature_id_name[FEATURE_ID_NAME_LENGTH];
 	int count = header->num_entries;
 	int size = header->entry_size;
 	int id = header->id;
 	int i;
 
-	switch (id) {
-	case DVSEC_INTEL_ID_TELEMETRY:
-		name = "pmt_telemetry";
-		break;
-	case DVSEC_INTEL_ID_WATCHER:
-		if (quirks & PMT_QUIRK_NO_WATCHER) {
-			dev_info(dev, "Watcher not supported\n");
-			return -EINVAL;
-		}
-		name = "pmt_watcher";
-		break;
-	case DVSEC_INTEL_ID_CRASHLOG:
-		if (quirks & PMT_QUIRK_NO_CRASHLOG) {
-			dev_info(dev, "Crashlog not supported\n");
-			return -EINVAL;
-		}
-		name = "pmt_crashlog";
-		break;
-	default:
+	if (!intel_ext_cap_allowed(id))
+		return -EINVAL;
+
+	if (intel_ext_cap_disabled(id, quirks))
+		return -EINVAL;
+
+	snprintf(feature_id_name, sizeof(feature_id_name), "%s_%d", INTEL_EXT_CAP_PREFIX, id);
+
+	if (!header->num_entries) {
+		dev_err(dev, "Invalid 0 entry count for %s header\n", feature_id_name);
 		return -EINVAL;
 	}
 
-	if (!header->num_entries || !header->entry_size) {
-		dev_err(dev, "Invalid count or size for %s header\n", name);
+	if (!header->entry_size) {
+		dev_err(dev, "Invalid 0 entry size for %s header\n", feature_id_name);
 		return -EINVAL;
 	}
 
@@ -135,26 +160,26 @@ static int pmt_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
 		header->offset >>= 3;
 
 	/*
-	 * The PMT DVSEC contains the starting offset and count for a block of
+	 * The DVSEC contains the starting offset and count for a block of
 	 * discovery tables, each providing access to monitoring facilities for
 	 * a section of the device. Create a resource list of these tables to
 	 * provide to the driver.
 	 */
 	for (i = 0, tmp = res; i < count; i++, tmp++) {
 		tmp->start = pdev->resource[header->tbir].start +
-			     header->offset + i * (size << 2);
-		tmp->end = tmp->start + (size << 2) - 1;
+			     header->offset + i * (size * sizeof(u32));
+		tmp->end = tmp->start + (size * sizeof(u32)) - 1;
 		tmp->flags = IORESOURCE_MEM;
 	}
 
 	cell->resources = res;
 	cell->num_resources = count;
-	cell->name = name;
+	cell->name = feature_id_name;
 
-	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cell, 1, NULL, 0,
-				    NULL);
+	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cell, 1, NULL, 0, NULL);
 }
 
+
 static int pmt_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct pmt_platform_info *info;
@@ -176,7 +201,7 @@ static int pmt_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 
 		header = info->capabilities;
 		while (*header) {
-			ret = pmt_add_dev(pdev, *header, quirks);
+			ret = intel_ext_cap_add_dev(pdev, *header, quirks);
 			if (ret)
 				dev_warn(&pdev->dev,
 					 "Failed to add device for DVSEC id %d\n",
@@ -212,7 +237,7 @@ static int pmt_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 			header.tbir = INTEL_DVSEC_TABLE_BAR(table);
 			header.offset = INTEL_DVSEC_TABLE_OFFSET(table);
 
-			ret = pmt_add_dev(pdev, &header, quirks);
+			ret = intel_ext_cap_add_dev(pdev, &header, quirks);
 			if (ret)
 				continue;
 
diff --git a/drivers/platform/x86/intel/pmt/crashlog.c b/drivers/platform/x86/intel/pmt/crashlog.c
index 1c1021f04d3c..86c4b016af59 100644
--- a/drivers/platform/x86/intel/pmt/crashlog.c
+++ b/drivers/platform/x86/intel/pmt/crashlog.c
@@ -17,7 +17,7 @@
 
 #include "class.h"
 
-#define DRV_NAME		"pmt_crashlog"
+#define DRV_NAME		"intel_extnd_cap_4"
 
 /* Crashlog discovery header types */
 #define CRASH_TYPE_OOBMSM	1
diff --git a/drivers/platform/x86/intel/pmt/telemetry.c b/drivers/platform/x86/intel/pmt/telemetry.c
index 38d52651c572..d93d02672679 100644
--- a/drivers/platform/x86/intel/pmt/telemetry.c
+++ b/drivers/platform/x86/intel/pmt/telemetry.c
@@ -17,7 +17,7 @@
 
 #include "class.h"
 
-#define TELEM_DEV_NAME		"pmt_telemetry"
+#define TELEM_DEV_NAME		"intel_extnd_cap_2"
 
 #define TELEM_SIZE_OFFSET	0x0
 #define TELEM_GUID_OFFSET	0x4
-- 
2.25.1

[PATCH v3 3/5] MFD: intel_pmt: Add support for PCIe VSEC structures

[David E. Box]

Adds support for discovering Intel extended capability features from
Vendor Specific Extended Capability (VSEC) registers in PCIe config space.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
---

V3:	No changes

V2:	Drop new driver. Keep changes in intel_pmt.c

 drivers/mfd/intel_pmt.c | 158 +++++++++++++++++++++++++++++-----------
 1 file changed, 115 insertions(+), 43 deletions(-)

diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
index 08cd3357577e..08e07b31aeec 100644
--- a/drivers/mfd/intel_pmt.c
+++ b/drivers/mfd/intel_pmt.c
@@ -40,7 +40,8 @@ static int intel_ext_cap_allow_list[] = {
 	INTEL_EXT_CAP_ID_CRASHLOG,
 };
 
-struct intel_dvsec_header {
+struct intel_ext_cap_header {
+	u8	rev;
 	u16	length;
 	u16	id;
 	u8	num_entries;
@@ -65,7 +66,7 @@ enum pmt_quirks {
 
 struct pmt_platform_info {
 	unsigned long quirks;
-	struct intel_dvsec_header **capabilities;
+	struct intel_ext_cap_header **capabilities;
 };
 
 static const struct pmt_platform_info tgl_info = {
@@ -74,7 +75,7 @@ static const struct pmt_platform_info tgl_info = {
 };
 
 /* DG1 Platform with DVSEC quirk*/
-static struct intel_dvsec_header dg1_telemetry = {
+static struct intel_ext_cap_header dg1_telemetry = {
 	.length = 0x10,
 	.id = 2,
 	.num_entries = 1,
@@ -83,7 +84,7 @@ static struct intel_dvsec_header dg1_telemetry = {
 	.offset = 0x466000,
 };
 
-static struct intel_dvsec_header *dg1_capabilities[] = {
+static struct intel_ext_cap_header *dg1_capabilities[] = {
 	&dg1_telemetry,
 	NULL
 };
@@ -118,7 +119,7 @@ static bool intel_ext_cap_disabled(u16 id, unsigned long quirks)
 	}
 }
 
-static int intel_ext_cap_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
+static int intel_ext_cap_add_dev(struct pci_dev *pdev, struct intel_ext_cap_header *header,
 				 unsigned long quirks)
 {
 	struct device *dev = &pdev->dev;
@@ -160,7 +161,7 @@ static int intel_ext_cap_add_dev(struct pci_dev *pdev, struct intel_dvsec_header
 		header->offset >>= 3;
 
 	/*
-	 * The DVSEC contains the starting offset and count for a block of
+	 * The DVSEC/VSEC contains the starting offset and count for a block of
 	 * discovery tables, each providing access to monitoring facilities for
 	 * a section of the device. Create a resource list of these tables to
 	 * provide to the driver.
@@ -179,13 +180,113 @@ static int intel_ext_cap_add_dev(struct pci_dev *pdev, struct intel_dvsec_header
 	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cell, 1, NULL, 0, NULL);
 }
 
+static bool intel_ext_cap_walk_dvsec(struct pci_dev *pdev, unsigned long quirks)
+{
+	int count = 0;
+	int pos = 0;
+
+	do {
+		struct intel_ext_cap_header header;
+		u32 table, hdr;
+		u16 vid;
+		int ret;
+
+		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
+		if (!pos)
+			break;
+
+		pci_read_config_dword(pdev, pos + PCI_DVSEC_HEADER1, &hdr);
+		vid = PCI_DVSEC_HEADER1_VID(hdr);
+		if (vid != PCI_VENDOR_ID_INTEL)
+			continue;
+
+		/* Support only revision 1 */
+		header.rev = PCI_DVSEC_HEADER1_REV(hdr);
+		if (header.rev != 1) {
+			dev_warn(&pdev->dev, "Unsupported DVSEC revision %d\n",
+				 header.rev);
+			continue;
+		}
+
+		header.length = PCI_DVSEC_HEADER1_LEN(hdr);
+
+		pci_read_config_byte(pdev, pos + INTEL_DVSEC_ENTRIES,
+				     &header.num_entries);
+		pci_read_config_byte(pdev, pos + INTEL_DVSEC_SIZE,
+				     &header.entry_size);
+		pci_read_config_dword(pdev, pos + INTEL_DVSEC_TABLE,
+				      &table);
+
+		header.tbir = INTEL_DVSEC_TABLE_BAR(table);
+		header.offset = INTEL_DVSEC_TABLE_OFFSET(table);
+
+		pci_read_config_dword(pdev, pos + PCI_DVSEC_HEADER2, &hdr);
+		header.id = PCI_DVSEC_HEADER2_ID(hdr);
+
+		ret = intel_ext_cap_add_dev(pdev, &header, quirks);
+		if (ret)
+			continue;
+
+		count++;
+	} while (true);
+
+	return count;
+}
+
+static bool intel_ext_cap_walk_vsec(struct pci_dev *pdev, unsigned long quirks)
+{
+	int count = 0;
+	int pos = 0;
+
+	do {
+		struct intel_ext_cap_header header;
+		u32 table, hdr;
+		int ret;
+
+		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_VNDR);
+		if (!pos)
+			break;
+
+		pci_read_config_dword(pdev, pos + PCI_VNDR_HEADER, &hdr);
+
+		/* Support only revision 1 */
+		header.rev = PCI_VNDR_HEADER_REV(hdr);
+		if (header.rev != 1) {
+			dev_warn(&pdev->dev, "Unsupported VSEC revision %d\n",
+				 header.rev);
+			continue;
+		}
+
+		header.id = PCI_VNDR_HEADER_ID(hdr);
+		header.length = PCI_VNDR_HEADER_LEN(hdr);
+
+		/* entry, size, and table offset are the same as DVSEC */
+		pci_read_config_byte(pdev, pos + INTEL_DVSEC_ENTRIES,
+				     &header.num_entries);
+		pci_read_config_byte(pdev, pos + INTEL_DVSEC_SIZE,
+				     &header.entry_size);
+		pci_read_config_dword(pdev, pos + INTEL_DVSEC_TABLE,
+				      &table);
+
+		header.tbir = INTEL_DVSEC_TABLE_BAR(table);
+		header.offset = INTEL_DVSEC_TABLE_OFFSET(table);
+
+		ret = intel_ext_cap_add_dev(pdev, &header, quirks);
+		if (ret)
+			continue;
+
+		count++;
+	} while (true);
+
+	return count;
+}
 
 static int pmt_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct pmt_platform_info *info;
 	unsigned long quirks = 0;
-	bool found_devices = false;
-	int ret, pos = 0;
+	int device_count = 0;
+	int ret;
 
 	ret = pcim_enable_device(pdev);
 	if (ret)
@@ -196,8 +297,11 @@ static int pmt_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	if (info)
 		quirks = info->quirks;
 
+	device_count += intel_ext_cap_walk_dvsec(pdev, quirks);
+	device_count += intel_ext_cap_walk_vsec(pdev, quirks);
+
 	if (info && (info->quirks & PMT_QUIRK_NO_DVSEC)) {
-		struct intel_dvsec_header **header;
+		struct intel_ext_cap_header **header;
 
 		header = info->capabilities;
 		while (*header) {
@@ -207,45 +311,13 @@ static int pmt_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 					 "Failed to add device for DVSEC id %d\n",
 					 (*header)->id);
 			else
-				found_devices = true;
+				device_count++;
 
 			++header;
 		}
-	} else {
-		do {
-			struct intel_dvsec_header header;
-			u32 table;
-			u16 vid;
-
-			pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
-			if (!pos)
-				break;
-
-			pci_read_config_word(pdev, pos + PCI_DVSEC_HEADER1, &vid);
-			if (vid != PCI_VENDOR_ID_INTEL)
-				continue;
-
-			pci_read_config_word(pdev, pos + PCI_DVSEC_HEADER2,
-					     &header.id);
-			pci_read_config_byte(pdev, pos + INTEL_DVSEC_ENTRIES,
-					     &header.num_entries);
-			pci_read_config_byte(pdev, pos + INTEL_DVSEC_SIZE,
-					     &header.entry_size);
-			pci_read_config_dword(pdev, pos + INTEL_DVSEC_TABLE,
-					      &table);
-
-			header.tbir = INTEL_DVSEC_TABLE_BAR(table);
-			header.offset = INTEL_DVSEC_TABLE_OFFSET(table);
-
-			ret = intel_ext_cap_add_dev(pdev, &header, quirks);
-			if (ret)
-				continue;
-
-			found_devices = true;
-		} while (true);
 	}
 
-	if (!found_devices)
+	if (!device_count)
 		return -ENODEV;
 
 	pm_runtime_put(&pdev->dev);
-- 
2.25.1

[PATCH v3 4/5] MFD: intel_pmt: Add DG2 support

[David E. Box]

Add Platform Monitoring Technology support for DG2 platforms.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
---

V3:	No change

V2:	New patch

 drivers/mfd/intel_pmt.c                | 9 +++++++++
 drivers/platform/x86/intel/pmt/class.c | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
index 08e07b31aeec..a6fe50f65479 100644
--- a/drivers/mfd/intel_pmt.c
+++ b/drivers/mfd/intel_pmt.c
@@ -94,6 +94,11 @@ static const struct pmt_platform_info dg1_info = {
 	.capabilities = dg1_capabilities,
 };
 
+/* DG2 Platform */
+static const struct pmt_platform_info dg2_info = {
+	.quirks = PMT_QUIRK_TABLE_SHIFT
+};
+
 static bool intel_ext_cap_allowed(u16 id)
 {
 	int i;
@@ -334,11 +339,15 @@ static void pmt_pci_remove(struct pci_dev *pdev)
 
 #define PCI_DEVICE_ID_INTEL_PMT_ADL	0x467d
 #define PCI_DEVICE_ID_INTEL_PMT_DG1	0x490e
+#define PCI_DEVICE_ID_INTEL_PMT_DG2_G10	0x4f93
+#define PCI_DEVICE_ID_INTEL_PMT_DG2_G11	0x4f95
 #define PCI_DEVICE_ID_INTEL_PMT_OOBMSM	0x09a7
 #define PCI_DEVICE_ID_INTEL_PMT_TGL	0x9a0d
 static const struct pci_device_id pmt_pci_ids[] = {
 	{ PCI_DEVICE_DATA(INTEL, PMT_ADL, &tgl_info) },
 	{ PCI_DEVICE_DATA(INTEL, PMT_DG1, &dg1_info) },
+	{ PCI_DEVICE_DATA(INTEL, PMT_DG2_G10, &dg2_info) },
+	{ PCI_DEVICE_DATA(INTEL, PMT_DG2_G11, &dg2_info) },
 	{ PCI_DEVICE_DATA(INTEL, PMT_OOBMSM, NULL) },
 	{ PCI_DEVICE_DATA(INTEL, PMT_TGL, &tgl_info) },
 	{ }
diff --git a/drivers/platform/x86/intel/pmt/class.c b/drivers/platform/x86/intel/pmt/class.c
index 659b1073033c..f2a8e19a02e7 100644
--- a/drivers/platform/x86/intel/pmt/class.c
+++ b/drivers/platform/x86/intel/pmt/class.c
@@ -29,6 +29,8 @@
 static const struct pci_device_id pmt_telem_early_client_pci_ids[] = {
 	{ PCI_VDEVICE(INTEL, 0x467d) }, /* ADL */
 	{ PCI_VDEVICE(INTEL, 0x490e) }, /* DG1 */
+	{ PCI_VDEVICE(INTEL, 0x4f93) }, /* DG2_G10 */
+	{ PCI_VDEVICE(INTEL, 0x4f95) }, /* DG2_G11 */
 	{ PCI_VDEVICE(INTEL, 0x9a0d) }, /* TGL */
 	{ }
 };
-- 
2.25.1

[PATCH v3 5/5] MFD: intel_extended_cap: Add support for Intel SDSi

[David E. Box]

Adds platform device support for the Intel Software Defined Silicon (SDSi)
device.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
---

V3:	New patch

 drivers/mfd/intel_pmt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
index a6fe50f65479..5d9adcfa67db 100644
--- a/drivers/mfd/intel_pmt.c
+++ b/drivers/mfd/intel_pmt.c
@@ -30,6 +30,7 @@
 #define INTEL_EXT_CAP_ID_TELEMETRY	2
 #define INTEL_EXT_CAP_ID_WATCHER	3
 #define INTEL_EXT_CAP_ID_CRASHLOG	4
+#define INTEL_EXT_CAP_ID_SDSI		65
 
 #define INTEL_EXT_CAP_PREFIX		"intel_extnd_cap"
 #define FEATURE_ID_NAME_LENGTH		25
@@ -38,6 +39,7 @@ static int intel_ext_cap_allow_list[] = {
 	INTEL_EXT_CAP_ID_TELEMETRY,
 	INTEL_EXT_CAP_ID_WATCHER,
 	INTEL_EXT_CAP_ID_CRASHLOG,
+	INTEL_EXT_CAP_ID_SDSI,
 };
 
 struct intel_ext_cap_header {
-- 
2.25.1

Re: [PATCH v3 0/5] Add general DVSEC/VSEC support

[Hans de Goede]

Hi,

On 9/22/21 11:30 PM, David E. Box wrote:
> This patch enables general support for Intel defined PCIe VSEC and DVSEC
> capabilities in the Intel Platform Monitoring Technology (PMT) driver.
> Though the driver was written exclusively for PMT capabilities, newer DVSEC
> and VSEC IDs for other capabilities can exist on the same device requiring
> that the driver handle them.
> 
> V3 is mostly a resend of V2. It drops a platform/x86 patch that was picked
> up separately by Hans in the last cycle. It also adds a new patch to
> support an upcoming capability.
> 
> David E. Box (5):
>   PCI: Add #defines for accessing PCIE DVSEC fields
>   MFD: intel_pmt: Support non-PMT capabilities
>   MFD: intel_pmt: Add support for PCIe VSEC structures
>   MFD: intel_pmt: Add DG2 support
>   MFD: intel_extended_cap: Add support for Intel SDSi

Since this mostly touches drivers/mfd/intel_pmt.c, I assume this is
going to get merged through the MFD trees.

For the few small drivers/platform/x86 changes:

Acked-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans





> 
>  drivers/mfd/intel_pmt.c                    | 258 +++++++++++++++------
>  drivers/platform/x86/intel/pmt/class.c     |   2 +
>  drivers/platform/x86/intel/pmt/crashlog.c  |   2 +-
>  drivers/platform/x86/intel/pmt/telemetry.c |   2 +-
>  include/uapi/linux/pci_regs.h              |   4 +
>  5 files changed, 191 insertions(+), 77 deletions(-)
> 

Re: [PATCH v3 0/5] Add general DVSEC/VSEC support

[David E. Box]

On Thu, 2021-09-23 at 11:04 +0200, Hans de Goede wrote:
> Hi,
> 
> On 9/22/21 11:30 PM, David E. Box wrote:
> > This patch enables general support for Intel defined PCIe VSEC and DVSEC
> > capabilities in the Intel Platform Monitoring Technology (PMT) driver.
> > Though the driver was written exclusively for PMT capabilities, newer DVSEC
> > and VSEC IDs for other capabilities can exist on the same device requiring
> > that the driver handle them.
> > 
> > V3 is mostly a resend of V2. It drops a platform/x86 patch that was picked
> > up separately by Hans in the last cycle. It also adds a new patch to
> > support an upcoming capability.
> > 
> > David E. Box (5):
> >   PCI: Add #defines for accessing PCIE DVSEC fields
> >   MFD: intel_pmt: Support non-PMT capabilities
> >   MFD: intel_pmt: Add support for PCIe VSEC structures
> >   MFD: intel_pmt: Add DG2 support
> >   MFD: intel_extended_cap: Add support for Intel SDSi
> 
> Since this mostly touches drivers/mfd/intel_pmt.c, I assume this is
> going to get merged through the MFD trees.

Yes. Thanks.

> 
> For the few small drivers/platform/x86 changes:
> 
> Acked-by: Hans de Goede <hdegoede@redhat.com>
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> > 
> >  drivers/mfd/intel_pmt.c                    | 258 +++++++++++++++------
> >  drivers/platform/x86/intel/pmt/class.c     |   2 +
> >  drivers/platform/x86/intel/pmt/crashlog.c  |   2 +-
> >  drivers/platform/x86/intel/pmt/telemetry.c |   2 +-
> >  include/uapi/linux/pci_regs.h              |   4 +
> >  5 files changed, 191 insertions(+), 77 deletions(-)
> > 
> 

Re: [PATCH v3 1/5] PCI: Add #defines for accessing PCIE DVSEC fields

[Bjorn Helgaas]

If you repost this for any reason, update the subject to:

s/PCIE/PCIe/

So it matches the commit log and other usage in drivers/pci/

On Wed, Sep 22, 2021 at 02:30:03PM -0700, David E. Box wrote:
> Add #defines for accessing Vendor ID, Revision, Length, and ID offsets
> in the Designated Vendor Specific Extended Capability (DVSEC). Defined
> in PCIe r5.0, sec 7.9.6.
> 
> Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> 
> v3:	No change
> 
>  include/uapi/linux/pci_regs.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index e709ae8235e7..57ee51f19283 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -1080,7 +1080,11 @@
>  
>  /* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */
>  #define PCI_DVSEC_HEADER1		0x4 /* Designated Vendor-Specific Header1 */
> +#define  PCI_DVSEC_HEADER1_VID(x)	((x) & 0xffff)
> +#define  PCI_DVSEC_HEADER1_REV(x)	(((x) >> 16) & 0xf)
> +#define  PCI_DVSEC_HEADER1_LEN(x)	(((x) >> 20) & 0xfff)
>  #define PCI_DVSEC_HEADER2		0x8 /* Designated Vendor-Specific Header2 */
> +#define  PCI_DVSEC_HEADER2_ID(x)		((x) & 0xffff)
>  
>  /* Data Link Feature */
>  #define PCI_DLF_CAP		0x04	/* Capabilities Register */
> -- 
> 2.25.1
> 

Re: [PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[Greg KH]

On Wed, Sep 22, 2021 at 02:30:04PM -0700, David E. Box wrote:
> Intel Platform Monitoring Technology (PMT) support is indicated by presence
> of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
> structures may also be used by Intel to indicate support for other
> capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
> and non-PMT capabilities. In order to support these capabilities it is
> necessary to modify the intel_pmt driver to handle the creation of platform
> devices more generically.

I said this on your other driver submission, but why are you turning a
PCIe device into a set of platform devices and craming it into the MFD
subsystem?

PCIe devices are NOT platform devices.

Why not use the auxiliary bus for this thing if you have individual
drivers that need to "bind" to the different attributes that this single
PCIe device is exporting.

Or why not just fix the hardware to report individual PCIe devices, like
a sane system would do?  Has this shipped in any devices yet?  If not,
can that be fixed first?  It's just a firmware change, right?

thanks,

greg k-h

Re: [PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[David E. Box]

On Mon, 2021-09-27 at 19:36 +0200, Greg KH wrote:
> On Wed, Sep 22, 2021 at 02:30:04PM -0700, David E. Box wrote:
> > Intel Platform Monitoring Technology (PMT) support is indicated by presence
> > of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
> > structures may also be used by Intel to indicate support for other
> > capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
> > and non-PMT capabilities. In order to support these capabilities it is
> > necessary to modify the intel_pmt driver to handle the creation of platform
> > devices more generically.
> 
> I said this on your other driver submission, but why are you turning a
> PCIe device into a set of platform devices and craming it into the MFD
> subsystem?
> 
> PCIe devices are NOT platform devices.

But they *are* used to create platform devices when the PCIe device is multi-functional, which is
what intel_pmt is.

> 
> Why not use the auxiliary bus for this thing if you have individual
> drivers that need to "bind" to the different attributes that this single
> PCIe device is exporting.

It wasn't clear in the beginning how this would evolve. MFD made sense for the PMT (platform
monitoring technology) driver. PMT has 3 related but individually enumerable devices on the same IP,
like lpss. But the same IP is now being used for other features too like SDSi. We could work on
converting this to the auxiliary bus and then covert the cell drivers.

> 
> Or why not just fix the hardware to report individual PCIe devices, like
> a sane system would do?

We have some systems with 1000+ PCIe devices. Each PCIe device adds cost to HW. So increasingly
VSEC/DVSEC is used to expose features which are handled by the same micro-controller in the HW.

>   Has this shipped in any devices yet?  If not,
> can that be fixed first?  It's just a firmware change, right?

PMT has been shipped for over a year. It's not just a firmware change.

David 
> 
> thanks,
> 
> greg k-h

Re: [PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[Greg KH]

On Mon, Sep 27, 2021 at 11:40:37AM -0700, David E. Box wrote:
> On Mon, 2021-09-27 at 19:36 +0200, Greg KH wrote:
> > On Wed, Sep 22, 2021 at 02:30:04PM -0700, David E. Box wrote:
> > > Intel Platform Monitoring Technology (PMT) support is indicated by presence
> > > of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
> > > structures may also be used by Intel to indicate support for other
> > > capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
> > > and non-PMT capabilities. In order to support these capabilities it is
> > > necessary to modify the intel_pmt driver to handle the creation of platform
> > > devices more generically.
> > 
> > I said this on your other driver submission, but why are you turning a
> > PCIe device into a set of platform devices and craming it into the MFD
> > subsystem?
> > 
> > PCIe devices are NOT platform devices.
> 
> But they *are* used to create platform devices when the PCIe device is multi-functional, which is
> what intel_pmt is.

That is an abuse of platform devices, as that is not what they are for.

> > Why not use the auxiliary bus for this thing if you have individual
> > drivers that need to "bind" to the different attributes that this single
> > PCIe device is exporting.
> 
> It wasn't clear in the beginning how this would evolve. MFD made sense for the PMT (platform
> monitoring technology) driver. PMT has 3 related but individually enumerable devices on the same IP,
> like lpss. But the same IP is now being used for other features too like SDSi. We could work on
> converting this to the auxiliary bus and then covert the cell drivers.

Please do so.

> > Or why not just fix the hardware to report individual PCIe devices, like
> > a sane system would do?
> 
> We have some systems with 1000+ PCIe devices. Each PCIe device adds cost to HW. So increasingly
> VSEC/DVSEC is used to expose features which are handled by the same micro-controller in the HW.

A PCIe device is a virtual thing, what HW cost do they have?

Anyway, a platform device should NOT ever be a child of a PCI device,
that is not ok and should be fixed here please.

A platform device is just that, something that the platform provides on
a non-discoverable bus.  A PCIe device is NOT that type of device at
all and never has been.

thanks,

greg k-h

Re: [PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[Lee Jones]

On Mon, 27 Sep 2021, David E. Box wrote:

> On Mon, 2021-09-27 at 19:36 +0200, Greg KH wrote:
> > On Wed, Sep 22, 2021 at 02:30:04PM -0700, David E. Box wrote:
> > > Intel Platform Monitoring Technology (PMT) support is indicated by presence
> > > of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
> > > structures may also be used by Intel to indicate support for other
> > > capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
> > > and non-PMT capabilities. In order to support these capabilities it is
> > > necessary to modify the intel_pmt driver to handle the creation of platform
> > > devices more generically.
> > 
> > I said this on your other driver submission, but why are you turning a
> > PCIe device into a set of platform devices and craming it into the MFD
> > subsystem?
> > 
> > PCIe devices are NOT platform devices.
> 
> But they *are* used to create platform devices when the PCIe device is multi-functional, which is
> what intel_pmt is.
> 
> > 
> > Why not use the auxiliary bus for this thing if you have individual
> > drivers that need to "bind" to the different attributes that this single
> > PCIe device is exporting.
> 
> It wasn't clear in the beginning how this would evolve. MFD made sense for the PMT (platform
> monitoring technology) driver. PMT has 3 related but individually enumerable devices on the same IP,
> like lpss. But the same IP is now being used for other features too like SDSi. We could work on
> converting this to the auxiliary bus and then covert the cell drivers.

I see this as subsequent work.  It should not affect this submission.

FWIW, I still plan to review this set for inclusion into MFD.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[Greg KH]

On Tue, Sep 28, 2021 at 08:54:45AM +0100, Lee Jones wrote:
> On Mon, 27 Sep 2021, David E. Box wrote:
> 
> > On Mon, 2021-09-27 at 19:36 +0200, Greg KH wrote:
> > > On Wed, Sep 22, 2021 at 02:30:04PM -0700, David E. Box wrote:
> > > > Intel Platform Monitoring Technology (PMT) support is indicated by presence
> > > > of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
> > > > structures may also be used by Intel to indicate support for other
> > > > capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
> > > > and non-PMT capabilities. In order to support these capabilities it is
> > > > necessary to modify the intel_pmt driver to handle the creation of platform
> > > > devices more generically.
> > > 
> > > I said this on your other driver submission, but why are you turning a
> > > PCIe device into a set of platform devices and craming it into the MFD
> > > subsystem?
> > > 
> > > PCIe devices are NOT platform devices.
> > 
> > But they *are* used to create platform devices when the PCIe device is multi-functional, which is
> > what intel_pmt is.
> > 
> > > 
> > > Why not use the auxiliary bus for this thing if you have individual
> > > drivers that need to "bind" to the different attributes that this single
> > > PCIe device is exporting.
> > 
> > It wasn't clear in the beginning how this would evolve. MFD made sense for the PMT (platform
> > monitoring technology) driver. PMT has 3 related but individually enumerable devices on the same IP,
> > like lpss. But the same IP is now being used for other features too like SDSi. We could work on
> > converting this to the auxiliary bus and then covert the cell drivers.
> 
> I see this as subsequent work.  It should not affect this submission.
> 
> FWIW, I still plan to review this set for inclusion into MFD.

That's fine, but as the add-on submission that builds on top of this is
a broken mess (which is what caused me to have to review this series), I
can't recommend that be taken yet as it needs work to prevent systems
from doing bad things.

thanks,

greg k-h

Re: [PATCH v3 2/5] MFD: intel_pmt: Support non-PMT capabilities

[Lee Jones]

On Tue, 28 Sep 2021, Greg KH wrote:

> On Tue, Sep 28, 2021 at 08:54:45AM +0100, Lee Jones wrote:
> > On Mon, 27 Sep 2021, David E. Box wrote:
> > 
> > > On Mon, 2021-09-27 at 19:36 +0200, Greg KH wrote:
> > > > On Wed, Sep 22, 2021 at 02:30:04PM -0700, David E. Box wrote:
> > > > > Intel Platform Monitoring Technology (PMT) support is indicated by presence
> > > > > of an Intel defined PCIe DVSEC structure with a PMT ID. However DVSEC
> > > > > structures may also be used by Intel to indicate support for other
> > > > > capabilities unrelated to PMT.  OOBMSM is a device that can have both PMT
> > > > > and non-PMT capabilities. In order to support these capabilities it is
> > > > > necessary to modify the intel_pmt driver to handle the creation of platform
> > > > > devices more generically.
> > > > 
> > > > I said this on your other driver submission, but why are you turning a
> > > > PCIe device into a set of platform devices and craming it into the MFD
> > > > subsystem?
> > > > 
> > > > PCIe devices are NOT platform devices.
> > > 
> > > But they *are* used to create platform devices when the PCIe device is multi-functional, which is
> > > what intel_pmt is.
> > > 
> > > > 
> > > > Why not use the auxiliary bus for this thing if you have individual
> > > > drivers that need to "bind" to the different attributes that this single
> > > > PCIe device is exporting.
> > > 
> > > It wasn't clear in the beginning how this would evolve. MFD made sense for the PMT (platform
> > > monitoring technology) driver. PMT has 3 related but individually enumerable devices on the same IP,
> > > like lpss. But the same IP is now being used for other features too like SDSi. We could work on
> > > converting this to the auxiliary bus and then covert the cell drivers.
> > 
> > I see this as subsequent work.  It should not affect this submission.
> > 
> > FWIW, I still plan to review this set for inclusion into MFD.
> 
> That's fine, but as the add-on submission that builds on top of this is
> a broken mess (which is what caused me to have to review this series), I
> can't recommend that be taken yet as it needs work to prevent systems
> from doing bad things.

Understood.  Deferred.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog