Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753946AbdCTJwx (ORCPT ); Mon, 20 Mar 2017 05:52:53 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38706 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753406AbdCTJws (ORCPT ); Mon, 20 Mar 2017 05:52:48 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 626B3607A2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=shankerd@codeaurora.org Reply-To: shankerd@codeaurora.org Subject: Re: [PATCH] irqchip: gic-v3-its: Don't assume GICv3 hardware supports 16bit INTID References: <1489556815-27121-1-git-send-email-shankerd@codeaurora.org> To: Marc Zyngier , linux-kernel , linux-arm-kernel Cc: Thomas Gleixner , Jason Cooper , Vikram Sethi From: Shanker Donthineni Message-ID: Date: Mon, 20 Mar 2017 04:52:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1708 Lines: 41 Hi Marc, On 03/17/2017 10:49 AM, Marc Zyngier wrote: > On 15/03/17 05:46, Shanker Donthineni wrote: >> The current ITS driver is assuming every ITS hardware implementation >> supports minimum of 16bit INTID. But this is not true, as per GICv3 >> specification, INTID field is IMPLEMENTATION DEFINED in the range of >> 14-24 bits. We might see an unpredictable system behavior on systems >> where hardware support less than 16bits and software tries to use >> 64K LPI interrupts. >> >> On Qualcomm Datacenter Technologies QDF2400 platform, boot log shows >> confusing information about number of LPI chunks as shown below. The >> QDF2400 ITS hardware supports 24bit INTID. >> >> This patch allocates the memory resources for PEND/PROP tables based >> on discoverable value which is specified in GITS_TYPER.IDbits. Also >> taking this opportunity to increase number of LPI/MSI(x) to 128K if >> the hardware is capable, and show log message that reflects the >> correct number of LPI chunks. > As much as I like the idea of fixing the obvious bug that assuming 16bit > of ID space is, what is the rational of capping the support to another > arbitrary value? I believe 128K LPIs are sufficient so capped to 17 bits. > Why can't we (just like other tables) try and allocate the full amount > required (with a possible back-off if allocations fail)? Qualcomm ITS hardware supports 24bit LPI, it requires lot of memory to handle 2^24 entry property and pending table. > > Thanks, > > M. -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.