Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp871929ybx; Thu, 31 Oct 2019 02:10:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqxnANuQwio+9iUzJsexUCzbCDYfR9bXQpmG6shOKpR3VmtV35ohTo0k/1mlEvjgzKGFSVYb X-Received: by 2002:a50:d80c:: with SMTP id o12mr4626308edj.251.1572513027923; Thu, 31 Oct 2019 02:10:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572513027; cv=none; d=google.com; s=arc-20160816; b=kWhCTPsGWAHld4Dh4BPgUvMQeIOD/NcuOFt/6gJNb6TVhhNZutoCEgO7wgucvkrWNm TOcta98ttD7I63cspjqRlwOtGtkPIiA499rkBJDwx3/xoxIHTKHu8Llsjar2fxRvLZYN SVnp4i8ZwpNRx/XWS7p0FYJenF+XT2YtQQFWLMT+mQ2pk6Y9LxEC4Z/Cp5hw5Xw+QlWZ IdQTEmGLxNbmtyE3JkWqdUDgaKdY88IDLrT4Nsze0OzcOpWrN7E56MZa3telVp1Y0zvy +jYjcJfOd0vyBvpeyz261DLFRLJUhCLzPyqn0vXvmckirze6IGdao5wheSdnJhD/qvkE Pv1Q== 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=+GzoLTL6xhfsdqyO3hwCQ0rmsI9l7WXpyI2rUPM4+40=; b=n+DvA0bJByNgkzdWZ0DVYkdVbgb7EEeaEGgji0u8n4bvkz6GWStecTO1Bvkgek7Uvf E+hSAPupCVzgSlht2oo6GeZ2ACIpYLPhvcy2+u9sk6YjR3dE+7wQTreJI5CI+WVI54qm qdDH/oaGTkSIdhloEzTJiv+r/LHKjnTluuQ8nOrN9WaZjnyeHKxYfWs/8b7JUATLSovS dviKVN051E39u9v+MKJXgicAVyeli1YUnPDw7Sl5+txiFjPkv6IuogcjYcBk0eLKlu17 amw75XPVeDetUukutxsmsVlwEaAdZ+ytcps5PSTqlI+O3lB+EfDsGgXzmCH8DfU0siaN CKQw== 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 a61si3822494edf.157.2019.10.31.02.10.03; Thu, 31 Oct 2019 02:10:27 -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 S1727130AbfJaJIR (ORCPT + 99 others); Thu, 31 Oct 2019 05:08:17 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:56710 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726827AbfJaJIR (ORCPT ); Thu, 31 Oct 2019 05:08:17 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id CA2A9A5AD9A00E4AB6C7; Thu, 31 Oct 2019 17:08:14 +0800 (CST) Received: from [127.0.0.1] (10.173.222.27) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.439.0; Thu, 31 Oct 2019 17:08:06 +0800 Subject: Re: [PATCH v2 06/36] irqchip/gic-v3-its: Kill its->device_ids and use TYPER copy instead To: Marc Zyngier CC: , , Eric Auger , James Morse , Julien Thierry , Suzuki K Poulose , Thomas Gleixner , Jason Cooper , Lorenzo Pieralisi , Andrew Murray , Jayachandran C , Robert Richter References: <20191027144234.8395-1-maz@kernel.org> <20191027144234.8395-7-maz@kernel.org> <603e60d8-b2a5-74a4-6d32-8277aa0e39c1@huawei.com> <86imo5xqoh.wl-maz@kernel.org> From: Zenghui Yu Message-ID: <7439499b-1626-51a5-2f67-e79e7fdbcdf9@huawei.com> Date: Thu, 31 Oct 2019 17:08:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <86imo5xqoh.wl-maz@kernel.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.222.27] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/10/31 16:30, Marc Zyngier wrote: > Hi Zenghui, > > On Thu, 31 Oct 2019 06:33:23 +0000, > Zenghui Yu wrote: >> >> Hi Marc, >> >> On 2019/10/27 22:42, Marc Zyngier wrote: >>> Now that we have a copy of TYPER in the ITS structure, rely on this >>> to provide the same service as its->device_ids, which gets axed. >>> Errata workarounds are now updating the cached fields instead of >>> requiring a separate field in the ITS structure. >>> >>> Signed-off-by: Marc Zyngier >> >> Reviewed-by: Zenghui Yu > > Thanks for that. > >> >>> --- >>> drivers/irqchip/irq-gic-v3-its.c | 24 +++++++++++++----------- >>> include/linux/irqchip/arm-gic-v3.h | 2 +- >>> 2 files changed, 14 insertions(+), 12 deletions(-) >>> >>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >>> index 3b046181ddfc..6c91c7feadf3 100644 >>> --- a/drivers/irqchip/irq-gic-v3-its.c >>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>> @@ -109,7 +109,6 @@ struct its_node { >>> struct list_head its_device_list; >>> u64 flags; >>> unsigned long list_nr; >>> - u32 device_ids; >>> int numa_node; >>> unsigned int msi_domain_flags; >>> u32 pre_its_base; /* for Socionext Synquacer */ >>> @@ -117,6 +116,7 @@ struct its_node { >>> }; >>> #define is_v4(its) (!!((its)->typer & >>> GITS_TYPER_VLPIS)) >>> +#define device_ids(its) (FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1) >>> #define ITS_ITT_ALIGN SZ_256 >>> @@ -1938,9 +1938,9 @@ static bool its_parse_indirect_baser(struct >>> its_node *its, >>> if (new_order >= MAX_ORDER) { >>> new_order = MAX_ORDER - 1; >>> ids = ilog2(PAGE_ORDER_TO_SIZE(new_order) / (int)esz); >>> - pr_warn("ITS@%pa: %s Table too large, reduce ids %u->%u\n", >>> + pr_warn("ITS@%pa: %s Table too large, reduce ids %llu->%u\n", >>> &its->phys_base, its_base_type_string[type], >>> - its->device_ids, ids); >>> + device_ids(its), ids); >> >> But this pr_warn() looks a bit odd. The table type is chosen from >> its_base_type_string[], but ids is always Devbits (+1)? > > This is a bit of a shortcut, I agree. But the device table practically > is the only one where we can run out of space if the ITS doesn't > support two level tables. All the other tables are very small, being > limited by the number of CPUs (collections) or a small ID space > (vPEs). Make sense. Thanks for the clarification. Zenghui > > So while this is a bit ugly, I don't thing it is not too concerning. > > Thanks, > > M. >