Received: by 10.192.165.148 with SMTP id m20csp4563478imm; Tue, 24 Apr 2018 05:01:24 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+eB04t8YKzj7LfpXpUDHQLAJreqENKYeIEF31Xy4MvyyDFrH4ZZJMomRBV+bWUhbPm7o03 X-Received: by 10.99.116.76 with SMTP id e12mr20001267pgn.270.1524571284521; Tue, 24 Apr 2018 05:01:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524571284; cv=none; d=google.com; s=arc-20160816; b=ToOlPqCbmy51MVo00hQ/WjfhaDN5QLlXMeoNabhqb2lSgZ09chGh7UvbLqfDVI4be0 rvTQ2aaA5IiCMsC6GAwaNS+knh+5eMO+TrcdkpGNKqujsBsvABwX3Gt3KpY+C6pBzFjY i9prioqrDgXY8wGzjW5VSsHvn6WXvR7EWP9Gl6Ba4o/E9jtVMC/s4Fap+2iMiTjqy8z4 iGJW9dmbAhhtaf4lo68Ma72MP+UYd6mRn5ZuYN+0tZgS58XJEpgAdIbNa3OErnKxJfVM 9A2FqgcXMGSZNglefRdwV4NXcDRW3aV5iQWwKNmx6iFN2El5Ak1/1RitfgDLP2dTRXaE RWQw== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=oS1IM95X3Lw6Rw5x35GQzDJO/UdjmIdjnEhvw9Ha3hA=; b=NGAwdeWe8ZYszhCQWjh0Zo4x1S85FQFZB05yTlP//LaYnGNxELoYbhJvIN6FPiXPot bBOGFJqrKGyjKraC+zrALLHbokmxisvEnAbMPBlzihMclW3Mrbr0VGe9tP9T67jbjCIp bKMJs14RQ3XHwjFdQdbG0MhAm1v59uE96vknK2WzGdwqKuaG/3Om7pm/PNfm5943tbkd DqTCms4ChKhi2mcf/IfS1MIhilfrDu+stmoTE5eT7HPfJf1E040WKg50eO2JIQLK8Tnw JBexfdykmSwRfTob2FiYRcrogqeHz0esCxYLihb0C2fpDgpFcZ4v1ODQ/xloIsLYADsY LpWg== 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 ba2-v6si13883123plb.110.2018.04.24.05.01.09; Tue, 24 Apr 2018 05:01:24 -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 S1756983AbeDXL5n (ORCPT + 99 others); Tue, 24 Apr 2018 07:57:43 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:7193 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756242AbeDXL5l (ORCPT ); Tue, 24 Apr 2018 07:57:41 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 35E272134EB3D; Tue, 24 Apr 2018 19:57:26 +0800 (CST) Received: from [127.0.0.1] (10.177.29.40) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Apr 2018 19:57:19 +0800 Subject: Re: [RFC 1/2] iommu/arm-smmu-v3: Remove bypass in arm_smmu_reset_device To: Robin Murphy , , References: <1524483959-54940-1-git-send-email-xieyisheng1@huawei.com> <1524483959-54940-2-git-send-email-xieyisheng1@huawei.com> <9e2f8646-482a-e721-d1b6-e674de48e276@arm.com> CC: , , , , From: Yisheng Xie Message-ID: <85c3b7d4-19c0-ea9c-b698-18e199b1da6d@huawei.com> Date: Tue, 24 Apr 2018 19:57:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <9e2f8646-482a-e721-d1b6-e674de48e276@arm.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.40] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, Thanks for your comment! On 2018/4/24 0:07, Robin Murphy wrote: > On 23/04/18 12:45, Yisheng Xie wrote: >> Add a bypass parameter in arm_smmu_device to keep whether smmu device >> should pypass or not, so parameter bypass in arm_smmu_reset_device can >> be removed. > > Given that the GBPA configuration implied by the bypass argument here > is only there to avoid initialising a full stream table when the firmware > is terminally broken, I wonder if it would make sense to simply skip > allocating a stream table at all in that case. Then we could just base > the subsequent SMMUEN/GPBA decision on whether strtab_cfg.strtab is valid or not. > Yes, it may save many memory, and should be care about not access strtab when attach device or other similar scenario, anyway software can achieve this after move bypass to struct arm_smmu_device. Thanks Yisheng > Robin. >