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] [thread-next>] [day] [month] [year] [list]
Message-ID: <521719D8.7060506@ti.com>
Date:	Fri, 23 Aug 2013 13:44:16 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Sricharan R <r.sricharan@...com>
CC:	Rajendra Nayak <rnayak@...com>, Nishanth Menon <nm@...com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/3] misc: Add crossbar driver

On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
> On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
>> On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
>>> Hi,
>>> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
>>>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
>>>>>  maps crossbar number<->  to interrupt number and
>>>>>  calls request_irq(int_no, crossbar_handler,..)
>>>> So will this mapping happen based on some data passed from DT or
>>>> just based on whats available when the device does a request_irq()?
>>>>
>>>> If its based on whats available then I see an issue when you need
>>>> to remap something thats already mapped by default (and not used)
>>>> since you run out of all free ones.
>>> Yes, when done based on what is available then there is a
>>> problem when we run out of free ones because we do not
>>> know which one to replace. I was thinking of something like
>>> this,
>>>     1) DT would give a list of all free ones, and also if some are
>>>         mapped as default and not used, mark those also as free.
>>>
>>>      2) While mapping see if it has a default mapping and use it.
>>>           otherwise, pick from free list.   
>> Since the entire DT is available to you at boot time, you should be able
>> to find each node where interrupt-parent = <&crossbar> and then allocate
>> one of 0-160 GIC interrupt numbers for that node, no? Where would there
>> be a need for default mapping and remapping? From one the mails in the
>> thread the crossbar is completely flexible - any of the 320 crossbar
>> interrupts can be mapped to any of the 160 GIC interrupts.
>>
>> Any GIC interrupts left after this boot-time scan can be added to an
>> unused list for use with runtime DT fragments (when that support comes).
>>  
>> Sorry if I misunderstood, but above proposal sounds like maintaining a
>> separate free interrupt lines list in DT. That will quickly go out of sync.
>  Say, peripheral x uses crossbar 1 and specifies this in DT.
>  During boot crossbar 1 gets mapped int 10. So if by default
> some other crossbar has its interrupt mapped to 10,
> then it should be removed.  Instead clear all crossbar registers
> once and mark all as free, then  allocate only during request.
> Correct ?. In this the free no need to maintain any list.

Right, so in my suggestion there is nothing like a "default mapping" and
entire 160 GIC interrupt number space is up for grabs. I think this will
be much simpler to write and maintain.

If you really want to maintain default mapping as far as possible, you
can do two passes on the crossbar interrupt numbers requested. Once to
assign the default map - for numbers less that 160 - and then look at
the free GIC interrupt slots and use those for numbers greater than 160.

Thanks,
Sekhar


--
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