linux-kernel - Re: [PATCH 1/3] misc: Add crossbar driver

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: <5216160D.5000308@ti.com>
Date:	Thu, 22 Aug 2013 09:45:49 -0400
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Sricharan R <r.sricharan@...com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Tony Lindgren <tony@...mide.com>, Nishanth Menon <nm@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Rajendra Nayak <rnayak@...com>, Felipe Balbi <balbi@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH 1/3] misc: Add crossbar driver

On Thursday 22 August 2013 07:33 AM, Sricharan R wrote:
> Hi Linus,
> 
> On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote:
>> On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar
>> <santosh.shilimkar@...com> wrote:
>>> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote:
>> (...)
>>>> Sorry I don't understand what thread that is... can you point me there?
>>>> My previous statement on this issue what this:
>>>> http://marc.info/?l=linux-kernel&m=137442541628641&w=2
>> (...)
>>>>> I don't see how you can make this happen with an irqchip
>>>>> infrastructure.
>>>> I think my post above describes this.
>>>>
>>> Sorry for being dumb but I don't think cascaded irqchip examples
>>> like GPIO and cross-bars are same. If you take an example of
>>> GPIO irqchip, it always have a physical connection even if it
>>> is 1 IRQ line for (32 logical/sparse IRQs). That goes with
>>> other MFD examples too.
>>>
>>> So may be I am still missing something in your proposal.
>> Why does it matter if it is a GPIO or MFD or whatever?
>> The point is that the IRQ line passes thru something else,
>> and this we model as an irqdomain.
>>
>> Anyway here is a silicon cascaded IRQ chip:
>> arch/arm/mach-versatile/core.c
>> See versatile_init_irq():
>>
>> __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np);
>> (...)
>> fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START,
>>                 IRQ_VICSOURCE31, PIC_VALID, np);
>>
>> The VIC in the versatile has the SIC cascaded from one of
>> its IRQ lines. Both the VIC and SIC (fpga IRQ) are
>> using irqdomains so the SIC spawns a child irqdomain
>> from IRQ 31 (last IRQ) of the VIC.
>  Ok, this is a typical example of irqchip cascaded.
>> The difference with a crossbar is that it can software-config
>> which IRQ goes where, and does not have a callback
>> to clear interrupts or anything like that, it just passes them
>> thru. But it is best modeled as an irqdomain IMO.
> We can model crossbar as irqchip and gic as its interrupt parent
> and peripherals to have crossbar as interrupt-parent.
>    
>  peripherals will do request_irq(crossbar_number)
>               |
>               |
>  crossbar_unmask()
>               |
>               |
>  maps crossbar number<->  to interrupt number and
>  calls request_irq(int_no, crossbar_handler,..)
> 
>  
>  crossbar_handler(interrupt number)
>             |
>             |
>  get crossbar number from interrupt number
>             |
>             |
>  handle_irq(crossbar_domain(crossbar number))
>                                                                              
> 
> So this means a extra dummy handler.
Its not optimal to go through the dummy call stack on
fast path but considering its not going to eat too many
instructions, its fine to have dummy handler. We should
try this out.

> Also the concern is by modelling it as irqchip, we will have
> to find a different solution for DMA crossbar.
> 
DMAEngine has a notion of logical channel and that was actually
used in the EDMA support series by Matt [1]
We can do something similar to handle that scenario.


[1] https://lkml.org/lkml/2013/6/18/56

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