From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [PATCH 1/2] xen: arm: log warning for interrupt
 configuration mismatch
Date: Mon, 02 Mar 2015 13:48:55 +0000
Message-ID: <54F46A47.1040906@linaro.org>
References: <1424359395.30924.89.camel@citrix.com>		
	<1424359443-21584-1-git-send-email-ian.campbell@citrix.com>		
	<54F23D65.8000602@linaro.org>
	<1425294756.1886.33.camel@citrix.com>	
	<54F45E11.8070305@linaro.org>
	<1425303755.21151.20.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1425303755.21151.20.camel@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <ian.campbell@citrix.com>
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, Pranavkumar Sawargaonkar <psawargaonkar@apm.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 02/03/15 13:42, Ian Campbell wrote:
>>> I even reread the spec before sending and reached the same conclusion,
>>> but apparently managed to fail to change the actual code!
>>>
>>> Question is -- what to do about PPIs, since the CFG register cannot
>>> express the polarity of the edge or level. I suppose we may as well just
>>> assume the one that is compatible with SPIs, since we have nothing
>>> better to go on.
>>
>> Linux seems to set edge (resp. level) bit for any edge (resp. level)
>> type interrupts.
> 
> Right, sorry I wasn't clear. We should obviously do this too when
> writing to ICFG (I believe we do), the case I was talking about was the
> one relating to the quoted code above: when we read back ICFG and find
> that the setting hasn't taken. In that case we want to update
> desc->arch.type to somehow reflect "reality", which requires us to
> fabricate a polarity for the interrupt (rising/falling or low/high).

desc->arch.type is only used in Xen for IRQ configuration.

Given that, I was wondering if it would be useful to only store
EDGE/LEVEL in the desc->arch.type and, therefore, ignoring
rising/falling and low/high.

That would make the code simpler.

Regards,

-- 
Julien Grall