Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

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

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

On Thu, Dec 14, 2017 at 10:37:22AM +0000, Lorenzo Pieralisi wrote:
> On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote:
> 
> [...]
> 
> > > > > Hi Bjorn,
> > > > > 
> > > > > there's a bunch of PCI related patches for Tegra floating around on the
> > > > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > > > tree after they've been reviewed and send you a pull request later on
> > > > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > > > linux-next for a bit and get broader testing in addition to the
> > > > > flexibility to patch things up if they break.
> > > > 
> > > > Lorenzo will be merging the Tegra stuff, so this is more a question
> > > > for him.
> > > > 
> > > > Just to clarify, I think your questions is about putting those patches
> > > > in
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > > > If you put them there they will show up in linux-next, and then when
> > > > Lorenzo merges them, you'll have to coordinate so they don't get
> > > > merged into linux-next twice (once via the usual PCI tree route and
> > > > again via the Tegra tree).
> > > > 
> > > > If you wait until after they've been reviewed to put them into the
> > > > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > > > would merge them at about that same point.
> > > 
> > > I think that after the review, the Tegra patches that are considered for
> > > upstream they should go to -next via the PCI tree as any other platform PCI
> > > patches; the relevant patches need ACKs from the respective platform
> > > maintainer - I am getting to them as fast as I can.
> > 
> > Just to clarify: I wasn't suggesting that these patches are merged for
> > v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
> > little while so that we can get broader testing and fix things up in
> > case they break. My proposal was to then send a pull request for
> > inclusion in the PCI tree. linux-next can deal with this type of
> > scenario just fine because it will simply see the same branch twice and
> > ignore the second one.
> > 
> > If you prefer to merge directly via the PCI tree that works for me too.
> 
> We would end up merging the patches into -next at the same time, so there
> is not much point in queuing them via Tegra if they go via the PCI tree
> eventually; we should not add to -next patches that are not ready to
> be merged anyway.
> 
> I need your help (ACKs) though to queue them up - I review the patches
> but I can neither test them nor get access to HW TRMs so for some of them
> there is not much I can do.

I've sent out a small series of patches that apply on top of this patch
which clean up and fix a couple of issues with this patch. Feel free to
squash those into this patch if you prefer.

Acked-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

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