[PATCH v2 0/5] Introduce Intel Elkhart Lake PSE TIO

[PATCH v2 0/5] Introduce Intel Elkhart Lake PSE TIO

[Raag Jadav]

Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
devices that expose two different capabilities of GPIO and Timed I/O
as a single PCI function through shared MMIO.

This series adds MFD driver for them and extends PPS generator driver
to support initial PSE TIO functionality.

v2: Use consistent naming with Intel drivers (Andy)
    Add MFD dependency for child drivers (Andy)
    Aesthetic adjustments (Andy)
    Update tags

Raag Jadav (5):
  mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO
  gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO
  pps: generators: tio: split pps_gen_tio.h
  pps: generators: tio: move to match_data() model
  pps: generators: tio: Introduce Intel Elkhart Lake PSE TIO

 MAINTAINERS                          |   5 ++
 drivers/gpio/Kconfig                 |   2 +-
 drivers/mfd/Kconfig                  |  12 ++++
 drivers/mfd/Makefile                 |   1 +
 drivers/mfd/intel_ehl_pse_gpio.c     | 100 +++++++++++++++++++++++++++
 drivers/pps/generators/Kconfig       |   2 +-
 drivers/pps/generators/pps_gen_tio.c |  80 ++++++++++-----------
 drivers/pps/generators/pps_gen_tio.h |  67 ++++++++++++++++++
 8 files changed, 228 insertions(+), 41 deletions(-)
 create mode 100644 drivers/mfd/intel_ehl_pse_gpio.c
 create mode 100644 drivers/pps/generators/pps_gen_tio.h


base-commit: 264ff8415aed324584acc85740596f6e1df7b663
-- 
2.34.1

[PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
devices that expose two different capabilities of GPIO and Timed I/O
as a single PCI function through shared MMIO.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 MAINTAINERS                      |   5 ++
 drivers/mfd/Kconfig              |  12 ++++
 drivers/mfd/Makefile             |   1 +
 drivers/mfd/intel_ehl_pse_gpio.c | 100 +++++++++++++++++++++++++++++++
 4 files changed, 118 insertions(+)
 create mode 100644 drivers/mfd/intel_ehl_pse_gpio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d4280facbe51..9077ab11478c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11643,6 +11643,11 @@ F:	drivers/gpio/gpio-sodaville.c
 F:	drivers/gpio/gpio-tangier.c
 F:	drivers/gpio/gpio-tangier.h
 
+INTEL GPIO MFD DRIVER
+M:	Raag Jadav <raag.jadav@intel.com>
+S:	Supported
+F:	drivers/mfd/intel_ehl_pse_gpio.c
+
 INTEL GVT-g DRIVERS (Intel GPU Virtualization)
 M:	Zhenyu Wang <zhenyuw@linux.intel.com>
 M:	Zhi Wang <zhi.wang.linux@gmail.com>
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6b0682af6e32..36eac5245179 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -597,6 +597,18 @@ config MFD_HI655X_PMIC
 	help
 	  Select this option to enable Hisilicon hi655x series pmic driver.
 
+config MFD_INTEL_EHL_PSE_GPIO
+	tristate "Intel Elkhart Lake PSE GPIO MFD"
+	depends on PCI && (X86 || COMPILE_TEST)
+	select MFD_CORE
+	help
+	  This MFD provides support for GPIO and TIO that exist on Intel
+	  Elkhart Lake PSE as a single PCI device. It splits the two I/O
+	  devices to their respective I/O drivers.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called intel_ehl_pse_gpio.
+
 config MFD_INTEL_QUARK_I2C_GPIO
 	tristate "Intel Quark MFD I2C GPIO"
 	depends on PCI
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9220eaf7cf12..8f7d257856db 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -196,6 +196,7 @@ obj-$(CONFIG_MFD_TIMBERDALE)    += timberdale.o
 obj-$(CONFIG_PMIC_ADP5520)	+= adp5520.o
 obj-$(CONFIG_MFD_ADP5585)	+= adp5585.o
 obj-$(CONFIG_MFD_KEMPLD)	+= kempld-core.o
+obj-$(CONFIG_MFD_INTEL_EHL_PSE_GPIO)	+= intel_ehl_pse_gpio.o
 obj-$(CONFIG_MFD_INTEL_QUARK_I2C_GPIO)	+= intel_quark_i2c_gpio.o
 obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
 obj-$(CONFIG_LPC_ICH)		+= lpc_ich.o
diff --git a/drivers/mfd/intel_ehl_pse_gpio.c b/drivers/mfd/intel_ehl_pse_gpio.c
new file mode 100644
index 000000000000..6a6ad1390a7b
--- /dev/null
+++ b/drivers/mfd/intel_ehl_pse_gpio.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel MFD driver for Elkhart Lake - Programmable Service Engine
+ * (PSE) GPIO & TIO
+ *
+ * Copyright (c) 2025 Intel Corporation
+ *
+ * Intel Elkhart Lake PSE includes two PCI devices that expose two
+ * different capabilities of GPIO and Timed I/O as a single PCI
+ * function through shared MMIO.
+ */
+
+#include <linux/array_size.h>
+#include <linux/ioport.h>
+#include <linux/mfd/core.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/stddef.h>
+
+#define PSE_GPIO_OFFSET		0x0000
+#define PSE_GPIO_SIZE		0x0134
+
+#define PSE_TIO_OFFSET		0x1000
+#define PSE_TIO_SIZE		0x06B0
+
+static struct resource ehl_pse_gpio_resources[] = {
+	DEFINE_RES_MEM(PSE_GPIO_OFFSET, PSE_GPIO_SIZE),
+	DEFINE_RES_IRQ(0),
+};
+
+static struct resource ehl_pse_tio_resources[] = {
+	DEFINE_RES_MEM(PSE_TIO_OFFSET, PSE_TIO_SIZE),
+	DEFINE_RES_IRQ(1),
+};
+
+static struct mfd_cell ehl_pse_gpio_devs[] = {
+	{
+		.name = "gpio-elkhartlake",
+		.num_resources = ARRAY_SIZE(ehl_pse_gpio_resources),
+		.resources = ehl_pse_gpio_resources,
+		.ignore_resource_conflicts = true,
+	},
+	{
+		.name = "pps-gen-tio",
+		.num_resources = ARRAY_SIZE(ehl_pse_tio_resources),
+		.resources = ehl_pse_tio_resources,
+		.ignore_resource_conflicts = true,
+	},
+};
+
+static int ehl_pse_gpio_probe(struct pci_dev *pci, const struct pci_device_id *id)
+{
+	int ret;
+
+	ret = pcim_enable_device(pci);
+	if (ret)
+		return ret;
+
+	pci_set_master(pci);
+
+	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
+	if (ret < 0)
+		return ret;
+
+	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,
+			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
+			      pci_irq_vector(pci, 0), NULL);
+	if (ret)
+		pci_free_irq_vectors(pci);
+
+	return ret;
+}
+
+static void ehl_pse_gpio_remove(struct pci_dev *pdev)
+{
+	mfd_remove_devices(&pdev->dev);
+	pci_free_irq_vectors(pdev);
+}
+
+static const struct pci_device_id ehl_pse_gpio_ids[] = {
+	{ PCI_VDEVICE(INTEL, 0x4b88) },
+	{ PCI_VDEVICE(INTEL, 0x4b89) },
+	{}
+};
+MODULE_DEVICE_TABLE(pci, ehl_pse_gpio_ids);
+
+static struct pci_driver ehl_pse_gpio_driver = {
+	.probe		= ehl_pse_gpio_probe,
+	.remove		= ehl_pse_gpio_remove,
+	.id_table	= ehl_pse_gpio_ids,
+	.name		= "ehl_pse_gpio",
+};
+module_pci_driver(ehl_pse_gpio_driver);
+
+MODULE_AUTHOR("Raymond Tan <raymond.tan@intel.com>");
+MODULE_AUTHOR("Raag Jadav <raag.jadav@intel.com>");
+MODULE_DESCRIPTION("Intel MFD for Elkhart Lake PSE GPIO & TIO");
+MODULE_LICENSE("GPL");
-- 
2.34.1

[PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

Now that we have Intel MFD driver for PSE GPIO, depend on it.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 98b4d1633b25..b2efd2533630 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1372,7 +1372,7 @@ config HTC_EGPIO
 
 config GPIO_ELKHARTLAKE
 	tristate "Intel Elkhart Lake PSE GPIO support"
-	depends on X86 || COMPILE_TEST
+	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
 	select GPIO_TANGIER
 	help
 	  Select this option to enable GPIO support for Intel Elkhart Lake
-- 
2.34.1

[PATCH v2 3/5] pps: generators: tio: split pps_gen_tio.h

[Raag Jadav]

Split macros and structure definition to header file for better
maintainability.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/pps/generators/pps_gen_tio.c | 30 +----------------
 drivers/pps/generators/pps_gen_tio.h | 49 ++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 29 deletions(-)
 create mode 100644 drivers/pps/generators/pps_gen_tio.h

diff --git a/drivers/pps/generators/pps_gen_tio.c b/drivers/pps/generators/pps_gen_tio.c
index 6c46b46c66cd..7f2aab1219af 100644
--- a/drivers/pps/generators/pps_gen_tio.c
+++ b/drivers/pps/generators/pps_gen_tio.c
@@ -5,8 +5,6 @@
  * Copyright (C) 2024 Intel Corporation
  */
 
-#include <linux/bitfield.h>
-#include <linux/bits.h>
 #include <linux/cleanup.h>
 #include <linux/container_of.h>
 #include <linux/device.h>
@@ -21,33 +19,7 @@
 
 #include <asm/cpu_device_id.h>
 
-#define TIOCTL			0x00
-#define TIOCOMPV		0x10
-#define TIOEC			0x30
-
-/* Control Register */
-#define TIOCTL_EN			BIT(0)
-#define TIOCTL_DIR			BIT(1)
-#define TIOCTL_EP			GENMASK(3, 2)
-#define TIOCTL_EP_RISING_EDGE		FIELD_PREP(TIOCTL_EP, 0)
-#define TIOCTL_EP_FALLING_EDGE		FIELD_PREP(TIOCTL_EP, 1)
-#define TIOCTL_EP_TOGGLE_EDGE		FIELD_PREP(TIOCTL_EP, 2)
-
-/* Safety time to set hrtimer early */
-#define SAFE_TIME_NS			(10 * NSEC_PER_MSEC)
-
-#define MAGIC_CONST			(NSEC_PER_SEC - SAFE_TIME_NS)
-#define ART_HW_DELAY_CYCLES		2
-
-struct pps_tio {
-	struct pps_gen_source_info gen_info;
-	struct pps_gen_device *pps_gen;
-	struct hrtimer timer;
-	void __iomem *base;
-	u32 prev_count;
-	spinlock_t lock;
-	struct device *dev;
-};
+#include "pps_gen_tio.h"
 
 static inline u32 pps_tio_read(u32 offset, struct pps_tio *tio)
 {
diff --git a/drivers/pps/generators/pps_gen_tio.h b/drivers/pps/generators/pps_gen_tio.h
new file mode 100644
index 000000000000..5033d5efdf92
--- /dev/null
+++ b/drivers/pps/generators/pps_gen_tio.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Intel PPS signal Generator Driver
+ *
+ * Copyright (C) 2025 Intel Corporation
+ */
+
+#ifndef _PPS_GEN_TIO_H_
+#define _PPS_GEN_TIO_H_
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/hrtimer.h>
+#include <linux/pps_gen_kernel.h>
+#include <linux/spinlock_types.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+struct device;
+
+#define TIOCTL			0x00
+#define TIOCOMPV		0x10
+#define TIOEC			0x30
+
+/* Control Register */
+#define TIOCTL_EN			BIT(0)
+#define TIOCTL_DIR			BIT(1)
+#define TIOCTL_EP			GENMASK(3, 2)
+#define TIOCTL_EP_RISING_EDGE		FIELD_PREP(TIOCTL_EP, 0)
+#define TIOCTL_EP_FALLING_EDGE		FIELD_PREP(TIOCTL_EP, 1)
+#define TIOCTL_EP_TOGGLE_EDGE		FIELD_PREP(TIOCTL_EP, 2)
+
+/* Safety time to set hrtimer early */
+#define SAFE_TIME_NS			(10 * NSEC_PER_MSEC)
+
+#define MAGIC_CONST			(NSEC_PER_SEC - SAFE_TIME_NS)
+#define ART_HW_DELAY_CYCLES		2
+
+struct pps_tio {
+	struct pps_gen_source_info gen_info;
+	struct pps_gen_device *pps_gen;
+	struct hrtimer timer;
+	void __iomem *base;
+	u32 prev_count;
+	spinlock_t lock;
+	struct device *dev;
+};
+
+#endif /* _PPS_GEN_TIO_H_ */
-- 
2.34.1

[PATCH v2 4/5] pps: generators: tio: move to match_data() model

[Raag Jadav]

Use device_get_match_data() which allows configuring platform
specific data like number of pins and MMIO registers for TIO.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/pps/generators/pps_gen_tio.c | 33 ++++++++++++++++++++--------
 drivers/pps/generators/pps_gen_tio.h | 19 +++++++++++++---
 2 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/pps/generators/pps_gen_tio.c b/drivers/pps/generators/pps_gen_tio.c
index 7f2aab1219af..6e3a4b198259 100644
--- a/drivers/pps/generators/pps_gen_tio.c
+++ b/drivers/pps/generators/pps_gen_tio.c
@@ -14,6 +14,7 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pps_gen_kernel.h>
+#include <linux/property.h>
 #include <linux/timekeeping.h>
 #include <linux/types.h>
 
@@ -28,7 +29,7 @@ static inline u32 pps_tio_read(u32 offset, struct pps_tio *tio)
 
 static inline void pps_ctl_write(u32 value, struct pps_tio *tio)
 {
-	writel(value, tio->base + TIOCTL);
+	writel(value, tio->base + tio->regs.ctl);
 }
 
 /*
@@ -37,7 +38,7 @@ static inline void pps_ctl_write(u32 value, struct pps_tio *tio)
  */
 static inline void pps_compv_write(u64 value, struct pps_tio *tio)
 {
-	hi_lo_writeq(value, tio->base + TIOCOMPV);
+	hi_lo_writeq(value, tio->base + tio->regs.compv);
 }
 
 static inline ktime_t first_event(struct pps_tio *tio)
@@ -49,7 +50,7 @@ static u32 pps_tio_disable(struct pps_tio *tio)
 {
 	u32 ctrl;
 
-	ctrl = pps_tio_read(TIOCTL, tio);
+	ctrl = pps_tio_read(tio->regs.ctl, tio);
 	pps_compv_write(0, tio);
 
 	ctrl &= ~TIOCTL_EN;
@@ -63,7 +64,7 @@ static void pps_tio_enable(struct pps_tio *tio)
 {
 	u32 ctrl;
 
-	ctrl = pps_tio_read(TIOCTL, tio);
+	ctrl = pps_tio_read(tio->regs.ctl, tio);
 	ctrl |= TIOCTL_EN;
 	pps_ctl_write(ctrl, tio);
 	tio->pps_gen->enabled = true;
@@ -112,7 +113,7 @@ static enum hrtimer_restart hrtimer_callback(struct hrtimer *timer)
 	 * Check if any event is missed.
 	 * If an event is missed, TIO will be disabled.
 	 */
-	event_count = pps_tio_read(TIOEC, tio);
+	event_count = pps_tio_read(tio->regs.ec, tio);
 	if (tio->prev_count && tio->prev_count == event_count)
 		goto err;
 	tio->prev_count = event_count;
@@ -172,6 +173,7 @@ static int pps_tio_get_time(struct pps_gen_device *pps_gen,
 static int pps_gen_tio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	const struct pps_tio_data *data;
 	struct pps_tio *tio;
 
 	if (!(cpu_feature_enabled(X86_FEATURE_TSC_KNOWN_FREQ) &&
@@ -184,6 +186,11 @@ static int pps_gen_tio_probe(struct platform_device *pdev)
 	if (!tio)
 		return -ENOMEM;
 
+	data = device_get_match_data(dev);
+	if (!data)
+		return -ENODEV;
+
+	tio->regs = data->regs;
 	tio->gen_info.use_system_clock = true;
 	tio->gen_info.enable = pps_tio_gen_enable;
 	tio->gen_info.get_time = pps_tio_get_time;
@@ -216,11 +223,19 @@ static void pps_gen_tio_remove(struct platform_device *pdev)
 	pps_gen_unregister_source(tio->pps_gen);
 }
 
+static const struct pps_tio_data pmc_data = {
+	.regs = {
+		.ctl = TIOCTL_PMC,
+		.compv = TIOCOMPV_PMC,
+		.ec = TIOEC_PMC,
+	},
+};
+
 static const struct acpi_device_id intel_pmc_tio_acpi_match[] = {
-	{ "INTC1021" },
-	{ "INTC1022" },
-	{ "INTC1023" },
-	{ "INTC1024" },
+	{ "INTC1021", (kernel_ulong_t)&pmc_data },
+	{ "INTC1022", (kernel_ulong_t)&pmc_data },
+	{ "INTC1023", (kernel_ulong_t)&pmc_data },
+	{ "INTC1024", (kernel_ulong_t)&pmc_data },
 	{}
 };
 MODULE_DEVICE_TABLE(acpi, intel_pmc_tio_acpi_match);
diff --git a/drivers/pps/generators/pps_gen_tio.h b/drivers/pps/generators/pps_gen_tio.h
index 5033d5efdf92..4329b6dbd598 100644
--- a/drivers/pps/generators/pps_gen_tio.h
+++ b/drivers/pps/generators/pps_gen_tio.h
@@ -18,9 +18,10 @@
 
 struct device;
 
-#define TIOCTL			0x00
-#define TIOCOMPV		0x10
-#define TIOEC			0x30
+/* PMC Registers */
+#define TIOCTL_PMC			0x00
+#define TIOCOMPV_PMC			0x10
+#define TIOEC_PMC			0x30
 
 /* Control Register */
 #define TIOCTL_EN			BIT(0)
@@ -36,9 +37,21 @@ struct device;
 #define MAGIC_CONST			(NSEC_PER_SEC - SAFE_TIME_NS)
 #define ART_HW_DELAY_CYCLES		2
 
+struct pps_tio_regs {
+	u32 ctl;
+	u32 compv;
+	u32 ec;
+};
+
+struct pps_tio_data {
+	struct pps_tio_regs regs;
+	u32 num_pins;
+};
+
 struct pps_tio {
 	struct pps_gen_source_info gen_info;
 	struct pps_gen_device *pps_gen;
+	struct pps_tio_regs regs;
 	struct hrtimer timer;
 	void __iomem *base;
 	u32 prev_count;
-- 
2.34.1

[PATCH v2 5/5] pps: generators: tio: Introduce Intel Elkhart Lake PSE TIO

[Raag Jadav]

Add initial support for Intel Elkhart Lake PSE TIO controller.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/pps/generators/Kconfig       |  2 +-
 drivers/pps/generators/pps_gen_tio.c | 17 ++++++++++++++++-
 drivers/pps/generators/pps_gen_tio.h |  5 +++++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/pps/generators/Kconfig b/drivers/pps/generators/Kconfig
index b3f340ed3163..83aada693ad2 100644
--- a/drivers/pps/generators/Kconfig
+++ b/drivers/pps/generators/Kconfig
@@ -33,7 +33,7 @@ config PPS_GENERATOR_PARPORT
 
 config PPS_GENERATOR_TIO
 	tristate "TIO PPS signal generator"
-	depends on X86 && CPU_SUP_INTEL
+	depends on X86 && CPU_SUP_INTEL && MFD_INTEL_EHL_PSE_GPIO
 	help
 	  If you say yes here you get support for a PPS TIO signal generator
 	  which generates a pulse at a prescribed time based on the system clock.
diff --git a/drivers/pps/generators/pps_gen_tio.c b/drivers/pps/generators/pps_gen_tio.c
index 6e3a4b198259..a2a23cdc2568 100644
--- a/drivers/pps/generators/pps_gen_tio.c
+++ b/drivers/pps/generators/pps_gen_tio.c
@@ -231,6 +231,14 @@ static const struct pps_tio_data pmc_data = {
 	},
 };
 
+static const struct pps_tio_data ehl_pse_data = {
+	.regs = {
+		.ctl = TIOCTL_PSE,
+		.compv = TIOCOMPV_PSE,
+		.ec = TIOEC_PSE,
+	},
+};
+
 static const struct acpi_device_id intel_pmc_tio_acpi_match[] = {
 	{ "INTC1021", (kernel_ulong_t)&pmc_data },
 	{ "INTC1022", (kernel_ulong_t)&pmc_data },
@@ -240,9 +248,16 @@ static const struct acpi_device_id intel_pmc_tio_acpi_match[] = {
 };
 MODULE_DEVICE_TABLE(acpi, intel_pmc_tio_acpi_match);
 
+static const struct platform_device_id pps_gen_tio_ids[] = {
+	{ "pps-gen-tio", (kernel_ulong_t)&ehl_pse_data },
+	{ }
+};
+MODULE_DEVICE_TABLE(platform, pps_gen_tio_ids);
+
 static struct platform_driver pps_gen_tio_driver = {
 	.probe          = pps_gen_tio_probe,
 	.remove         = pps_gen_tio_remove,
+	.id_table	= pps_gen_tio_ids,
 	.driver         = {
 		.name                   = "intel-pps-gen-tio",
 		.acpi_match_table       = intel_pmc_tio_acpi_match,
@@ -255,5 +270,5 @@ MODULE_AUTHOR("Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>");
 MODULE_AUTHOR("Pandith N <pandith.n@intel.com>");
 MODULE_AUTHOR("Thejesh Reddy T R <thejesh.reddy.t.r@intel.com>");
 MODULE_AUTHOR("Subramanian Mohan <subramanian.mohan@intel.com>");
-MODULE_DESCRIPTION("Intel PMC Time-Aware IO Generator Driver");
+MODULE_DESCRIPTION("Intel Time-Aware IO Generator Driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/pps/generators/pps_gen_tio.h b/drivers/pps/generators/pps_gen_tio.h
index 4329b6dbd598..509bd2633dfb 100644
--- a/drivers/pps/generators/pps_gen_tio.h
+++ b/drivers/pps/generators/pps_gen_tio.h
@@ -18,6 +18,11 @@
 
 struct device;
 
+/* EHL PSE Registers */
+#define TIOCTL_PSE			0x00
+#define TIOCOMPV_PSE			0x04
+#define TIOEC_PSE			0x24
+
 /* PMC Registers */
 #define TIOCTL_PMC			0x00
 #define TIOCOMPV_PMC			0x10
-- 
2.34.1

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:
> Now that we have Intel MFD driver for PSE GPIO, depend on it.

...

>  config GPIO_ELKHARTLAKE
>  	tristate "Intel Elkhart Lake PSE GPIO support"
> -	depends on X86 || COMPILE_TEST
> +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
>  	select GPIO_TANGIER

Looking on how GPIO PMIC drivers are written, I would redo this as

	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:
> Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
> devices that expose two different capabilities of GPIO and Timed I/O
> as a single PCI function through shared MMIO.

...

> +INTEL GPIO MFD DRIVER

This also needs to be more precise and follow the name. We have more Intel GPIO
drivers, and MFD doesn't ring any bell about the platform or so. Are you going
to support all of them (existing and comining)?

> +M:	Raag Jadav <raag.jadav@intel.com>
> +S:	Supported
> +F:	drivers/mfd/intel_ehl_pse_gpio.c

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:
> > Now that we have Intel MFD driver for PSE GPIO, depend on it.
> 
> ...
> 
> >  config GPIO_ELKHARTLAKE
> >  	tristate "Intel Elkhart Lake PSE GPIO support"
> > -	depends on X86 || COMPILE_TEST
> > +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> >  	select GPIO_TANGIER
> 
> Looking on how GPIO PMIC drivers are written, I would redo this as
> 
> 	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO

True, but perhaps allow independent COMPILE_TEST where possible?

Raag

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:
> > Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
> > devices that expose two different capabilities of GPIO and Timed I/O
> > as a single PCI function through shared MMIO.
> 
> ...
> 
> > +INTEL GPIO MFD DRIVER
> 
> This also needs to be more precise and follow the name. We have more Intel GPIO
> drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> to support all of them (existing and comining)?

Not that it is planned as of now but I wouldn't mind :)

> > +M:	Raag Jadav <raag.jadav@intel.com>
> > +S:	Supported
> > +F:	drivers/mfd/intel_ehl_pse_gpio.c

Raag

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > >  config GPIO_ELKHARTLAKE
> > >  	tristate "Intel Elkhart Lake PSE GPIO support"
> > > -	depends on X86 || COMPILE_TEST
> > > +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> > >  	select GPIO_TANGIER
> > 
> > Looking on how GPIO PMIC drivers are written, I would redo this as
> > 
> > 	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
> 
> True, but perhaps allow independent COMPILE_TEST where possible?

It will be tested in all-or-none way. Or you think it has to be tested
individually? If so, why is it needed?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:

...

> > > +INTEL GPIO MFD DRIVER
> > 
> > This also needs to be more precise and follow the name. We have more Intel GPIO
> > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > to support all of them (existing and comining)?
> 
> Not that it is planned as of now but I wouldn't mind :)

It sounds like solving the problem that even might never appear :-)

> > > +M:	Raag Jadav <raag.jadav@intel.com>
> > > +S:	Supported
> > > +F:	drivers/mfd/intel_ehl_pse_gpio.c

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > >  config GPIO_ELKHARTLAKE
> > > >  	tristate "Intel Elkhart Lake PSE GPIO support"
> > > > -	depends on X86 || COMPILE_TEST
> > > > +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> > > >  	select GPIO_TANGIER
> > > 
> > > Looking on how GPIO PMIC drivers are written, I would redo this as
> > > 
> > > 	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
> > 
> > True, but perhaps allow independent COMPILE_TEST where possible?
> 
> It will be tested in all-or-none way. Or you think it has to be tested
> individually? If so, why is it needed?

Better CI coverage? We also have it for Intel pinctrl drivers.

Raag

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 01:45:35PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > > +INTEL GPIO MFD DRIVER
> > > 
> > > This also needs to be more precise and follow the name. We have more Intel GPIO
> > > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > > to support all of them (existing and comining)?
> > 
> > Not that it is planned as of now but I wouldn't mind :)
> 
> It sounds like solving the problem that even might never appear :-)

Right, somehow that sounds familiar :D

Raag

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > >  config GPIO_ELKHARTLAKE
> > > > >  	tristate "Intel Elkhart Lake PSE GPIO support"
> > > > > -	depends on X86 || COMPILE_TEST
> > > > > +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> > > > >  	select GPIO_TANGIER
> > > > 
> > > > Looking on how GPIO PMIC drivers are written, I would redo this as
> > > > 
> > > > 	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
> > > 
> > > True, but perhaps allow independent COMPILE_TEST where possible?
> > 
> > It will be tested in all-or-none way. Or you think it has to be tested
> > individually? If so, why is it needed?
> 
> Better CI coverage?

How? I do not see the difference, can you elaborate?
(Assuming that CIs are using the merge_config.sh approach or alike)

> We also have it for Intel pinctrl drivers.

This is unrelated to Intel pin control drivers.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 02:14:35PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 01:45:35PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:

...

> > > > > +INTEL GPIO MFD DRIVER
> > > > 
> > > > This also needs to be more precise and follow the name. We have more Intel GPIO
> > > > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > > > to support all of them (existing and comining)?
> > > 
> > > Not that it is planned as of now but I wouldn't mind :)
> > 
> > It sounds like solving the problem that even might never appear :-)
> 
> Right, somehow that sounds familiar :D

So, can we rename the MAINTAINERS record as the result of our discussion?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > > > >  config GPIO_ELKHARTLAKE
> > > > > >  	tristate "Intel Elkhart Lake PSE GPIO support"
> > > > > > -	depends on X86 || COMPILE_TEST
> > > > > > +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> > > > > >  	select GPIO_TANGIER
> > > > > 
> > > > > Looking on how GPIO PMIC drivers are written, I would redo this as
> > > > > 
> > > > > 	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
> > > > 
> > > > True, but perhaps allow independent COMPILE_TEST where possible?
> > > 
> > > It will be tested in all-or-none way. Or you think it has to be tested
> > > individually? If so, why is it needed?
> > 
> > Better CI coverage?
> 
> How? I do not see the difference, can you elaborate?
> (Assuming that CIs are using the merge_config.sh approach or alike)

That is my understanding of it.

config COMPILE_TEST
        bool "Compile also drivers which will not load"
        depends on HAS_IOMEM
        help
          Some drivers can be compiled on a different platform than they are
          intended to be run on. Despite they cannot be loaded there (or even
          when they load they cannot be used due to missing HW support),
          developers still, opposing to distributors, might want to build such
          drivers to compile-test them.

Raag

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 02:22:41PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 02:14:35PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 01:45:35PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> > > > On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > > > > +INTEL GPIO MFD DRIVER
> > > > > 
> > > > > This also needs to be more precise and follow the name. We have more Intel GPIO
> > > > > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > > > > to support all of them (existing and comining)?
> > > > 
> > > > Not that it is planned as of now but I wouldn't mind :)
> > > 
> > > It sounds like solving the problem that even might never appear :-)
> > 
> > Right, somehow that sounds familiar :D
> 
> So, can we rename the MAINTAINERS record as the result of our discussion?

Yep, but perhaps wait a few days for review comments.

Raag

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > > > >  config GPIO_ELKHARTLAKE
> > > > > > >  	tristate "Intel Elkhart Lake PSE GPIO support"
> > > > > > > -	depends on X86 || COMPILE_TEST
> > > > > > > +	depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> > > > > > >  	select GPIO_TANGIER
> > > > > > 
> > > > > > Looking on how GPIO PMIC drivers are written, I would redo this as
> > > > > > 
> > > > > > 	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
> > > > > 
> > > > > True, but perhaps allow independent COMPILE_TEST where possible?
> > > > 
> > > > It will be tested in all-or-none way. Or you think it has to be tested
> > > > individually? If so, why is it needed?
> > > 
> > > Better CI coverage?
> > 
> > How? I do not see the difference, can you elaborate?
> > (Assuming that CIs are using the merge_config.sh approach or alike)
> 
> That is my understanding of it.
> 
> config COMPILE_TEST
>         bool "Compile also drivers which will not load"
>         depends on HAS_IOMEM
>         help
>           Some drivers can be compiled on a different platform than they are
>           intended to be run on. Despite they cannot be loaded there (or even
>           when they load they cannot be used due to missing HW support),
>           developers still, opposing to distributors, might want to build such
>           drivers to compile-test them.

Yes, and how does my suggestion prevent from this happening?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 02:47:29PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 02:22:41PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 02:14:35PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 01:45:35PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:

...

> > > > > > > +INTEL GPIO MFD DRIVER
> > > > > > 
> > > > > > This also needs to be more precise and follow the name. We have more Intel GPIO
> > > > > > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > > > > > to support all of them (existing and comining)?
> > > > > 
> > > > > Not that it is planned as of now but I wouldn't mind :)
> > > > 
> > > > It sounds like solving the problem that even might never appear :-)
> > > 
> > > Right, somehow that sounds familiar :D
> > 
> > So, can we rename the MAINTAINERS record as the result of our discussion?
> 
> Yep, but perhaps wait a few days for review comments.

Sure.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 03:19:57PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > Better CI coverage?
> > > 
> > > How? I do not see the difference, can you elaborate?
> > > (Assuming that CIs are using the merge_config.sh approach or alike)
> > 
> > That is my understanding of it.
> > 
> > config COMPILE_TEST
> >         bool "Compile also drivers which will not load"
> >         depends on HAS_IOMEM
> >         help
> >           Some drivers can be compiled on a different platform than they are
> >           intended to be run on. Despite they cannot be loaded there (or even
> >           when they load they cannot be used due to missing HW support),
> >           developers still, opposing to distributors, might want to build such
> >           drivers to compile-test them.
> 
> Yes, and how does my suggestion prevent from this happening?

Nothing's preventing it, but since we have an opportunity to allow
a wider build test (even without arch or mfd dependency), shouldn't
we allow it?

Raag

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 04:01:43PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 03:19:57PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > > Better CI coverage?
> > > > 
> > > > How? I do not see the difference, can you elaborate?
> > > > (Assuming that CIs are using the merge_config.sh approach or alike)
> > > 
> > > That is my understanding of it.
> > > 
> > > config COMPILE_TEST
> > >         bool "Compile also drivers which will not load"
> > >         depends on HAS_IOMEM
> > >         help
> > >           Some drivers can be compiled on a different platform than they are
> > >           intended to be run on. Despite they cannot be loaded there (or even
> > >           when they load they cannot be used due to missing HW support),
> > >           developers still, opposing to distributors, might want to build such
> > >           drivers to compile-test them.
> > 
> > Yes, and how does my suggestion prevent from this happening?
> 
> Nothing's preventing it, but since we have an opportunity to allow
> a wider build test (even without arch or mfd dependency), shouldn't
> we allow it?

I don't see much benefit out of this. If MFD is not available, the other
drivers may be built, but it won't make any practical sense except build for
the sake of build. I think when they are all together, it makes real sense
to compile test. MFD driver here is like a subsubsystem dependecy, we don't
usually compile the drivers without subsystem being enabled.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 04:20:08PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 04:01:43PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 03:19:57PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> > > > On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > > > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > > > > Better CI coverage?
> > > > > 
> > > > > How? I do not see the difference, can you elaborate?
> > > > > (Assuming that CIs are using the merge_config.sh approach or alike)
> > > > 
> > > > That is my understanding of it.
> > > > 
> > > > config COMPILE_TEST
> > > >         bool "Compile also drivers which will not load"
> > > >         depends on HAS_IOMEM
> > > >         help
> > > >           Some drivers can be compiled on a different platform than they are
> > > >           intended to be run on. Despite they cannot be loaded there (or even
> > > >           when they load they cannot be used due to missing HW support),
> > > >           developers still, opposing to distributors, might want to build such
> > > >           drivers to compile-test them.
> > > 
> > > Yes, and how does my suggestion prevent from this happening?
> > 
> > Nothing's preventing it, but since we have an opportunity to allow
> > a wider build test (even without arch or mfd dependency), shouldn't
> > we allow it?
> 
> I don't see much benefit out of this. If MFD is not available, the other
> drivers may be built, but it won't make any practical sense except build for
> the sake of build. I think when they are all together, it makes real sense
> to compile test. MFD driver here is like a subsubsystem dependecy, we don't
> usually compile the drivers without subsystem being enabled.

I thought the point of COMPILE_TEST is to do exactly that, but sure if
you insist.

Raag

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

On Mon, Mar 03, 2025 at 03:20:12PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 03, 2025 at 02:47:29PM +0200, Raag Jadav wrote:
> > On Mon, Mar 03, 2025 at 02:22:41PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 03, 2025 at 02:14:35PM +0200, Raag Jadav wrote:
> > > > On Mon, Mar 03, 2025 at 01:45:35PM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> > > > > > On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > > > > > > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > > > > > > +INTEL GPIO MFD DRIVER
> > > > > > > 
> > > > > > > This also needs to be more precise and follow the name. We have more Intel GPIO
> > > > > > > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > > > > > > to support all of them (existing and comining)?
> > > > > > 
> > > > > > Not that it is planned as of now but I wouldn't mind :)
> > > > > 
> > > > > It sounds like solving the problem that even might never appear :-)
> > > > 
> > > > Right, somehow that sounds familiar :D
> > > 
> > > So, can we rename the MAINTAINERS record as the result of our discussion?
> > 
> > Yep, but perhaps wait a few days for review comments.
> 
> Sure.

Or can we just add it under INTEL GPIO DRIVERS? With that I think it'll
be in much better hands.

Raag

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Tue, Mar 04, 2025 at 07:22:23AM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 04:20:08PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 04:01:43PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 03:19:57PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > > > > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > > > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > > > > Better CI coverage?
> > > > > > 
> > > > > > How? I do not see the difference, can you elaborate?
> > > > > > (Assuming that CIs are using the merge_config.sh approach or alike)
> > > > > 
> > > > > That is my understanding of it.
> > > > > 
> > > > > config COMPILE_TEST
> > > > >         bool "Compile also drivers which will not load"
> > > > >         depends on HAS_IOMEM
> > > > >         help
> > > > >           Some drivers can be compiled on a different platform than they are
> > > > >           intended to be run on. Despite they cannot be loaded there (or even
> > > > >           when they load they cannot be used due to missing HW support),
> > > > >           developers still, opposing to distributors, might want to build such
> > > > >           drivers to compile-test them.
> > > > 
> > > > Yes, and how does my suggestion prevent from this happening?
> > > 
> > > Nothing's preventing it, but since we have an opportunity to allow
> > > a wider build test (even without arch or mfd dependency), shouldn't
> > > we allow it?
> > 
> > I don't see much benefit out of this. If MFD is not available, the other
> > drivers may be built, but it won't make any practical sense except build for
> > the sake of build. I think when they are all together, it makes real sense
> > to compile test. MFD driver here is like a subsubsystem dependecy, we don't
> > usually compile the drivers without subsystem being enabled.
> 
> I thought the point of COMPILE_TEST is to do exactly that, but sure if
> you insist.

I think it's okay to compile test the whole batch of the related to each other
drivers, they are not many and again, the configuration that MFD is absent and
leaf drivers are built sounds to me impractical, so not really used in the real
life. If the leaf driver makes sense separately on some future HW or HW designs,
then we might reconsider the dependencies.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Tue, Mar 04, 2025 at 07:25:00AM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 03:20:12PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 02:47:29PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 02:22:41PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 02:14:35PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 01:45:35PM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 01:39:16PM +0200, Raag Jadav wrote:
> > > > > > > On Mon, Mar 03, 2025 at 10:24:43AM +0200, Andy Shevchenko wrote:
> > > > > > > > On Mon, Mar 03, 2025 at 10:17:41AM +0530, Raag Jadav wrote:

...

> > > > > > > > > +INTEL GPIO MFD DRIVER
> > > > > > > > 
> > > > > > > > This also needs to be more precise and follow the name. We have more Intel GPIO
> > > > > > > > drivers, and MFD doesn't ring any bell about the platform or so. Are you going
> > > > > > > > to support all of them (existing and comining)?
> > > > > > > 
> > > > > > > Not that it is planned as of now but I wouldn't mind :)
> > > > > > 
> > > > > > It sounds like solving the problem that even might never appear :-)
> > > > > 
> > > > > Right, somehow that sounds familiar :D
> > > > 
> > > > So, can we rename the MAINTAINERS record as the result of our discussion?
> > > 
> > > Yep, but perhaps wait a few days for review comments.
> > 
> > Sure.
> 
> Or can we just add it under INTEL GPIO DRIVERS?

But it's not a GPIO driver. It's a glue between GPIO and PPS drivers to support
such a hardware on some platforms.

> With that I think it'll be in much better hands.

So, I don't think so.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 04:01:43PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 03:19:57PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > > Better CI coverage?
> > > > 
> > > > How? I do not see the difference, can you elaborate?
> > > > (Assuming that CIs are using the merge_config.sh approach or alike)
> > > 
> > > That is my understanding of it.
> > > 
> > > config COMPILE_TEST
> > >         bool "Compile also drivers which will not load"
> > >         depends on HAS_IOMEM
> > >         help
> > >           Some drivers can be compiled on a different platform than they are
> > >           intended to be run on. Despite they cannot be loaded there (or even
> > >           when they load they cannot be used due to missing HW support),
> > >           developers still, opposing to distributors, might want to build such
> > >           drivers to compile-test them.
> > 
> > Yes, and how does my suggestion prevent from this happening?
> 
> Nothing's preventing it, but since we have an opportunity to allow
> a wider build test (even without arch or mfd dependency), shouldn't
> we allow it?

We are going circles here. My point that there is a little sense to do that
without MFD as it's impractical. On top of that this is inconsistent to other
drivers with similar design.

-- 
With Best Regards,
Andy Shevchenko