All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>,
	"Moore, Robert" <robert.moore@intel.com>,
	Toshi Kani <toshi.kani@hp.com>, Yinghai Lu <yinghai@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Aaron Lu <aaron.lu@intel.com>, Lv Zheng <lv.zheng@intel.com>
Subject: Re: [PATCH 7/10] ACPI / hotplug: Move container-specific code out of the core
Date: Fri, 13 Dec 2013 14:17:32 +0900	[thread overview]
Message-ID: <52AA986C.7050305@jp.fujitsu.com> (raw)
In-Reply-To: <4217831.DpCd0ng0jT@vostro.rjw.lan>

(2013/12/13 13:56), Rafael J. Wysocki wrote:
> On Friday, December 13, 2013 11:56:32 AM Yasuaki Ishimatsu wrote:
>> Hi Rafael,
>
> Hi,
>
>> Please share your more detailed idea. I started to implement the following
>> idea. But the idea has one problem.
>>
>>>>> The eject work flow can be:
>>>>>      (1) an eject event occurs,
>>>>>      (2) the container "physical" device fails offline in acpi_scan_hot_remove()
>>>>>          emmitting, say, KOBJ_CHANGE for the "physical" device,
>>>>>      (3) user space notices the KOBJ_CHANGE and does the cleanup as needed,
>>>>>      (4) user space changes the "physical" container device flag controlling
>>>>>          offline to 0,
>>>>>      (5) user space uses the sysfs "eject" attribute of the ACPI container object
>>>>>          to finally eject the container,
>>>>>      (6) the offline in acpi_scan_hot_remove() is now successful, because the
>>>>>          flag controlling it has been set to 0 in step (4),
>>>>>      (7) the "physical" container device goes away before executing _EJ0,
>>>>>      (8) the container is ejected.
>>
>> I want to emit KOBJ_CHANGE before offlining devices on container device at (2).
>> But acpi_scan_hot_remove() offlines devices on container device at first.
>> So when offline container device, devices on container has been offlined.
>>
>> Thus the idea cannot fulfill my necessary feature.
>
> Well, in that case we need to treat containers in a special way at the ACPI
> level.  Which is a bit unfortunate so to speak.
>
> To that end I'd try to add a new flag to struct acpi_hotplug_profile, say
> .verify_offline, such that if set, it would cause acpi_scan_hot_remove() to
> check if all of the "physical" companions of the top-level device are offline
> to start with, and if not, it would just emit KOBJ_CHANGE for the companions
> that are not offline and bail out.
>
> So the above algorithm would become:
>
> (1) an eject event occurs,
> (2) acpi_scan_hot_remove() checks the verify_offline flag in the target device's
>      scan_handler structure,
> (3) if set (it would always be set for containers), acpi_scan_hot_remove()
>      checks the status of the target device's "physical" companions; if at least
>      one of them is offline, KOBJ_CHANGE is emitted for that "physical" device,
>      and acpi_scan_hot_remove() returns, [I guess we can just emit KOBJ_CHANGE
>      for the first companion that is not offline at this point.]
> (4) user space notices the KOBJ_CHANGE and does the cleanup as needed; in the
>      process it carries out the offline operation for the container's "physical"
>      companion (there's only one such companion for each container), [That
>      operation for the container itself is trivial, but to succeed it requires
>      all devices below the container to be taken offline in advance.]
> (5) user space uses the sysfs "eject" attribute of the ACPI container object
>      to finally eject the container,
> (6) acpi_scan_hot_remove() is now successful, because the container's "physical"
>      companion is now offline,
> (7) the "physical" container device goes away before executing _EJ0,
> (8) the container is ejected.
>
> I think that should work for you.

This idea seems to same as your previous work.
http://lkml.org/lkml/2013/2/23/97

How about add autoremove flag into acpi_hotplug_profile and check it as follow:

---
  drivers/acpi/scan.c | 5 +++++
  1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5383c81..c43d110 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -409,6 +409,11 @@ static void acpi_hotplug_notify_cb(acpi_handle handle, u32 type, void *data)
  			ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
  			goto err_out;
  		}
+		if (!handler->hotplug.autoremove) {
+			kobject_uevent(&device->dev.kobj, KOBJ_CHANGE);
+			ost_code = ACPI_OST_SC_EJECT_NON_SPECIFIC_FAILURE;
+			goto err_out;
+		}
  		acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST,
  					  ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
  		break;

Adding the check into "acpi_hotplug_notify_cb()", user need not change the
flag for removing container device by "sysfs eject".

Thanks,
Yasuaki Ishimatsu

>
> Thanks,
> Rafael
>

  reply	other threads:[~2013-12-13  5:17 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-17 16:29 [PATCH 0/10] ACPI: Device objects for all namespace nodes and PCI root hotplug integration Rafael J. Wysocki
2013-11-17 16:31 ` [PATCH 1/10] ACPICA: Delete all attached data objects on node deletion Rafael J. Wysocki
2013-11-17 16:31 ` [PATCH 2/10] ACPI / scan: Define non-empty device removal handler Rafael J. Wysocki
2013-11-17 16:33 ` [PATCH 3/10] ACPI / scan: Add acpi_device objects for all device nodes in the namespace Rafael J. Wysocki
2013-11-17 16:33 ` [PATCH 4/10] ACPI / hotplug: Do not fail bus and device checks for disabled hotplug Rafael J. Wysocki
2013-11-17 16:34 ` [PATCH 5/10] ACPI / hotplug: Introduce common hotplug function acpi_device_hotplug() Rafael J. Wysocki
2013-11-17 16:35 ` [PATCH 6/10] ACPI / hotplug: Make ACPI PCI root hotplug use common hotplug code Rafael J. Wysocki
2013-11-17 16:36 ` [PATCH 7/10] ACPI / hotplug: Move container-specific code out of the core Rafael J. Wysocki
2013-11-29  2:36   ` Yasuaki Ishimatsu
2013-11-29 13:08     ` Rafael J. Wysocki
2013-12-03  2:46       ` Yasuaki Ishimatsu
2013-12-03 13:15         ` Rafael J. Wysocki
2013-12-04  5:43           ` Yasuaki Ishimatsu
2013-12-13  2:56           ` Yasuaki Ishimatsu
2013-12-13  4:56             ` Rafael J. Wysocki
2013-12-13  5:17               ` Yasuaki Ishimatsu [this message]
2013-12-14  5:07                 ` Rafael J. Wysocki
2013-12-23 13:58                   ` Rafael J. Wysocki
2013-12-23 14:00                     ` [PATCH 1/2][Untested] ACPI / hotplug: Add demand_offline hotplug profile flag Rafael J. Wysocki
2013-12-26  3:10                       ` Yasuaki Ishimatsu
2013-12-26  4:10                         ` Yasuaki Ishimatsu
2013-12-27  0:58                           ` Rafael J. Wysocki
2013-12-27  5:18                             ` Yasuaki Ishimatsu
2013-12-27  5:34                               ` Yasuaki Ishimatsu
2013-12-27 11:52                                 ` Rafael J. Wysocki
2013-12-27 11:51                               ` Rafael J. Wysocki
2013-12-27 22:21                                 ` [PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices Rafael J. Wysocki
2013-12-27 22:23                                   ` [PATCH 1/2] ACPI / hotplug: Add demand_offline hotplug profile flag Rafael J. Wysocki
2013-12-27 22:28                                   ` [PATCH 2/2] ACPI / hotplug / driver core: Handle containers in a special way Rafael J. Wysocki
2013-12-29  3:58                                     ` Greg Kroah-Hartman
2013-12-29  3:59                                   ` [PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices Greg Kroah-Hartman
2013-12-29 14:20                                     ` Rafael J. Wysocki
2013-12-27  0:33                         ` [PATCH 1/2][Untested] ACPI / hotplug: Add demand_offline hotplug profile flag Rafael J. Wysocki
2013-12-23 14:02                     ` [PATCH 2/2][Untested] ACPI / hotplug / driver core: Handle containers in a special way Rafael J. Wysocki
2013-12-24  0:41                       ` [Update][PATCH 2/2] " Rafael J. Wysocki
2013-12-26  1:01                     ` [PATCH 7/10] ACPI / hotplug: Move container-specific code out of the core Rafael J. Wysocki
2013-12-26  2:53                       ` Yasuaki Ishimatsu
2013-12-27  0:31                         ` Rafael J. Wysocki
2013-11-17 16:36 ` [PATCH 8/10] ACPI / hotplug: Rework generic code to handle suprise removals Rafael J. Wysocki
2013-11-17 16:37 ` [PATCH 9/10] ACPI / hotplug: Drop unfinished global notification handling routines Rafael J. Wysocki
2013-11-17 16:38 ` [PATCH 10/10] ACPI: Introduce acpi_set_device_status() Rafael J. Wysocki
2013-11-19 14:30 ` [PATCH 0/10] ACPI: Device objects for all namespace nodes and PCI root hotplug integration Mika Westerberg
2013-11-19 20:51   ` Rafael J. Wysocki
2013-11-19 21:05     ` Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52AA986C.7050305@jp.fujitsu.com \
    --to=isimatu.yasuaki@jp.fujitsu.com \
    --cc=aaron.lu@intel.com \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=rui.zhang@intel.com \
    --cc=toshi.kani@hp.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.