linux-kernel - Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5241B3B4.7020603@collabora.co.uk>
Date:	Tue, 24 Sep 2013 17:45:56 +0200
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Tony Lindgren <tony@...mide.com>
CC:	Santosh Shilimkar <santosh.shilimkar@...com>,
	Kevin Hilman <khilman@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Lars Poeschel <larsi@....tu-dresden.de>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Kumar Gala <galak@...eaurora.org>,
	Pawel Moll <pawel.moll@....com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Enric Balletbo i Serra <eballetbo@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Balaji T K <balajitk@...com>,
	Jon Hunter <jgchunter@...il.com>, linux-gpio@...r.kernel.org,
	linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, r.sricharan@...com,
	holler@...oftware.de
Subject: Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ

On 09/24/2013 05:40 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas <javier.martinez@...labora.co.uk> [130924 01:06]:
>> The OMAP GPIO controller HW requires a pin to be configured in GPIO
>> input mode in order to operate as an interrupt input. Since drivers
>> should not be aware of whether an interrupt pin is also a GPIO or not,
>> the HW should be fully configured/enabled as an IRQ if a driver solely
>> uses IRQ APIs such as request_irq(), and never calls any GPIO-related
>> APIs. As such, add the missing HW setup to the OMAP GPIO controller's
>> irq_chip driver.
>> 
>> Since this bypasses the GPIO subsystem we have to ensure that another
>> caller won't be able to request the same GPIO pin that is used as an
>> IRQ and set its direction as output. Requesting the GPIO and setting
>> its direction as input is allowed though.
> 
> Also please mention the regression that this fixes. So far we know
> that smsc911x for tobi and igep boards in mainline, and also the
> MMC card detect for omap4 boards.
>  

Ok, I'll mention that on the next post.

>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -63,6 +63,7 @@ struct gpio_bank {
>>  	struct gpio_chip chip;
>>  	struct clk *dbck;
>>  	u32 mod_usage;
>> +	u32 irq_usage;
>>  	u32 dbck_enable_mask;
>>  	bool dbck_enabled;
>>  	struct device *dev;
>> @@ -86,6 +87,9 @@ struct gpio_bank {
>>  #define GPIO_BIT(bank, gpio) (1 << GPIO_INDEX(bank, gpio))
>>  #define GPIO_MOD_CTRL_BIT	BIT(0)
>>  
>> +#define BANK_USED(bank) (bank->mod_usage || bank->irq_usage)
>> +#define LINE_USED(line, offset) (line & (1 << offset))
> 
> Hmm this patch is hard to read, maybe break it into two patches?
> 
> First you could do a patch to prepare thing by introducing
> BANK_USED and LINE_USED.
> 
>> +static int gpio_is_input(struct gpio_bank *bank, int mask)
>> +{
>> +	void __iomem *reg = bank->base + bank->regs->direction;
>> +
>> +	return __raw_readl(reg) & mask;
>> +}
> 
> And also move gpio_is_input() around in the first patch.
> 
> Then the second patch for the fix would probably be much
> easier to read.
>

Sure will split in more patches, I just wanted to keep in one patch since it was
a RFC but it seems that the change makes sense so I'll post it as a proper
patch-set.

> Regards,
> 
> Tony
> 

Thanks a lot for your feedback and best regards,
Javier
--
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/