Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2386935imm; Mon, 24 Sep 2018 03:34:35 -0700 (PDT) X-Google-Smtp-Source: ACcGV61OZdY/SHklNG4s+yQgV8dYdFIWSe6tpi2Cww7LNc41Gz5gTs0GYnmxq6EvJzxXHRFLEpeB X-Received: by 2002:a63:e943:: with SMTP id q3-v6mr8895453pgj.42.1537785275389; Mon, 24 Sep 2018 03:34:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537785275; cv=none; d=google.com; s=arc-20160816; b=JVboGOudIrx0aUM3PlUdM+jQukjaOFJ73/SWUTLfCYV7CJ1YyOVWOnMv2iJXJwNY24 mAJm9G2cd0maDb9Qd8UPsIQfCkwZs2x8YsRTmZFzBce2lpHZJVdyeOTYROblx6wYGREz GkY2iFhh5YRqfo9I5rVt3T6MWAB4VOYqBtecc7Uo93sPHr2z674HB3yQ2WndPSUVCuOt JLjfLPseU5nAS31VkwpXMebuh7eN7VaO7aIXbBC0ke3PC9/ZbFF96G6cuFmm6p43utah 0If/hK8UTK7z3LRQPrScRJIX6e25lsTTykhMSm4qJkSBfccjEG+1XESjS87WUUtbnQud Km1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=mkhOJri4RJj+PyzBjSSYTYqGnc3a5VfuT6AAoNa/X+4=; b=e1mADoDbfDLY+osf8y8NBjFMYTJiZMz7ypxBA/KyZZf4ocBRqrh8McAidNLuC92ryu HaJiCwruMS0nN7p2AIXDB0/J7c7o1Z4XlDYHgkV0fcIOZGRWtgG9VkxUSNM+YdHVOq5h Ee9eRoYMID6FvIsi1bUTDGJWKiObz0HgvG2v3koYC29mmoNTSJBF6XLaQ9TH2+RD6Sk7 et3IyjBh1u5mf6QKlrbLrjCtyDo2aiV0uu4pIMVjyj5v16j7u7ZPUDSCsbQ1cyUTm31h BtPU/Y2JJNqdM1R32LvNNXrVDkbSORVcKIpa+LUrb+k7hCJ8hsDNYo2Ddx7pkMAg4coB rk9w== 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 o33-v6si35126244pld.180.2018.09.24.03.34.20; Mon, 24 Sep 2018 03:34:35 -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; 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 S1728158AbeIXQfU (ORCPT + 99 others); Mon, 24 Sep 2018 12:35:20 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:60072 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727730AbeIXQfU (ORCPT ); Mon, 24 Sep 2018 12:35:20 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D4EFC80D; Mon, 24 Sep 2018 03:33:55 -0700 (PDT) Received: from [10.4.13.23] (en101.Emea.Arm.com [10.4.13.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AAC1F3F5B3; Mon, 24 Sep 2018 03:33:53 -0700 (PDT) Subject: Re: [PATCH 02/10] irqchip/gic-v3-its: Consolidate LPI_PENDBASE_SZ usage To: Marc Zyngier , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Ard Biesheuvel , Jeremy Linton , Jeffrey Hugo , Thomas Gleixner , Jason Cooper References: <20180921195954.21574-1-marc.zyngier@arm.com> <20180921195954.21574-3-marc.zyngier@arm.com> From: Suzuki K Poulose Message-ID: Date: Mon, 24 Sep 2018 11:33:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180921195954.21574-3-marc.zyngier@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 21/09/18 20:59, Marc Zyngier wrote: > LPI_PENDING_SZ is always used in conjunction with a max(). Let's > factor this in the definition of the macro, and simplify the rest > of the code. > > Signed-off-by: Marc Zyngier > --- > drivers/irqchip/irq-gic-v3-its.c | 12 ++++-------- > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index c2df341ff6fa..ed6aab11e019 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -62,7 +62,7 @@ static u32 lpi_id_bits; > */ > #define LPI_NRBITS lpi_id_bits > #define LPI_PROPBASE_SZ ALIGN(BIT(LPI_NRBITS), SZ_64K) > -#define LPI_PENDBASE_SZ ALIGN(BIT(LPI_NRBITS) / 8, SZ_64K) > +#define LPI_PENDBASE_SZ max_t(u32, SZ_64K, ALIGN(BIT(LPI_NRBITS) / 8, SZ_64K)) minor nit: The ALIGN() already aligns the given value up to the required alignment. So, if the LPI_NRBITS is guaranteed to be non-zero, we could simply drop the max_t(). Rest looks good to me. Suzuki > > #define LPI_PROP_DEFAULT_PRIO 0xa0 > > @@ -1924,12 +1924,9 @@ static int its_alloc_collections(struct its_node *its) > static struct page *its_allocate_pending_table(gfp_t gfp_flags) > { > struct page *pend_page; > - /* > - * The pending pages have to be at least 64kB aligned, > - * hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below. > - */ > + > pend_page = alloc_pages(gfp_flags | __GFP_ZERO, > - get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K))); > + get_order(LPI_PENDBASE_SZ)); > if (!pend_page) > return NULL; > > @@ -1941,8 +1938,7 @@ static struct page *its_allocate_pending_table(gfp_t gfp_flags) > > static void its_free_pending_table(struct page *pt) > { > - free_pages((unsigned long)page_address(pt), > - get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K))); > + free_pages((unsigned long)page_address(pt), get_order(LPI_PENDBASE_SZ)); > } > > static void its_cpu_init_lpis(void) >