Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752613AbdGGNXs (ORCPT ); Fri, 7 Jul 2017 09:23:48 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:48890 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752568AbdGGNXq (ORCPT ); Fri, 7 Jul 2017 09:23:46 -0400 From: "Rafael J. Wysocki" To: "Lee, Chun-Yi" Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, "Lee, Chun-Yi" , Len Brown , Michal Hocko Subject: Re: [RFC PATCH v4] acpi: indicate to platform when hot remove returns busy Date: Fri, 07 Jul 2017 15:16:03 +0200 Message-ID: <2215692.6PBOUeBxzM@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.12.0-rc1+; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170707062523.29735-1-jlee@suse.com> References: <20170707062523.29735-1-jlee@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3140 Lines: 91 On Friday, July 07, 2017 02:25:23 PM Lee, Chun-Yi wrote: > In hotplug logic, it always indicates non-specific failure to > platform through _OST when handing acpi hot-remove event failed. Then > platform terminates the hot-remove process but it can not identify > the reason. > > Base on current hot-remove code, there have two situations that it > returns busy: > - OSPM try to offline an individual device, but the device offline > function returns busy. > - When the ejection event is applied to an "not offlined yet" container. > OSPM send kobject change event to userspace and returns busy. > > Both of them will returns -EBUSY to acpi device hotplug function then > hotplug function indicates non-specific failure to platform just like > any other error, e.g. -ENODEV or -EIO. > > The benefit to platform for identifying the OS busy state is that > platform can be applied different approach to handle the busy but > not just terminate the hot-remove process by unknown reason. For > example, platform can wait for a while then triggers hot-remove > again. > > This RFC patch adds one more parameter to the handler function of > acpi generic hotplug event to give the function a chance to propose > the return code of _OST. In this case, it sets ost return code to > ACPI_OST_SC_DEVICE_BUSY when the acpi hot remove function returns > -EBUSY. > > v4: > Use switch-case statements to simplify code. (Andy Shevchenko, Rafael J. Wysocki) > > v3: > Removed redundant 'else' in acpi_ost_status_code(). (Andy Shevchenko) > > v2: > Do not overwrite ost code in acpi_generic_hotplug_event(). Move > the "error code to ost code" logic to a help function. (Andy Shevchenko) > > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: Michal Hocko > Reviewed-by: Andy Shevchenko > Signed-off-by: "Lee, Chun-Yi" I've applied this one already I think. Please check in linux-next. > --- > drivers/acpi/scan.c | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index d531629..ce88175 100644 > --- a/drivers/acpi/scan.c > +++ b/drivers/acpi/scan.c > @@ -404,10 +404,6 @@ void acpi_device_hotplug(struct acpi_device *adev, u32 src) > error = dock_notify(adev, src); > } else if (adev->flags.hotplug_notify) { > error = acpi_generic_hotplug_event(adev, src); > - if (error == -EPERM) { > - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; > - goto err_out; > - } > } else { > int (*notify)(struct acpi_device *, u32); > > @@ -423,8 +419,20 @@ void acpi_device_hotplug(struct acpi_device *adev, u32 src) > else > goto out; > } > - if (!error) > + switch (error) { > + case 0: > ost_code = ACPI_OST_SC_SUCCESS; > + break; > + case -EPERM: > + ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; > + break; > + case -EBUSY: > + ost_code = ACPI_OST_SC_DEVICE_BUSY; > + break; > + default: > + ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; > + break; > + } > > err_out: > acpi_evaluate_ost(adev->handle, src, ost_code, NULL); >