From patchwork Fri Nov 23 17:50:36 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vasilis Liaskovitis X-Patchwork-Id: 1796661 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id A668DDF254 for ; Fri, 23 Nov 2012 17:51:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755051Ab2KWRvh (ORCPT ); Fri, 23 Nov 2012 12:51:37 -0500 Received: from mail-bk0-f46.google.com ([209.85.214.46]:60385 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754387Ab2KWRuu (ORCPT ); Fri, 23 Nov 2012 12:50:50 -0500 Received: by mail-bk0-f46.google.com with SMTP id q16so3985272bkw.19 for ; Fri, 23 Nov 2012 09:50:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references :x-gm-message-state; bh=XSf1yEdCdZQh83MakwhAF8NOQwZqOgwrv4+GzYV+6Uk=; b=e5CVpJmzM+F7qzKvvWofFavOv+LfLUBu+SwQkEhFpBsmjjXJ3rUdXSPjKrkxppyeTb uMX4j82p7OE+xSPVfuMPF4gEUiGF/6+Q8OoVAnAZFEY/5OdNffZenWViB1Q01m33wZol 3xn4lqC+TfNeu2weHPQy0uTbsZy/XuCuFnHqcjkZzXS4rulkexLyJEPsDCrxuBdJox5E Ah2KNSJh1UGBHfpqhjkNtKs8/YlQUb+EY7babNysEmA7HPmLkn7mh4lczHXo6mK0Mt+y h3BYHKmfdYavjdOyDaaNHvx1yjizM/shRFgaucrL3RCuRViqUqjq0dQAG/6cdv1SQ+W2 sPlQ== Received: by 10.205.135.20 with SMTP id ie20mr1494039bkc.16.1353693049540; Fri, 23 Nov 2012 09:50:49 -0800 (PST) Received: from dhcp-192-168-178-175.ri.profitbricks.localdomain ([62.217.45.26]) by mx.google.com with ESMTPS id 1sm5165091bks.3.2012.11.23.09.50.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Nov 2012 09:50:48 -0800 (PST) From: Vasilis Liaskovitis To: linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com, wency@cn.fujitsu.com Cc: rjw@sisk.pl, lenb@kernel.org, toshi.kani@hp.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Vasilis Liaskovitis Subject: [RFC PATCH v3 2/3] acpi_memhotplug: Add prepare_remove operation Date: Fri, 23 Nov 2012 18:50:36 +0100 Message-Id: <1353693037-21704-3-git-send-email-vasilis.liaskovitis@profitbricks.com> X-Mailer: git-send-email 1.7.9 In-Reply-To: <1353693037-21704-1-git-send-email-vasilis.liaskovitis@profitbricks.com> References: <1353693037-21704-1-git-send-email-vasilis.liaskovitis@profitbricks.com> X-Gm-Message-State: ALoCoQloBvPuXYClS1oUGX+6L+s5oDMHjr9Ju277p1/wpopE4Slx8bgpjFCTnVSVqbdZ81KteQZ+ Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Offlining and removal of memory is now done in the prepare_remove callback, not in the remove callback. The prepare_remove callback will be called when trying to remove a memory device with the following ways: 1. send eject request by SCI 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject Note that unbinding the acpi driver from a memory device with: echo "PNP0C80:XX" > /sys/bus/acpi/drivers/acpi_memhotplug/unbind will no longer try to remove the memory. This is in compliance with normal unbind driver core semantics, see the discussion in v2 of this patchset: https://lkml.org/lkml/2012/11/16/649 After a successful unbind of the driver: - OSPM ejects of the memory device cannot proceed, as acpi_eject_store will return -ENODEV on missing driver. - SCI ejects of the memory device also cannot proceed, as they will also get a "driver data is NULL" error. So the memory can continue to be used safely after unbind. Signed-off-by: Vasilis Liaskovitis --- drivers/acpi/acpi_memhotplug.c | 18 ++++++++++++++++-- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index eb30e5a..d0cfbd9 100644 --- a/drivers/acpi/acpi_memhotplug.c +++ b/drivers/acpi/acpi_memhotplug.c @@ -55,6 +55,7 @@ MODULE_LICENSE("GPL"); static int acpi_memory_device_add(struct acpi_device *device); static int acpi_memory_device_remove(struct acpi_device *device, int type); +static int acpi_memory_device_prepare_remove(struct acpi_device *device); static const struct acpi_device_id memory_device_ids[] = { {ACPI_MEMORY_DEVICE_HID, 0}, @@ -69,6 +70,7 @@ static struct acpi_driver acpi_memory_device_driver = { .ops = { .add = acpi_memory_device_add, .remove = acpi_memory_device_remove, + .prepare_remove = acpi_memory_device_prepare_remove, }, }; @@ -448,6 +450,20 @@ static int acpi_memory_device_add(struct acpi_device *device) static int acpi_memory_device_remove(struct acpi_device *device, int type) { struct acpi_memory_device *mem_device = NULL; + + if (!device || !acpi_driver_data(device)) + return -EINVAL; + + mem_device = acpi_driver_data(device); + + acpi_memory_device_free(mem_device); + + return 0; +} + +static int acpi_memory_device_prepare_remove(struct acpi_device *device) +{ + struct acpi_memory_device *mem_device = NULL; int result; if (!device || !acpi_driver_data(device)) @@ -459,8 +475,6 @@ static int acpi_memory_device_remove(struct acpi_device *device, int type) if (result) return result; - acpi_memory_device_free(mem_device); - return 0; }