Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp7000238ybc; Thu, 28 Nov 2019 09:04:48 -0800 (PST) X-Google-Smtp-Source: APXvYqwhrPZbWNVnRgY4KaNu7rzRqTRrM8k3+Zq6WkRbf31MRaRSsETvT2D+GgZiJhQxNe0w4Dwh X-Received: by 2002:a17:907:2112:: with SMTP id qn18mr29479219ejb.92.1574960688694; Thu, 28 Nov 2019 09:04:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574960688; cv=none; d=google.com; s=arc-20160816; b=vPVrL4jgXIFUhi9QrvCjqZRFPITpMGdJnnxkHjm2SUcil2Mzn7GlWmKw1X+a+zdMpr cpky7xmwuS5ghaXwsV2ONkYl1oZMhsEbGOVRqf6Mbb3Xmv11wYYookhstIW7ErCX/p61 ALHwgyKFJqULH5gSeFXrsjR/SRbw2x3UfmIUQCOo8WUGjyMvFLcHJwS3Jv0C3kqsVhpO oeK+PTW3ttFowOGX2677BM7eZvSA04e+/0locb0yuL8Goy2ywRSH9Jrb6nOOWdnZ2z8c uJsqjwYp2j9YbgDAq1DM/f8osWyyx1gp1miZk3OANYupx9bJclx72KtIymBRLlrCff7J 1O2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=T7ODtklfB7U88cTMrrRsr1HTevuQiXBLpBnaqbTja8w=; b=s0Q+0KJi8vTegRPTLkKp5DJPTwpTXFxlkSuYoBxvpZaB/6f+z+q8BqqJK3LVrr70ml N7Z9OGu1bZ6rIy789odatPd9aKY82Uj3YfuvhZppMWXMPp9PsL5jy13kZCLEr1g8SgKE R9iKPkQ8hikwCO7++Tu1JWK+rt3GsKW9U/LFgrpERXBbPepivFO0oSNdzj1UCK/bW47x m3whcSRWPeaU4f89/N5saaVsp04nd4jSpBz4uxesuSTi7uZykYfkPjrwYjK8rzBoxOY6 HYJqwfqH8OU/7LHqx5HRW+TpxKyDJm38xD2L6/dwiCuMiMzd8Vwd7Km9pA/YM4eUEgY9 axqg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s24si507050edi.372.2019.11.28.09.04.24; Thu, 28 Nov 2019 09:04:48 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726699AbfK1RAa (ORCPT + 99 others); Thu, 28 Nov 2019 12:00:30 -0500 Received: from foss.arm.com ([217.140.110.172]:38648 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726681AbfK1RA3 (ORCPT ); Thu, 28 Nov 2019 12:00:29 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 772F71FB; Thu, 28 Nov 2019 09:00:29 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 921EF3F6C4; Thu, 28 Nov 2019 09:00:28 -0800 (PST) Date: Thu, 28 Nov 2019 17:00:26 +0000 From: Qais Yousef To: "Paul E. McKenney" Cc: Thomas Gleixner , Greg Kroah-Hartman , Davidlohr Bueso , Josh Triplett , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/14] torture: Replace cpu_up/down with device_online/offline Message-ID: <20191128170025.ii3vqbj4jpcyghut@e107158-lin.cambridge.arm.com> References: <20191125112754.25223-1-qais.yousef@arm.com> <20191125112754.25223-13-qais.yousef@arm.com> <20191127214725.GG2889@paulmck-ThinkPad-P72> <20191128165611.7lmjaszjl4gbo7u2@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191128165611.7lmjaszjl4gbo7u2@e107158-lin.cambridge.arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/28/19 16:56, Qais Yousef wrote: > On 11/27/19 13:47, Paul E. McKenney wrote: > > On Mon, Nov 25, 2019 at 11:27:52AM +0000, Qais Yousef wrote: > > > The core device API performs extra housekeeping bits that are missing > > > from directly calling cpu_up/down. > > > > > > See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and > > > serialization during LPM") for an example description of what might go > > > wrong. > > > > > > This also prepares to make cpu_up/down a private interface for anything > > > but the cpu subsystem. > > > > > > Signed-off-by: Qais Yousef > > > CC: Davidlohr Bueso > > > CC: "Paul E. McKenney" > > > CC: Josh Triplett > > > CC: linux-kernel@vger.kernel.org > > > > Looks fine from an rcutorture viewpoint, but why not provide an API > > that pulled lock_device_hotplug() and unlock_device_hotplug() into the > > online/offline calls? > > I *think* the right way to do what you say is by doing lock_device_hotplug() > inside device_{online, offline}() - which affects all drivers not just the CPU. > > And even then, I think we need to refcount it so nested calls won't deadlock. Forget that. I don't think nesting here makes actually any sense. Thanks -- Qais Yousef