linux-kernel - Re: [PATCH] pinctrl: sirf: lock IRQs when starting them

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-prev] [day] [month] [year] [list]

Date:	Mon, 27 Jan 2014 11:02:15 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Barry Song <21cnbao@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Binghua Duan <Binghua.Duan@....com>,
	Rongjun Ying <rongjun.ying@....com>, guoying.zhang@....com,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>
Subject: Re: [PATCH] pinctrl: sirf: lock IRQs when starting them

On Mon, Jan 27, 2014 at 8:01 AM, Barry Song <21cnbao@...il.com> wrote:

> i read the patch "gpio: add API to be strict about GPIO IRQ usage"
> again, it seems by checking if (test_bit(FLAG_USED_AS_IRQ,
> &desc->flags)), we do be able to stop users setting irqline to output.

Yes that is the specific use of that flag right now.

> but my concern is actually that: when users use request_irq to get the
> irq line from gpio, in that case, gpio_request() probably will not be
> called at all,

This question has come up a lot recently as we recently established
that irqchip and gpiolib APIs are orthogonal, just like you say.

> who will fix the availability of this pin if it is
> muxed with other functionality except gpio?

So the problem is with the established semantic that
irqchips and gpiochips are orthogonal, not with this
particular patch, right?

Muxing is the responsibility of the pin control pin mux
subsystem and not GPIO.

If you require pinctrl_request_gpio() to be called from the
gpiolib driver for the pin to be muxed in, then this function must
be called from the irqchip side as well, e.g. from .irq_startup().

> but if gpio_request() is called, in it, pinctrl_request_gpio() is
> called as well, which will mark the pin as not-free. so do you think
> we need to call pinctrl_request_gpio() in startup() of irqline as
> well?

I think so.

> but this might be buggy again since people might call
> gpio_request() before calling request_irq().

Hm, you should study this problem and suggest the best
solution. In general I do not think it hurts to call
pinctrl_request_gpio() multiple times, and if it does maybe
that is something we want to fix?

Yours,
Linus Walleij
--
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/