lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1281971684-16505-1-git-send-email-w.sang@pengutronix.de>
Date:	Mon, 16 Aug 2010 17:14:44 +0200
From:	Wolfram Sang <w.sang@...gutronix.de>
To:	linux-kernel@...r.kernel.org
Cc:	Wolfram Sang <w.sang@...gutronix.de>,
	Rabin Vincent <rabin.vincent@...ricsson.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Samuel Ortiz <sameo@...ux.intel.com>
Subject: [RFC] gpio/stmpe: add bitmask to block requests to unavailable GPIOs

GPIOs on these controller are multi-functional. If you decided to use
some of them e.g. as input channels for the ADC, you surely don't want
those pins to be reassigned as simple GPIOs (which may be triggered even
from userspace via 'export'). Same for the touchscreen controller pins.
Since knowledge about the hardware is needed to decide which GPIOs to
reserve, let this bitmask be inside platform_data and provide some
defines to assist potential users.

Signed-off-by: Wolfram Sang <w.sang@...gutronix.de>
Cc: Rabin Vincent <rabin.vincent@...ricsson.com>
Cc: Linus Walleij <linus.walleij@...ricsson.com>
Cc: Samuel Ortiz <sameo@...ux.intel.com>
---

Tested on a custom board. I'm not sure if this is the best solution. Now, using
'export' might fail without the GPIO in question appearing in debugfs. That
might be confusing. Still, it should be a lot safer than being able to change
the pins via userspace.

 drivers/gpio/stmpe-gpio.c |    5 +++++
 include/linux/mfd/stmpe.h |    6 ++++++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/stmpe-gpio.c b/drivers/gpio/stmpe-gpio.c
index 4e1f1b9..65b9960 100644
--- a/drivers/gpio/stmpe-gpio.c
+++ b/drivers/gpio/stmpe-gpio.c
@@ -30,6 +30,7 @@ struct stmpe_gpio {
 	struct mutex irq_lock;
 
 	int irq_base;
+	unsigned norequest_mask;
 
 	/* Caches of interrupt control registers for bus_lock */
 	u8 regs[CACHE_NR_REGS][CACHE_NR_BANKS];
@@ -103,6 +104,9 @@ static int stmpe_gpio_request(struct gpio_chip *chip, unsigned offset)
 	struct stmpe_gpio *stmpe_gpio = to_stmpe_gpio(chip);
 	struct stmpe *stmpe = stmpe_gpio->stmpe;
 
+	if (stmpe_gpio->norequest_mask & (1 << offset))
+		return -EINVAL;
+
 	return stmpe_set_altfunc(stmpe, 1 << offset, STMPE_BLOCK_GPIO);
 }
 
@@ -302,6 +306,7 @@ static int __devinit stmpe_gpio_probe(struct platform_device *pdev)
 
 	stmpe_gpio->dev = &pdev->dev;
 	stmpe_gpio->stmpe = stmpe;
+	stmpe_gpio->norequest_mask = pdata ? pdata->norequest_mask : 0;
 
 	stmpe_gpio->chip = template_chip;
 	stmpe_gpio->chip.ngpio = stmpe->num_gpios;
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index 90faa98..845abaa 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -112,13 +112,19 @@ struct stmpe_keypad_platform_data {
 	bool no_autorepeat;
 };
 
+#define STMPE_GPIO_NOREQ_811_TOUCH	(0xf0)
+
 /**
  * struct stmpe_gpio_platform_data - STMPE GPIO platform data
  * @gpio_base: first gpio number assigned.  A maximum of
  *	       %STMPE_NR_GPIOS GPIOs will be allocated.
+ * @norequest_mask: bitmask specifying which GPIOs should _not_ be
+ *		    requestable due to different usage (e.g. touch, keypad)
+ *		    STMPE_GPIO_NOREQ_* macros can be used here.
  */
 struct stmpe_gpio_platform_data {
 	int gpio_base;
+	unsigned norequest_mask;
 	void (*setup)(struct stmpe *stmpe, unsigned gpio_base);
 	void (*remove)(struct stmpe *stmpe, unsigned gpio_base);
 };
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ