Received: by 10.223.176.46 with SMTP id f43csp165938wra; Thu, 18 Jan 2018 15:34:04 -0800 (PST) X-Google-Smtp-Source: ACJfBotX7xKKwaNFN0UgysitK/8iW3njCSYm8tvD7lIAggRU/pv7QsLc+KmjkFhIhe/UVo7TOO0T X-Received: by 10.101.66.131 with SMTP id j3mr1259821pgp.56.1516318444551; Thu, 18 Jan 2018 15:34:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516318444; cv=none; d=google.com; s=arc-20160816; b=uuEhM0cj2KV4l1TpX1PZG04vutZho503Cik2YMhSy49UedkxBeCvGWnQ/Fz6dXpBIh lPuN7slw5qEXv3hLKoaki/jxe8nB1qeo0O8MSifkeQldbBQ9zJyengo5G7bH/tGnAiIH Qb1MJ7/kcTT0/0fRjIxeIFxSWaQrNAwEWeVxe8v3OHgYTra1HAUIpRVWkyhiJovlxxPr A0cqT8kTcvvTb/PccD21QUFJSBJOJ1n6NqUdwhemzKeHdax9PCOWRCqv+FyQAwQe0a47 GQ04fzxHxdI0HZ6CE5VtpiGlQW+87GlMHYHaRu5SKsAgnWWPsIX5Xd9CoF6K0v3JLxJJ yoDw== 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:dkim-signature:arc-authentication-results; bh=3bEWnuhwjz13sno/ye9QYjZPbbD9ZTfhw4J51+LJMow=; b=at6LcheSd/kiXXKdLTyEpSWHdG6gX454ml2eZ9nI7Y7Ic3+rR33KFLK7RNtNlAhbZo azgl2HDVp5glzCzaiezmmt/WXoeqPPuNlQa2i3hZPnFdHo5BnadqXYTnKXJbS3rAU3vp 1pWUyPZTvCyY23a7NDyuqNI2uBXtlyFmn1Q/Segcm4ro+RUNzPu37DtWuI0Pop3IJaz+ Ve0/Ogje09u3f7Bb/FH7pszIeDEiTTa+9gCMiz3E1VgHga8+yvc6vhKOBkNjWMoXelkF JV3fwoia4t33SBf6D9WfqFakwHaczhpXMRIJH9q8KOPVHXAqa9u9ADips+YMm7O6Lc/b XrqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=IYMKoJ7H; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13si6813108pgp.347.2018.01.18.15.33.49; Thu, 18 Jan 2018 15:34:04 -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; dkim=pass header.i=@chromium.org header.s=google header.b=IYMKoJ7H; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932587AbeARXdR (ORCPT + 99 others); Thu, 18 Jan 2018 18:33:17 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:38407 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932414AbeARXdJ (ORCPT ); Thu, 18 Jan 2018 18:33:09 -0500 Received: by mail-pf0-f193.google.com with SMTP id k19so15936767pfj.5 for ; Thu, 18 Jan 2018 15:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3bEWnuhwjz13sno/ye9QYjZPbbD9ZTfhw4J51+LJMow=; b=IYMKoJ7HbqZ+XDMZJljmT6FivG0OKZMQkUCg8LRSJ+N4gj1kdh/NPHZU37OSv9h2sC egluQsIAuKvUpNP67Jb/u50hqQgFUZIjbHi6ZmU/vkz3xEuP+4MyAQdWxNd08LebOsrv yuEKc+dcK6K3IE72EKnks7Su5UKRIJcvvDv1g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3bEWnuhwjz13sno/ye9QYjZPbbD9ZTfhw4J51+LJMow=; b=sXprwGFo6dK66lmXt2VheBwBPQrEFWurgOyKBbFxs0htfm7F0FHMfzeN/Euz0pia8H Gj9qj72u1MufvoSYYzGsi2PW24t22TkC3GZIBd77kIRcYAgT2thHrD+R4zKaF/9DIGEh iwANT2OElp7/r+lp1p3mENR5tBSeb7fCzxT2HFwMgRNuiy10toN+uJd6Xqwwc83CduMW hAZhK8A4izxxvzZ7yHElBDhNG3MrCyoYI2/mv2TOxwHB2MeWiyBDWD/S11SSVYMzEpp6 WnnYeJAmbSFV31hyTxJTOZHqBVq04YSQOK23+lj6yYmPRkcXPrCjJBKGqi8vUeyqRMF+ NFlw== X-Gm-Message-State: AKGB3mLAw2SGdYCw7YnzjSjRJP9GbhEui63sXSpPfSPMSlBZCwaSla/t fdgtW1Y0qbU5vEiqX065ILtNNXGZRVw= X-Received: by 10.99.122.15 with SMTP id v15mr30477237pgc.175.1516318388540; Thu, 18 Jan 2018 15:33:08 -0800 (PST) Received: from google.com ([2620:0:1000:1600:2995:5156:92ad:6019]) by smtp.gmail.com with ESMTPSA id a28sm15581048pfe.70.2018.01.18.15.33.07 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 18 Jan 2018 15:33:07 -0800 (PST) Date: Thu, 18 Jan 2018 15:33:05 -0800 From: Brian Norris To: Marc Zyngier Cc: Derek Basehore , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com, tglx@linutronix.de, Sudeep Holla Subject: Re: [PATCH 4/8] irqchip/gic-v3: add ability to save/restore GIC/ITS state Message-ID: <20180118233243.GA209323@google.com> References: <20180112212422.148625-1-dbasehore@chromium.org> <20180112212422.148625-5-dbasehore@chromium.org> <86fu79fx3n.wl-marc.zyngier@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86fu79fx3n.wl-marc.zyngier@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Sat, Jan 13, 2018 at 06:10:52PM +0000, Marc Zyngier wrote: > On Fri, 12 Jan 2018 21:24:18 +0000, > Derek Basehore wrote: > > > > Some platforms power off GIC logic in S3, so we need to save/restore > > S3 is a not a GIC concept, and is only vaguely mentioned in terms of > the rk3399 silicon, if grep serves me right. Please expand on what > state this is exactly. > > > state. This adds a DT-binding to save/restore the GICD/GICR/GITS > > states using the new CPU_PM_SYSTEM_ENTER/EXIT CPU PM states. > > DT binding? I can't see any in this patch. > > > > > Change-Id: I1fb2117296373fa67397fdd4a8960077b241462e > > It's been mentioned somewhere else in the thread: these tags have no > purpose in the kernel. Please sanitise your patches before posting them. > > > Signed-off-by: Derek Basehore > > Signed-off-by: Brian Norris > > Who is the author of this patch? If that's a joined authorship, please > use the Co-Developed-by: tag. I only did some minimal code shuffling when rebasing and working with this code in our downstream tree. I probably didn't actually need to apply my Signed-off-by at the time, but Derek carried it along anyway. Derek is the author, and I'd be perfectly fine dropping my S-o-b from these patches. > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > > index 9a7a15049903..95d37fb6f458 100644 > > --- a/drivers/irqchip/irq-gic-v3.c > > +++ b/drivers/irqchip/irq-gic-v3.c ... > > @@ -991,11 +1188,99 @@ static const struct irq_domain_ops partition_domain_ops = { > > .select = gic_irq_domain_select, > > }; > > > > +static int gic_populate_ctx(struct gic_dist_ctx *ctx, int irqs) > > This isn't the GIC context. This is the save area. Please name the > function accordingly. > > > +{ > > + int err; > > + > > + ctx->irouter = kcalloc(GICD_NR_REGS(IROUTER, irqs), > > + sizeof(*ctx->irouter), GFP_KERNEL); > > + if (IS_ERR(ctx->irouter)) > > + return PTR_ERR(ctx->irouter); > > + > > + ctx->igroupr = kcalloc(GICD_NR_REGS(IGROUPR, irqs), > > + sizeof(*ctx->igroupr), GFP_KERNEL); > > + if (IS_ERR(ctx->igroupr)) { > > + err = PTR_ERR(ctx->igroupr); > > + goto out_irouter; > > + } > > + > > + ctx->isenabler = kcalloc(GICD_NR_REGS(ISENABLER, irqs), > > + sizeof(*ctx->isenabler), GFP_KERNEL); > > + if (IS_ERR(ctx->isenabler)) { > > + err = PTR_ERR(ctx->isenabler); > > + goto out_igroupr; > > + } > > + > > + ctx->ispendr = kcalloc(GICD_NR_REGS(ISPENDR, irqs), > > + sizeof(*ctx->ispendr), GFP_KERNEL); > > + if (IS_ERR(ctx->ispendr)) { > > + err = PTR_ERR(ctx->ispendr); > > + goto out_isenabler; > > + } > > + > > + ctx->isactiver = kcalloc(GICD_NR_REGS(ISACTIVER, irqs), > > + sizeof(*ctx->isactiver), GFP_KERNEL); > > + if (IS_ERR(ctx->isactiver)) { > > + err = PTR_ERR(ctx->isactiver); > > + goto out_ispendr; > > + } > > + > > + ctx->ipriorityr = kcalloc(GICD_NR_REGS(IPRIORITYR, irqs), > > + sizeof(*ctx->ipriorityr), GFP_KERNEL); > > + if (IS_ERR(ctx->ipriorityr)) { > > + err = PTR_ERR(ctx->ipriorityr); > > + goto out_isactiver; > > + } > > + > > + ctx->icfgr = kcalloc(GICD_NR_REGS(ICFGR, irqs), sizeof(*ctx->icfgr), > > + GFP_KERNEL); > > + if (IS_ERR(ctx->icfgr)) { > > + err = PTR_ERR(ctx->icfgr); > > + goto out_ipriorityr; > > + } > > + > > + ctx->igrpmodr = kcalloc(GICD_NR_REGS(IGRPMODR, irqs), > > + sizeof(*ctx->igrpmodr), GFP_KERNEL); > > + if (IS_ERR(ctx->igrpmodr)) { > > + err = PTR_ERR(ctx->igrpmodr); > > + goto out_icfgr; > > + } > > + > > + ctx->nsacr = kcalloc(GICD_NR_REGS(NSACR, irqs), sizeof(*ctx->nsacr), > > + GFP_KERNEL); > > + if (IS_ERR(ctx->nsacr)) { > > + err = PTR_ERR(ctx->nsacr); > > + goto out_igrpmodr; > > + } > > + > > + return 0; > > + > > +out_irouter: > > + kfree(ctx->irouter); > > +out_igroupr: > > + kfree(ctx->igroupr); > > +out_isenabler: > > + kfree(ctx->isenabler); > > +out_ispendr: > > + kfree(ctx->ispendr); > > +out_isactiver: > > + kfree(ctx->isactiver); > > +out_ipriorityr: > > + kfree(ctx->ipriorityr); > > +out_icfgr: > > + kfree(ctx->icfgr); > > +out_igrpmodr: > > + kfree(ctx->igrpmodr); > > WHy do you need all of these labels? Can't you just branch to an error > one and free them all in one go? If you assume that the memory was initially all zero (which it is -- kzalloc()), then you can get away with a single error label (kfree(0) is a no-op). But otherwise, this is the right way to do error handling... > In the end, what is the point of > keeping almost all of them if the last allocation fails? I didn't understand this question until I realized that the error handling is all accidentally done in reverse. If we fail the last allocation, we should be freeing all but the last one. But this code actually only frees 1 bit of memory in that case (i.e., a memory leak). > > + return err; > > +} > > + > > static int __init gic_init_bases(void __iomem *dist_base, > > struct redist_region *rdist_regs, > > u32 nr_redist_regions, > > u64 redist_stride, > > - struct fwnode_handle *handle) > > + struct fwnode_handle *handle, > > + struct gic_dist_ctx *gicd_ctx, > > + struct gic_redist_ctx *gicr_ctx) > > { > > u32 typer; > > int gic_irqs; ... > > @@ -1232,17 +1527,35 @@ static int __init gic_of_init(struct device_node *node, struct device_node *pare > > if (of_property_read_u64(node, "redistributor-stride", &redist_stride)) > > redist_stride = 0; > > > > + if (of_property_read_bool(node, "save-suspend-state")) { > > + gicd_ctx = kzalloc(sizeof(*gicd_ctx), GFP_KERNEL); > > + if (IS_ERR(gicd_ctx)) { > > + err = PTR_ERR(gicd_ctx); > > + goto out_unmap_rdist; > > + } > > + > > + gicr_ctx = kcalloc(num_possible_cpus(), sizeof(*gicr_ctx), > > + GFP_KERNEL); > > Since this is a per-cpu allocation, why isn't this a per-cpu > allocation? In other words, why isn't the GICR save area allocated as > CPUs get matched against their redistributors instead? > > > + if (IS_ERR(gicr_ctx)) { > > + err = PTR_ERR(gicr_ctx); > > + goto out_free_gicd_ctx; > > + } > > + } > > You really want to kill the box because something went wrong in your > save area allocation? It doesn't feel quite right. Isn't that what all drivers (including irqchip drivers) do on failed allocations? What else would we do? Pretend that we can limp along and just b0rk the system when it suspends? Brian