Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4787128imm; Mon, 14 May 2018 13:04:43 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrZEUA+dMCaJ7WQELmskemB6tzrrpwzYfX67vyFNM8SBOFjbDbD4AY1+tjHMO2BGrIplxu7 X-Received: by 2002:a63:7e08:: with SMTP id z8-v6mr9532803pgc.383.1526328283849; Mon, 14 May 2018 13:04:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526328283; cv=none; d=google.com; s=arc-20160816; b=W1poig2fowUruyQSDxcau+CHm6nK+EvitDNZff4XizrHbLUFTnACPUA8NTpmAMWFFW 3sqoNlYgUVpp6rQoishfRzrl3RlOePBYV2ehJDrQCDbLUgCev8q1+KaJayVK0yqkaBAs Wa7bE56WmNP6UBYLInbVq6zLjbEnf33qM5hUfnXBehqgug8yfeFeFCWwWewFdTnp+Kzc +n+hNgJRZOnSYf7q0PvrEDdSPVQPyS8KwQIUp7qDaN6Hl9HpfDrHVSitL7cPg9mBmr1X /bc6Tmojbpqa7L3m8n1gGq3Iq+MOuZZWNRz/jes8Y0bVhus/v6znYtN7W3/XJlhLoDxS Ucfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=gQCV5aADvJyVb33k0Uw6Y9lyjw2tNhgyBQHjOCYE2t8=; b=yoLUQqzII6FmX7v7NGo68XbN5QO+fGLI3wqou4V6B3NFQF10HNcZJP/01LycTp2Vju tpa5Dyc4B3Zc/9Cxm0VETIHgJNdJ0RCuYnDwUVYTBO4eDBP5xqWTLa5fCQRRhtA/8zti Q0lvcS/2ucaegpDWzmPJA8tNixb3tI6LmE4sX4qZjOw7zyQmeD3pRll8VGfrB59puzcu 7Tb+InBEDf50opQPRbJEFc+UITOsCeR/hvBAoIl1FHqNxHPQfd6NdeBTvRRkOK3gnR7m LZFfeh2eNSLZrv+MaYl/8DbE4eegekxT3ZnamFAoHKBYoQ6RmugbdxpDj9Ivpyg7ho2x zorw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iXwaLLnH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 71-v6si10340740plc.164.2018.05.14.13.04.29; Mon, 14 May 2018 13:04:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iXwaLLnH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752087AbeENUEF (ORCPT + 99 others); Mon, 14 May 2018 16:04:05 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:36904 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751855AbeENUED (ORCPT ); Mon, 14 May 2018 16:04:03 -0400 Received: by mail-qt0-f194.google.com with SMTP id q13-v6so17841945qtp.4; Mon, 14 May 2018 13:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gQCV5aADvJyVb33k0Uw6Y9lyjw2tNhgyBQHjOCYE2t8=; b=iXwaLLnHtpuOZWr1z9KM7uWGOtegcQAD8f58RhWlzKwgRrhV+etsYeC3xwVp0BldHq KjfKZXmZ47LSSPFMAjtheAW4PnVmPkUkEKNjIvSrUMzGjn7wmuembQaV6oSQJDEoAtqW DMdy072CwyzJPTX1UOunc3dOPbSTXemgSK8WhneA6kdhJImN0CXdr9M67LHvZoifzFSH BFVjeBfS/pWCHUI53sqxXofDax5mCzYpB4NpKnFoQYGd8mWhshY19eeShLBpQLVhIK8Y 469ZRz/IhbA5EynOiu/12IV3Z0sfluJbEZV6eU7OMGo6ZIjcBS+I156KyRbOl52kK0Mn +kkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gQCV5aADvJyVb33k0Uw6Y9lyjw2tNhgyBQHjOCYE2t8=; b=ECd9bPhsjPZALNdCIl9xyzQDR/XvYZYJeV80rHMJ52WoRoKA0ugW/g0I9aYzdjB6xy iI2b+KKHMr0PB795wDOVaL6IEtVTfYyySlWPih3oz44qKOEjjj7bH/vYJFX6tQYIX/P0 o3qqlBBQnUci8YB3aVpxahBnYV3y2Ci6Pi03mkc0ZCyL3gc72Orw1laMtacI62tU1Jyr RAXzkr9sZxXIg7XM1gwOXYJkUMgIRPZ00rpH5Abgh3zbyao93hDW8amGoIjG6BEpVH44 1n8plS2WGVN+JkdEihB9dKblksdxq2q75wC74/v4lvIT4KkqZyugIhMw8IYgRa1Ibc30 fIhQ== X-Gm-Message-State: ALKqPweo0VDn1W6pcQit2YgsDAdg+IMj2FMXMdZm9/vjejjXoq1BBt+E qQmJWFKoBTfkJKr1fBQIU95cZahVEs93ar6qBq4= X-Received: by 2002:ac8:3488:: with SMTP id w8-v6mr10874847qtb.278.1526328243048; Mon, 14 May 2018 13:04:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.152.150 with HTTP; Mon, 14 May 2018 13:04:02 -0700 (PDT) In-Reply-To: <20180514194254.14748-2-pasha.tatashin@oracle.com> References: <20180514194254.14748-1-pasha.tatashin@oracle.com> <20180514194254.14748-2-pasha.tatashin@oracle.com> From: Andy Shevchenko Date: Mon, 14 May 2018 23:04:02 +0300 Message-ID: Subject: Re: [PATCH v4 1/1] drivers core: multi-threading device shutdown To: Pavel Tatashin Cc: Steven Sistare , Daniel Jordan , Linux Kernel Mailing List , "Kirsher, Jeffrey T" , intel-wired-lan@lists.osuosl.org, netdev , Greg Kroah-Hartman , alexander.duyck@gmail.com, tobin@apporbit.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 14, 2018 at 10:42 PM, Pavel Tatashin wrote: > #include > #include > #include > +#include Can we still preserve an order here? (Yes, even if the entire list is not fully ordered) In the context I see it would go before netdevice.h. > +/** > + * device_get_child_by_index - Return child using the provided index. > + * @parent: parent struct device. > + * @index: Index of the child, where 0 is the first child in the children list, > + * and so on. > + * > + * Returns child or NULL if child with this index is not present. > + */ > +static struct device * > +device_get_child_by_index(struct device *parent, int index) > +{ > + struct klist_iter i; > + struct device *dev = NULL, *d; > + int child_index = 0; > + > + if (!parent->p || index < 0) > + return NULL; > + > + klist_iter_init(&parent->p->klist_children, &i); > + while ((d = next_device(&i))) { > + if (child_index == index) { > + dev = d; > + break; > + } > + child_index++; > + } > + klist_iter_exit(&i); > + > + return dev; > +} This can be implemented as a subfunction to device_find_child(), can't it be? > +/** Hmm... Why it's marked as kernel doc while it's just a plain comment? Same applies to the rest of similar comments. > + * Shutdown device tree with root started in dev. If dev has no children > + * simply shutdown only this device. If dev has children recursively shutdown > + * children first, and only then the parent. For performance reasons children > + * are shutdown in parallel using kernel threads. because we lock dev its > + * children cannot be removed while this functions is running. > + */ > +static void device_shutdown_tree(struct device *dev) > +{ > + int children_count; > + > + device_lock(dev); > + children_count = device_children_count(dev); > + > + if (children_count) { > + struct device_shutdown_task_data tdata; > + int i; > + > + init_completion(&tdata.complete); > + atomic_set(&tdata.child_next_index, 0); > + atomic_set(&tdata.tasks_running, children_count); > + tdata.parent = dev; > + > + for (i = 0; i < children_count; i++) { > + if (device_shutdown_serial) { > + device_shutdown_child_task(&tdata); > + } else { > + kthread_run(device_shutdown_child_task, > + &tdata, "device_shutdown.%s", > + dev_name(dev)); > + } > + } Can't we just use device_for_each_child() instead? > + wait_for_completion(&tdata.complete); > + } > + device_shutdown_one(dev); > + device_unlock(dev); > +} -- With Best Regards, Andy Shevchenko