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>] [day] [month] [year] [list]
Date:	Mon, 13 Jul 2015 16:21:17 +0300
From:	Roger Quadros <rogerq@...com>
To:	nick <xerofoify@...il.com>, Tony Lindgren <tony@...mide.com>
CC:	<devicetree@...r.kernel.org>, <computersforpeace@...il.com>,
	<linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
	<ezequiel@...guardiasur.com.ar>, <bcousson@...libre.com>,
	<linux-omap@...r.kernel.org>, <dwmw2@...radead.org>
Subject: Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to
 NAND driver

On 13/07/15 16:15, nick wrote:
> 
> 
> On 2015-07-13 09:12 AM, Roger Quadros wrote:
>> On 13/07/15 16:03, nick wrote:
>>>
>>>
>>> On 2015-07-13 09:01 AM, Tony Lindgren wrote:
>>>> * nick <xerofoify@...il.com> [150713 05:54]:
>>>>> On 2015-07-13 08:40 AM, Tony Lindgren wrote:
>>>>>> * Roger Quadros <rogerq@...com> [150713 03:07]:
>>>>>>  
>>>>>>> What is the best map we should use for irqchip?
>>>>>>> Some Socs have 4 WAIT pins, some have 3 and some have 2.
>>>>>>>
>>>>>>> Should we start with 0,1,2, for the wait pins and use the next
>>>>>>> available free one for the NAND?
>>>>>>
>>>>>> Maybe we can just use the bits defined for each SoC in the
>>>>>> GPMC_IRQSTATUS register for the mapping?  
>>>>>> Regards,
>>>>>
>>>>> Is that a good idea as to my knowledge of OMAP platforms that register is hardware
>>>>> dependent and therefore that may be an issue unless your idea is to create device
>>>>> tables like the way they do in the nand subsystems to support various vendor's 
>>>>> nand flash expect here for the pins on OMAP SOCs.
>>>>
>>>> Do you mean mapping irqs based on the GPMC_IRQSTATUS register
>>>> bits? If so, that's pretty much how all the GPIO drivers
>>>> handle them. We can have a SoC specific irqmask of the valid
>>>> bits passed from the dts files, and if necessary we can also
>>>> add custom SoC specific IRQ handlers to the GPMC driver if
>>>> needed.
>>>>
>>>> The idea is that the NAND driver can just request the irq
>>>> from the GPMC driver and do whatever it wants with the
>>>> interrupt.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>>>
>>> Tony,
>>> That is what I was hoping the code was doing. So what appears to be the problem with the 
>>> patches related to irq requesting from the GPMC driver.
>>> Cheers,
>>> Nick 
>>>
>>
>> The problem with this patch is that it expects GPMC_IRQ registers
>> to be accessible by the NAND driver and looses the 2 to 4 pins
>> of WAIT pin edge detection interrupt capability if it is needed
>> for generic use. (not NAND/GPMC memory specific)
>>
>> cheers,
>> -roger
>>
> I am not sure if this is possible with OMAP boards but can we split the pins
> into 1 or 2 for NAND/GPMC memory specific and use the others for WAIT interrupt
> capability.
> Nick
> 
Yes if the wait pins are not used for NAND/GPMC memory then they can be used
as generic edge detect interrupt or probably even a GPI.
I don't see what would prevent it.

I'm not sure if anyone will dare to use them though as they weren't originally meant
for that use and none of the existing kernels support that. So it is really a
chicken and egg situation here. :)

But I see value in doing it the way Tony says cause it is much cleaner to specify
which interrupt (or wait pin) you want for NAND use.

cheers,
-roger
--
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