linux-kernel - RE: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze

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: <8520D5D51A55D047800579B09414719825873DCF@XAP-PVEXMBX01.xlnx.xilinx.com>
Date:	Wed, 27 Jan 2016 14:41:27 +0000
From:	Bharat Kumar Gogada <bharat.kumar.gogada@...inx.com>
To:	Arnd Bergmann <arnd@...db.de>, Michal Simek <michals@...inx.com>
CC:	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
	"paul.burton@...tec.com" <paul.burton@...tec.com>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"wangyijing@...wei.com" <wangyijing@...wei.com>,
	"robh@...nel.org" <robh@...nel.org>,
	"russell.joyce@...k.ac.uk" <russell.joyce@...k.ac.uk>,
	Soren Brinkmann <sorenb@...inx.com>,
	"jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>,
	"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>,
	"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 V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge
 driver to work on both Zynq and Microblaze

> 
> On Tuesday 26 January 2016 10:59:12 Michal Simek wrote:
> > >> diff --git a/drivers/pci/host/pcie-xilinx.c
> > >> b/drivers/pci/host/pcie-xilinx.c index 3e3757f..1981948 100644
> > >> --- a/drivers/pci/host/pcie-xilinx.c
> > >> +++ b/drivers/pci/host/pcie-xilinx.c
> > >> @@ -92,7 +92,12 @@
> > >>  #define ECAM_DEV_NUM_SHIFT          12
> > >>
> > >>  /* Number of MSI IRQs */
> > >> -#define XILINX_NUM_MSI_IRQS         128
> > >> +#define XILINX_NUM_MSI_IRQS 128
> > >> +#ifdef CONFIG_ARM
> > >> +#define TOT_NR_IRQS         XILINX_NUM_MSI_IRQS
> > >> +#else
> > >> +#define TOT_NR_IRQS         (NR_IRQS + XILINX_NUM_MSI_IRQS)
> > >> +#endif
> > >
> > > Something looks wrong here in the microblaze variant. What does
> > > NR_IRQS have to do with it?
> >
> > Arnd: What was the story regarding NR_IRQS?
> > I remember some discussion about it but just forget.
> >
> > Default value in include/asm-generic/irq.h is 64.
> > Current value is 32 because microblaze primary interrupt controller is
> > axi_intc core which has up to 32 input lines.
> 
> The value in asm-generic is completely arbitrary, it's just something that
> happens to work for a number of the simpler architectures.
> 
> Traditionally, there is a a fixed NR_IRQS which defines the maximum number
> of interrupts that can be used, and each irqchip has a fixed start offset below
> that number.
> 
> On modern systems, you have CONFIG_SPARSE_IRQ, which lets an irqchip
> allocate its own interrupts, without an upper limit. This is more flexible and
> avoids preallocating space for all irq_desc instances, so it saves memory.
> 
> This code however doesn't do either of the two on microblaze:
> 
> +       irq = pos;
> +#ifdef CONFIG_MICROBLAZE
> +#define TOT_NR_IRQS            (NR_IRQS + XILINX_NUM_MSI_IRQS)
> +       irq = XILINX_NUM_MSI_IRQS + pos; #endif
> +       if (irq < TOT_NR_IRQS)
>                 set_bit(pos, msi_irq_in_use);
> 
> So you define XILINX_NUM_MSI_IRQS to mean the number of interrupts
> that the xilinx_pcie_port can handle itself, but then pick a number
> outside of this range by making the hwirq number something between
> XILINX_NUM_MSI_IRQS and (2*XILINX_NUM_MSI_IRQS - 1), and in the
> end compare it to (NR_IRQS + XILINX_NUM_MSI_IRQS), which is the
> sum of two things that are not related: the total number of interrupts
> including the MSIs and the number of MSI.
> 
Agreed, I have crosschecked something's which I missed previously, NR_IRQS have nothing to do with the count, and also no need to add, irq = XILINX_NUM_MSI_IRQS + pos; in microblaze, I will remove these checks in next patch series.