linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH V8 0/5] Intel Platform Monitoring Technology
@ 2020-10-03  1:31 David E. Box
  2020-10-03  1:31 ` [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
                   ` (5 more replies)
  0 siblings, 6 replies; 20+ messages in thread
From: David E. Box @ 2020-10-03  1:31 UTC (permalink / raw)
  To: lee.jones, david.e.box, dvhart, andy, bhelgaas, hdegoede,
	alexey.budankov
  Cc: linux-kernel, platform-driver-x86, linux-pci

Intel Platform Monitoring Technology (PMT) is an architecture for
enumerating and accessing hardware monitoring capabilities on a device.
With customers increasingly asking for hardware telemetry, engineers not
only have to figure out how to measure and collect data, but also how to
deliver it and make it discoverable. The latter may be through some device
specific method requiring device specific tools to collect the data. This
in turn requires customers to manage a suite of different tools in order to
collect the differing assortment of monitoring data on their systems.  Even
when such information can be provided in kernel drivers, they may require
constant maintenance to update register mappings as they change with
firmware updates and new versions of hardware. PMT provides a solution for
discovering and reading telemetry from a device through a hardware agnostic
framework that allows for updates to systems without requiring patches to
the kernel or software tools.

PMT defines several capabilities to support collecting monitoring data from
hardware. All are discoverable as separate instances of the PCIE Designated
Vendor extended capability (DVSEC) with the Intel vendor code. The DVSEC ID
field uniquely identifies the capability. Each DVSEC also provides a BAR
offset to a header that defines capability-specific attributes, including
GUID, feature type, offset and length, as well as configuration settings
where applicable. The GUID uniquely identifies the register space of any
monitor data exposed by the capability. The GUID is associated with an XML
file from the vendor that describes the mapping of the register space along
with properties of the monitor data. This allows vendors to perform
firmware updates that can change the mapping (e.g. add new metrics) without
requiring any changes to drivers or software tools. The new mapping is
confirmed by an updated GUID, read from the hardware, which software uses
with a new XML.

The current capabilities defined by PMT are Telemetry, Watcher, and
Crashlog.  The Telemetry capability provides access to a continuous block
of read only data. The Watcher capability provides access to hardware
sampling and tracing features. Crashlog provides access to device crash
dumps.  While there is some relationship between capabilities (Watcher can
be configured to sample from the Telemetry data set) each exists as stand
alone features with no dependency on any other. The design therefore splits
them into individual, capability specific drivers. MFD is used to create
platform devices for each capability so that they may be managed by their
own driver. The PMT architecture is (for the most part) agnostic to the
type of device it can collect from. Software can determine which devices
support a PMT feature by searching through each device node entry in the
sysfs class folder. It can additionally determine if a particular device
supports a PMT feature by checking for a PMT class folder in the device
folder.

This patch set provides support for the PMT framework, along with support
for Telemetry on Tiger Lake.

Changes from V7:
Link: https://lore.kernel.org/lkml/20201001014250.26987-1-david.e.box@linux.intel.com/

 	- Refactor to minimize code duplication by putting more setup code 
	  in the common intel_pmt_dev_create(). 
	- Add and use a function pointer to handle capability specific
	  header decoding.
	- Add comment on usage of early_client_pci_ids list and add
	  Alder Lake PCI ID to the list.
	- Remove unneeded check on the count variable in intel_pmt_read().
	- Add missing header functions.
	- Specify module names in Kconfig.
	- Fix spelling errors across patch set.

Changes from V6:
	- Use NULL for OOBMSM driver data instead of an empty struct.
	  Rewrite the code to check for NULL driver_data.
	- Fix spelling and formatting in Kconfig.
	- Use MKDEV(0,0) to prevent unneeded device node from being
	  created.

Changes from V5:
	- Add Alder Lake and the "Out of Band Management Services
	  Module (OOBMSM)" ids to the MFD driver. Transferred to this
	  patch set.
	- Use a single class for all PMT capabilities as suggested by
	  Hans.
	- Add binary attribute for telemetry driver to allow read
	  syscall as suggested by Hans.
	- Use the class file to hold attributes and other common code
	  used by all PMT drivers.
	- Add the crashlog driver to the patch set and add a mutex to
	  protect access to the enable control and trigger files as
	  suggested by Hans.

Changes from V4:
	- Replace MFD with PMT in driver title
	- Fix commit tags in chronological order
	- Fix includes in alphabetical order
	- Use 'raw' string instead of defines for device names
	- Add an error message when returning an error code for
	  unrecognized capability id
	- Use dev_err instead of dev_warn for messages when returning
	  an error
	- Change while loop to call pci_find_next_ext_capability once
	- Add missing continue in while loop
	- Keep PCI platform defines using PCI_DEVICE_DATA magic tied to
	  the pci_device_id table
	- Comment and kernel message cleanup

Changes from V3:
	- Write out full acronym for DVSEC in PCI patch commit message and
	  add 'Designated' to comments
	- remove unused variable caught by kernel test robot <lkp@intel.com>
	- Add required Co-developed-by signoffs, noted by Andy
	- Allow access using new CAP_PERFMON capability as suggested by
	  Alexey Bundankov
	- Fix spacing in Kconfig, noted by Randy
	- Other style changes and fixups suggested by Andy

Changes from V2:
	- In order to handle certain HW bugs from the telemetry capability
	  driver, create a single platform device per capability instead of
	  a device per entry. Add the entry data as device resources and
	  let the capability driver manage them as a set allowing for
	  cleaner HW bug resolution.
	- Handle discovery table offset bug in intel_pmt.c
	- Handle overlapping regions in intel_pmt_telemetry.c
	- Add description of sysfs class to testing ABI.
	- Don't check size and count until confirming support for the PMT
	  capability to avoid bailing out when we need to skip it.
	- Remove unneeded header file. Move code to the intel_pmt.c, the
	  only place where it's needed.
	- Remove now unused platform data.
	- Add missing header files types.h, bits.h.
	- Rename file name and build options from telem to telemetry.
	- Code cleanup suggested by Andy S.
	- x86 mailing list added.

Changes from V1:
	- In the telemetry driver, set the device in device_create() to
	  the parent PCI device (the monitoring device) for clear
	  association in sysfs. Was set before to the platform device
	  created by the PCI parent.
	- Move telem struct into driver and delete unneeded header file.
	- Start telem device numbering from 0 instead of 1. 1 was used
	  due to anticipated changes, no longer needed.
	- Use helper macros suggested by Andy S.
	- Rename class to pmt_telemetry, spelling out full name
	- Move monitor device name defines to common header
	- Coding style, spelling, and Makefile/MAINTAINERS ordering fixes

Alexander Duyck (3):
  platform/x86: Intel PMT class driver
  platform/x86: Intel PMT Telemetry capability driver
  platform/x86: Intel PMT Crashlog capability driver

David E. Box (2):
  PCI: Add defines for Designated Vendor-Specific Extended Capability
  mfd: Intel Platform Monitoring Technology support

 .../ABI/testing/sysfs-class-intel_pmt         | 119 +++++++
 MAINTAINERS                                   |   6 +
 drivers/mfd/Kconfig                           |  10 +
 drivers/mfd/Makefile                          |   1 +
 drivers/mfd/intel_pmt.c                       | 226 ++++++++++++
 drivers/platform/x86/Kconfig                  |  34 ++
 drivers/platform/x86/Makefile                 |   3 +
 drivers/platform/x86/intel_pmt_class.c        | 297 ++++++++++++++++
 drivers/platform/x86/intel_pmt_class.h        |  52 +++
 drivers/platform/x86/intel_pmt_crashlog.c     | 328 ++++++++++++++++++
 drivers/platform/x86/intel_pmt_telemetry.c    | 160 +++++++++
 include/uapi/linux/pci_regs.h                 |   5 +
 12 files changed, 1241 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-intel_pmt
 create mode 100644 drivers/mfd/intel_pmt.c
 create mode 100644 drivers/platform/x86/intel_pmt_class.c
 create mode 100644 drivers/platform/x86/intel_pmt_class.h
 create mode 100644 drivers/platform/x86/intel_pmt_crashlog.c
 create mode 100644 drivers/platform/x86/intel_pmt_telemetry.c

-- 
2.20.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
@ 2020-10-03  1:31 ` David E. Box
  2020-10-06 22:45   ` David E. Box
  2020-10-03  1:31 ` [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 20+ messages in thread
From: David E. Box @ 2020-10-03  1:31 UTC (permalink / raw)
  To: lee.jones, david.e.box, dvhart, andy, bhelgaas, hdegoede,
	alexey.budankov
  Cc: linux-kernel, platform-driver-x86, linux-pci, Andy Shevchenko

Add PCIe Designated Vendor-Specific Extended Capability (DVSEC) and defines
for the header offsets. 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>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 include/uapi/linux/pci_regs.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index f9701410d3b5..beafeee39e44 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -720,6 +720,7 @@
 #define PCI_EXT_CAP_ID_DPC	0x1D	/* Downstream Port Containment */
 #define PCI_EXT_CAP_ID_L1SS	0x1E	/* L1 PM Substates */
 #define PCI_EXT_CAP_ID_PTM	0x1F	/* Precision Time Measurement */
+#define PCI_EXT_CAP_ID_DVSEC	0x23	/* Designated Vendor-Specific */
 #define PCI_EXT_CAP_ID_DLF	0x25	/* Data Link Feature */
 #define PCI_EXT_CAP_ID_PL_16GT	0x26	/* Physical Layer 16.0 GT/s */
 #define PCI_EXT_CAP_ID_MAX	PCI_EXT_CAP_ID_PL_16GT
@@ -1062,6 +1063,10 @@
 #define  PCI_L1SS_CTL1_LTR_L12_TH_SCALE	0xe0000000  /* LTR_L1.2_THRESHOLD_Scale */
 #define PCI_L1SS_CTL2		0x0c	/* Control 2 Register */
 
+/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */
+#define PCI_DVSEC_HEADER1		0x4 /* Designated Vendor-Specific Header1 */
+#define PCI_DVSEC_HEADER2		0x8 /* Designated Vendor-Specific Header2 */
+
 /* Data Link Feature */
 #define PCI_DLF_CAP		0x04	/* Capabilities Register */
 #define  PCI_DLF_EXCHANGE_ENABLE	0x80000000  /* Data Link Feature Exchange Enable */
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
  2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
  2020-10-03  1:31 ` [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
@ 2020-10-03  1:31 ` David E. Box
  2020-10-07  6:57   ` Lee Jones
  2020-11-10 10:39   ` Geert Uytterhoeven
  2020-10-03  1:31 ` [PATCH V8 3/5] platform/x86: Intel PMT class driver David E. Box
                   ` (3 subsequent siblings)
  5 siblings, 2 replies; 20+ messages in thread
From: David E. Box @ 2020-10-03  1:31 UTC (permalink / raw)
  To: lee.jones, david.e.box, dvhart, andy, bhelgaas, hdegoede,
	alexey.budankov
  Cc: linux-kernel, platform-driver-x86, linux-pci, Alexander Duyck,
	Andy Shevchenko

Intel Platform Monitoring Technology (PMT) is an architecture for
enumerating and accessing hardware monitoring facilities. PMT supports
multiple types of monitoring capabilities. This driver creates platform
devices for each type so that they may be managed by capability specific
drivers (to be introduced). Capabilities are discovered using PCIe DVSEC
ids. Support is included for the 3 current capability types, Telemetry,
Watcher, and Crashlog. The features are available on new Intel platforms
starting from Tiger Lake for which support is added. This patch adds
support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band Management
Services Module (OOBMSM).

Also add a quirk mechanism for several early hardware differences and bugs.
For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
capabilities since they will not be compatible with future product. Also,
fix use a quirk to fix the discovery table offset.

Co-developed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 MAINTAINERS             |   5 +
 drivers/mfd/Kconfig     |  10 ++
 drivers/mfd/Makefile    |   1 +
 drivers/mfd/intel_pmt.c | 226 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 242 insertions(+)
 create mode 100644 drivers/mfd/intel_pmt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 190c7fa2ea01..0f2663b1d376 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8946,6 +8946,11 @@ F:	drivers/mfd/intel_soc_pmic*
 F:	include/linux/mfd/intel_msic.h
 F:	include/linux/mfd/intel_soc_pmic*
 
+INTEL PMT DRIVER
+M:	"David E. Box" <david.e.box@linux.intel.com>
+S:	Maintained
+F:	drivers/mfd/intel_pmt.c
+
 INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
 M:	Stanislav Yakovlev <stas.yakovlev@gmail.com>
 L:	linux-wireless@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 33df0837ab41..f092db50e518 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -670,6 +670,16 @@ config MFD_INTEL_PMC_BXT
 	  Register and P-unit access. In addition this creates devices
 	  for iTCO watchdog and telemetry that are part of the PMC.
 
+config MFD_INTEL_PMT
+	tristate "Intel Platform Monitoring Technology (PMT) support"
+	depends on PCI
+	select MFD_CORE
+	help
+	  The Intel Platform Monitoring Technology (PMT) is an interface that
+	  provides access to hardware monitor registers. This driver supports
+	  Telemetry, Watcher, and Crashlog PMT capabilities/devices for
+	  platforms starting from Tiger Lake.
+
 config MFD_IPAQ_MICRO
 	bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
 	depends on SA1100_H3100 || SA1100_H3600
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a60e5f835283..b9565d98ab09 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -215,6 +215,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS_PCI)	+= intel-lpss-pci.o
 obj-$(CONFIG_MFD_INTEL_LPSS_ACPI)	+= intel-lpss-acpi.o
 obj-$(CONFIG_MFD_INTEL_MSIC)	+= intel_msic.o
 obj-$(CONFIG_MFD_INTEL_PMC_BXT)	+= intel_pmc_bxt.o
+obj-$(CONFIG_MFD_INTEL_PMT)	+= intel_pmt.o
 obj-$(CONFIG_MFD_PALMAS)	+= palmas.o
 obj-$(CONFIG_MFD_VIPERBOARD)    += viperboard.o
 obj-$(CONFIG_MFD_RC5T583)	+= rc5t583.o rc5t583-irq.o
diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
new file mode 100644
index 000000000000..1b57a970a9d7
--- /dev/null
+++ b/drivers/mfd/intel_pmt.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Platform Monitoring Technology PMT driver
+ *
+ * Copyright (c) 2020, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Author: David E. Box <david.e.box@linux.intel.com>
+ */
+
+#include <linux/bits.h>
+#include <linux/kernel.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/pm_runtime.h>
+#include <linux/types.h>
+
+/* Intel DVSEC capability vendor space offsets */
+#define INTEL_DVSEC_ENTRIES		0xA
+#define INTEL_DVSEC_SIZE		0xB
+#define INTEL_DVSEC_TABLE		0xC
+#define INTEL_DVSEC_TABLE_BAR(x)	((x) & GENMASK(2, 0))
+#define INTEL_DVSEC_TABLE_OFFSET(x)	((x) & GENMASK(31, 3))
+#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
+
+struct intel_dvsec_header {
+	u16	length;
+	u16	id;
+	u8	num_entries;
+	u8	entry_size;
+	u8	tbir;
+	u32	offset;
+};
+
+enum pmt_quirks {
+	/* Watcher capability not supported */
+	PMT_QUIRK_NO_WATCHER	= BIT(0),
+
+	/* Crashlog capability not supported */
+	PMT_QUIRK_NO_CRASHLOG	= BIT(1),
+
+	/* Use shift instead of mask to read discovery table offset */
+	PMT_QUIRK_TABLE_SHIFT	= BIT(2),
+};
+
+struct pmt_platform_info {
+	unsigned long quirks;
+};
+
+static const struct pmt_platform_info pmt_info;
+
+static const struct pmt_platform_info tgl_info = {
+	.quirks = PMT_QUIRK_NO_WATCHER | PMT_QUIRK_NO_CRASHLOG |
+		  PMT_QUIRK_TABLE_SHIFT,
+};
+
+static int pmt_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
+		       struct pmt_platform_info *info)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res, *tmp;
+	struct mfd_cell *cell;
+	const char *name;
+	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 (info->quirks & PMT_QUIRK_NO_WATCHER) {
+			dev_info(dev, "Watcher not supported\n");
+			return 0;
+		}
+		name = "pmt_watcher";
+		break;
+	case DVSEC_INTEL_ID_CRASHLOG:
+		if (info->quirks & PMT_QUIRK_NO_CRASHLOG) {
+			dev_info(dev, "Crashlog not supported\n");
+			return 0;
+		}
+		name = "pmt_crashlog";
+		break;
+	default:
+		dev_err(dev, "Unrecognized PMT capability: %d\n", id);
+		return -EINVAL;
+	}
+
+	if (!header->num_entries || !header->entry_size) {
+		dev_err(dev, "Invalid count or size for %s header\n", name);
+		return -EINVAL;
+	}
+
+	cell = devm_kzalloc(dev, sizeof(*cell), GFP_KERNEL);
+	if (!cell)
+		return -ENOMEM;
+
+	res = devm_kcalloc(dev, count, sizeof(*res), GFP_KERNEL);
+	if (!res)
+		return -ENOMEM;
+
+	if (info->quirks & PMT_QUIRK_TABLE_SHIFT)
+		header->offset >>= 3;
+
+	/*
+	 * The PMT 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;
+		tmp->flags = IORESOURCE_MEM;
+	}
+
+	cell->resources = res;
+	cell->num_resources = count;
+	cell->name = name;
+
+	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;
+	bool found_devices = false;
+	int ret, pos = 0;
+
+	ret = pcim_enable_device(pdev);
+	if (ret)
+		return ret;
+
+	info = devm_kmemdup(&pdev->dev, (void *)id->driver_data, sizeof(*info),
+			    GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+
+	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 = pmt_add_dev(pdev, &header, info);
+		if (ret) {
+			dev_warn(&pdev->dev,
+				 "Failed to add device for DVSEC id %d\n",
+				 header.id);
+			continue;
+		}
+
+		found_devices = true;
+	} while (true);
+
+	if (!found_devices) {
+		dev_err(&pdev->dev, "No supported PMT capabilities found.\n");
+		return -ENODEV;
+	}
+
+	pm_runtime_put(&pdev->dev);
+	pm_runtime_allow(&pdev->dev);
+
+	return 0;
+}
+
+static void pmt_pci_remove(struct pci_dev *pdev)
+{
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+}
+
+#define PCI_DEVICE_ID_INTEL_PMT_ADL	0x467d
+#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_OOBMSM, &pmt_info) },
+	{ PCI_DEVICE_DATA(INTEL, PMT_TGL, &tgl_info) },
+	{ }
+};
+MODULE_DEVICE_TABLE(pci, pmt_pci_ids);
+
+static struct pci_driver pmt_pci_driver = {
+	.name = "intel-pmt",
+	.id_table = pmt_pci_ids,
+	.probe = pmt_pci_probe,
+	.remove = pmt_pci_remove,
+};
+module_pci_driver(pmt_pci_driver);
+
+MODULE_AUTHOR("David E. Box <david.e.box@linux.intel.com>");
+MODULE_DESCRIPTION("Intel Platform Monitoring Technology PMT driver");
+MODULE_LICENSE("GPL v2");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH V8 3/5] platform/x86: Intel PMT class driver
  2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
  2020-10-03  1:31 ` [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
  2020-10-03  1:31 ` [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
@ 2020-10-03  1:31 ` David E. Box
  2020-10-03  1:31 ` [PATCH V8 4/5] platform/x86: Intel PMT Telemetry capability driver David E. Box
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 20+ messages in thread
From: David E. Box @ 2020-10-03  1:31 UTC (permalink / raw)
  To: lee.jones, david.e.box, dvhart, andy, bhelgaas, hdegoede,
	alexey.budankov
  Cc: Alexander Duyck, linux-kernel, platform-driver-x86, linux-pci

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Intel Platform Monitoring Technology is meant to provide a common way to
access telemetry and system metrics.

Register mappings are not provided by the driver. Instead, a GUID is read
from a header for each endpoint. The GUID identifies the device and is to
be used with an XML, provided by the vendor, to discover the available set
of metrics and their register mapping.  This allows firmware updates to
modify the register space without needing to update the driver every time
with new mappings. Firmware writes a new GUID in this case to specify the
new mapping.  Software tools with access to the associated XML file can
then interpret the changes.

The module manages access to all Intel PMT endpoints on a system,
independent of the device exporting them. It creates an intel_pmt class
to manage the devices. For each telemetry endpoint, sysfs files provide
GUID and size information as well as a pointer to the parent device the
telemetry came from. Software may discover the association between
endpoints and devices by iterating through the list in sysfs, or by looking
for the existence of the class folder under the device of interest.  A
binary sysfs attribute of the same name allows software to then read or map
the telemetry space for direct access.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 .../ABI/testing/sysfs-class-intel_pmt         |  54 ++++
 MAINTAINERS                                   |   1 +
 drivers/platform/x86/Kconfig                  |  12 +
 drivers/platform/x86/Makefile                 |   1 +
 drivers/platform/x86/intel_pmt_class.c        | 297 ++++++++++++++++++
 drivers/platform/x86/intel_pmt_class.h        |  52 +++
 6 files changed, 417 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-intel_pmt
 create mode 100644 drivers/platform/x86/intel_pmt_class.c
 create mode 100644 drivers/platform/x86/intel_pmt_class.h

diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt b/Documentation/ABI/testing/sysfs-class-intel_pmt
new file mode 100644
index 000000000000..926b5cf95fd1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-intel_pmt
@@ -0,0 +1,54 @@
+What:		/sys/class/intel_pmt/
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		The intel_pmt/ class directory contains information for
+		devices that expose hardware telemetry using Intel Platform
+		Monitoring Technology (PMT)
+
+What:		/sys/class/intel_pmt/telem<x>
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		The telem<x> directory contains files describing an instance of
+		a PMT telemetry device that exposes hardware telemetry. Each
+		telem<x> directory has an associated telem file. This file
+		may be opened and mapped or read to access the telemetry space
+		of the device. The register layout of the telemetry space is
+		determined from an XML file that matches the PCI device id and
+		GUID for the device.
+
+What:		/sys/class/intel_pmt/telem<x>/telem
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		(RO) The telemetry data for this telemetry device. This file
+		may be mapped or read to obtain the data.
+
+What:		/sys/class/intel_pmt/telem<x>/guid
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		(RO) The GUID for this telemetry device. The GUID identifies
+		the version of the XML file for the parent device that is to
+		be used to get the register layout.
+
+What:		/sys/class/intel_pmt/telem<x>/size
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		(RO) The size of telemetry region in bytes that corresponds to
+		the mapping size for the telem file.
+
+What:		/sys/class/intel_pmt/telem<x>/offset
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		(RO) The offset of telemetry region in bytes that corresponds to
+		the mapping for the telem file.
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f2663b1d376..47fdb8a6e151 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8950,6 +8950,7 @@ INTEL PMT DRIVER
 M:	"David E. Box" <david.e.box@linux.intel.com>
 S:	Maintained
 F:	drivers/mfd/intel_pmt.c
+F:	drivers/platform/x86/intel_pmt_*
 
 INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
 M:	Stanislav Yakovlev <stas.yakovlev@gmail.com>
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 40219bba6801..12431e0e974d 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1360,6 +1360,18 @@ config INTEL_PMC_CORE
 		- LTR Ignore
 		- MPHY/PLL gating status (Sunrisepoint PCH only)
 
+config INTEL_PMT_CLASS
+	tristate "Intel Platform Monitoring Technology (PMT) Class driver"
+	help
+	  The Intel Platform Monitoring Technology (PMT) class driver provides
+	  the basic sysfs interface and file hierarchy uses by PMT devices.
+
+	  For more information, see:
+	  <file:Documentation/ABI/testing/sysfs-class-intel_pmt>
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called intel_pmt_class.
+
 config INTEL_PUNIT_IPC
 	tristate "Intel P-Unit IPC Driver"
 	help
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 5f823f7eff45..f4b1f87f2401 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -140,6 +140,7 @@ obj-$(CONFIG_INTEL_MFLD_THERMAL)	+= intel_mid_thermal.o
 obj-$(CONFIG_INTEL_MID_POWER_BUTTON)	+= intel_mid_powerbtn.o
 obj-$(CONFIG_INTEL_MRFLD_PWRBTN)	+= intel_mrfld_pwrbtn.o
 obj-$(CONFIG_INTEL_PMC_CORE)		+= intel_pmc_core.o intel_pmc_core_pltdrv.o
+obj-$(CONFIG_INTEL_PMT_CLASS)		+= intel_pmt_class.o
 obj-$(CONFIG_INTEL_PUNIT_IPC)		+= intel_punit_ipc.o
 obj-$(CONFIG_INTEL_SCU_IPC)		+= intel_scu_ipc.o
 obj-$(CONFIG_INTEL_SCU_PCI)		+= intel_scu_pcidrv.o
diff --git a/drivers/platform/x86/intel_pmt_class.c b/drivers/platform/x86/intel_pmt_class.c
new file mode 100644
index 000000000000..aa88dc23bbde
--- /dev/null
+++ b/drivers/platform/x86/intel_pmt_class.c
@@ -0,0 +1,297 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Platform Monitory Technology Telemetry driver
+ *
+ * Copyright (c) 2020, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Author: "Alexander Duyck" <alexander.h.duyck@linux.intel.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mm.h>
+#include <linux/pci.h>
+
+#include "intel_pmt_class.h"
+
+#define PMT_XA_START		0
+#define PMT_XA_MAX		INT_MAX
+#define PMT_XA_LIMIT		XA_LIMIT(PMT_XA_START, PMT_XA_MAX)
+
+/*
+ * sysfs
+ */
+static ssize_t
+intel_pmt_read(struct file *filp, struct kobject *kobj,
+	       struct bin_attribute *attr, char *buf, loff_t off,
+	       size_t count)
+{
+	struct intel_pmt_entry *entry = container_of(attr,
+						     struct intel_pmt_entry,
+						     pmt_bin_attr);
+
+	if (off < 0)
+		return -EINVAL;
+
+	if (off >= entry->size)
+		return 0;
+
+	if (count > entry->size - off)
+		count = entry->size - off;
+
+	memcpy_fromio(buf, entry->base + off, count);
+
+	return count;
+}
+
+static int
+intel_pmt_mmap(struct file *filp, struct kobject *kobj,
+		struct bin_attribute *attr, struct vm_area_struct *vma)
+{
+	struct intel_pmt_entry *entry = container_of(attr,
+						     struct intel_pmt_entry,
+						     pmt_bin_attr);
+	unsigned long vsize = vma->vm_end - vma->vm_start;
+	struct device *dev = kobj_to_dev(kobj);
+	unsigned long phys = entry->base_addr;
+	unsigned long pfn = PFN_DOWN(phys);
+	unsigned long psize;
+
+	if (vma->vm_flags & (VM_WRITE | VM_MAYWRITE))
+		return -EROFS;
+
+	psize = (PFN_UP(entry->base_addr + entry->size) - pfn) * PAGE_SIZE;
+	if (vsize > psize) {
+		dev_err(dev, "Requested mmap size is too large\n");
+		return -EINVAL;
+	}
+
+	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+	if (io_remap_pfn_range(vma, vma->vm_start, pfn,
+		vsize, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+static ssize_t
+guid_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct intel_pmt_entry *entry = dev_get_drvdata(dev);
+
+	return sprintf(buf, "0x%x\n", entry->guid);
+}
+static DEVICE_ATTR_RO(guid);
+
+static ssize_t size_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
+{
+	struct intel_pmt_entry *entry = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%zu\n", entry->size);
+}
+static DEVICE_ATTR_RO(size);
+
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct intel_pmt_entry *entry = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%lu\n", offset_in_page(entry->base_addr));
+}
+static DEVICE_ATTR_RO(offset);
+
+static struct attribute *intel_pmt_attrs[] = {
+	&dev_attr_guid.attr,
+	&dev_attr_size.attr,
+	&dev_attr_offset.attr,
+	NULL
+};
+ATTRIBUTE_GROUPS(intel_pmt);
+
+static struct class intel_pmt_class = {
+	.name = "intel_pmt",
+	.owner = THIS_MODULE,
+	.dev_groups = intel_pmt_groups,
+};
+
+static int intel_pmt_populate_entry(struct intel_pmt_entry *entry,
+				    struct intel_pmt_header *header,
+				    struct device *dev,
+				    struct resource *disc_res)
+{
+	struct pci_dev *pci_dev = to_pci_dev(dev->parent);
+	u8 bir;
+
+	/*
+	 * The base offset should always be 8 byte aligned.
+	 *
+	 * For non-local access types the lower 3 bits of base offset
+	 * contains the index of the base address register where the
+	 * telemetry can be found.
+	 */
+	bir = GET_BIR(header->base_offset);
+
+	/* Local access and BARID only for now */
+	switch (header->access_type) {
+	case ACCESS_LOCAL:
+		if (bir) {
+			dev_err(dev,
+				"Unsupported BAR index %d for access type %d\n",
+				bir, header->access_type);
+			return -EINVAL;
+		}
+		/*
+		 * For access_type LOCAL, the base address is as follows:
+		 * base address = end of discovery region + base offset
+		 */
+		entry->base_addr = disc_res->end + 1 + header->base_offset;
+		break;
+	case ACCESS_BARID:
+		/*
+		 * If another BAR was specified then the base offset
+		 * represents the offset within that BAR. SO retrieve the
+		 * address from the parent PCI device and add offset.
+		 */
+		entry->base_addr = pci_resource_start(pci_dev, bir) +
+				   GET_ADDRESS(header->base_offset);
+		break;
+	default:
+		dev_err(dev, "Unsupported access type %d\n",
+			header->access_type);
+		return -EINVAL;
+	}
+
+	entry->guid = header->guid;
+	entry->size = header->size;
+
+	return 0;
+}
+
+static int intel_pmt_dev_register(struct intel_pmt_entry *entry,
+				  struct intel_pmt_namespace *ns,
+				  struct device *parent)
+{
+	struct resource res;
+	struct device *dev;
+	int ret;
+
+	ret = xa_alloc(ns->xa, &entry->devid, entry, PMT_XA_LIMIT, GFP_KERNEL);
+	if (ret)
+		return ret;
+
+	dev = device_create(&intel_pmt_class, parent, MKDEV(0, 0), entry,
+			    "%s%d", ns->name, entry->devid);
+
+	if (IS_ERR(dev)) {
+		dev_err(parent, "Could not create %s%d device node\n",
+			ns->name, entry->devid);
+		ret = PTR_ERR(dev);
+		goto fail_dev_create;
+	}
+
+	entry->kobj = &dev->kobj;
+
+	if (ns->attr_grp) {
+		ret = sysfs_create_group(entry->kobj, ns->attr_grp);
+		if (ret)
+			goto fail_sysfs;
+	}
+
+	/* if size is 0 assume no data buffer, so no file needed */
+	if (!entry->size)
+		return 0;
+
+	res.start = entry->base_addr;
+	res.end = res.start + entry->size - 1;
+	res.flags = IORESOURCE_MEM;
+
+	entry->base = devm_ioremap_resource(dev, &res);
+	if (IS_ERR(entry->base)) {
+		ret = PTR_ERR(entry->base);
+		goto fail_ioremap;
+	}
+
+	sysfs_bin_attr_init(&entry->pmt_bin_attr);
+	entry->pmt_bin_attr.attr.name = ns->name;
+	entry->pmt_bin_attr.attr.mode = 0440;
+	entry->pmt_bin_attr.mmap = intel_pmt_mmap;
+	entry->pmt_bin_attr.read = intel_pmt_read;
+	entry->pmt_bin_attr.size = entry->size;
+
+	ret = sysfs_create_bin_file(&dev->kobj, &entry->pmt_bin_attr);
+	if (!ret)
+		return 0;
+
+fail_ioremap:
+	sysfs_remove_group(entry->kobj, ns->attr_grp);
+fail_sysfs:
+	device_unregister(dev);
+fail_dev_create:
+	xa_erase(ns->xa, entry->devid);
+
+	return ret;
+}
+
+int intel_pmt_dev_create(struct intel_pmt_entry *entry,
+			 struct intel_pmt_namespace *ns,
+			 struct platform_device *pdev, int idx)
+{
+	struct intel_pmt_header header;
+	struct resource	*disc_res;
+	int ret = -ENODEV;
+
+	disc_res = platform_get_resource(pdev, IORESOURCE_MEM, idx);
+	if (!disc_res)
+		return ret;
+
+	entry->disc_table = devm_platform_ioremap_resource(pdev, idx);
+	if (IS_ERR(entry->disc_table))
+		return PTR_ERR(entry->disc_table);
+
+	ret = ns->pmt_header_decode(entry, &header, &pdev->dev);
+	if (ret)
+		return ret;
+
+	ret = intel_pmt_populate_entry(entry, &header, &pdev->dev, disc_res);
+	if (ret)
+		return ret;
+
+	return intel_pmt_dev_register(entry, ns, &pdev->dev);
+
+}
+EXPORT_SYMBOL_GPL(intel_pmt_dev_create);
+
+void intel_pmt_dev_destroy(struct intel_pmt_entry *entry,
+			   struct intel_pmt_namespace *ns)
+{
+	struct device *dev = kobj_to_dev(entry->kobj);
+
+	if (entry->size)
+		sysfs_remove_bin_file(entry->kobj, &entry->pmt_bin_attr);
+
+	if (ns->attr_grp)
+		sysfs_remove_group(entry->kobj, ns->attr_grp);
+
+	device_unregister(dev);
+	xa_erase(ns->xa, entry->devid);
+}
+EXPORT_SYMBOL_GPL(intel_pmt_dev_destroy);
+
+static int __init pmt_class_init(void)
+{
+	return class_register(&intel_pmt_class);
+}
+
+static void __exit pmt_class_exit(void)
+{
+	class_unregister(&intel_pmt_class);
+}
+
+module_init(pmt_class_init);
+module_exit(pmt_class_exit);
+
+MODULE_AUTHOR("Alexander Duyck <alexander.h.duyck@linux.intel.com>");
+MODULE_DESCRIPTION("Intel PMT Class driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/platform/x86/intel_pmt_class.h b/drivers/platform/x86/intel_pmt_class.h
new file mode 100644
index 000000000000..de8f8139ba31
--- /dev/null
+++ b/drivers/platform/x86/intel_pmt_class.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _INTEL_PMT_CLASS_H
+#define _INTEL_PMT_CLASS_H
+
+#include <linux/platform_device.h>
+#include <linux/xarray.h>
+#include <linux/types.h>
+#include <linux/bits.h>
+#include <linux/err.h>
+#include <linux/io.h>
+
+/* PMT access types */
+#define ACCESS_BARID		2
+#define ACCESS_LOCAL		3
+
+/* PMT discovery base address/offset register layout */
+#define GET_BIR(v)		((v) & GENMASK(2, 0))
+#define GET_ADDRESS(v)		((v) & GENMASK(31, 3))
+
+struct intel_pmt_entry {
+	struct bin_attribute	pmt_bin_attr;
+	struct kobject		*kobj;
+	void __iomem		*disc_table;
+	void __iomem		*base;
+	unsigned long		base_addr;
+	size_t			size;
+	u32			guid;
+	int			devid;
+};
+
+struct intel_pmt_header {
+	u32	base_offset;
+	u32	size;
+	u32	guid;
+	u8	access_type;
+};
+
+struct intel_pmt_namespace {
+	const char *name;
+	struct xarray *xa;
+	const struct attribute_group *attr_grp;
+	int (*pmt_header_decode)(struct intel_pmt_entry *entry,
+				 struct intel_pmt_header *header,
+				 struct device *dev);
+};
+
+int intel_pmt_dev_create(struct intel_pmt_entry *entry,
+			 struct intel_pmt_namespace *ns,
+			 struct platform_device *pdev, int idx);
+void intel_pmt_dev_destroy(struct intel_pmt_entry *entry,
+			   struct intel_pmt_namespace *ns);
+#endif
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH V8 4/5] platform/x86: Intel PMT Telemetry capability driver
  2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
                   ` (2 preceding siblings ...)
  2020-10-03  1:31 ` [PATCH V8 3/5] platform/x86: Intel PMT class driver David E. Box
@ 2020-10-03  1:31 ` David E. Box
  2020-10-03  1:31 ` [PATCH V8 5/5] platform/x86: Intel PMT Crashlog " David E. Box
  2020-10-27 11:28 ` [PATCH V8 0/5] Intel Platform Monitoring Technology Hans de Goede
  5 siblings, 0 replies; 20+ messages in thread
From: David E. Box @ 2020-10-03  1:31 UTC (permalink / raw)
  To: lee.jones, david.e.box, dvhart, andy, bhelgaas, hdegoede,
	alexey.budankov
  Cc: Alexander Duyck, linux-kernel, platform-driver-x86, linux-pci

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

PMT Telemetry is a capability of the Intel Platform Monitoring Technology.
The Telemetry capability provides access to device telemetry metrics that
provide hardware performance data to users from read-only register spaces.

With this driver present the intel_pmt directory can be populated with
telem<x> devices. These devices will contain the standard intel_pmt sysfs
data and a "telem" binary sysfs attribute which can be used to access the
telemetry data.

Also create a PCI device id list for early telemetry hardware that require
workarounds for known issues.

Co-developed-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 drivers/platform/x86/Kconfig               |  11 ++
 drivers/platform/x86/Makefile              |   1 +
 drivers/platform/x86/intel_pmt_telemetry.c | 160 +++++++++++++++++++++
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/platform/x86/intel_pmt_telemetry.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 12431e0e974d..90b4c1bd9532 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1372,6 +1372,17 @@ config INTEL_PMT_CLASS
 	  To compile this driver as a module, choose M here: the module
 	  will be called intel_pmt_class.
 
+config INTEL_PMT_TELEMETRY
+	tristate "Intel Platform Monitoring Technology (PMT) Telemetry driver"
+	select INTEL_PMT_CLASS
+	help
+	  The Intel Platform Monitory Technology (PMT) Telemetry driver provides
+	  access to hardware telemetry metrics on devices that support the
+	  feature.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called intel_pmt_telemetry.
+
 config INTEL_PUNIT_IPC
 	tristate "Intel P-Unit IPC Driver"
 	help
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index f4b1f87f2401..6a7b61f59ea8 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_INTEL_MID_POWER_BUTTON)	+= intel_mid_powerbtn.o
 obj-$(CONFIG_INTEL_MRFLD_PWRBTN)	+= intel_mrfld_pwrbtn.o
 obj-$(CONFIG_INTEL_PMC_CORE)		+= intel_pmc_core.o intel_pmc_core_pltdrv.o
 obj-$(CONFIG_INTEL_PMT_CLASS)		+= intel_pmt_class.o
+obj-$(CONFIG_INTEL_PMT_TELEMETRY)	+= intel_pmt_telemetry.o
 obj-$(CONFIG_INTEL_PUNIT_IPC)		+= intel_punit_ipc.o
 obj-$(CONFIG_INTEL_SCU_IPC)		+= intel_scu_ipc.o
 obj-$(CONFIG_INTEL_SCU_PCI)		+= intel_scu_pcidrv.o
diff --git a/drivers/platform/x86/intel_pmt_telemetry.c b/drivers/platform/x86/intel_pmt_telemetry.c
new file mode 100644
index 000000000000..f8a87614efa4
--- /dev/null
+++ b/drivers/platform/x86/intel_pmt_telemetry.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Platform Monitory Technology Telemetry driver
+ *
+ * Copyright (c) 2020, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Author: "David E. Box" <david.e.box@linux.intel.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/overflow.h>
+
+#include "intel_pmt_class.h"
+
+#define TELEM_DEV_NAME		"pmt_telemetry"
+
+#define TELEM_SIZE_OFFSET	0x0
+#define TELEM_GUID_OFFSET	0x4
+#define TELEM_BASE_OFFSET	0x8
+#define TELEM_ACCESS(v)		((v) & GENMASK(3, 0))
+/* size is in bytes */
+#define TELEM_SIZE(v)		(((v) & GENMASK(27, 12)) >> 10)
+
+/* Used by client hardware to identify a fixed telemetry entry*/
+#define TELEM_CLIENT_FIXED_BLOCK_GUID	0x10000000
+
+struct pmt_telem_priv {
+	int				num_entries;
+	struct intel_pmt_entry		entry[];
+};
+
+/*
+ * Early implementations of PMT on client platforms have some
+ * differences from the server platforms (which use the Out Of Band
+ * Management Services Module OOBMSM). This list tracks those
+ * platforms as needed to handle those differences. Newer client
+ * platforms are expected to be fully compatible with server.
+ */
+static const struct pci_device_id pmt_telem_early_client_pci_ids[] = {
+	{ PCI_VDEVICE(INTEL, 0x9a0d) }, /* TGL */
+	{ PCI_VDEVICE(INTEL, 0x467d) }, /* ADL */
+	{ }
+};
+
+static bool intel_pmt_is_early_client_hw(struct device *dev)
+{
+	struct pci_dev *parent = to_pci_dev(dev->parent);
+
+	return !!pci_match_id(pmt_telem_early_client_pci_ids, parent);
+}
+
+static bool pmt_telem_region_overlaps(struct intel_pmt_entry *entry,
+				      struct device *dev)
+{
+	u32 guid = readl(entry->disc_table + TELEM_GUID_OFFSET);
+
+	if (guid != TELEM_CLIENT_FIXED_BLOCK_GUID)
+		return false;
+
+	return intel_pmt_is_early_client_hw(dev);
+}
+
+static int pmt_telem_header_decode(struct intel_pmt_entry *entry,
+				   struct intel_pmt_header *header,
+				   struct device *dev)
+{
+	void __iomem *disc_table = entry->disc_table;
+
+	if (pmt_telem_region_overlaps(entry, dev))
+		return 1;
+
+	header->access_type = TELEM_ACCESS(readl(disc_table));
+	header->guid = readl(disc_table + TELEM_GUID_OFFSET);
+	header->base_offset = readl(disc_table + TELEM_BASE_OFFSET);
+
+	/* Size is measured in DWORDS, but accessor returns bytes */
+	header->size = TELEM_SIZE(readl(disc_table));
+
+	return 0;
+}
+
+static DEFINE_XARRAY_ALLOC(telem_array);
+static struct intel_pmt_namespace pmt_telem_ns = {
+	.name = "telem",
+	.xa = &telem_array,
+	.pmt_header_decode = pmt_telem_header_decode,
+};
+
+static int pmt_telem_remove(struct platform_device *pdev)
+{
+	struct pmt_telem_priv *priv = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = 0; i < priv->num_entries; i++)
+		intel_pmt_dev_destroy(&priv->entry[i], &pmt_telem_ns);
+
+	return 0;
+}
+
+static int pmt_telem_probe(struct platform_device *pdev)
+{
+	struct pmt_telem_priv *priv;
+	size_t size;
+	int i, ret;
+
+	size = struct_size(priv, entry, pdev->num_resources);
+	priv = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, priv);
+
+	for (i = 0; i < pdev->num_resources; i++) {
+		struct intel_pmt_entry *entry = &priv->entry[i];
+
+		ret = intel_pmt_dev_create(entry, &pmt_telem_ns, pdev, i);
+		if (ret < 0)
+			goto abort_probe;
+		if (ret)
+			continue;
+
+		priv->num_entries++;
+	}
+
+	return 0;
+abort_probe:
+	pmt_telem_remove(pdev);
+	return ret;
+}
+
+static struct platform_driver pmt_telem_driver = {
+	.driver = {
+		.name   = TELEM_DEV_NAME,
+	},
+	.remove = pmt_telem_remove,
+	.probe  = pmt_telem_probe,
+};
+
+static int __init pmt_telem_init(void)
+{
+	return platform_driver_register(&pmt_telem_driver);
+}
+module_init(pmt_telem_init);
+
+static void __exit pmt_telem_exit(void)
+{
+	platform_driver_unregister(&pmt_telem_driver);
+	xa_destroy(&telem_array);
+}
+module_exit(pmt_telem_exit);
+
+MODULE_AUTHOR("David E. Box <david.e.box@linux.intel.com>");
+MODULE_DESCRIPTION("Intel PMT Telemetry driver");
+MODULE_ALIAS("platform:" TELEM_DEV_NAME);
+MODULE_LICENSE("GPL v2");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH V8 5/5] platform/x86: Intel PMT Crashlog capability driver
  2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
                   ` (3 preceding siblings ...)
  2020-10-03  1:31 ` [PATCH V8 4/5] platform/x86: Intel PMT Telemetry capability driver David E. Box
@ 2020-10-03  1:31 ` David E. Box
  2020-10-27 11:28 ` [PATCH V8 0/5] Intel Platform Monitoring Technology Hans de Goede
  5 siblings, 0 replies; 20+ messages in thread
From: David E. Box @ 2020-10-03  1:31 UTC (permalink / raw)
  To: lee.jones, david.e.box, dvhart, andy, bhelgaas, hdegoede,
	alexey.budankov
  Cc: Alexander Duyck, linux-kernel, platform-driver-x86, linux-pci

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Add support for the Intel Platform Monitoring Technology crashlog
interface. This interface provides a few sysfs values to allow for
controlling the crashlog telemetry interface as well as a character
driver to allow for mapping the crashlog memory region so that it can be
accessed after a crashlog has been recorded.

This driver is meant to only support the server version of the crashlog
which is identified as crash_type 1 with a version of zero. Currently no
other types are supported.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 .../ABI/testing/sysfs-class-intel_pmt         |  65 ++++
 drivers/platform/x86/Kconfig                  |  11 +
 drivers/platform/x86/Makefile                 |   1 +
 drivers/platform/x86/intel_pmt_crashlog.c     | 328 ++++++++++++++++++
 4 files changed, 405 insertions(+)
 create mode 100644 drivers/platform/x86/intel_pmt_crashlog.c

diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt b/Documentation/ABI/testing/sysfs-class-intel_pmt
index 926b5cf95fd1..ed4c886a21b1 100644
--- a/Documentation/ABI/testing/sysfs-class-intel_pmt
+++ b/Documentation/ABI/testing/sysfs-class-intel_pmt
@@ -52,3 +52,68 @@ Contact:	David Box <david.e.box@linux.intel.com>
 Description:
 		(RO) The offset of telemetry region in bytes that corresponds to
 		the mapping for the telem file.
+
+What:		/sys/class/intel_pmt/crashlog<x>
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+		The crashlog<x> directory contains files for configuring an
+		instance of a PMT crashlog device that can perform crash data
+		recording. Each crashlog<x> device has an associated crashlog
+		file. This file can be opened and mapped or read to access the
+		resulting crashlog buffer. The register layout for the buffer
+		can be determined from an XML file of specified GUID for the
+		parent device.
+
+What:		/sys/class/intel_pmt/crashlog<x>/crashlog
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	David Box <david.e.box@linux.intel.com>
+Description:
+		(RO) The crashlog buffer for this crashlog device. This file
+		may be mapped or read to obtain the data.
+
+What:		/sys/class/intel_pmt/crashlog<x>/guid
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+		(RO) The GUID for this crashlog device. The GUID identifies the
+		version of the XML file for the parent device that should be
+		used to determine the register layout.
+
+What:		/sys/class/intel_pmt/crashlog<x>/size
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+		(RO) The length of the result buffer in bytes that corresponds
+		to the size for the crashlog buffer.
+
+What:		/sys/class/intel_pmt/crashlog<x>/offset
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+		(RO) The offset of the buffer in bytes that corresponds
+		to the mapping for the crashlog device.
+
+What:		/sys/class/intel_pmt/crashlog<x>/enable
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+		(RW) Boolean value controlling if the crashlog functionality
+		is enabled for the crashlog device.
+
+What:		/sys/class/intel_pmt/crashlog<x>/trigger
+Date:		October 2020
+KernelVersion:	5.10
+Contact:	Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+		(RW) Boolean value controlling the triggering of the crashlog
+		device node. When read it provides data on if the crashlog has
+		been triggered. When written to it can be used to either clear
+		the current trigger by writing false, or to trigger a new
+		event if the trigger is not currently set.
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 90b4c1bd9532..4ac555a9916b 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1383,6 +1383,17 @@ config INTEL_PMT_TELEMETRY
 	  To compile this driver as a module, choose M here: the module
 	  will be called intel_pmt_telemetry.
 
+config INTEL_PMT_CRASHLOG
+	tristate "Intel Platform Monitoring Technology (PMT) Crashlog driver"
+	select INTEL_PMT_CLASS
+	help
+	  The Intel Platform Monitoring Technology (PMT) crashlog driver provides
+	  access to hardware crashlog capabilities on devices that support the
+	  feature.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called intel_pmt_crashlog.
+
 config INTEL_PUNIT_IPC
 	tristate "Intel P-Unit IPC Driver"
 	help
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 6a7b61f59ea8..ca82c1344977 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_INTEL_MRFLD_PWRBTN)	+= intel_mrfld_pwrbtn.o
 obj-$(CONFIG_INTEL_PMC_CORE)		+= intel_pmc_core.o intel_pmc_core_pltdrv.o
 obj-$(CONFIG_INTEL_PMT_CLASS)		+= intel_pmt_class.o
 obj-$(CONFIG_INTEL_PMT_TELEMETRY)	+= intel_pmt_telemetry.o
+obj-$(CONFIG_INTEL_PMT_CRASHLOG)	+= intel_pmt_crashlog.o
 obj-$(CONFIG_INTEL_PUNIT_IPC)		+= intel_punit_ipc.o
 obj-$(CONFIG_INTEL_SCU_IPC)		+= intel_scu_ipc.o
 obj-$(CONFIG_INTEL_SCU_PCI)		+= intel_scu_pcidrv.o
diff --git a/drivers/platform/x86/intel_pmt_crashlog.c b/drivers/platform/x86/intel_pmt_crashlog.c
new file mode 100644
index 000000000000..97dd749c8290
--- /dev/null
+++ b/drivers/platform/x86/intel_pmt_crashlog.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Platform Monitoring Technology Crashlog driver
+ *
+ * Copyright (c) 2020, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Author: "Alexander Duyck" <alexander.h.duyck@linux.intel.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/overflow.h>
+
+#include "intel_pmt_class.h"
+
+#define DRV_NAME		"pmt_crashlog"
+
+/* Crashlog discovery header types */
+#define CRASH_TYPE_OOBMSM	1
+
+/* Control Flags */
+#define CRASHLOG_FLAG_DISABLE		BIT(27)
+
+/*
+ * Bits 28 and 29 control the state of bit 31.
+ *
+ * Bit 28 will clear bit 31, if set, allowing a new crashlog to be captured.
+ * Bit 29 will immediately trigger a crashlog to be generated, setting bit 31.
+ * Bit 30 is read-only and reserved as 0.
+ * Bit 31 is the read-only status with a 1 indicating log is complete.
+ */
+#define CRASHLOG_FLAG_TRIGGER_CLEAR	BIT(28)
+#define CRASHLOG_FLAG_TRIGGER_EXECUTE	BIT(29)
+#define CRASHLOG_FLAG_TRIGGER_COMPLETE	BIT(31)
+#define CRASHLOG_FLAG_TRIGGER_MASK	GENMASK(31, 28)
+
+/* Crashlog Discovery Header */
+#define CONTROL_OFFSET		0x0
+#define GUID_OFFSET		0x4
+#define BASE_OFFSET		0x8
+#define SIZE_OFFSET		0xC
+#define GET_ACCESS(v)		((v) & GENMASK(3, 0))
+#define GET_TYPE(v)		(((v) & GENMASK(7, 4)) >> 4)
+#define GET_VERSION(v)		(((v) & GENMASK(19, 16)) >> 16)
+/* size is in bytes */
+#define GET_SIZE(v)		((v) * sizeof(u32))
+
+struct crashlog_entry {
+	/* entry must be first member of struct */
+	struct intel_pmt_entry		entry;
+	struct mutex			control_mutex;
+};
+
+struct pmt_crashlog_priv {
+	int			num_entries;
+	struct crashlog_entry	entry[];
+};
+
+/*
+ * I/O
+ */
+static bool pmt_crashlog_complete(struct intel_pmt_entry *entry)
+{
+	u32 control = readl(entry->disc_table + CONTROL_OFFSET);
+
+	/* return current value of the crashlog complete flag */
+	return !!(control & CRASHLOG_FLAG_TRIGGER_COMPLETE);
+}
+
+static bool pmt_crashlog_disabled(struct intel_pmt_entry *entry)
+{
+	u32 control = readl(entry->disc_table + CONTROL_OFFSET);
+
+	/* return current value of the crashlog disabled flag */
+	return !!(control & CRASHLOG_FLAG_DISABLE);
+}
+
+static bool pmt_crashlog_supported(struct intel_pmt_entry *entry)
+{
+	u32 discovery_header = readl(entry->disc_table + CONTROL_OFFSET);
+	u32 crash_type, version;
+
+	crash_type = GET_TYPE(discovery_header);
+	version = GET_VERSION(discovery_header);
+
+	/*
+	 * Currently we only recognize OOBMSM version 0 devices.
+	 * We can ignore all other crashlog devices in the system.
+	 */
+	return crash_type == CRASH_TYPE_OOBMSM && version == 0;
+}
+
+static void pmt_crashlog_set_disable(struct intel_pmt_entry *entry,
+				     bool disable)
+{
+	u32 control = readl(entry->disc_table + CONTROL_OFFSET);
+
+	/* clear trigger bits so we are only modifying disable flag */
+	control &= ~CRASHLOG_FLAG_TRIGGER_MASK;
+
+	if (disable)
+		control |= CRASHLOG_FLAG_DISABLE;
+	else
+		control &= ~CRASHLOG_FLAG_DISABLE;
+
+	writel(control, entry->disc_table + CONTROL_OFFSET);
+}
+
+static void pmt_crashlog_set_clear(struct intel_pmt_entry *entry)
+{
+	u32 control = readl(entry->disc_table + CONTROL_OFFSET);
+
+	control &= ~CRASHLOG_FLAG_TRIGGER_MASK;
+	control |= CRASHLOG_FLAG_TRIGGER_CLEAR;
+
+	writel(control, entry->disc_table + CONTROL_OFFSET);
+}
+
+static void pmt_crashlog_set_execute(struct intel_pmt_entry *entry)
+{
+	u32 control = readl(entry->disc_table + CONTROL_OFFSET);
+
+	control &= ~CRASHLOG_FLAG_TRIGGER_MASK;
+	control |= CRASHLOG_FLAG_TRIGGER_EXECUTE;
+
+	writel(control, entry->disc_table + CONTROL_OFFSET);
+}
+
+/*
+ * sysfs
+ */
+static ssize_t
+enable_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct intel_pmt_entry *entry = dev_get_drvdata(dev);
+	int enabled = !pmt_crashlog_disabled(entry);
+
+	return sprintf(buf, "%d\n", enabled);
+}
+
+static ssize_t
+enable_store(struct device *dev, struct device_attribute *attr,
+	    const char *buf, size_t count)
+{
+	struct crashlog_entry *entry;
+	bool enabled;
+	int result;
+
+	entry = dev_get_drvdata(dev);
+
+	result = kstrtobool(buf, &enabled);
+	if (result)
+		return result;
+
+	mutex_lock(&entry->control_mutex);
+	pmt_crashlog_set_disable(&entry->entry, !enabled);
+	mutex_unlock(&entry->control_mutex);
+
+	return count;
+}
+static DEVICE_ATTR_RW(enable);
+
+static ssize_t
+trigger_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct intel_pmt_entry *entry;
+	int trigger;
+
+	entry = dev_get_drvdata(dev);
+	trigger = pmt_crashlog_complete(entry);
+
+	return sprintf(buf, "%d\n", trigger);
+}
+
+static ssize_t
+trigger_store(struct device *dev, struct device_attribute *attr,
+	    const char *buf, size_t count)
+{
+	struct crashlog_entry *entry;
+	bool trigger;
+	int result;
+
+	entry = dev_get_drvdata(dev);
+
+	result = kstrtobool(buf, &trigger);
+	if (result)
+		return result;
+
+	mutex_lock(&entry->control_mutex);
+
+	if (!trigger) {
+		pmt_crashlog_set_clear(&entry->entry);
+	} else if (pmt_crashlog_complete(&entry->entry)) {
+		/* we cannot trigger a new crash if one is still pending */
+		result = -EEXIST;
+		goto err;
+	} else if (pmt_crashlog_disabled(&entry->entry)) {
+		/* if device is currently disabled, return busy */
+		result = -EBUSY;
+		goto err;
+	} else {
+		pmt_crashlog_set_execute(&entry->entry);
+	}
+
+	result = count;
+err:
+	mutex_unlock(&entry->control_mutex);
+	return result;
+}
+static DEVICE_ATTR_RW(trigger);
+
+static struct attribute *pmt_crashlog_attrs[] = {
+	&dev_attr_enable.attr,
+	&dev_attr_trigger.attr,
+	NULL
+};
+
+static struct attribute_group pmt_crashlog_group = {
+	.attrs	= pmt_crashlog_attrs,
+};
+
+static int pmt_crashlog_header_decode(struct intel_pmt_entry *entry,
+				      struct intel_pmt_header *header,
+				      struct device *dev)
+{
+	void __iomem *disc_table = entry->disc_table;
+	struct crashlog_entry *crashlog;
+
+	if (!pmt_crashlog_supported(entry))
+		return 1;
+
+	/* initialize control mutex */
+	crashlog = container_of(entry, struct crashlog_entry, entry);
+	mutex_init(&crashlog->control_mutex);
+
+	header->access_type = GET_ACCESS(readl(disc_table));
+	header->guid = readl(disc_table + GUID_OFFSET);
+	header->base_offset = readl(disc_table + BASE_OFFSET);
+
+	/* Size is measured in DWORDS, but accessor returns bytes */
+	header->size = GET_SIZE(readl(disc_table + SIZE_OFFSET));
+
+	return 0;
+}
+
+static DEFINE_XARRAY_ALLOC(crashlog_array);
+static struct intel_pmt_namespace pmt_crashlog_ns = {
+	.name = "crashlog",
+	.xa = &crashlog_array,
+	.attr_grp = &pmt_crashlog_group,
+	.pmt_header_decode = pmt_crashlog_header_decode,
+};
+
+/*
+ * initialization
+ */
+static int pmt_crashlog_remove(struct platform_device *pdev)
+{
+	struct pmt_crashlog_priv *priv = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = 0; i < priv->num_entries; i++)
+		intel_pmt_dev_destroy(&priv->entry[i].entry, &pmt_crashlog_ns);
+
+	return 0;
+}
+
+static int pmt_crashlog_probe(struct platform_device *pdev)
+{
+	struct pmt_crashlog_priv *priv;
+	size_t size;
+	int i, ret;
+
+	size = struct_size(priv, entry, pdev->num_resources);
+	priv = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, priv);
+
+	for (i = 0; i < pdev->num_resources; i++) {
+		struct intel_pmt_entry *entry = &priv->entry[i].entry;
+
+		ret = intel_pmt_dev_create(entry, &pmt_crashlog_ns, pdev, i);
+		if (ret < 0)
+			goto abort_probe;
+		if (ret)
+			continue;
+
+		priv->num_entries++;
+	}
+
+	return 0;
+abort_probe:
+	pmt_crashlog_remove(pdev);
+	return ret;
+}
+
+static struct platform_driver pmt_crashlog_driver = {
+	.driver = {
+		.name   = DRV_NAME,
+	},
+	.remove = pmt_crashlog_remove,
+	.probe  = pmt_crashlog_probe,
+};
+
+static int __init pmt_crashlog_init(void)
+{
+	return platform_driver_register(&pmt_crashlog_driver);
+}
+
+static void __exit pmt_crashlog_exit(void)
+{
+	platform_driver_unregister(&pmt_crashlog_driver);
+	xa_destroy(&crashlog_array);
+}
+
+module_init(pmt_crashlog_init);
+module_exit(pmt_crashlog_exit);
+
+MODULE_AUTHOR("Alexander Duyck <alexander.h.duyck@linux.intel.com>");
+MODULE_DESCRIPTION("Intel PMT Crashlog driver");
+MODULE_ALIAS("platform:" DRV_NAME);
+MODULE_LICENSE("GPL v2");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-03  1:31 ` [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
@ 2020-10-06 22:45   ` David E. Box
  2020-10-07  0:51     ` Bjorn Helgaas
  0 siblings, 1 reply; 20+ messages in thread
From: David E. Box @ 2020-10-06 22:45 UTC (permalink / raw)
  To: lee.jones, dvhart, andy, bhelgaas, hdegoede, alexey.budankov,
	Andy Shevchenko, rjw
  Cc: linux-kernel, platform-driver-x86, linux-pci

Hi Bjorn,

This patch has been acked and unchanged for weeks. Is it possible to
get this pulled into next? We have SIOV and CXL related work that is
using these definitions. Thanks.

David

On Fri, 2020-10-02 at 18:31 -0700, David E. Box wrote:
> Add PCIe Designated Vendor-Specific Extended Capability (DVSEC) and
> defines
> for the header offsets. 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>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> ---
>  include/uapi/linux/pci_regs.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/uapi/linux/pci_regs.h
> b/include/uapi/linux/pci_regs.h
> index f9701410d3b5..beafeee39e44 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -720,6 +720,7 @@
>  #define PCI_EXT_CAP_ID_DPC	0x1D	/* Downstream Port
> Containment */
>  #define PCI_EXT_CAP_ID_L1SS	0x1E	/* L1 PM Substates */
>  #define PCI_EXT_CAP_ID_PTM	0x1F	/* Precision Time Measurement
> */
> +#define PCI_EXT_CAP_ID_DVSEC	0x23	/* Designated Vendor-Specific 
> */
>  #define PCI_EXT_CAP_ID_DLF	0x25	/* Data Link Feature */
>  #define PCI_EXT_CAP_ID_PL_16GT	0x26	/* Physical Layer
> 16.0 GT/s */
>  #define PCI_EXT_CAP_ID_MAX	PCI_EXT_CAP_ID_PL_16GT
> @@ -1062,6 +1063,10 @@
>  #define  PCI_L1SS_CTL1_LTR_L12_TH_SCALE	0xe0000000  /*
> LTR_L1.2_THRESHOLD_Scale */
>  #define PCI_L1SS_CTL2		0x0c	/* Control 2 Register
> */
>  
> +/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */
> +#define PCI_DVSEC_HEADER1		0x4 /* Designated Vendor-
> Specific Header1 */
> +#define PCI_DVSEC_HEADER2		0x8 /* Designated Vendor-
> Specific Header2 */
> +
>  /* Data Link Feature */
>  #define PCI_DLF_CAP		0x04	/* Capabilities Register */
>  #define  PCI_DLF_EXCHANGE_ENABLE	0x80000000  /* Data Link
> Feature Exchange Enable */


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-06 22:45   ` David E. Box
@ 2020-10-07  0:51     ` Bjorn Helgaas
  2020-10-07  1:47       ` David E. Box
  0 siblings, 1 reply; 20+ messages in thread
From: Bjorn Helgaas @ 2020-10-07  0:51 UTC (permalink / raw)
  To: David E. Box
  Cc: lee.jones, dvhart, andy, bhelgaas, hdegoede, alexey.budankov,
	Andy Shevchenko, rjw, linux-kernel, platform-driver-x86,
	linux-pci

On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
> Hi Bjorn,
> 
> This patch has been acked and unchanged for weeks. Is it possible to
> get this pulled into next? We have SIOV and CXL related work that is
> using these definitions. Thanks.

I acked it because I expected you to merge it along with the rest of
the series.

I guess I could merge this patch via the PCI tree if you really want,
but that ends up being a hassle because we have to worry about which
order things get merged to Linus' tree.  Better if the whole series is
merged via the same tree.

> On Fri, 2020-10-02 at 18:31 -0700, David E. Box wrote:
> > Add PCIe Designated Vendor-Specific Extended Capability (DVSEC) and
> > defines
> > for the header offsets. 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>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > ---
> >  include/uapi/linux/pci_regs.h | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/include/uapi/linux/pci_regs.h
> > b/include/uapi/linux/pci_regs.h
> > index f9701410d3b5..beafeee39e44 100644
> > --- a/include/uapi/linux/pci_regs.h
> > +++ b/include/uapi/linux/pci_regs.h
> > @@ -720,6 +720,7 @@
> >  #define PCI_EXT_CAP_ID_DPC	0x1D	/* Downstream Port
> > Containment */
> >  #define PCI_EXT_CAP_ID_L1SS	0x1E	/* L1 PM Substates */
> >  #define PCI_EXT_CAP_ID_PTM	0x1F	/* Precision Time Measurement
> > */
> > +#define PCI_EXT_CAP_ID_DVSEC	0x23	/* Designated Vendor-Specific 
> > */
> >  #define PCI_EXT_CAP_ID_DLF	0x25	/* Data Link Feature */
> >  #define PCI_EXT_CAP_ID_PL_16GT	0x26	/* Physical Layer
> > 16.0 GT/s */
> >  #define PCI_EXT_CAP_ID_MAX	PCI_EXT_CAP_ID_PL_16GT
> > @@ -1062,6 +1063,10 @@
> >  #define  PCI_L1SS_CTL1_LTR_L12_TH_SCALE	0xe0000000  /*
> > LTR_L1.2_THRESHOLD_Scale */
> >  #define PCI_L1SS_CTL2		0x0c	/* Control 2 Register
> > */
> >  
> > +/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */
> > +#define PCI_DVSEC_HEADER1		0x4 /* Designated Vendor-
> > Specific Header1 */
> > +#define PCI_DVSEC_HEADER2		0x8 /* Designated Vendor-
> > Specific Header2 */
> > +
> >  /* Data Link Feature */
> >  #define PCI_DLF_CAP		0x04	/* Capabilities Register */
> >  #define  PCI_DLF_EXCHANGE_ENABLE	0x80000000  /* Data Link
> > Feature Exchange Enable */
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-07  0:51     ` Bjorn Helgaas
@ 2020-10-07  1:47       ` David E. Box
  2020-10-07  6:54         ` Lee Jones
  0 siblings, 1 reply; 20+ messages in thread
From: David E. Box @ 2020-10-07  1:47 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: lee.jones, dvhart, andy, bhelgaas, hdegoede, alexey.budankov,
	Andy Shevchenko, rjw, linux-kernel, platform-driver-x86,
	linux-pci

On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote:
> On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
> > Hi Bjorn,
> > 
> > This patch has been acked and unchanged for weeks. Is it possible
> > to
> > get this pulled into next? We have SIOV and CXL related work that
> > is
> > using these definitions. Thanks.
> 
> I acked it because I expected you to merge it along with the rest of
> the series.
> 
> I guess I could merge this patch via the PCI tree if you really want,
> but that ends up being a hassle because we have to worry about which
> order things get merged to Linus' tree.  Better if the whole series
> is
> merged via the same tree.

Agreed. The hope is that this series is ready for the next merge window
but no ack yet on V8. And if the series does not make it I'd like this
patch to at least get in.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-07  1:47       ` David E. Box
@ 2020-10-07  6:54         ` Lee Jones
  2020-10-07 21:36           ` Hans de Goede
  0 siblings, 1 reply; 20+ messages in thread
From: Lee Jones @ 2020-10-07  6:54 UTC (permalink / raw)
  To: David E. Box
  Cc: Bjorn Helgaas, dvhart, andy, bhelgaas, hdegoede, alexey.budankov,
	Andy Shevchenko, rjw, linux-kernel, platform-driver-x86,
	linux-pci

On Tue, 06 Oct 2020, David E. Box wrote:

> On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote:
> > On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
> > > Hi Bjorn,
> > > 
> > > This patch has been acked and unchanged for weeks. Is it possible
> > > to
> > > get this pulled into next? We have SIOV and CXL related work that
> > > is
> > > using these definitions. Thanks.
> > 
> > I acked it because I expected you to merge it along with the rest of
> > the series.
> > 
> > I guess I could merge this patch via the PCI tree if you really want,
> > but that ends up being a hassle because we have to worry about which
> > order things get merged to Linus' tree.  Better if the whole series
> > is
> > merged via the same tree.
> 
> Agreed. The hope is that this series is ready for the next merge window
> but no ack yet on V8. And if the series does not make it I'd like this
> patch to at least get in.

If Bjorn is happy to take this patch so late in the release cycle then
please go ahead.  The other patches are due for v5.11.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
  2020-10-03  1:31 ` [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
@ 2020-10-07  6:57   ` Lee Jones
  2020-10-07 16:10     ` David E. Box
  2020-11-10 10:39   ` Geert Uytterhoeven
  1 sibling, 1 reply; 20+ messages in thread
From: Lee Jones @ 2020-10-07  6:57 UTC (permalink / raw)
  To: David E. Box
  Cc: dvhart, andy, bhelgaas, hdegoede, alexey.budankov, linux-kernel,
	platform-driver-x86, linux-pci, Alexander Duyck, Andy Shevchenko

On Fri, 02 Oct 2020, David E. Box wrote:

> Intel Platform Monitoring Technology (PMT) is an architecture for
> enumerating and accessing hardware monitoring facilities. PMT supports
> multiple types of monitoring capabilities. This driver creates platform
> devices for each type so that they may be managed by capability specific
> drivers (to be introduced). Capabilities are discovered using PCIe DVSEC
> ids. Support is included for the 3 current capability types, Telemetry,
> Watcher, and Crashlog. The features are available on new Intel platforms
> starting from Tiger Lake for which support is added. This patch adds
> support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band Management
> Services Module (OOBMSM).
> 
> Also add a quirk mechanism for several early hardware differences and bugs.
> For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
> capabilities since they will not be compatible with future product. Also,
> fix use a quirk to fix the discovery table offset.
> 
> Co-developed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> ---
>  MAINTAINERS             |   5 +
>  drivers/mfd/Kconfig     |  10 ++
>  drivers/mfd/Makefile    |   1 +
>  drivers/mfd/intel_pmt.c | 226 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 242 insertions(+)
>  create mode 100644 drivers/mfd/intel_pmt.c

I Acked this back in August.

Any reason why you didn't carry it forward?

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
  2020-10-07  6:57   ` Lee Jones
@ 2020-10-07 16:10     ` David E. Box
  2020-10-08  7:32       ` Lee Jones
  0 siblings, 1 reply; 20+ messages in thread
From: David E. Box @ 2020-10-07 16:10 UTC (permalink / raw)
  To: Lee Jones
  Cc: dvhart, andy, bhelgaas, hdegoede, alexey.budankov, linux-kernel,
	platform-driver-x86, linux-pci, Alexander Duyck, Andy Shevchenko

On Wed, 2020-10-07 at 07:57 +0100, Lee Jones wrote:
> On Fri, 02 Oct 2020, David E. Box wrote:
> 
> > Intel Platform Monitoring Technology (PMT) is an architecture for
> > enumerating and accessing hardware monitoring facilities. PMT
> > supports
> > multiple types of monitoring capabilities. This driver creates
> > platform
> > devices for each type so that they may be managed by capability
> > specific
> > drivers (to be introduced). Capabilities are discovered using PCIe
> > DVSEC
> > ids. Support is included for the 3 current capability types,
> > Telemetry,
> > Watcher, and Crashlog. The features are available on new Intel
> > platforms
> > starting from Tiger Lake for which support is added. This patch
> > adds
> > support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band
> > Management
> > Services Module (OOBMSM).
> > 
> > Also add a quirk mechanism for several early hardware differences
> > and bugs.
> > For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
> > capabilities since they will not be compatible with future product.
> > Also,
> > fix use a quirk to fix the discovery table offset.
> > 
> > Co-developed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com
> > >
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > ---
> >  MAINTAINERS             |   5 +
> >  drivers/mfd/Kconfig     |  10 ++
> >  drivers/mfd/Makefile    |   1 +
> >  drivers/mfd/intel_pmt.c | 226
> > ++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 242 insertions(+)
> >  create mode 100644 drivers/mfd/intel_pmt.c
> 
> I Acked this back in August.
> 
> Any reason why you didn't carry it forward?

So that you could review changes made after the Ack. You did and you
requested fixups which were made. Please let me know if this is not
preferred. Thanks.

David


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-07  6:54         ` Lee Jones
@ 2020-10-07 21:36           ` Hans de Goede
  2020-10-08  7:29             ` Lee Jones
  0 siblings, 1 reply; 20+ messages in thread
From: Hans de Goede @ 2020-10-07 21:36 UTC (permalink / raw)
  To: Lee Jones, David E. Box
  Cc: Bjorn Helgaas, dvhart, andy, bhelgaas, alexey.budankov,
	Andy Shevchenko, rjw, linux-kernel, platform-driver-x86,
	linux-pci

Hi,

On 10/7/20 8:54 AM, Lee Jones wrote:
> On Tue, 06 Oct 2020, David E. Box wrote:
> 
>> On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote:
>>> On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
>>>> Hi Bjorn,
>>>>
>>>> This patch has been acked and unchanged for weeks. Is it possible
>>>> to
>>>> get this pulled into next? We have SIOV and CXL related work that
>>>> is
>>>> using these definitions. Thanks.
>>>
>>> I acked it because I expected you to merge it along with the rest of
>>> the series.
>>>
>>> I guess I could merge this patch via the PCI tree if you really want,
>>> but that ends up being a hassle because we have to worry about which
>>> order things get merged to Linus' tree.  Better if the whole series
>>> is
>>> merged via the same tree.
>>
>> Agreed. The hope is that this series is ready for the next merge window
>> but no ack yet on V8. And if the series does not make it I'd like this
>> patch to at least get in.
> 
> If Bjorn is happy to take this patch so late in the release cycle then
> please go ahead.  The other patches are due for v5.11.

I agree (that the other patches are for 5.11) talking about merging
this series patch 2 is a mfd patch and patches 3-5 are drivers/platform/x86
patches.

Lee, FYI I'm taking over drivers/platform/x86 maintainership from Andy.

I suggest that we merge the entire series through a single tree
(with acks or reviewed-by-s from the other maintainer)
either through the mfd tree or through the drivers/platform/x86
tree. Since most changes are in drivers/platform/x86 the latter
probably makes more sense, but either way works for me.
So how would you like to proceed with this series ?

Regards,

Hans


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-07 21:36           ` Hans de Goede
@ 2020-10-08  7:29             ` Lee Jones
  2020-10-08 11:13               ` Hans de Goede
  0 siblings, 1 reply; 20+ messages in thread
From: Lee Jones @ 2020-10-08  7:29 UTC (permalink / raw)
  To: Hans de Goede
  Cc: David E. Box, Bjorn Helgaas, dvhart, andy, bhelgaas,
	alexey.budankov, Andy Shevchenko, rjw, linux-kernel,
	platform-driver-x86, linux-pci

On Wed, 07 Oct 2020, Hans de Goede wrote:

> Hi,
> 
> On 10/7/20 8:54 AM, Lee Jones wrote:
> > On Tue, 06 Oct 2020, David E. Box wrote:
> > 
> > > On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote:
> > > > On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
> > > > > Hi Bjorn,
> > > > > 
> > > > > This patch has been acked and unchanged for weeks. Is it possible
> > > > > to
> > > > > get this pulled into next? We have SIOV and CXL related work that
> > > > > is
> > > > > using these definitions. Thanks.
> > > > 
> > > > I acked it because I expected you to merge it along with the rest of
> > > > the series.
> > > > 
> > > > I guess I could merge this patch via the PCI tree if you really want,
> > > > but that ends up being a hassle because we have to worry about which
> > > > order things get merged to Linus' tree.  Better if the whole series
> > > > is
> > > > merged via the same tree.
> > > 
> > > Agreed. The hope is that this series is ready for the next merge window
> > > but no ack yet on V8. And if the series does not make it I'd like this
> > > patch to at least get in.
> > 
> > If Bjorn is happy to take this patch so late in the release cycle then
> > please go ahead.  The other patches are due for v5.11.
> 
> I agree (that the other patches are for 5.11) talking about merging
> this series patch 2 is a mfd patch and patches 3-5 are drivers/platform/x86
> patches.
> 
> Lee, FYI I'm taking over drivers/platform/x86 maintainership from Andy.

Congratulations, Hans.

> I suggest that we merge the entire series through a single tree
> (with acks or reviewed-by-s from the other maintainer)
> either through the mfd tree or through the drivers/platform/x86
> tree. Since most changes are in drivers/platform/x86 the latter
> probably makes more sense, but either way works for me.
> So how would you like to proceed with this series ?

I'm happy either way, but bear in mind that, due to the intrinsic
heterogeneous nature of MFD, I already have infrastructure to easily
apply (and send pull-requests for) cross-subsystem patch-sets.

If however, you decide that you'd really like to take the set, that's
also fine but I will require a pull-request from an immutable branch.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
  2020-10-07 16:10     ` David E. Box
@ 2020-10-08  7:32       ` Lee Jones
  0 siblings, 0 replies; 20+ messages in thread
From: Lee Jones @ 2020-10-08  7:32 UTC (permalink / raw)
  To: David E. Box
  Cc: dvhart, andy, bhelgaas, hdegoede, alexey.budankov, linux-kernel,
	platform-driver-x86, linux-pci, Alexander Duyck, Andy Shevchenko

On Wed, 07 Oct 2020, David E. Box wrote:

> On Wed, 2020-10-07 at 07:57 +0100, Lee Jones wrote:
> > On Fri, 02 Oct 2020, David E. Box wrote:
> > 
> > > Intel Platform Monitoring Technology (PMT) is an architecture for
> > > enumerating and accessing hardware monitoring facilities. PMT
> > > supports
> > > multiple types of monitoring capabilities. This driver creates
> > > platform
> > > devices for each type so that they may be managed by capability
> > > specific
> > > drivers (to be introduced). Capabilities are discovered using PCIe
> > > DVSEC
> > > ids. Support is included for the 3 current capability types,
> > > Telemetry,
> > > Watcher, and Crashlog. The features are available on new Intel
> > > platforms
> > > starting from Tiger Lake for which support is added. This patch
> > > adds
> > > support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band
> > > Management
> > > Services Module (OOBMSM).
> > > 
> > > Also add a quirk mechanism for several early hardware differences
> > > and bugs.
> > > For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
> > > capabilities since they will not be compatible with future product.
> > > Also,
> > > fix use a quirk to fix the discovery table offset.
> > > 
> > > Co-developed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com
> > > >
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > ---
> > >  MAINTAINERS             |   5 +
> > >  drivers/mfd/Kconfig     |  10 ++
> > >  drivers/mfd/Makefile    |   1 +
> > >  drivers/mfd/intel_pmt.c | 226
> > > ++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 242 insertions(+)
> > >  create mode 100644 drivers/mfd/intel_pmt.c
> > 
> > I Acked this back in August.
> > 
> > Any reason why you didn't carry it forward?
> 
> So that you could review changes made after the Ack.
> Please let me know if this is not preferred. Thanks.

No, that is the correct way to do things (see below).

> You did and you requested fixups which were made.

Keeping the status of each and every patch-set currently in my inbox
would be a very difficult task.

This is why I recommend patch-level changelogs (just below the '---'
marker).

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability
  2020-10-08  7:29             ` Lee Jones
@ 2020-10-08 11:13               ` Hans de Goede
  0 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2020-10-08 11:13 UTC (permalink / raw)
  To: Lee Jones
  Cc: David E. Box, Bjorn Helgaas, dvhart, andy, bhelgaas,
	alexey.budankov, Andy Shevchenko, rjw, linux-kernel,
	platform-driver-x86, linux-pci

Hi,

On 10/8/20 9:29 AM, Lee Jones wrote:
> On Wed, 07 Oct 2020, Hans de Goede wrote:
> 
>> Hi,
>>
>> On 10/7/20 8:54 AM, Lee Jones wrote:
>>> On Tue, 06 Oct 2020, David E. Box wrote:
>>>
>>>> On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote:
>>>>> On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote:
>>>>>> Hi Bjorn,
>>>>>>
>>>>>> This patch has been acked and unchanged for weeks. Is it possible
>>>>>> to
>>>>>> get this pulled into next? We have SIOV and CXL related work that
>>>>>> is
>>>>>> using these definitions. Thanks.
>>>>>
>>>>> I acked it because I expected you to merge it along with the rest of
>>>>> the series.
>>>>>
>>>>> I guess I could merge this patch via the PCI tree if you really want,
>>>>> but that ends up being a hassle because we have to worry about which
>>>>> order things get merged to Linus' tree.  Better if the whole series
>>>>> is
>>>>> merged via the same tree.
>>>>
>>>> Agreed. The hope is that this series is ready for the next merge window
>>>> but no ack yet on V8. And if the series does not make it I'd like this
>>>> patch to at least get in.
>>>
>>> If Bjorn is happy to take this patch so late in the release cycle then
>>> please go ahead.  The other patches are due for v5.11.
>>
>> I agree (that the other patches are for 5.11) talking about merging
>> this series patch 2 is a mfd patch and patches 3-5 are drivers/platform/x86
>> patches.
>>
>> Lee, FYI I'm taking over drivers/platform/x86 maintainership from Andy.
> 
> Congratulations, Hans.
> 
>> I suggest that we merge the entire series through a single tree
>> (with acks or reviewed-by-s from the other maintainer)
>> either through the mfd tree or through the drivers/platform/x86
>> tree. Since most changes are in drivers/platform/x86 the latter
>> probably makes more sense, but either way works for me.
>> So how would you like to proceed with this series ?
> 
> I'm happy either way, but bear in mind that, due to the intrinsic
> heterogeneous nature of MFD, I already have infrastructure to easily
> apply (and send pull-requests for) cross-subsystem patch-sets.

Ok, you applying the entire series to the mfd tree is fine with me.

I'll try to review the entire series next week and then we'll see
from there.

Regards,

Hans


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 0/5] Intel Platform Monitoring Technology
  2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
                   ` (4 preceding siblings ...)
  2020-10-03  1:31 ` [PATCH V8 5/5] platform/x86: Intel PMT Crashlog " David E. Box
@ 2020-10-27 11:28 ` Hans de Goede
  2020-10-29  1:50   ` David E. Box
  5 siblings, 1 reply; 20+ messages in thread
From: Hans de Goede @ 2020-10-27 11:28 UTC (permalink / raw)
  To: David E. Box, lee.jones, dvhart, andy, bhelgaas, alexey.budankov
  Cc: linux-kernel, platform-driver-x86, linux-pci

Hi,

On 10/3/20 3:31 AM, David E. Box wrote:
> Intel Platform Monitoring Technology (PMT) is an architecture for
> enumerating and accessing hardware monitoring capabilities on a device.
> With customers increasingly asking for hardware telemetry, engineers not
> only have to figure out how to measure and collect data, but also how to
> deliver it and make it discoverable. The latter may be through some device
> specific method requiring device specific tools to collect the data. This
> in turn requires customers to manage a suite of different tools in order to
> collect the differing assortment of monitoring data on their systems.  Even
> when such information can be provided in kernel drivers, they may require
> constant maintenance to update register mappings as they change with
> firmware updates and new versions of hardware. PMT provides a solution for
> discovering and reading telemetry from a device through a hardware agnostic
> framework that allows for updates to systems without requiring patches to
> the kernel or software tools.
> 
> PMT defines several capabilities to support collecting monitoring data from
> hardware. All are discoverable as separate instances of the PCIE Designated
> Vendor extended capability (DVSEC) with the Intel vendor code. The DVSEC ID
> field uniquely identifies the capability. Each DVSEC also provides a BAR
> offset to a header that defines capability-specific attributes, including
> GUID, feature type, offset and length, as well as configuration settings
> where applicable. The GUID uniquely identifies the register space of any
> monitor data exposed by the capability. The GUID is associated with an XML
> file from the vendor that describes the mapping of the register space along
> with properties of the monitor data. This allows vendors to perform
> firmware updates that can change the mapping (e.g. add new metrics) without
> requiring any changes to drivers or software tools. The new mapping is
> confirmed by an updated GUID, read from the hardware, which software uses
> with a new XML.
> 
> The current capabilities defined by PMT are Telemetry, Watcher, and
> Crashlog.  The Telemetry capability provides access to a continuous block
> of read only data. The Watcher capability provides access to hardware
> sampling and tracing features. Crashlog provides access to device crash
> dumps.  While there is some relationship between capabilities (Watcher can
> be configured to sample from the Telemetry data set) each exists as stand
> alone features with no dependency on any other. The design therefore splits
> them into individual, capability specific drivers. MFD is used to create
> platform devices for each capability so that they may be managed by their
> own driver. The PMT architecture is (for the most part) agnostic to the
> type of device it can collect from. Software can determine which devices
> support a PMT feature by searching through each device node entry in the
> sysfs class folder. It can additionally determine if a particular device
> supports a PMT feature by checking for a PMT class folder in the device
> folder.
> 
> This patch set provides support for the PMT framework, along with support
> for Telemetry on Tiger Lake.

The entire series looks good to me, so you may add my:

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

To the entire series.

Lee, in the discussion about previous versions you indicated that you
would be happy to merge the entire series through the MFD tree.

From my pov this is ready for merging, so if you can pick up the entire
series and then provide me with an immutable branch to merge into the
pdx86 tree that would be great.

Regards,

Hans


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 0/5] Intel Platform Monitoring Technology
  2020-10-27 11:28 ` [PATCH V8 0/5] Intel Platform Monitoring Technology Hans de Goede
@ 2020-10-29  1:50   ` David E. Box
  0 siblings, 0 replies; 20+ messages in thread
From: David E. Box @ 2020-10-29  1:50 UTC (permalink / raw)
  To: Hans de Goede, lee.jones, dvhart, andy, bhelgaas, alexey.budankov
  Cc: linux-kernel, platform-driver-x86, linux-pci

On Tue, 2020-10-27 at 12:28 +0100, Hans de Goede wrote:
> Hi,
> 
> On 10/3/20 3:31 AM, David E. Box wrote:
> > Intel Platform Monitoring Technology (PMT) is an architecture for
> > enumerating and accessing hardware monitoring capabilities on a
> > device.
> > With customers increasingly asking for hardware telemetry,
> > engineers not
> > only have to figure out how to measure and collect data, but also
> > how to
> > deliver it and make it discoverable. The latter may be through some
> > device
> > specific method requiring device specific tools to collect the
> > data. This
> > in turn requires customers to manage a suite of different tools in
> > order to
> > collect the differing assortment of monitoring data on their
> > systems.  Even
> > when such information can be provided in kernel drivers, they may
> > require
> > constant maintenance to update register mappings as they change
> > with
> > firmware updates and new versions of hardware. PMT provides a
> > solution for
> > discovering and reading telemetry from a device through a hardware
> > agnostic
> > framework that allows for updates to systems without requiring
> > patches to
> > the kernel or software tools.
> > 
> > PMT defines several capabilities to support collecting monitoring
> > data from
> > hardware. All are discoverable as separate instances of the PCIE
> > Designated
> > Vendor extended capability (DVSEC) with the Intel vendor code. The
> > DVSEC ID
> > field uniquely identifies the capability. Each DVSEC also provides
> > a BAR
> > offset to a header that defines capability-specific attributes,
> > including
> > GUID, feature type, offset and length, as well as configuration
> > settings
> > where applicable. The GUID uniquely identifies the register space
> > of any
> > monitor data exposed by the capability. The GUID is associated with
> > an XML
> > file from the vendor that describes the mapping of the register
> > space along
> > with properties of the monitor data. This allows vendors to perform
> > firmware updates that can change the mapping (e.g. add new metrics)
> > without
> > requiring any changes to drivers or software tools. The new mapping
> > is
> > confirmed by an updated GUID, read from the hardware, which
> > software uses
> > with a new XML.
> > 
> > The current capabilities defined by PMT are Telemetry, Watcher, and
> > Crashlog.  The Telemetry capability provides access to a continuous
> > block
> > of read only data. The Watcher capability provides access to
> > hardware
> > sampling and tracing features. Crashlog provides access to device
> > crash
> > dumps.  While there is some relationship between capabilities
> > (Watcher can
> > be configured to sample from the Telemetry data set) each exists as
> > stand
> > alone features with no dependency on any other. The design
> > therefore splits
> > them into individual, capability specific drivers. MFD is used to
> > create
> > platform devices for each capability so that they may be managed by
> > their
> > own driver. The PMT architecture is (for the most part) agnostic to
> > the
> > type of device it can collect from. Software can determine which
> > devices
> > support a PMT feature by searching through each device node entry
> > in the
> > sysfs class folder. It can additionally determine if a particular
> > device
> > supports a PMT feature by checking for a PMT class folder in the
> > device
> > folder.
> > 
> > This patch set provides support for the PMT framework, along with
> > support
> > for Telemetry on Tiger Lake.
> 
> The entire series looks good to me, so you may add my:
> 
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Thanks. I did send out a V9 after rebasing and noticing that I
accidentally dropped a change in the MFD driver between V7 and V8. This
was added back. I also took the opportunity to get rid of a nuisance
dev_warn.

David


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
  2020-10-03  1:31 ` [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
  2020-10-07  6:57   ` Lee Jones
@ 2020-11-10 10:39   ` Geert Uytterhoeven
  2020-11-10 18:06     ` David E. Box
  1 sibling, 1 reply; 20+ messages in thread
From: Geert Uytterhoeven @ 2020-11-10 10:39 UTC (permalink / raw)
  To: David E. Box
  Cc: Lee Jones, Darren Hart, andy, Bjorn Helgaas, Hans de Goede,
	alexey.budankov, Linux Kernel Mailing List, platform-driver-x86,
	linux-pci, Alexander Duyck, Andy Shevchenko

Hi David,

On Sat, Oct 3, 2020 at 3:32 AM David E. Box <david.e.box@linux.intel.com> wrote:
> Intel Platform Monitoring Technology (PMT) is an architecture for
> enumerating and accessing hardware monitoring facilities. PMT supports
> multiple types of monitoring capabilities. This driver creates platform
> devices for each type so that they may be managed by capability specific
> drivers (to be introduced). Capabilities are discovered using PCIe DVSEC
> ids. Support is included for the 3 current capability types, Telemetry,
> Watcher, and Crashlog. The features are available on new Intel platforms
> starting from Tiger Lake for which support is added. This patch adds
> support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band Management
> Services Module (OOBMSM).
>
> Also add a quirk mechanism for several early hardware differences and bugs.
> For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
> capabilities since they will not be compatible with future product. Also,
> fix use a quirk to fix the discovery table offset.
>
> Co-developed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Thanks for your patch, which is now commit 4f8217d5b0ca8ace ("mfd: Intel
Platform Monitoring Technology support") in the mfd/for-mfd-next.

> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -670,6 +670,16 @@ config MFD_INTEL_PMC_BXT
>           Register and P-unit access. In addition this creates devices
>           for iTCO watchdog and telemetry that are part of the PMC.
>
> +config MFD_INTEL_PMT
> +       tristate "Intel Platform Monitoring Technology (PMT) support"
> +       depends on PCI

Does this need a "depend on X86 || COMPILE_TEST", to prevent the
question from showing up on platforms where the PMT cannot be present?

I see the TGL and ADL PCI IDs are also referenced from
drivers/platform/x86/intel_pmt_telemetry.c, which suggests this is X86-only.
Perhaps the OOBMSM is a PCI device that can be used on non-X86 platforms?

> +       select MFD_CORE
> +       help
> +         The Intel Platform Monitoring Technology (PMT) is an interface that
> +         provides access to hardware monitor registers. This driver supports
> +         Telemetry, Watcher, and Crashlog PMT capabilities/devices for
> +         platforms starting from Tiger Lake.
> +

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
  2020-11-10 10:39   ` Geert Uytterhoeven
@ 2020-11-10 18:06     ` David E. Box
  0 siblings, 0 replies; 20+ messages in thread
From: David E. Box @ 2020-11-10 18:06 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Lee Jones, Darren Hart, andy, Bjorn Helgaas, Hans de Goede,
	alexey.budankov, Linux Kernel Mailing List, platform-driver-x86,
	linux-pci, Andy Shevchenko

Hi Geert,

On Tue, 2020-11-10 at 11:39 +0100, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Sat, Oct 3, 2020 at 3:32 AM David E. Box <
> david.e.box@linux.intel.com> wrote:
> > Intel Platform Monitoring Technology (PMT) is an architecture for
> > enumerating and accessing hardware monitoring facilities. PMT
> > supports
> > multiple types of monitoring capabilities. This driver creates
> > platform
> > devices for each type so that they may be managed by capability
> > specific
> > drivers (to be introduced). Capabilities are discovered using PCIe
> > DVSEC
> > ids. Support is included for the 3 current capability types,
> > Telemetry,
> > Watcher, and Crashlog. The features are available on new Intel
> > platforms
> > starting from Tiger Lake for which support is added. This patch
> > adds
> > support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band
> > Management
> > Services Module (OOBMSM).
> > 
> > Also add a quirk mechanism for several early hardware differences
> > and bugs.
> > For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
> > capabilities since they will not be compatible with future product.
> > Also,
> > fix use a quirk to fix the discovery table offset.
> > 
> > Co-developed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com
> > >
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> 
> Thanks for your patch, which is now commit 4f8217d5b0ca8ace ("mfd:
> Intel
> Platform Monitoring Technology support") in the mfd/for-mfd-next.
> 
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -670,6 +670,16 @@ config MFD_INTEL_PMC_BXT
> >           Register and P-unit access. In addition this creates
> > devices
> >           for iTCO watchdog and telemetry that are part of the PMC.
> > 
> > +config MFD_INTEL_PMT
> > +       tristate "Intel Platform Monitoring Technology (PMT)
> > support"
> > +       depends on PCI
> 
> Does this need a "depend on X86 || COMPILE_TEST", to prevent the
> question from showing up on platforms where the PMT cannot be
> present?

Though not currently available on non X86 hardware it is not
restricted. The use of PCIE Designated Vendor Specific Capability
(DVSEC) was to specifically allow use of this IP by other vendors.

> 
> I see the TGL and ADL PCI IDs are also referenced from
> drivers/platform/x86/intel_pmt_telemetry.c, which suggests this is
> X86-only.
> Perhaps the OOBMSM is a PCI device that can be used on non-X86
> platforms?

TGL and AGL are only referenced in this driver because they require
quirks.

Thanks

David


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2020-11-10 18:07 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
2020-10-03  1:31 ` [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
2020-10-06 22:45   ` David E. Box
2020-10-07  0:51     ` Bjorn Helgaas
2020-10-07  1:47       ` David E. Box
2020-10-07  6:54         ` Lee Jones
2020-10-07 21:36           ` Hans de Goede
2020-10-08  7:29             ` Lee Jones
2020-10-08 11:13               ` Hans de Goede
2020-10-03  1:31 ` [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
2020-10-07  6:57   ` Lee Jones
2020-10-07 16:10     ` David E. Box
2020-10-08  7:32       ` Lee Jones
2020-11-10 10:39   ` Geert Uytterhoeven
2020-11-10 18:06     ` David E. Box
2020-10-03  1:31 ` [PATCH V8 3/5] platform/x86: Intel PMT class driver David E. Box
2020-10-03  1:31 ` [PATCH V8 4/5] platform/x86: Intel PMT Telemetry capability driver David E. Box
2020-10-03  1:31 ` [PATCH V8 5/5] platform/x86: Intel PMT Crashlog " David E. Box
2020-10-27 11:28 ` [PATCH V8 0/5] Intel Platform Monitoring Technology Hans de Goede
2020-10-29  1:50   ` David E. Box

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).