linux-kernel - Re: [PATCH V4 3/3] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC

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: <3532163.SqzZzxO4BR@wuerfel>
Date:	Wed, 12 Jun 2013 12:55:36 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Jingoo Han <jg1.han@...sung.com>,
	'Kukjin Kim' <kgene.kim@...sung.com>,
	'Bjorn Helgaas' <bhelgaas@...gle.com>,
	'Thomas Petazzoni' <thomas.petazzoni@...e-electrons.com>,
	'Jason Gunthorpe' <jgunthorpe@...idianresearch.com>,
	linux-samsung-soc@...r.kernel.org,
	'Siva Reddy Kallam' <siva.kallam@...sung.com>,
	linux-pci@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	'Thierry Reding' <thierry.reding@...onic-design.de>,
	linux-kernel@...r.kernel.org,
	'Grant Likely' <grant.likely@...retlab.ca>,
	'Surendranath Gurivireddy Balla' <suren.reddy@...sung.com>,
	'Thomas Abraham' <thomas.abraham@...aro.org>,
	'Andrew Murray' <andrew.murray@....com>
Subject: Re: [PATCH V4 3/3] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC

Thanks for the update! A few comments again:

On Wednesday 12 June 2013 19:20:00 Jingoo Han wrote:
> 
> diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> index d55042b..efe7d39 100644
> --- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> +++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> @@ -30,4 +30,12 @@
>                         clock-frequency = <50000000>;
>                 };
>         };
> +
> +       pcie0@...00000 {
> +               reset-gpio = <5>;
> +       };
> +
> +       pcie1@...00000 {
> +               reset-gpio = <22>;
> +       };
>  };

As mentioned before, please use the gpio binding to pass gpio numbers.

> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
> index f6b1c89..2c15f9d 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -216,4 +216,42 @@
>                 clock-names = "rtc";
>                 status = "disabled";
>         };
> +
> +       pcie0@...90000 {
> +               compatible = "samsung,exynos5440-pcie";
> +               reg = <0x290000 0x1000
> +                       0x270000 0x1000
> +                       0x271000 0x40>;
> +               interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> +               clocks = <&clock 28>, <&clock 27>;
> +               clock-names = "pcie", "pcie_bus";
> +               #address-cells = >;
> +               #size-cells = <2>;
> +               device_type = "pci";
> +               ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00200000   /* configuration space */
> +                         0x81000000 0 0          0x40200000 0 0x00010000   /* downstream I/O */
> +                         0x82000000 0 0x40210000 0x40210000 0 0x10000000>; /* non-prefetchable memory */

I think you did not reply to my question regarding the size of the
memory space. Does it extend from 0x40210000 to 0x50210000,
or from 0x40210000 to 0x50000000. You probably meant the latter
but wrote the former. If not, please add a comment for clarification.

> +               #interrupt-cells = <1>;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0x0 0 &gic 53>;
> +       };

So all PCI IntA interrupts are mapped to a single gic interrupt? That
sounds like a bottleneck when you have a lot of devices on the bus.
Do you have MSI support?

	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/