linux-kernel - Re: [PATCH 00/14] Rewrite Tegra PCIe driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130109222517.3c590553@skate>
Date:	Wed, 9 Jan 2013 22:25:17 +0100
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Thierry Reding <thierry.reding@...onic-design.de>
Cc:	linux-tegra@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Russell King <linux@....linux.org.uk>,
	Stephen Warren <swarren@...dotorg.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Andrew Murray <andrew.murray@....com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Arnd Bergmann <arnd@...db.de>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH 00/14] Rewrite Tegra PCIe driver

Dear Thierry Reding,

On Wed,  9 Jan 2013 21:43:00 +0100, Thierry Reding wrote:
> This patch series contains an almost complete rewrite of the Tegra PCIe
> driver. The code is moved to the drivers/pci/host directory and turned
> into a proper platform driver, adding MSI and DT support while at it.
> Other PCI host controller drivers can be added to that directory in an
> attempt to make it easier to factor out common code.

Thanks!

I have started basing the Marvell PCIe code on some of your earlier
versions. But apparently in this final version, you no longer have the
emulated Host bridge. Why so?

For the Marvell PCIe code, I've used your emulated Host bridge, and
added an emulated PCI-to-PCI bridge implementation, in order to get the
following hierarchy:

 + Host Bridge
   + PCI-to-PCI bridge
     + PCI Device
   + PCI-to-PCI bridge
     + PCI device

So, I instantiate one unique emulated Host Bridge, and then one
emulated PCI-to-PCI Bridge for each PCIe interface that I have.

The nice thing about that is that I can then read the configuration
space of the PCI-to-PCI bridge to find out how much I/O space and
memory space is needed for the device connected to this interface, and
at which address is has been mapped. This greatly helps my "address
decoding" problem, and removes the ad-hoc virtual space allocator I had
written.

Is there a reason for having given up on this idea? Is there still a
hope for a different PCIe implementation to use this idea?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/