From: Jiang Liu <jiang.liu@huawei.com>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Toshi Kani <toshi.kani@hp.com>,
yinghai@kernel.org, bhelgaas@google.com, lenb@kernel.org,
izumi.taku@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
mihailm@parallels.com, linux-acpi@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] Improve container_notify_cb() to support container hot-remove.
Date: Thu, 25 Oct 2012 09:47:00 +0800 [thread overview]
Message-ID: <50889A14.9030607@huawei.com> (raw)
In-Reply-To: <5088967E.3060204@cn.fujitsu.com>
On 2012-10-25 9:31, Tang Chen wrote:
> Hi Toshi,
>
> On 10/25/2012 01:14 AM, Toshi Kani wrote:
>> On Wed, 2012-10-24 at 14:05 +0800, Tang Chen wrote:
>>> +static int container_device_remove(struct acpi_device *device)
>>> +{
>>> + int ret;
>>> + struct acpi_eject_event *ej_event;
>>> +
>>> + /* stop container device at first */
>>> + ret = acpi_bus_trim(device, 0);
>>
>> Hi Tang,
>>
>> Why do you need to call acpi_bus_trim(device,0) to stop the container
>> device first?
>
> This issue was introduced by Lu Yinghai, I think he could give a better
> answer than me. :)
> Please refer to the following url:
>
> http://www.spinics.net/lists/linux-pci/msg17667.html
>
> However, this is not applied into the pci tree yet.
We have worked out a patch set to clean up the logic for PCI/ACPI binding
relationship. It updates PCI/ACPI binding relationship by registering bus
notification onto pci_bus_type instead of hooking into the ACPI/glue.c.
To accommodate that patch set, the ACPI device destroy process has been
split into two steps:
1) acpi_bus_trim(device,0) to unbind ACPI drivers
2) acpi_bus_trim(device,1) to destroy ACPI devices
>
>>
>>> + printk(KERN_WARNING "acpi_bus_trim stop return %x\n", ret);
>>
>> Do you need this message in the normal case? If so, I'd suggest to use
>> pr_debug().
>>
>>> + if (ret)
>>> + return ret;
>>> +
>>> + /* event originated from ACPI eject notification */
>>> + device->flags.eject_pending = 1;
>>
>> You do not need to set the eject_pending flag when the handler calls
>> acpi_bus_hot_remove_device(). It was set before because the handler did
>> not initiate the hot-remove operation.
>
> I just set it to keep the logic the same as before.
> And thanks for telling me this. :)
>
>>
> ...
>>> + printk(KERN_WARNING "Container driver received %s event\n",
>>> + "ACPI_NOTIFY_EJECT_REQUEST");
>>
>> Same as other comment. Suggest to use pr_debug().
>
> OK. :)
>
>>
>>> +
>>> + if (!present || ACPI_FAILURE(status) || !device)
>>> + break;
>>> +
>>> + result = container_device_remove(device);
>>> + if (result) {
>>> + printk(KERN_WARNING "Failed to remove container\n");
>>
>> Please use pr_warn().
>>
>> Thanks,
>> -Toshi
>>
>>> + break;
>>> }
>>> - break;
>>> +
>>> + return;
>>>
>>> default:
>>> /* non-hotplug event; possibly handled by other handler */
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Jiang Liu <jiang.liu@huawei.com>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Toshi Kani <toshi.kani@hp.com>, <yinghai@kernel.org>,
<bhelgaas@google.com>, <lenb@kernel.org>,
<izumi.taku@jp.fujitsu.com>, <isimatu.yasuaki@jp.fujitsu.com>,
<mihailm@parallels.com>, <linux-acpi@vger.kernel.org>,
<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] Improve container_notify_cb() to support container hot-remove.
Date: Thu, 25 Oct 2012 09:47:00 +0800 [thread overview]
Message-ID: <50889A14.9030607@huawei.com> (raw)
In-Reply-To: <5088967E.3060204@cn.fujitsu.com>
On 2012-10-25 9:31, Tang Chen wrote:
> Hi Toshi,
>
> On 10/25/2012 01:14 AM, Toshi Kani wrote:
>> On Wed, 2012-10-24 at 14:05 +0800, Tang Chen wrote:
>>> +static int container_device_remove(struct acpi_device *device)
>>> +{
>>> + int ret;
>>> + struct acpi_eject_event *ej_event;
>>> +
>>> + /* stop container device at first */
>>> + ret = acpi_bus_trim(device, 0);
>>
>> Hi Tang,
>>
>> Why do you need to call acpi_bus_trim(device,0) to stop the container
>> device first?
>
> This issue was introduced by Lu Yinghai, I think he could give a better
> answer than me. :)
> Please refer to the following url:
>
> http://www.spinics.net/lists/linux-pci/msg17667.html
>
> However, this is not applied into the pci tree yet.
We have worked out a patch set to clean up the logic for PCI/ACPI binding
relationship. It updates PCI/ACPI binding relationship by registering bus
notification onto pci_bus_type instead of hooking into the ACPI/glue.c.
To accommodate that patch set, the ACPI device destroy process has been
split into two steps:
1) acpi_bus_trim(device,0) to unbind ACPI drivers
2) acpi_bus_trim(device,1) to destroy ACPI devices
>
>>
>>> + printk(KERN_WARNING "acpi_bus_trim stop return %x\n", ret);
>>
>> Do you need this message in the normal case? If so, I'd suggest to use
>> pr_debug().
>>
>>> + if (ret)
>>> + return ret;
>>> +
>>> + /* event originated from ACPI eject notification */
>>> + device->flags.eject_pending = 1;
>>
>> You do not need to set the eject_pending flag when the handler calls
>> acpi_bus_hot_remove_device(). It was set before because the handler did
>> not initiate the hot-remove operation.
>
> I just set it to keep the logic the same as before.
> And thanks for telling me this. :)
>
>>
> ...
>>> + printk(KERN_WARNING "Container driver received %s event\n",
>>> + "ACPI_NOTIFY_EJECT_REQUEST");
>>
>> Same as other comment. Suggest to use pr_debug().
>
> OK. :)
>
>>
>>> +
>>> + if (!present || ACPI_FAILURE(status) || !device)
>>> + break;
>>> +
>>> + result = container_device_remove(device);
>>> + if (result) {
>>> + printk(KERN_WARNING "Failed to remove container\n");
>>
>> Please use pr_warn().
>>
>> Thanks,
>> -Toshi
>>
>>> + break;
>>> }
>>> - break;
>>> +
>>> + return;
>>>
>>> default:
>>> /* non-hotplug event; possibly handled by other handler */
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> .
>
next prev parent reply other threads:[~2012-10-25 1:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 6:05 [PATCH v2 0/2] ACPI: container hot remove support Tang Chen
2012-10-24 6:05 ` [PATCH v2 1/2] Use kacpi_hotplug_wq to handle container hotplug event Tang Chen
2012-10-24 6:54 ` Yasuaki Ishimatsu
2012-10-24 6:54 ` Yasuaki Ishimatsu
2012-10-24 7:24 ` Tang Chen
2012-10-24 8:09 ` Yasuaki Ishimatsu
2012-10-24 8:09 ` Yasuaki Ishimatsu
2012-10-24 7:42 ` Tang Chen
2012-10-24 6:05 ` [PATCH v2 2/2] Improve container_notify_cb() to support container hot-remove Tang Chen
2012-10-24 17:14 ` Toshi Kani
2012-10-24 18:02 ` Bjorn Helgaas
2012-10-25 0:53 ` Jiang Liu
2012-10-25 0:53 ` Jiang Liu
2012-10-25 1:31 ` Tang Chen
2012-10-25 1:47 ` Jiang Liu [this message]
2012-10-25 1:47 ` Jiang Liu
2012-10-25 17:20 ` Toshi Kani
2012-10-26 5:43 ` Tang Chen
2012-10-26 20:02 ` Toshi Kani
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=50889A14.9030607@huawei.com \
--to=jiang.liu@huawei.com \
--cc=bhelgaas@google.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mihailm@parallels.com \
--cc=tangchen@cn.fujitsu.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.