On Wed, Aug 08, 2018 at 02:58:15PM +0000, Leonard Crestez wrote:

On Wed, 2018-08-08 at 15:19 +0100, Lorenzo Pieralisi wrote:

quoted

On Wed, Aug 08, 2018 at 11:37:14AM +0000, Leonard Crestez wrote:

quoted

On Wed, 2018-08-08 at 12:14 +0100, Lorenzo Pieralisi wrote:

quoted

On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:

quoted

On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:

quoted

Changes since v2:
 * Print with dev_info if link fails on resume (Lucas)
 * Add a comment on imx7d pci irq mappings (Andrey)
 * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)

The ltssm_disable does not return an error because it can't be usefully
handled, reversing partial suspend is a nightmare and unlikely to work.

 * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)

Series is against linux-next tag next-20180724 where the reset patch was
already accepted. The imx7d.dtsi patch is also useful standalone.

This is a gentle reminder that this series was reviewed by Lucas two
weeks ago but not yet included.

Does this series have a functional dependency on the reset fix ? If yes
we can have a bisection proplem depending on which tree gets merged
first.

Yes, without the reset fix I expect hangs.

Maybe the reset fix should be pulled in the pci tree? I don't know how
these issues are sorted out.

Well either I pull that fix into the PCI tree (but it is already -rc8
and I can't guarantee v4.19 inclusion - I shall try) or I can ack these
patches and Philippe will send them upstream on my behalf, atop the
reset fix above.

When will the reset fix will be sent to Linus ? Please let me know
how you want to proceed.

I have some other unsent changes for imx pci+dts+reset standing by.
Since these changes qualify more as "pm features" than fixes I don't
really mind skipping 4.19.

OK that's fine by me, resend this series and the new patches at
v4.19-rc1 and I will pull the changes into the pci tree then.

Pulling pci features into the reset tree doesn't make much sense to me.

I was just giving you an option.

Maybe this kind of stuff could go through Shawn's tree? There shouldn't
be any interaction with non-imx stuff.

As I said, I can ack the changes for Shawn to pick them up but if
Shawn's tree goes to Linus via eg arm-soc we are back to square
one, it is just too late.

I have no problem taking these changes in the PCI tree for v4.20 as long
as we plan the dependencies in advance.

Lorenzo