linux-kernel - Re: Subject: L2x0 OF properties do not include interrupt #

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: <4E42965A.9010500@calxeda.com>
Date:	Wed, 10 Aug 2011 09:31:54 -0500
From:	Rob Herring <rob.herring@...xeda.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux@....linux.org.uk, tglx@...utronix.de, weizeng.he@....com,
	workgroup.linux@....com, 'Barry Song' <21cnbao@...il.com>,
	'Grant Likely' <grant.likely@...retlab.ca>,
	'Olof Johansson' <olof@...om.net>,
	Will Deacon <Will.Deacon@....com>
Subject: Re: Subject: L2x0 OF properties do not include interrupt #

Arnd,

On 08/10/2011 09:09 AM, Arnd Bergmann wrote:
> On Wednesday 10 August 2011, Mark Rutland wrote:
> 
>> I realise I'm a bit late to the party here, but I'd like to propose adding an
>> optional interrupt parameter to the binding. I'm not aware of any
>> implementations which use separate interrupts, but given the binding
>> seems to be generic across L2CC implementations (and is not limited simply to
>> the L2x0), having a list rather than a single interrupt may be appropriate for
>> someone.
> 
> Sounds good, thanks for pointing this out.
> 
> How many possible interrupt sources are there? If there is only a small number
> of those (e.g. at most 4), we might just list all of them and register
> them from the driver even if they are all the same.
> 

Here's all the interrupts on the PL310:

DECERRINTR Decode error received on master ports from L3
SLVERRINTR Slave error received on master ports from L3
ERRRDINTR Error on L2 data RAM read
ERRRTINTR Error on L2 tag RAM read
ERRWDINTR Error on L2 data RAM write
ERRWTINTR Error on L2 tag RAM write
PARRDINTR Parity error on L2 data RAM read
PARRTINTR Parity error on L2 tag RAM read
ECNTRINTR Event Counter Overflow/Increment
L2CCINTR L2CC Combined Interrupt Output

It's likely that you would want to split these to different drivers.
EDAC for parity/bus errors and hw-events for event counters, for example.

Rob

>> This would boil down to (for the moment) a Documentation change along the lines of:
>>
>>> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
>>> index f50e021..d4b387b 100644
>>> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
>>> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
>>> @@ -28,6 +28,7 @@ Optional properties:
>>>  - arm,filter-ranges : <start length> Starting address and length of window to
>>>    filter. Addresses in the filter window are directed to the M1 port. Other
>>>    addresses will go to the M0 port.
>>> +- interrupt : A combined interrupt.
>>>  
>>>  Example:
>>>  
>>> @@ -39,4 +40,5 @@ L2: cache-controller {
>>>          arm,filter-latency = <0x80000000 0x8000000>;
>>>          cache-unified;
>>>          cache-level = <2>;
>>> +        interrupt = <45>;
>>>  };
>>
>> Any thoughts?
> 
> Do we also need to document an interrupt-parent property, or is that implied?
> 
> 	Arnd

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