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: <56E80F19.7010503@codeaurora.org>
Date:	Tue, 15 Mar 2016 09:33:13 -0400
From:	Sinan Kaya <okaya@...eaurora.org>
To:	Bjorn Helgaas <helgaas@...nel.org>
Cc:	linux-acpi@...r.kernel.org, timur@...eaurora.org,
	cov@...eaurora.org, linux-pci@...r.kernel.org,
	ravikanth.nalla@....com, lenb@...nel.org, harish.k@....com,
	ashwin.reghunandanan@....com, bhelgaas@...gle.com,
	rjw@...ysocki.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] acpi,pci,irq: reduce resource requirements

On 3/14/2016 10:36 PM, Bjorn Helgaas wrote:
> On Mon, Mar 14, 2016 at 10:28:11PM -0400, Sinan Kaya wrote:
>> On 3/14/2016 9:48 PM, Bjorn Helgaas wrote:
>>
>> Yes. I was talking about PCIe on ARM64. 
>>
>>> If you go to Fry's and buy a conventional PCI card, it is going to
>>> pull INTA# low to assert an interrupt.  It doesn't matter whether you
>>> put it in an x86 system or an arm64 system.
>>
>> I don't see INTA# of the PCIe card at the system level. The PCIe wire 
>> interrupt gets converted to the system level interrupt by the PCIe controller.
> 
> That's why I said *conventional PCI*.  If you have a conventional PCI
> device below either a conventional PCI host controller or a PCIe-to-PCI
> bridge, there are real INTx wires, not virtual wires, and they are
> level/low.  But I think you pointed out the key below (that the
> Interrupt resource in a PNP0C0F device encodes the trigger type).
> 
>>>>> I pasted the code here again. It looks like you want to validate that
>>>>> PCI interrupts are always level low. 
>>> I don't really care whether PCI interrupts are always level low.  What
>>> matters is that the PCI interrupt line matches the configuration of
>>> the interrupt controller input.
>>>
>>
>> Agreed. But the interrupt controller configuration is system specific. How would
>> you check interrupt line against what the interrupt controller requires
>> on each architecture as this is common code?
>>
>>
>>> If the PCI interrupt can be a different type, e.g., level high, and
>>> there's a way to discover that, we can check that against the
>>> interrupt controller configuration.
>>>
>>> This is all in the context of conventional PCI, and we're probably
>>> talking about arm64 PCIe systems, not conventional PCI. 
>>
>> INTx interrupts are TLP messages on PCIe as you already know. There is no INTA 
>> interrupt wire.
> 
> Yes, that's why I mentioned PCIe sec 2.2.8.1 below.
> 
>> "6.1.2. PCI Compatible INTx Emulation" section of the PCIe spec describes
>> INTx emulation on PCIe.
>>  ...
>>
>>> I'm not sure what an Interrupt Link device means in PCIe.  I suppose it would have
>>> to connect an INTx virtual wire to a system interrupt?  The PCIe spec
>>> says this sort of mapping is system implementation specific (r3.0, sec
>>> 2.2.8.1).
>>
>> The INTx messages are converted to the system interrupt by the PCIe controller.
>> The interrupt type between the PCIe controller and the ARM GIC interrupt 
>> controller is dictated by the ARM GIC Interrupt Controller Specification for
>> ARM64.
>>
>> Here is what ACPI table looks like for reference
>>
>> 	Name(_PRT, Package(){
>> 		Package(){0x0FFFF, 0, \_SB.LN0A, 0},  // Slot 0, INTA
>> 		Package(){0x0FFFF, 1, \_SB.LN0B, 0},  // Slot 0, INTB
>> 		Package(){0x0FFFF, 2, \_SB.LN0C, 0},  // Slot 0, INTC
>> 		Package(){0x0FFFF, 3, \_SB.LN0D, 0}   // Slot 0, INTD
>> 	}) 
>>
>> Device(LN0A){
>> 	Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
>> 	Name(_UID, 1)
>> 	Name(_PRS, ResourceTemplate(){
>> 	Interrupt(ResourceProducer, Level, ActiveHigh, Exclusive, , ,) {0x123}
>> 	})
> 
> I forgot that the link already include the trigger mode in it.  Maybe we
> can check for that instead of assuming level/low.
> 

Let me explore this area.

> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ