Re: [PATCH 0/4] PCI: tegra: Configuration space mapping cleanups and fixes

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

On Thu, Dec 14, 2017 at 05:37:45PM +0000, Lorenzo Pieralisi wrote:
> Hi Thierry,
> 
> On Thu, Dec 14, 2017 at 02:45:41PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > 
> > Hi Lorenzo,
> > 
> > This cleans up a few oddities that I found while reviewing and testing
> > the patch
> > 
> > 	[PATCH V3 1/2] PCI: tegra: refactor config space mapping code
> > 
> > that Vidya Sagar sent out earlier. The first three patches are mostly
> > cleanup and admittedly somewhat bikeshedding in nature. They could've
> > been just review comments, but I thought I'd just submit them as a
> > series of patches since I had already typed them up anyway.
> > 
> > The last patch gets rid of an artificial restriction regarding the
> > mapping address and does a bit of simplification.
> > 
> > These are technically incremental on top of the original patch, but if
> > you prefer, feel free to squash them into that patch.
> 
> I took some time to have a look at all of them and actually I am happy
> with the end result, except that I would prefer if you squash them all
> in and rewrite the logs since I can easily miss something (eg I have no
> insights into the Tegra config space FPCI windowing mechanism) - I will
> merge the resulting patch(es).
> 
> I have a question: after merging both series, are
> 
> tegra_pcie_{add/remove}_bus()
> 
> (and struct tegra_pcie_bus)
> 
> still needed ? I do not think so.

Yes, you're right, those were only to track the quilt mappings that we
used to do. I've removed them in the patch I just sent (v4).

> > I've tested these on all of Tegra20, Tegra30, Tegra124, Tegra210 and
> > Tegra186.
> 
> If the testing goes OK please send me unified series and will merge
> that one.
> 
> This brings me to a question for you and Bjorn: how do you usually
> handle DT updates ? I assume we send them via the PCI tree but I am
> asking to prevent any issue upfront.

DT updates usually go through the ARM SoC tree. It's usually okay to do
that because the DT stability requirement nicely decouples DT and driver
updates already.

In this particular case, the driver will be presented with a 256 MiB
window from existing DTs and simply use the first 4 KiB of that window
for the configuration space mapping. We can apply the DT patches at any
later time to reduce the region from 256 MiB to 4 KiB. I plan to do that
during for v4.17.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]