pinctrl: qcom: add support for sparse GPIOs

Add support for specifying that some GPIOs within a range are unavailable. Some systems have a sparse list of GPIOs, where a range of GPIOs is specified (usually 0 to n-1), but some subset within that range is absent or unavailable for whatever reason.

To support this, allow drivers to specify a bitmask of GPIOs that are present or absent. Gpiolib will then block access to those that are absent.

Signed-off-by Timur Tabi <[email protected]>

---
 drivers/gpio/gpiolib.c      | 43 +++++++++++++++++++++++++++++++++++--------
 include/linux/gpio/driver.h |  2 ++
 2 files changed, 37 insertions(+), 8 deletions(-)

drivers/gpio/gpiolib.c +0 -0

index 60553af4c004..c32387936cdd 100644

drivers/gpio/gpiolib.c +2 -4

+		if (!gpiochip->irq_valid_mask)
+			return -ENOMEM;
 
-	gpiochip->irq_valid_mask = kcalloc(BITS_TO_LONGS(gpiochip->ngpio),
-					   sizeof(long), GFP_KERNEL);
-	if (!gpiochip->irq_valid_mask)
-		return -ENOMEM;

drivers/gpio/gpiolib.c +22 -0

+		if (!gpiochip->line_valid_mask)
+			return -ENOMEM;
+
+		/* Assume by default all GPIOs are valid */
+		bitmap_fill(gpiochip->line_valid_mask, gpiochip->ngpio);
+	}
 
 	return 0;
 }
 
 static void gpiochip_irqchip_free_valid_mask(struct gpio_chip *gpiochip)
 {
+	kfree(gpiochip->line_valid_mask);
+	gpiochip->line_valid_mask = NULL;
+
 	kfree(gpiochip->irq_valid_mask);
 	gpiochip->irq_valid_mask = NULL;
 }

@@ -1510,6 +1524,15 @@ static bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gpiochip,
 	return test_bit(offset, gpiochip->irq_valid_mask);
 }
 
+static bool gpiochip_irqchip_line_valid(const struct gpio_chip *gpiochip,
+					unsigned int offset)
+{
+	/* No mask means all valid */
+	if (likely(!gpiochip->line_valid_mask))
+		return true;
+	return test_bit(offset, gpiochip->line_valid_mask);
+}
+
 /**
  * gpiochip_set_cascaded_irqchip() - connects a cascaded irqchip to a gpiochip
  * @gpiochip: the gpiochip to set the irqchip chain to

@@ -3320,6 +3343,10 @@ struct gpio_desc *__must_check gpiod_get_index(struct device *dev,
 		return desc;
 	}
 
+	/* Make sure the GPIO is valid before we request it. */
+	if (!gpiochip_irqchip_line_valid(desc->gdev->chip, idx))
+		return ERR_PTR(-EACCES);
+
 	status = gpiod_request(desc, con_id);
 	if (status < 0)
 		return ERR_PTR(status);

include/linux/gpio/driver.h +2 -1

index 424e5139ff10..853828ccabc8 100644
@@ -173,6 +173,8 @@ struct gpio_chip {
 	bool			irq_nested;
 	bool			irq_need_valid_mask;
 	unsigned long		*irq_valid_mask;
+	bool			line_need_valid_mask;
+	unsigned long		*line_valid_mask;
 	struct lock_class_key	*lock_key;
 #endif
 
--

Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

drivers/gpio/gpiolib.c static struct gpio_chip *find_chip_by_name(const char *name) · line 1487

Quoted 4 lines

drivers/gpio/gpiolib.c +4 -0

+	if (gpiochip->irq_need_valid_mask) {
+		gpiochip->irq_valid_mask =
+			kcalloc(BITS_TO_LONGS(gpiochip->ngpio),
+				sizeof(long), GFP_KERNEL);

Since 'irq_valid_mask' is getting filled below wouldn't a kmalloc suffice?

Quoted 10 lines

drivers/gpio/gpiolib.c +4 -0

+		if (!gpiochip->irq_valid_mask)
+			return -ENOMEM;
 
 
 
+		/* Assume by default all GPIOs are valid */
+		bitmap_fill(gpiochip->irq_valid_mask, gpiochip-

Quoted 1 line

ngpio);

(quoted diff) +1 -0

+	}

drivers/gpio/gpiolib.c static struct gpio_chip *find_chip_by_name(const char *name) · line 1498

Quoted 4 lines

drivers/gpio/gpiolib.c +4 -0

+	if (gpiochip->line_need_valid_mask) {
+		gpiochip->line_valid_mask =
+			kcalloc(BITS_TO_LONGS(gpiochip->ngpio),
+				sizeof(long), GFP_KERNEL);

Since 'line_valid_mask' is getting filled below wouldn't a kmalloc suffice?

I suppose you meant kmalloc_array.
Anyway, it's a separate change if you wish, because Timur didn't change the original approach here.

Add support for specifying that some GPIOs within a range are unavailable. Some systems have a sparse list of GPIOs, where a range of GPIOs is specified (usually 0 to n-1), but some subset within that range is absent or unavailable for whatever reason.

To support this, allow drivers to specify a bitmask of GPIOs that are present or absent. Gpiolib will then block access to those that are absent.

Signed-off-by Timur Tabi <[email protected]>

---
  drivers/gpio/gpiolib.c      | 43 +++++++++++++++++++++++++++++++++++--------
  include/linux/gpio/driver.h |  2 ++
  2 files changed, 37 insertions(+), 8 deletions(-)

drivers/gpio/gpiolib.c +31 -8

index 60553af4c004..c32387936cdd 100644
@@ -1481,22 +1481,36 @@ static struct gpio_chip *find_chip_by_name(const char *name)
 
  static int gpiochip_irqchip_init_valid_mask(struct gpio_chip *gpiochip)
  {
-	if (!gpiochip->irq_need_valid_mask)
-		return 0;
+	if (gpiochip->irq_need_valid_mask) {
+		gpiochip->irq_valid_mask =
+			kcalloc(BITS_TO_LONGS(gpiochip->ngpio),
+				sizeof(long), GFP_KERNEL);
+		if (!gpiochip->irq_valid_mask)
+			return -ENOMEM;
 
-	gpiochip->irq_valid_mask = kcalloc(BITS_TO_LONGS(gpiochip->ngpio),
-					   sizeof(long), GFP_KERNEL);
-	if (!gpiochip->irq_valid_mask)
-		return -ENOMEM;
+		/* Assume by default all GPIOs are valid */
+		bitmap_fill(gpiochip->irq_valid_mask, gpiochip->ngpio);
+	}
 
-	/* Assume by default all GPIOs are valid */
-	bitmap_fill(gpiochip->irq_valid_mask, gpiochip->ngpio);
+	if (gpiochip->line_need_valid_mask) {
+		gpiochip->line_valid_mask =
+			kcalloc(BITS_TO_LONGS(gpiochip->ngpio),
+				sizeof(long), GFP_KERNEL);
+		if (!gpiochip->line_valid_mask)
+			return -ENOMEM;
+
+		/* Assume by default all GPIOs are valid */
+		bitmap_fill(gpiochip->line_valid_mask, gpiochip->ngpio);
+	}
 
  	return 0;
  }
 
  static void gpiochip_irqchip_free_valid_mask(struct gpio_chip *gpiochip)
  {
+	kfree(gpiochip->line_valid_mask);
+	gpiochip->line_valid_mask = NULL;
+
  	kfree(gpiochip->irq_valid_mask);
  	gpiochip->irq_valid_mask = NULL;
  }

@@ -1510,6 +1524,15 @@ static bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gpiochip,
  	return test_bit(offset, gpiochip->irq_valid_mask);
  }
 
+static bool gpiochip_irqchip_line_valid(const struct gpio_chip *gpiochip,
+					unsigned int offset)
+{
+	/* No mask means all valid */
+	if (likely(!gpiochip->line_valid_mask))
+		return true;
+	return test_bit(offset, gpiochip->line_valid_mask);
+}
+
  /**
   * gpiochip_set_cascaded_irqchip() - connects a cascaded irqchip to a gpiochip
   * @gpiochip: the gpiochip to set the irqchip chain to

drivers/gpio/gpiolib.c +1 -0

+
  	status = gpiod_request(desc, con_id);
  	if (status < 0)
  		return ERR_PTR(status);

include/linux/gpio/driver.h +2 -0

index 424e5139ff10..853828ccabc8 100644
@@ -173,6 +173,8 @@ struct gpio_chip {
  	bool			irq_nested;
  	bool			irq_need_valid_mask;
  	unsigned long		*irq_valid_mask;
+	bool			line_need_valid_mask;
+	unsigned long		*line_valid_mask;
  	struct lock_class_key	*lock_key;
  #endif
 

We're hitting an issue here ^ when a consumer calls the devm_gpiod_get() API. This API
internally sets idx in gpiod_get_index to always 0. For example, in the call sequence
below, the idx argument to gpiochip_irqchip_line_valid is always 0:

devm_gpiod_get(dev, con_id, flags)
?? devm_gpiod_get_index(dev, con_id, 0, flags)
????? gpiod_get_index(dev, con_id, 0, flags)
???????? if (!gpiochip_irqchip_line_valid(desc->gdev->chip, 0)) ???????????? return ERR_PTR(-EACCES);

Therefore, with these patches, if we create a sparse gpio map, and the 0th gpio is set to "not accessible", all gpio requests end up failing with EACCESS
because idx is always passed as 0.

In gpiochip_irqchip_line_valid, shouldn't we test the nth bit (that corresponds to
this gpio_desc) in chip->line_valid_mask instead of idx passed above, which is always
0?

pinctrl-msm only accepts an array of GPIOs from 0 to n-1, and it expects each group to support have only one pin (npins == 1).

We can support "sparse" GPIO maps if we allow for some groups to have zero pins (npins == 0). These pins are "hidden" from the rest of the driver and gpiolib.

A new boolean 'sparse' indicates whether the GPIO map is sparse. If any GPIO has an 'npins' value of 0, then 'sparse' must be set to True.

Most access to unavailable GPIOs can be blocked via the gpio_chip.request function. The one exception is when gpiochip_add_data() scans all of

the GPIOs without "requesting" them. To cover this case,

msm_gpio_get_direction() separately checks if the GPIO is available.

Quoted 2 lines

Most access to unavailable GPIOs can be blocked via the gpio_chip.request function. The one exception is when gpiochip_add_data() scans all of

If patch 1 is applied is this statement still true?

Quoted 1 line

the GPIOs without "requesting" them. To cover this case,

s/GPIOs/GPIOs for their direction/ perhaps?

Quoted 4 lines · Stephen Boyd

Quoted 2 lines

Most access to unavailable GPIOs can be blocked via the gpio_chip.request function. The one exception is when gpiochip_add_data() scans all of

If patch 1 is applied is this statement still true?

Nope.

Quoted 4 lines · Timur Tabi

Quoted 2 lines · Stephen Boyd

Quoted 2 lines

Most access to unavailable GPIOs can be blocked via the gpio_chip.request function. The one exception is when gpiochip_add_data() scans all of

Quoted 4 lines

Quoted 1 line

If patch 1 is applied is this statement still true?

Nope.

Ok. So what's the point of this patch then? Put another way, is there some path that doesn't request the gpio still even with patch 1 applied?

Quoted 5 lines · Stephen Boyd

Quoted 4 lines · Timur Tabi

Quoted 2 lines · Stephen Boyd

Quoted 2 lines

Most access to unavailable GPIOs can be blocked via the gpio_chip.request function. The one exception is when gpiochip_add_data() scans all of

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

If patch 1 is applied is this statement still true?

Nope.

Ok. So what's the point of this patch then? Put another way, is there some path that doesn't request the gpio still even with patch 1 applied?

This patch is how the pinctrl-msm driver actually reports the sparse GPIO map.

Patch 1 prevents gpiolib from accessing GPIOs that haven't been properly requested.

Patch 2 adds an infrastructure for sparse GPIO maps

Patch 3 updates pinctrl-msm to use that expose that new infrastructure

Patch 4 updates pinctrl-qdf2xxx to work with the new feature in pinctrl-msm

Quoted 5 lines

Patch 1 prevents gpiolib from accessing GPIOs that haven't been properly requested.

Patch 2 adds an infrastructure for sparse GPIO maps

Quoted 4 lines

Patch 3 updates pinctrl-msm to use that expose that new infrastructure

Patch 4 updates pinctrl-qdf2xxx to work with the new feature in pinctrl-msm

Ok. What path doesn't request the gpio though? If we don't have a path that fails to request the gpio before using it then I don't see the need for this patch.

Newer versions of the firmware for the Qualcomm Datacenter Technologies QDF2400 restricts access to a subset of the GPIOs on the TLMM. To prevent older kernels from accidentally accessing the restricted GPIOs, we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002, and introduce a new property "gpios". This property is an array of specific GPIOs that are accessible. When an older kernel boots on newer (restricted) firmware, it will fail to probe.

To implement the sparse GPIO map, we register all of the GPIOs, but set the pin count for the unavailable GPIOs to zero. The pinctrl-msm driver will block those unavailable GPIOs from being accessed.

To allow newer kernels to support older firmware, the driver retains support for QCOM8001.

Signed-off-by Timur Tabi <[email protected]>

---
 drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 145 +++++++++++++++++++++++++--------
 1 file changed, 109 insertions(+), 36 deletions(-)

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +24 -3

index bb3ce5c3e18b..37f746f6eb8c 100644
@@ -38,68 +38,147 @@
 /* maximum size of each gpio name (enough room for "gpioXXX" + null) */
 #define NAME_SIZE	8
 
+enum {
+	QDF2XXX_V1,
+	QDF2XXX_V2,
+};
+
+static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
+	{"QCOM8001", QDF2XXX_V1},
+	{"QCOM8002", QDF2XXX_V2},
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
+
 static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
 {
+	const struct acpi_device_id *id =
+		acpi_match_device(qdf2xxx_acpi_ids, &pdev->dev);
 	struct pinctrl_pin_desc *pins;
 	struct msm_pingroup *groups;
 	char (*names)[NAME_SIZE];
 	unsigned int i;
 	u32 num_gpios;
+	unsigned int avail_gpios; /* The number of GPIOs we support */
+	u16 *gpios; /* An array of supported GPIOs */
 	int ret;
 
 	/* Query the number of GPIOs from ACPI */
 	ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
 	if (ret < 0) {
-		dev_warn(&pdev->dev, "missing num-gpios property\n");
+		dev_err(&pdev->dev, "missing 'num-gpios' property\n");
 		return ret;
 	}
-
 	if (!num_gpios || num_gpios > MAX_GPIOS) {
-		dev_warn(&pdev->dev, "invalid num-gpios property\n");
+		dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
 		return -ENODEV;
 	}
 
+	/*
+	 * The QCOM8001 HID contains only the number of GPIOs, and assumes
+	 * that all of them are available. avail_gpios is the same as num_gpios.
+	 *
+	 * The QCOM8002 HID introduces the 'gpios' DSD, which lists
+	 * specific GPIOs that the driver is allowed to access.

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +4 -0

+		if (!gpios)
+			return -ENOMEM;
+
+		for (i = 0; i < avail_gpios; i++)

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +54 -34

+		if (!gpios)
+			return -ENOMEM;
+
+		ret = device_property_read_u16_array(&pdev->dev, "gpios", gpios,
+						     avail_gpios);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "could not read list of GPIOs\n");
+			return ret;
+		}
+
+		/*
+		 * Because we have a specific list of GPIOs, the GPIO map
+		 * is 'sparse'.
+		 */
+		qdf2xxx_pinctrl.sparse = true;
+	}
+
 	pins = devm_kcalloc(&pdev->dev, num_gpios,
 		sizeof(struct pinctrl_pin_desc), GFP_KERNEL);
 	groups = devm_kcalloc(&pdev->dev, num_gpios,
 		sizeof(struct msm_pingroup), GFP_KERNEL);
-	names = devm_kcalloc(&pdev->dev, num_gpios, NAME_SIZE, GFP_KERNEL);
+	names = devm_kcalloc(&pdev->dev, avail_gpios, NAME_SIZE, GFP_KERNEL);
 
 	if (!pins || !groups || !names)
 		return -ENOMEM;
 
+	/*
+	 * Initialize the array.  GPIOs not listed in the 'gpios' array
+	 * still need a number, but nothing else.
+	 */
 	for (i = 0; i < num_gpios; i++) {
-		snprintf(names[i], NAME_SIZE, "gpio%u", i);
-
 		pins[i].number = i;
-		pins[i].name = names[i];
-
-		groups[i].npins = 1;
-		groups[i].name = names[i];
 		groups[i].pins = &pins[i].number;
+	}
 
-		groups[i].ctl_reg = 0x10000 * i;
-		groups[i].io_reg = 0x04 + 0x10000 * i;
-		groups[i].intr_cfg_reg = 0x08 + 0x10000 * i;
-		groups[i].intr_status_reg = 0x0c + 0x10000 * i;
-		groups[i].intr_target_reg = 0x08 + 0x10000 * i;
-
-		groups[i].mux_bit = 2;
-		groups[i].pull_bit = 0;
-		groups[i].drv_bit = 6;
-		groups[i].oe_bit = 9;
-		groups[i].in_bit = 0;
-		groups[i].out_bit = 1;
-		groups[i].intr_enable_bit = 0;
-		groups[i].intr_status_bit = 0;
-		groups[i].intr_target_bit = 5;
-		groups[i].intr_target_kpss_val = 1;
-		groups[i].intr_raw_status_bit = 4;
-		groups[i].intr_polarity_bit = 1;
-		groups[i].intr_detection_bit = 2;
-		groups[i].intr_detection_width = 2;
+	/* Populate the entries that are meant to be exposes as GPIOs. */
+	for (i = 0; i < avail_gpios; i++) {
+		unsigned int gpio = gpios[i];
+
+		groups[gpio].npins = 1;
+		snprintf(names[i], NAME_SIZE, "gpio%u", gpio);
+		pins[gpio].name = names[i];
+		groups[gpio].name = names[i];
+
+		groups[gpio].ctl_reg = 0x10000 * gpio;
+		groups[gpio].io_reg = 0x04 + 0x10000 * gpio;
+		groups[gpio].intr_cfg_reg = 0x08 + 0x10000 * gpio;
+		groups[gpio].intr_status_reg = 0x0c + 0x10000 * gpio;
+		groups[gpio].intr_target_reg = 0x08 + 0x10000 * gpio;
+
+		groups[gpio].mux_bit = 2;
+		groups[gpio].pull_bit = 0;
+		groups[gpio].drv_bit = 6;
+		groups[gpio].oe_bit = 9;
+		groups[gpio].in_bit = 0;
+		groups[gpio].out_bit = 1;
+		groups[gpio].intr_enable_bit = 0;
+		groups[gpio].intr_status_bit = 0;
+		groups[gpio].intr_target_bit = 5;
+		groups[gpio].intr_target_kpss_val = 1;
+		groups[gpio].intr_raw_status_bit = 4;
+		groups[gpio].intr_polarity_bit = 1;
+		groups[gpio].intr_detection_bit = 2;
+		groups[gpio].intr_detection_width = 2;
 	}
 
+	devm_kfree(&pdev->dev, gpios);
+
 	qdf2xxx_pinctrl.pins = pins;
 	qdf2xxx_pinctrl.groups = groups;
 	qdf2xxx_pinctrl.npins = num_gpios;

@@ -109,12 +188,6 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
 	return msm_pinctrl_probe(pdev, &qdf2xxx_pinctrl);
 }
 
-static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
-	{"QCOM8001"},
-	{},
-};
-MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
-
 static struct platform_driver qdf2xxx_pinctrl_driver = {
 	.driver = {
 		.name = "qdf2xxx-pinctrl",
--

Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c line 92

Quoted 5 lines

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +5 -0

+	if (id->driver_data == QDF2XXX_V1) {
+		avail_gpios = num_gpios;
+
+		gpios = devm_kcalloc(&pdev->dev, avail_gpios, sizeof(gpios[0]),
+				     GFP_KERNEL);

Wouldn't kmalloc suffice since the array gets initialized just below.

Quoted 7 lines

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +7 -0

+		if (!gpios)
+			return -ENOMEM;
+
+		for (i = 0; i < avail_gpios; i++)
+			gpios[i] = i;
+	} else {
+		/* The number of GPIOs in the approved list */

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c line 106

Quoted 7 lines

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +7 -0

+		ret = device_property_read_u16_array(&pdev->dev, "gpios",
+						     NULL, 0);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "missing 'num-gpios' property\n");
+			return ret;
+		}
+		if (!ret || ret > MAX_GPIOS) {

Instead of ret > MAX_GPIOS, should we check for ret > num_gpios?

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c line 109

Quoted 4 lines

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +3 -0

+			dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
+			return -ENODEV;
+		}

In both the above error messages 'num-gpios' should be 'gpios'

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c line 113

Quoted 5 lines

drivers/pinctrl/qcom/pinctrl-qdf2xxx.c +4 -0

+		avail_gpios = ret;
+
+		gpios = devm_kcalloc(&pdev->dev, avail_gpios, sizeof(gpios[0]),
+				     GFP_KERNEL);

devm_kmalloc?

A series of patches that add support for GPIO maps that have holes in them. That is, even though a client driver has N consecutive GPIOs, some are just unavailable for whatever reason, and the hardware should not be accessed for those GPIOs.

Any chance of these patches going into 4.15?

I've been making lots of
changes, but I haven't gotten a lot of feedback. I still think that v7 is more intrusive and risky than v5, with no real benefit. But at this point, I just want something to be merged so that I stop thinking about it.

From what I have understood Qualcomm has one finger constantly

From what I have understood Qualcomm has one finger constantly
on the fast-forward button for upstreaming right now, which I think is good (everyone should have!) but the limited number of trusted maintainers of core infrastructure code makes bottlenecks form around these drivers where review is really needed and deep queues of patches form. Sorry.

Quoted 8 lines · Linus Walleij

From what I have understood Qualcomm has one finger constantly
on the fast-forward button for upstreaming right now, which I think is good (everyone should have!) but the limited number of trusted maintainers of core infrastructure code makes bottlenecks form around these drivers where review is really needed and deep queues of patches form. Sorry.

That's one of the reasons why I prefer v5 of my patch instead of v7. v5 does not touch the core. It's much less intrusive and has no risk of breaking other drivers. I can't say that about v7.

The more intrusive design is on my request so I will look at it in detail ASAP. I took a quick look and liked what I saw, I just need to make sure about the details. Also it'd be nice to have a nod from Bj?rn.

The main reason for some of the work is ACPI, am I right?

Timur could you look quickly at the series posted by Andy Shevchenko (6 patches prefixed gpiolib: acpi: ) for augmenting ACPI GPIOs in the core? Especially patch 5 and 6 which introduce the ability to add quirks in the core.

I'd like to get some ARM-based people to look at it to make sure we those systems can also quirk their GPIOs if need be.