Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp870630ybt; Wed, 1 Jul 2020 12:04:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyz+2DHIlMPHQ6Qxj+4VDmGoIIqDLpTtangVKrVfExJrUPfH3TugplBLuhfhNSaQ62RteEt X-Received: by 2002:a05:6402:742:: with SMTP id p2mr11866267edy.135.1593630269517; Wed, 01 Jul 2020 12:04:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593630269; cv=none; d=google.com; s=arc-20160816; b=Y4E/2BSnflgfNf/khhZwsV/UliMDJLOV6VLvPl22tevSKSYjnU752aqtBluZ4Mft67 655yUdkF3gdVOV0tvEqLcQRaT7DwpR/vjqGR2/2j1SKgD0whJhiHa6EQtuVsaa9oGIyZ D6EvDyRv574KRd7AW7zUXiKFH9iOXsxLtOjZSTjjGxW8MXzp/CzXzvCdvb99Wp/WfXMn RED4hszIQ/s3BMVO8Sf2SAbVK/WzD9QXLiGs9joC5OM8019wrigbz30m7U88CJifdWmS RzExyRRm8KEj8XsKHD4U7jOCP/UgkzFCvGKltq4LV5FPd4yfWfD8E3ZP1VvYqfhxz0LI AZMw== 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=zQD5AqEJieTIUv79OsZgP1JA3MX0RuZlMCyd1RHfjHY=; b=mU47HXCn67bfrc3UDEkqt1kEDoEDsajxyePTQlDoa2ckG+5TCbJl4d0aE9/AraaCkp PbSOOjyquuOuG6h7qi7wJTHO3jzTIMmKZ6x6CD20XibUGEJwTBX2iKSPN3atVAtJjwW9 WdPuDsM1SlLGYyypTo5bYAmFBH+QqqsvuCX0e2N/HaUJ2nihObSxj5LVPv07v6bb6Irv f1BJWyrjuQVti/4s/97i8dWtRlJwav8zAY0ZSiOQtH7a1DgIyAPvGqi/HHHK36CxZ51C rDfJgEmrJ4U64OUUhCk35hXIKKwUzDuxMCeDebl2YuhZxxhA2H0cONg6QcDwrUUoNl7t d0IQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jo13si4604403ejb.198.2020.07.01.12.03.58; Wed, 01 Jul 2020 12:04:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726444AbgGATDT (ORCPT + 99 others); Wed, 1 Jul 2020 15:03:19 -0400 Received: from foss.arm.com ([217.140.110.172]:39426 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725875AbgGATDP (ORCPT ); Wed, 1 Jul 2020 15:03:15 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA3441FB; Wed, 1 Jul 2020 12:03:14 -0700 (PDT) Received: from [10.57.21.32] (unknown [10.57.21.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E0A843F68F; Wed, 1 Jul 2020 12:03:11 -0700 (PDT) Subject: Re: [PATCH v8 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU To: Jon Hunter , Krishna Reddy Cc: "joro@8bytes.org" , "will@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Thierry Reding , Yu-Huan Hsu , Sachin Nikam , Pritesh Raithatha , Timo Alho , Bitan Biswas , Mikko Perttunen , Nicolin Chen , Bryan Huntsman , "nicoleotsuka@gmail.com" References: <20200630001051.12350-1-vdumpa@nvidia.com> <20200630001051.12350-3-vdumpa@nvidia.com> <3e655881-bac4-f083-44ed-cfa0a61298d0@arm.com> <0d4f46d6-6a4e-bca0-bcf3-0e22a950e57b@nvidia.com> From: Robin Murphy Message-ID: Date: Wed, 1 Jul 2020 20:03:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0d4f46d6-6a4e-bca0-bcf3-0e22a950e57b@nvidia.com> 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 On 2020-07-01 19:47, Jon Hunter wrote: > > On 01/07/2020 19:28, Krishna Reddy wrote: >>>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500" >>> Hmm, there must be a better way to word that to express that it only applies to the sets of SMMUs that must be programmed identically, and not any other independent MMU-500s that might also happen to be in the same SoC. >> >> Let me reword it to "NVIDIA SoCs that must program multiple MMU-500s identically". >> >>>> + items: >>>> + - enum: >>>> + - nvdia,tegra194-smmu >>>> + - const: arm,mmu-500 >> >>> Is the fallback compatible appropriate here? If software treats this as a standard MMU-500 it will only program the first instance (because the second isn't presented as a separate MMU-500) - is there any way that isn't going to blow up? >> >> When compatible is set to both nvidia,tegra194-smmu and arm,mmu-500, implementation override ensure that both instances are programmed. Isn't it? I am not sure I follow your comment fully. > > The problem is, if for some reason someone had a Tegra194, but only set > the compatible string to 'arm,mmu-500' it would assume that it was a > normal arm,mmu-500 and only one instance would be programmed. We always > want at least 2 of the 3 instances programmed and so we should only > match 'nvidia,tegra194-smmu'. In fact, I think that we also need to > update the arm_smmu_of_match table to add 'nvidia,tegra194-smmu' with > the data set to &arm_mmu500. Right, the main concern is if the shiny new DT gets passed to an older kernel (or other OS entirely) which doesn't know the "nvdia,tegra194-smmu" compatible but would match on "arm,mmu-500" and bind a standard driver thinking it's going to work OK. The user would probably prefer that no driver matched and both instances were left turned off, than face the fallout of only one of them being set up. Robin.