[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337891135.16730.404.camel@misato.fc.hp.com>
Date: Thu, 24 May 2012 14:25:35 -0600
From: Toshi Kani <toshi.kani@...com>
To: shuahkhan@...il.com
Cc: lenb@...nel.org, linux-acpi@...r.kernel.org, bhelgaas@...gle.com,
liuj97@...il.com, andi@...stfloor.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/6] ACPI: Add _OST support for ACPI memory hotplug
On Thu, 2012-05-24 at 12:21 -0600, Shuah Khan wrote:
> On Wed, 2012-05-23 at 20:25 -0600, Toshi Kani wrote:
> > Changed acpi_memory_device_notify() to call ACPI _OST method
> > when ACPI memory hotplug operation has completed.
> >
> > Signed-off-by: Toshi Kani <toshi.kani@...com>
> > ---
> > drivers/acpi/acpi_memhotplug.c | 43 +++++++++++++++++++++++++++++----------
> > 1 files changed, 32 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> > index d985713..24c807f 100644
> > --- a/drivers/acpi/acpi_memhotplug.c
> > +++ b/drivers/acpi/acpi_memhotplug.c
> > @@ -341,7 +341,7 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
> > {
> > struct acpi_memory_device *mem_device;
> > struct acpi_device *device;
> > -
> > + u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
> >
> > switch (event) {
> > case ACPI_NOTIFY_BUS_CHECK:
> > @@ -354,15 +354,20 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
> > "\nReceived DEVICE CHECK notification for device\n"));
> > if (acpi_memory_get_device(handle, &mem_device)) {
> > printk(KERN_ERR PREFIX "Cannot find driver data\n");
> > - return;
> > + break;
> > }
> >
> > - if (!acpi_memory_check_device(mem_device)) {
> > - if (acpi_memory_enable_device(mem_device))
> > - printk(KERN_ERR PREFIX
> > - "Cannot enable memory device\n");
> > + if (acpi_memory_check_device(mem_device))
> > + break;
> > +
> > + if (acpi_memory_enable_device(mem_device)) {
> > + printk(KERN_ERR PREFIX "Cannot enable memory device\n");
> > + break;
> > }
> > +
> > + ost_code = ACPI_OST_SC_SUCCESS;
> > break;
> > +
> > case ACPI_NOTIFY_EJECT_REQUEST:
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> > "\nReceived EJECT REQUEST notification for device\n"));
> > @@ -383,19 +388,35 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
> > * TBD: Can also be disabled by Callback registration
> > * with generic sysfs driver
> > */
> > - if (acpi_memory_disable_device(mem_device))
> > - printk(KERN_ERR PREFIX
> > - "Disable memory device\n");
> > + if (acpi_memory_disable_device(mem_device)) {
> > + printk(KERN_ERR PREFIX "Disable memory device\n");
> > + /*
> > + * If _EJ0 was called but failed, _OST is not
> > + * necessary.
> > + */
> > + if (mem_device->state == MEMORY_INVALID_STATE)
> > + return;
> > +
> > + break;
> > + }
>
> Why isn't _OST called in this case to report failure? Isn't this one of
> the cases Spec talks about. Reference: 6.3.5 _OST (OSPM Status
> Indication) page 302.
If an ejection operation failed before calling _EJ0, the OS needs to
call _OST. Once the OS called _EJ0, the OS need not to call _OST again
since FW has been informed with _EJ0 already. If _EJ0 failed, FW knows
it failed as well. Please see page 14, Figure 2, of DIG64 HPPF doc.
The pointer to the doc is described in patch [0/6].
Thanks,
-Toshi
>
> -- Shuah
>
> > +
> > /*
> > * TBD: Invoke acpi_bus_remove to cleanup data structures
> > */
> > - break;
> > +
> > + /* _EJ0 succeeded; _OST is not necessary */
> > + return;
> > +
> > default:
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> > "Unsupported event [0x%x]\n", event));
> > - break;
> > +
> > + /* non-hotplug event; possibly handled by other handler */
> > + return;
> > }
> >
> > + /* Inform firmware that the hotplug operation has completed */
> > + (void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
> > return;
> > }
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists