linux-kernel - Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

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, 04 Nov 2015 08:49:05 +0000
From:	Marc Zyngier <marc.zyngier@....com>
To:	Bharat Kumar Gogada <bharat.kumar.gogada@...inx.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	Michal Simek <michals@...inx.com>,
	Soren Brinkmann <sorenb@...inx.com>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"arnd@...db.de" <arnd@...db.de>,
	"tinamdar@....com" <tinamdar@....com>,
	"treding@...dia.com" <treding@...dia.com>,
	"rjui@...adcom.com" <rjui@...adcom.com>,
	"Minghuan.Lian@...escale.com" <Minghuan.Lian@...escale.com>,
	"m-karicheri2@...com" <m-karicheri2@...com>,
	"hauke@...ke-m.de" <hauke@...ke-m.de>,
	"dhdang@....com" <dhdang@....com>,
	"sbranden@...adcom.com" <sbranden@...adcom.com>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Ravikiran Gummaluri <rgummal@...inx.com>
Subject: Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
 PCIe Host Controller

On 04/11/15 06:38, Bharat Kumar Gogada wrote:
>>> +static struct msi_domain_info nwl_msi_domain_info = {
>>> +	.flags = (MSI_FLAG_USE_DEF_DOM_OPS |
>> MSI_FLAG_USE_DEF_CHIP_OPS |
>>> +		  MSI_FLAG_MULTI_PCI_MSI),
>>
>> If you're supporting multi-MSI, how do you ensure that all hwirqs are
>> contiguous as required by the spec? Clearly, your allocator doesn't provide
>> this guarantee.
>>
> Oh ok, then how can we know if one EP is requesting for multiple irq's, because in pci_enable_msi_range,
>  it does do while loop according to msi_capability_init return value 
> which in turn requests for multiple irq's. Is there any way to find out when single EP requesting for multiple MSI?

Please read what I've written: hwirqs *must* be contiguous for
multi-MSI. If the device requests 4 MSIs, they *must* be in the [x,x+3]
range. Your allocator only allocates one interrupt at time (ignoring the
nr_irqs parameter).

You shouldn't try to find what the device does, that's irrelevant at
that level.

>> Also, you still lack support for MSI-X (which would come for free...).
> 
> We don't support MSI-X in root port mode.

I don't believe you. If you support single MSI, you support MSI-X
(because that's mostly a property of the endpoint).

>>> +	.chip = &nwl_msi_irq_chip,
>>> +};
>>> +#endif
>>> +
>>> +	irq_domain_remove(pcie->legacy_irq_domain);
>>> +
>>> +#ifdef CONFIG_PCI_MSI
>>> +	irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
>>> +	irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);
>>> +
>>> +	irq_domain_remove(msi->msi_domain);
>>> +	irq_domain_remove(msi->dev_domain);
>>> +#endif
>>> +
>>> +}
>>
>> Remove these #ifdefs. You can test the validity of these fields before calling
>> the various functions. You can also move this to a separate function.
> 
> Without #ifdefs if we compile driver for legacy, MSI structures will not be available and we get compile time error.

Legacy? Legacy interrupts? The msi structure is still there, you've
embedded it in your pcie structure. Let me spell it out for you:

static void nwl_msi_free_domain(struct nwl_pcie *pcie)
{
	struct nwl_msi *msi = &pcie->msi;

	if (msi->irq_msi0)
		irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
	if (msi->irq_msi1)
		irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);

	if (msi->msi_domain)
		irq_domain_remove(msi->msi_domain);
	if (msi->dev_domain)
		irq_domain_remove(msi->dev_domain);
}

static void nwl_pcie_free_irq_domain(struct nwl_pcie *pcie)
{
	int i;
	u32 irq;

	for (i = 0; i < 4; i++) {
		irq = irq_find_mapping(pcie->legacy_irq_domain, i + 1);
		if (irq > 0)
			irq_dispose_mapping(irq);
	}

	irq_domain_remove(pcie->legacy_irq_domain);

	nwl_msi_free_domain(pcie);
}

>>> +
>>> +	/* setup AFI/FPCI range */
>>> +	msi->pages = __get_free_pages(GFP_KERNEL, 0);
>>> +	base = virt_to_phys((void *)msi->pages);
>>> +	nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
>>> +	nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
>>
>> I just read this, and I'm puzzled. Actually, puzzled is an understatement. Why
>> on Earth do you need to give RAM to your MSI HW?
>> This should be a device, not RAM. By the look of it, this could be absolutely
>> anything. Are you sure you have to supply RAM here?
>>
> This is required in our hardware, so that bridge identifies incoming MWr as MSI.

I'm asking why this has to be RAM. What is the actual requirement?

	M.
-- 
Jazz is not dead. It just smells funny...
--
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/