Received: by 10.223.148.5 with SMTP id 5csp6228910wrq; Wed, 17 Jan 2018 10:56:13 -0800 (PST) X-Google-Smtp-Source: ACJfBosyrGkZb/FU3Hetd3qYaArRJEBp7TR9llCOQQajrsM+OFvIXTXyvae9LfSGEGhRwJHOs3de X-Received: by 10.98.152.149 with SMTP id d21mr32260838pfk.108.1516215373763; Wed, 17 Jan 2018 10:56:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516215373; cv=none; d=google.com; s=arc-20160816; b=JZpmszvk1KZ0hVQ/4E2UIV99vZl8TuWJ1+d3VpzPkLmrGhLCk43OSPIZs3Mb2FecI6 w3VOLRph2KrRAWooL4ZVl15l50jM9SnCwl4r0ZmM3cvp61In7RGgFRHAmlYAOShSJsni NdqPqXXF4Nw8XdfJ1uTl3tPaQnZ17tDihOnVgUnpom/8DEuAXnRXL6ozdMUZn4W9YlpF DKEUhKf76NoNujd4IOTEazq72L3q5xfDWsAe2Dm5clWDguyMtBgMKU6f8dZqD33Fqvpk ASxr6NUwq3//Z1SrXHiLtuxK1XNwznvLpiiMu+gEmaof4zX+l4BmAB+qkYdrDabHgsCj Ht/Q== 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:arc-authentication-results; bh=KlJxX514S3sWXEh1HaaDQrqvI0+8uSOnFCa3pmn6L80=; b=HOLu9ELJYFMPoaum9D53hgVMsfT1UiUcn2TZ0qGHo1Bgt3WkKYAXkfiomiMPteAWGy C2QMKiSzo2SI3mPWEiA2gzGq3Sn/Bk/2kSjsse8REUKRZBvRfsO1ztt5T4NVFcwjgpJR yEz4Qbom1U4OoR3amtS3a6aFUlwGRHMKs/sbY2mG0YnshLHi9e9LDlgE6+79syvnqlRU YowXVvtXKZeb3erAlNFG7ioR2Os68RLbHEW+7vmzSNmoYj9ayHltyM2GM36s+fossQLR 26dkLYW6lpFU2RHukqYNKLR231WQZ6Pp7+zUWfQoX2QRswPuW3C7BV4Y/NGkGE61CCTl YB4A== 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 p63si4223522pga.736.2018.01.17.10.55.59; Wed, 17 Jan 2018 10:56:13 -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 S1754589AbeAQSyG (ORCPT + 99 others); Wed, 17 Jan 2018 13:54:06 -0500 Received: from foss.arm.com ([217.140.101.70]:46404 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754066AbeAQSyF (ORCPT ); Wed, 17 Jan 2018 13:54:05 -0500 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 0BD9A80D; Wed, 17 Jan 2018 10:54:05 -0800 (PST) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A134F3F53D; Wed, 17 Jan 2018 10:54:03 -0800 (PST) Subject: Re: [PATCH] iommu/arm-smmu-v3: suppress MSI allocation failure message To: Nate Watterson , Will Deacon , Joerg Roedel , linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Cc: Sinan Kaya , Marc Zyngier References: <1516214399-24012-1-git-send-email-nwatters@codeaurora.org> From: Robin Murphy Message-ID: <2f651cfe-e006-cf1d-b624-08e2ba5340fc@arm.com> Date: Wed, 17 Jan 2018 18:54:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1516214399-24012-1-git-send-email-nwatters@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ +Marc just in case ] On 17/01/18 18:39, Nate Watterson wrote: > From: Sinan Kaya > > Even though QDF2400 supports MSI interrupts with SMMUv3, it is not enabled > in ACPI FW to preserve compatibility with older kernel versions. Code is > emitting warning message during boot. > > This is causing some test tools to record a false warning and is causing > support issues. > > Better reduce the message level. Ugh, that's unfortunate, since there are also plenty of genuine error conditions encapsulated in there which we *would* want to report as such (but still then fall back to wired IRQs if possible). Is the return value sufficient to differentiate the "there is no MSI parent" and "there are MSIs but something went wrong" cases, or is it more complicated than that? Robin. > Signed-off-by: Sinan Kaya > Signed-off-by: Nate Watterson > --- > drivers/iommu/arm-smmu-v3.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c > index 744592d..2118fda 100644 > --- a/drivers/iommu/arm-smmu-v3.c > +++ b/drivers/iommu/arm-smmu-v3.c > @@ -2331,7 +2331,7 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu) > /* Allocate MSIs for evtq, gerror and priq. Ignore cmdq */ > ret = platform_msi_domain_alloc_irqs(dev, nvec, arm_smmu_write_msi_msg); > if (ret) { > - dev_warn(dev, "failed to allocate MSIs\n"); > + dev_info(dev, "failed to allocate MSIs\n"); > return; > } > >