On Wed, Sep 14, 2016 at 03:14:37PM +0200, Rafael J. Wysocki wrote: > On Wednesday, September 14, 2016 11:56:40 AM Lukas Wunner wrote: > > I first tried to solve this only for Thunderbolt by opting out of the > > mandatory resume after direct_complete. It worked, but it was ugly. > > > > (I have to clear the direct_complete flag in the ->complete hook, but > > the device tree is walked bottom-up during ->complete, and since the > > Thunderbolt controller exposes multiple devices, I have to clear the > > flag for all devices from the bottom-most device, which is the NHI. > > And all the rest of the s/r code lives on the top-most device, which > > is the upstream bridge.) > > > > You suggested in your e-mail of July 18: "maybe it's better to change > > the PCI bus type to do something different from calling the generic > > function?" > > > > So there, I did what you suggested and tried to fix it not just for > > Thunderbolt but for everyone. > > > > And you're still not happy. > > > > *sigh* > > Sorry for disappointing you. > > I have concerns, so I talk about them. Is that wrong? If so, what's wrong > about it? > > My time goes into that as well, mind you. Sorry, never mind, just a bout of desperation that I failed to control. Kind regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html