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  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]
Date:	Fri, 8 Aug 2014 16:58:49 -0700
From:	Doug Anderson <>
To:	Javier Martinez Canillas <>
Cc:	Dmitry Torokhov <>,
	Nick Dyer <>,
	Stephen Warren <>,
	Yufeng Shen <>,
	Benson Leung <>,
	Olof Johansson <>,
	Tomasz Figa <>,
	"" <>,
	"" <>,
	linux-samsung-soc <>,
	"" <>,
	Thomas Gleixner <>,
	Jason Cooper <>,
	Benjamin Herrenschmidt <>,
	Thomas Abraham <>
Subject: Re: [PATCH v2 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on
 DT booting


On Fri, Aug 8, 2014 at 3:26 PM, Javier Martinez Canillas
<> wrote:
>> I have some vague recollection that I set interrupts to pin-function
>> "0" by default for some reason (assuming they would go to 0xf when
>> interrupts were enabled).  ...but I can't for the life of me remember
>> if it was a good reason or just seemed like the right thing to do.
> It would be great to know if there is a good reason. I see indeed that all
> pinctrl setup in the Peach Pit/Pi and Snow DTS that involves interrupts are
> using 0x0 as the pin function. Since as Tomasz explained Samsung SoC makes a
> difference between GPIO-IRQ and GPIO input I guess that it's better to change
> those to 0xf instead. What do you think?

I think it's worth trying out.  If there are no problems with it then
let's do it.

My vague recollection is that I was worried that pinctrl would take
effect right at driver probe time (maybe this used to happen? or maybe
I imagined it?) and that configuring to 0xf at this point in time
would cause a spurious interrupt.  I can't remember ever testing it so
it was probably just something I imagined.  Even if it was configured
as 0xf I'd imagine that the interrupt would be masked anyway so there
should be no spurious interrupt, right?

> Regardless of this though I think that both the patch to move the IRQ
> pinmux setup from .irq_set_type to the .irq_request_resources and the patch to
> to prevent any pinmux reconfiguration are good improvements to avoid future
> issues like the one we found here.

OK.  I'll let you, Tomasz, and Linus figure out what's best here since
I haven't done extensive thinking on it.  ;)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists