On Thursday, November 26, 2015 06:45:17 PM Andy Shevchenko wrote: > On Thu, 2015-11-26 at 18:30 +0200, Jarkko Nikula wrote: > > On 11/26/2015 05:19 PM, Andy Shevchenko wrote: > > > This is an amendment to previously pushed commit 01ac170ba29a (ACPI > > > / LPSS: > > > allow to use specific PM domain during ->probe()). We can't assign > > > anything to > > > the platform device on ADD_DEVICE stage since it might be changed > > > during > > > unbound / bind cycle. > > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > > --- > > > drivers/acpi/acpi_lpss.c | 9 +++++++-- > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c > > > index f9e0d09..e840229 100644 > > > --- a/drivers/acpi/acpi_lpss.c > > > +++ b/drivers/acpi/acpi_lpss.c > > > @@ -705,8 +705,14 @@ static int acpi_lpss_platform_notify(struct > > > notifier_block *nb, > > > } > > > > > > switch (action) { > > > - case BUS_NOTIFY_ADD_DEVICE: > > > + case BUS_NOTIFY_BIND_DRIVER: > > > pdev->dev.pm_domain = &acpi_lpss_pm_domain; > > > + break; > > > + case BUS_NOTIFY_BIND_DRIVER_ERROR: > > > + case BUS_NOTIFY_UNBOUND_DRIVER: > > > + pdev->dev.pm_domain = NULL; > > > + break; > > > + case BUS_NOTIFY_ADD_DEVICE: > > > > This won't fix like revert of original commit does. Which commit exactly are you talking about, for reference? > > Primary problem here > > is that there is no explicit power on at all during LPSS device probe > > because dev->pm_domain is set before probing. > > And we can't do this as in very original code of acpi_lpss.c since DMA > has to be sure it's powered on while probing. We could guarantee this > only in case when PM domain is assigned already and we do our quirk for > it. > > From my point of view we have to fix hang first since it's most painful > case for users and their experience. Though I'm open to any better > solution if you have any in mind. > > > > > driver_probe_device > > platform_drv_prove > > dev_pm_domain_attach > > acpi_dev_pm_attach > > returns instantly because of dev->pm_domain is set This looks like a candidate for the new PM domain callbacks, ->activate and ->dismiss. ->activate() is called before the probe, so it may power up things. ->dismiss() in turn is called in the failed probe case, so it can do the cleanup. Have you considered using these? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html