Received: by 10.223.185.116 with SMTP id b49csp3006776wrg; Mon, 12 Feb 2018 19:18:35 -0800 (PST) X-Google-Smtp-Source: AH8x225TGUxS2RnunhtaLYvXbQ79GrcKOWwdl3O40iNOm0+tNEFb0RDSZsKrqGk4x91TTZnCVS3Y X-Received: by 10.98.92.1 with SMTP id q1mr13466504pfb.238.1518491915460; Mon, 12 Feb 2018 19:18:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518491915; cv=none; d=google.com; s=arc-20160816; b=K0Ed9O79RnL7bSqVg1NZ5z2H4xXqnsdv7rYTWtXvSCk69YyHzC7LAjwv96y7sKKGDO 4pjnlohjCiObBI1FaFJ4xf/PsIuyK8Y85HcN/T/8Oekj0+oi7FfhrMpk9WXZVS8AJr3e mziD2ImFBkwHmYj3BLqGizXpaKPHjg0221DOqAATAaf6J12jk9ciVdP/sA8GUnfUZFGR CWrRE5dUFWnoiEDhrr8UrFzs2N1uKXuwzvAs01I5vgjN58fR8eiMqB9+HtUZHQUTQkGi LB/JwHoWx3k1QpgrYf2wVwVD2/WTlA/hbhoETGOL45xXCikM7fRYVrcjEMegY+tTOYjI HnrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=GjoinCDet37nw/zRm9JcSwQfDq1hNGb8nkoI5ZKWpt8=; b=RtSvdalmONONtDBC6CE2hSnP+Hyac+kZDftvHZuMCdVRnw4KmrfKVYTOPzlv9ADtdl Oy6kTp27q/VOJZhmmG9hfXlu3YZgqiTBnGFK4aCeUoK1BBoUQkPHHPvWzKoApZPofdof fy1yxzw9O8wenFwGn7UWIl0E5qaOS9ZhbS+CRjQldMuRKuNiM6OWM+geH0S79EyZZJCA uV/3+dAm8l7/JsJrFHNHVvqCtanY2f7KUBGlm3F7aEzeQ5G7PhBreVSj9NH5b23pCkvU f7+aigsVonC8R88gqSuD5cj8tp9vMDA33B1FbVkseDaEH/sjrwW29s8zf9AlmE0BCGaY NGWg== 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 e3si514598pgt.217.2018.02.12.19.18.07; Mon, 12 Feb 2018 19:18:35 -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 S933357AbeBMDRK (ORCPT + 99 others); Mon, 12 Feb 2018 22:17:10 -0500 Received: from ozlabs.org ([103.22.144.67]:47085 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933293AbeBMDRJ (ORCPT ); Mon, 12 Feb 2018 22:17:09 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 3zgSPv4wbDz9sNw; Tue, 13 Feb 2018 14:17:07 +1100 (AEDT) From: Michael Ellerman To: Sukadev Bhattiprolu Cc: Benjamin Herrenschmidt , mikey@neuling.org, hbabu@us.ibm.com, linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] powerpc/vas: Fix cleanup when VAS is not configured In-Reply-To: <20180212202510.GB28183@us.ibm.com> References: <1518234567-24869-1-git-send-email-sukadev@linux.vnet.ibm.com> <1518234567-24869-2-git-send-email-sukadev@linux.vnet.ibm.com> <87d11awzkp.fsf@concordia.ellerman.id.au> <20180212202510.GB28183@us.ibm.com> Date: Tue, 13 Feb 2018 14:17:07 +1100 Message-ID: <87tvulvarw.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sukadev Bhattiprolu writes: > Michael Ellerman [mpe@ellerman.id.au] wrote: >> Sukadev Bhattiprolu writes: >> >> > When VAS is not configured in the system, make sure to remove >> > the VAS debugfs directory and unregister the platform driver. >> > >> > Signed-off-by: Sukadev Bhattiprolu >> ... >> > diff --git a/arch/powerpc/platforms/powernv/vas.c b/arch/powerpc/platforms/powernv/vas.c >> > index aebbe95..f83e27d8 100644 >> > --- a/arch/powerpc/platforms/powernv/vas.c >> > +++ b/arch/powerpc/platforms/powernv/vas.c >> > @@ -169,8 +169,11 @@ static int __init vas_init(void) >> > found++; >> > } >> > >> > - if (!found) >> > + if (!found) { >> > + platform_driver_unregister(&vas_driver); >> > + vas_cleanup_dbgdir(); >> > return -ENODEV; >> > + } >> >> The better patch would be to move the call to vas_init_dbgdir() down >> here, where we know we have successfully registered the driver. > > Well, when VAS is configured, init_vas_instance() expects the top level > "vas" debugfs dir to already be setup. OK. > We could have each init_vas_instance() assume it is the first and > unconditionally call vas_init_dbgdir(). vas_init_dbgdir() could make > sure to initialize only once. Yeah that looks like a good solution. cheers