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]

Date:	Wed, 24 Jul 2013 12:38:51 -0400
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Nishanth Menon <nm@...com>
CC:	Sricharan R <r.sricharan@...com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"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>,
	ext Tony Lindgren <tony@...mide.com>,
	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 Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote:
> On 07/22/2013 11:23 AM, Santosh Shilimkar wrote:
>> To summaries it again, what I understood from Sricharan's proposal,
>>
>> - Setup all the routing at cross-bar probe so that kernel continue to
>> work like normal IRQ controller with cross-bar scope vanishes once
>> the routing is done. Cross-bar does this before any of the devices
>> are created.
>> - Something similar needs to happen for DMA lines as well or for any
>> other event routing in future.
>> - Cross-bar callbacks for device drivers for error paths.
>> (Sricharan, you have to drop these because it doesn't bring any
>> functionality and rather can create a side effects of drivers
>> getting polluted.)
> Ack.
> 
>>
>> The concern raised on above was instead of fixing the routing at DT
>> statically, doing at the driver probes where the loop-up for IRQ or DMA
>> lines should happen in background transparently on drivers call of
>> request_irq/request_dma_channel etc with cross-bar number as
>> an input to it. Though it will be nice to have
>> such feature, it doesn't bring anything special and brings the
>> notion of these APIs which expect that you know what IRQ and DMA
>> lines you want while calling these.
> Unfortunately, we do have a constraint without allocating dynamic IRQs - what IP instances should hwmod and dts contain?
> 
> If we go with current series of patches[1] [2] for DRA7 dts which assumes default mapping, hence, uart7-10, GPTimers12-16 dont have default irq - hence they dont exist in dts etc.
> 
> How would we like to support those with pinctrl approach?
>
The whole reason the cross-bar being there because all the peripherals
IRQs can not me routed to the IRQ controller. So You pick up a configuration
would like to support and stick to it. It will be good to specify all the
peripheral devices but tsome of them might not have the IRQ/DMA lines
associated with them because of limited slots on IRQ/DMA controller.

>>
>> Note that mux inputs are pretty much fixed. Its his connection
>> to IRQ controller or DMA controller is what needs to be programmed.
>> So scope is pretty much limited. I felt this requirement is pretty
>> similar to pin-mux and hence thought of it as a viable option.
>>
>> Having said all of above, if there is a better alternative than
>> enhanced pin-mux we surely can do that.
> We could look at it as a signal mux problem as this thread suggests OR look at it as interrupt distribution problem (which is how it looks like at the face of it).
Its not interrupt distribution problem but rather setting up the signal
routing which otherwise generally hardwired in SOC. Hence the pin-control analogy.
Pinmux also lets you set many possible combinations but we pick one for a board design.

> That said, maybe a intermediate pinctrl approach might be more pragmatic andless theoretically flexible.
> an option might be to "statically allocate" default number of interrupts to a domain - example:
> * GIC IRQ 72->78 allotted to UARTs
> * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use)
> * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel.
> 
> Does that sound fair trade off?
This sounds better. That way we can get all the devices in the DT at least.

Regards,
Santosh

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