From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: iommu/arm-smmu-v2 ASID/VMID calculation Date: Wed, 27 Jan 2016 19:08:50 +0000 Message-ID: <20160127190849.GF25545@arm.com> References: <198F501C-8D30-4EB5-BC40-4F40BB75D40B@caviumnetworks.com> <20160125170312.GJ22927@arm.com> <6F24A28A-6302-4C48-A933-B47A9735808C@caviumnetworks.com> <20160126115435.GB21553@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Chalamarla, Tirumalesh" Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , linux-arm-kernel List-Id: iommu@lists.linux-foundation.org On Wed, Jan 27, 2016 at 07:06:48PM +0000, Chalamarla, Tirumalesh wrote: > On 1/26/16, 3:54 AM, "Will Deacon" wrote: > >The problem is that you have shared state between multiple SMMU instances, > >which I don't think is correct. I'm fine with a workaround, but I don't > >want this logic to be used on other implementations where it is not > >needed. > > Ok, I will treat it as Errata and provide a patch for workaround this. Thank you. Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Wed, 27 Jan 2016 19:08:50 +0000 Subject: iommu/arm-smmu-v2 ASID/VMID calculation In-Reply-To: References: <198F501C-8D30-4EB5-BC40-4F40BB75D40B@caviumnetworks.com> <20160125170312.GJ22927@arm.com> <6F24A28A-6302-4C48-A933-B47A9735808C@caviumnetworks.com> <20160126115435.GB21553@arm.com> Message-ID: <20160127190849.GF25545@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Jan 27, 2016 at 07:06:48PM +0000, Chalamarla, Tirumalesh wrote: > On 1/26/16, 3:54 AM, "Will Deacon" wrote: > >The problem is that you have shared state between multiple SMMU instances, > >which I don't think is correct. I'm fine with a workaround, but I don't > >want this logic to be used on other implementations where it is not > >needed. > > Ok, I will treat it as Errata and provide a patch for workaround this. Thank you. Will