On Fri, 2015-11-27 at 00:15 +0100, Rafael J. Wysocki wrote: > 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 <[email protected] > > > > om> > > > > --- > > > > 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?
commit 01ac170ba29a9903ee590e1ef2d8e6b27b49a16c Author: Andy Shevchenko <[email protected]> Date: Wed Nov 5 18:34:46 2014 +0200 ACPI / LPSS: allow to use specific PM domain during ->probe() > > > 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 for the hint. We will check this. -- Andy Shevchenko <[email protected]> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
