[PATCH 0/2] gpio: davinci: fix probe-time IRQ setup

[PATCH 0/2] gpio: davinci: fix probe-time IRQ setup

[Sahaj Chaudhari]

This series fixes two independent probe-time bugs in the DaVinci GPIO
driver:

1. A file-global MMIO base can be overwritten by overlapping controller
   probes, causing BINTEN setup to target the wrong controller.
2. Per-bank IRQ data is allocated as chained handlers are installed. A
   later allocation failure can leave handlers pointing to devm-managed
   data freed during probe unwind.

The first patch derives BINTEN from the current controller's mapped bank.
The second allocates all IRQ data before installing any handlers.

---
Testing:
- ARM64 W=1 Image builds passed for both patches.
- On AM642, a forced asynchronous-probe interleave made the baseline
  compute the wrong BINTEN target. The test redirected the unsafe baseline
  write before it reached hardware; the fixed path selected the expected
  target and verified readback 0x3f.
- With targeted probe allocation failure, the baseline left one chained
  handler installed; it was detached safely before devm cleanup. The fixed
  path left no handlers installed and reprobed normally.

The private baseline and fixed kernels showed unexplained
TAINT_MACHINE_CHECK bit 16. No BUG/Oops/WARNING/call trace/SError was
captured; the cause remains unknown, so this is not a clean hardware-health
claim.

GitHub Copilot CLI assisted with investigating the bugs and drafting the
fixes. The submitter reviewed the code and personally ran both board tests.

Sahaj Chaudhari (2):
  gpio: davinci: use controller-specific MMIO for BINTEN
  gpio: davinci: allocate bank IRQ data before installing handlers

 drivers/gpio/gpio-davinci.c | 28 +++++++++++++---------------
 1 file changed, 13 insertions(+), 15 deletions(-)

base-commit: 4fc2c9ab68f4324bea62cb5a43e93392225f1d11

-- 
2.43.0

[PATCH 1/2] gpio: davinci: use controller-specific MMIO for BINTEN

[Sahaj Chaudhari]

The file-global gpio_base can be overwritten when probes for multiple
DaVinci GPIO controllers overlap. The later IRQ setup can then write the
BINTEN register of a different controller.

Derive the BINTEN address from the current controller's mapped bank
instead of shared global state.

Fixes: 118150f22d6b ("gpio: davinci: move to platform device")
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
---
 drivers/gpio/gpio-davinci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index f7c3b644e0e3..caeecfc3df20 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -43,7 +43,6 @@ typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
 
 #define BINTEN	0x8 /* GPIO Interrupt Per-Bank Enable Register */
 
-static void __iomem *gpio_base;
 static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
 
 struct davinci_gpio_irq_data {
@@ -168,6 +167,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 	unsigned int ngpio, nbank, nirq, gpio_unbanked;
 	struct davinci_gpio_controller *chips;
 	struct device *dev = &pdev->dev;
+	void __iomem *gpio_base;
 
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
@@ -588,7 +588,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
 	 * BINTEN -- per-bank interrupt enable. genirq would also let these
 	 * bits be set/cleared dynamically.
 	 */
-	writel_relaxed(binten, gpio_base + BINTEN);
+	writel_relaxed(binten, chips->regs[0] - offset_array[0] + BINTEN);
 
 	return 0;
 }
-- 
2.43.0

Re: [PATCH 1/2] gpio: davinci: use controller-specific MMIO for BINTEN

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] gpio: davinci: out-of-bounds array access in
  davinci_gpio_probe() [1]
--

commit 28eb7330290061761743897d388da288ba076340
Author: Sahaj Chaudhari <sahaj123.sc@gmail.com>

gpio: davinci: use controller-specific MMIO for BINTEN

This commit makes gpio_base local to davinci_gpio_probe() and derives the
BINTEN register address from the controller's mapped bank rather than a
file-global variable.

> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index f7c3b644e0e39..caeecfc3df204 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c

[ ... ]

> @@ -168,6 +167,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
>  	unsigned int ngpio, nbank, nirq, gpio_unbanked;
>  	struct davinci_gpio_controller *chips;
>  	struct device *dev = &pdev->dev;
> +	void __iomem *gpio_base;
>  
>  	/*
>  	 * The gpio banks conceptually expose a segmented bitmap,

[Severity: Critical]
This problem wasn't introduced by this patch, but can a large ti,ngpio
value overflow offset_array[] and chips->regs[] [1]?

When ti,davinci-gpio-unbanked is set, nirq is taken from gpio_unbanked
rather than DIV_ROUND_UP(ngpio, 16), so the nirq > MAX_INT_PER_BANK check
never bounds ngpio:

drivers/gpio/gpio-davinci.c:davinci_gpio_probe() {
	...
	if (gpio_unbanked)
		nirq = gpio_unbanked;
	else
		nirq = DIV_ROUND_UP(ngpio, 16);

	if (nirq > MAX_INT_PER_BANK) {
		dev_err(dev, "Too many IRQs!\n");
		return -EINVAL;
	}
	...
	nbank = DIV_ROUND_UP(ngpio, 32);
	for (bank = 0; bank < nbank; bank++)
		chips->regs[bank] = gpio_base + offset_array[bank];
	...
}

If ngpio exceeds 160, nbank exceeds 5 (MAX_REGS_BANKS), and the loop reads
past the end of offset_array[] and writes out-of-bounds into chips->regs[],
corrupting memory in struct davinci_gpio_controller.

[1] https://sashiko.dev/#/bug/linux-59cf1b6f-2241-467c-a82a-93a3d1bf5d16

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109194910.2282454-1-sahaj123.sc@gmail.com?part=1

[PATCH 2/2] gpio: davinci: allocate bank IRQ data before installing handlers

[Sahaj Chaudhari]

If allocation fails partway through bank setup, previously installed
chained handlers still point at devm-managed data that is released when
probe fails. Allocate the complete bank-data array before installing the
first chained handler so an allocation failure leaves no handlers behind.

This fixes the probe-failure path; it does not change ordinary device
removal.

Fixes: b5cf3fd827d2 ("gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip")
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
---
 drivers/gpio/gpio-davinci.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index caeecfc3df20..751c0e3a9676 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -550,6 +550,13 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
 	 * Or, AINTC can handle IRQs for banks of 16 GPIO IRQs, which we
 	 * then chain through our own handler.
 	 */
+	irqdata = devm_kcalloc(dev, DIV_ROUND_UP(ngpio, 16),
+			       sizeof(*irqdata), GFP_KERNEL);
+	if (!irqdata) {
+		irq_domain_remove(chips->irq_domain);
+		return -ENOMEM;
+	}
+
 	for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 16) {
 		/* disabled by default, enabled only as needed
 		 * There are register sets for 32 GPIOs. 2 banks of 16
@@ -564,21 +571,12 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
 		 * gpio irqs. Pass the irq bank's corresponding controller to
 		 * the chained irq handler.
 		 */
-		irqdata = devm_kzalloc(&pdev->dev,
-				       sizeof(struct
-					      davinci_gpio_irq_data),
-					      GFP_KERNEL);
-		if (!irqdata) {
-			irq_domain_remove(chips->irq_domain);
-			return -ENOMEM;
-		}
-
-		irqdata->regs = g;
-		irqdata->bank_num = bank;
-		irqdata->chip = chips;
+		irqdata[bank].regs = g;
+		irqdata[bank].bank_num = bank;
+		irqdata[bank].chip = chips;
 
 		irq_set_chained_handler_and_data(chips->irqs[bank],
-						 gpio_irq_handler, irqdata);
+						 gpio_irq_handler, &irqdata[bank]);
 
 		binten |= BIT(bank);
 	}
-- 
2.43.0