Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757832Ab3ECLkg (ORCPT ); Fri, 3 May 2013 07:40:36 -0400 Received: from hydra.sisk.pl ([212.160.235.94]:56374 "EHLO hydra.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700Ab3ECLke (ORCPT ); Fri, 3 May 2013 07:40:34 -0400 From: "Rafael J. Wysocki" To: Toshi Kani Cc: Greg Kroah-Hartman , ACPI Devel Maling List , LKML , isimatu.yasuaki@jp.fujitsu.com, vasilis.liaskovitis@profitbricks.com Subject: Re: [PATCH 1/3 RFC] Driver core: Add offline/online device operations Date: Fri, 03 May 2013 13:48:51 +0200 Message-ID: <113992061.ktikQHQeGn@vostro.rjw.lan> User-Agent: KMail/4.9.5 (Linux/3.9.0+; KDE/4.9.5; x86_64; ; ) In-Reply-To: <1367537373.16154.185.camel@misato.fc.hp.com> References: <1576321.HU0tZ4cGWk@vostro.rjw.lan> <1431630.dgj2h0U6M6@vostro.rjw.lan> <1367537373.16154.185.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3129 Lines: 93 On Thursday, May 02, 2013 05:29:33 PM Toshi Kani wrote: > On Thu, 2013-05-02 at 02:58 +0200, Rafael J. Wysocki wrote: > > On Tuesday, April 30, 2013 05:38:38 PM Toshi Kani wrote: > > > On Mon, 2013-04-29 at 14:26 +0200, Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki > : > > > > + */ > > > > +int device_offline(struct device *dev) > > > > +{ > > > > + int ret; > > > > + > > > > + if (dev->offline_disabled) > > > > + return -EPERM; > > > > + > > > > + ret = device_for_each_child(dev, NULL, device_check_offline); > > > > + if (ret) > > > > + return ret; > > > > + > > > > + device_lock(dev); > > > > + if (device_supports_offline(dev)) { > > > > + if (dev->offline) { > > > > + ret = 1; > > > > + } else { > > > > + ret = dev->bus->offline(dev); > > > > + if (!ret) { > > > > + kobject_uevent(&dev->kobj, KOBJ_OFFLINE); > > > > + dev->offline = true; > > > > > > Shouldn't this offline flag be set before sending KOBJ_OFFLINE? > > > > > > > + } > > > > + } > > > > + } > > > > + device_unlock(dev); > > > > + > > > > + return ret; > > > > +} > > > > + > > > > +/** > > > > + * device_online - Put the device back online after successful device_offline(). > > > > + * @dev: Device to be put back online. > > > > + * > > > > + * If device_offline() has been successfully executed for @dev, but the device > > > > + * has not been removed subsequently, execute its bus type's .online() callback > > > > + * to indicate that the device can be used again. > > > > > > There is another use-case for online(). When a device like CPU is > > > hot-added, it is added in offline. I am not sure why, but it has been > > > this way. So, we need to call online() to make a new device available > > > for use after a hot-add. > > > > Actually, in the CPU case that is left to user space as far as I can say. > > That is, the device appears initially offline and user space is supposed to > > bring it online via sysfs. > > > > > > + * > > > > + * Call under device_offline_lock. > > > > + */ > > > > +int device_online(struct device *dev) > > > > +{ > > > > + int ret = 0; > > > > + > > > > + device_lock(dev); > > > > + if (device_supports_offline(dev)) { > > > > + if (dev->offline) { > > > > + ret = dev->bus->online(dev); > > > > + if (!ret) { > > > > + kobject_uevent(&dev->kobj, KOBJ_ONLINE); > > > > + dev->offline = false; > > > > > > Same comment as KOBJ_OFFLINE. > > > > I wonder why the ordering may be important? > > I do not think it causes any race condition (so this isn't a big deal), > but it seems to make more sense to emit an ONLINE/OFFLINE event after > its object is marked online/offline. Well, dev->offline only matters for device_offline() and device_online() themselves at this time. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/