From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org ([203.11.71.1]:51685 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753443AbeDQMx6 (ORCPT ); Tue, 17 Apr 2018 08:53:58 -0400 From: Michael Ellerman To: Anshuman Khandual , David Miller , khandual@linux.vnet.ibm.com Cc: hch@lst.de, konrad.wilk@oracle.com, iommu@lists.linux-foundation.org, x86@kernel.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-ide@vger.kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 01/12] iommu-common: move to arch/sparc In-Reply-To: References: <20180415145947.1248-1-hch@lst.de> <20180415145947.1248-2-hch@lst.de> <20180416.095833.969403163564136309.davem@davemloft.net> Date: Tue, 17 Apr 2018 22:53:53 +1000 Message-ID: <87wox60za6.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org Anshuman Khandual writes: > On 04/16/2018 07:28 PM, David Miller wrote: >> From: Anshuman Khandual >> Date: Mon, 16 Apr 2018 14:26:07 +0530 >> >>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote: >>>> This code is only used by sparc, and all new iommu drivers should use the >>>> drivers/iommu/ framework. Also remove the unused exports. >>>> >>>> Signed-off-by: Christoph Hellwig >>> >>> Right, these functions are used only from SPARC architecture. Simple >>> git grep confirms it as well. Hence it makes sense to move them into >>> arch code instead. >> >> Well, we put these into a common location and used type friendly for >> powerpc because we hoped powerpc would convert over to using this >> common piece of code as well. >> >> But nobody did the powerpc work. Sorry. >> If you look at the powerpc iommu support, it's the same code basically >> for entry allocation. > > I understand. But there are some differences in iommu_table structure, > how both regular and large IOMMU pools are being initialized etc. So > if the movement of code into SPARC help cleaning up these generic config > options in general, I guess we should do that. But I will leave it upto > others who have more experience in this area. > > +mpe This is the first I've heard of it, I guess it's probably somewhere on Ben's append-only TODO list. Some of the code does look very similar, but not 100%. So someone would need to do some work to reconcile the two and test the result. TBH I doubt we're going to get around to it any time soon. Unless we have a volunteer? cheers From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Ellerman Subject: Re: [PATCH 01/12] iommu-common: move to arch/sparc Date: Tue, 17 Apr 2018 22:53:53 +1000 Message-ID: <87wox60za6.fsf@concordia.ellerman.id.au> References: <20180415145947.1248-1-hch@lst.de> <20180415145947.1248-2-hch@lst.de> <20180416.095833.969403163564136309.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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: Anshuman Khandual , David Miller khandual-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org, konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, hch-jcswGhMUV9g@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-ide@vger.kernel.org Anshuman Khandual writes: > On 04/16/2018 07:28 PM, David Miller wrote: >> From: Anshuman Khandual >> Date: Mon, 16 Apr 2018 14:26:07 +0530 >> >>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote: >>>> This code is only used by sparc, and all new iommu drivers should use the >>>> drivers/iommu/ framework. Also remove the unused exports. >>>> >>>> Signed-off-by: Christoph Hellwig >>> >>> Right, these functions are used only from SPARC architecture. Simple >>> git grep confirms it as well. Hence it makes sense to move them into >>> arch code instead. >> >> Well, we put these into a common location and used type friendly for >> powerpc because we hoped powerpc would convert over to using this >> common piece of code as well. >> >> But nobody did the powerpc work. Sorry. >> If you look at the powerpc iommu support, it's the same code basically >> for entry allocation. > > I understand. But there are some differences in iommu_table structure, > how both regular and large IOMMU pools are being initialized etc. So > if the movement of code into SPARC help cleaning up these generic config > options in general, I guess we should do that. But I will leave it upto > others who have more experience in this area. > > +mpe This is the first I've heard of it, I guess it's probably somewhere on Ben's append-only TODO list. Some of the code does look very similar, but not 100%. So someone would need to do some work to reconcile the two and test the result. TBH I doubt we're going to get around to it any time soon. Unless we have a volunteer? cheers From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ozlabs.org ([IPv6:2401:3900:2:1::2]:59003 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23990498AbeDQMyBgl03P (ORCPT ); Tue, 17 Apr 2018 14:54:01 +0200 From: Michael Ellerman Subject: Re: [PATCH 01/12] iommu-common: move to arch/sparc In-Reply-To: References: <20180415145947.1248-1-hch@lst.de> <20180415145947.1248-2-hch@lst.de> <20180416.095833.969403163564136309.davem@davemloft.net> Date: Tue, 17 Apr 2018 22:53:53 +1000 Message-ID: <87wox60za6.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Anshuman Khandual , David Miller khandual@linux.vnet.ibm.com Cc: hch@lst.de, konrad.wilk@oracle.com, iommu@lists.linux-foundation.org, x86@kernel.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-ide@vger.kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linux-arm-kernel@lists.infradead.org Message-ID: <20180417125353._HrRsS6ooKMh8Om3zy06oKPZX9HmuNh3tJdl4URUfn8@z> Anshuman Khandual writes: > On 04/16/2018 07:28 PM, David Miller wrote: >> From: Anshuman Khandual >> Date: Mon, 16 Apr 2018 14:26:07 +0530 >> >>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote: >>>> This code is only used by sparc, and all new iommu drivers should use the >>>> drivers/iommu/ framework. Also remove the unused exports. >>>> >>>> Signed-off-by: Christoph Hellwig >>> >>> Right, these functions are used only from SPARC architecture. Simple >>> git grep confirms it as well. Hence it makes sense to move them into >>> arch code instead. >> >> Well, we put these into a common location and used type friendly for >> powerpc because we hoped powerpc would convert over to using this >> common piece of code as well. >> >> But nobody did the powerpc work. Sorry. >> If you look at the powerpc iommu support, it's the same code basically >> for entry allocation. > > I understand. But there are some differences in iommu_table structure, > how both regular and large IOMMU pools are being initialized etc. So > if the movement of code into SPARC help cleaning up these generic config > options in general, I guess we should do that. But I will leave it upto > others who have more experience in this area. > > +mpe This is the first I've heard of it, I guess it's probably somewhere on Ben's append-only TODO list. Some of the code does look very similar, but not 100%. So someone would need to do some work to reconcile the two and test the result. TBH I doubt we're going to get around to it any time soon. Unless we have a volunteer? cheers From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Ellerman Date: Tue, 17 Apr 2018 12:53:53 +0000 Subject: Re: [PATCH 01/12] iommu-common: move to arch/sparc Message-Id: <87wox60za6.fsf@concordia.ellerman.id.au> List-Id: References: <20180415145947.1248-1-hch@lst.de> <20180415145947.1248-2-hch@lst.de> <20180416.095833.969403163564136309.davem@davemloft.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org Anshuman Khandual writes: > On 04/16/2018 07:28 PM, David Miller wrote: >> From: Anshuman Khandual >> Date: Mon, 16 Apr 2018 14:26:07 +0530 >> >>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote: >>>> This code is only used by sparc, and all new iommu drivers should use the >>>> drivers/iommu/ framework. Also remove the unused exports. >>>> >>>> Signed-off-by: Christoph Hellwig >>> >>> Right, these functions are used only from SPARC architecture. Simple >>> git grep confirms it as well. Hence it makes sense to move them into >>> arch code instead. >> >> Well, we put these into a common location and used type friendly for >> powerpc because we hoped powerpc would convert over to using this >> common piece of code as well. >> >> But nobody did the powerpc work. Sorry. >> If you look at the powerpc iommu support, it's the same code basically >> for entry allocation. > > I understand. But there are some differences in iommu_table structure, > how both regular and large IOMMU pools are being initialized etc. So > if the movement of code into SPARC help cleaning up these generic config > options in general, I guess we should do that. But I will leave it upto > others who have more experience in this area. > > +mpe This is the first I've heard of it, I guess it's probably somewhere on Ben's append-only TODO list. Some of the code does look very similar, but not 100%. So someone would need to do some work to reconcile the two and test the result. TBH I doubt we're going to get around to it any time soon. Unless we have a volunteer? cheers From mboxrd@z Thu Jan 1 00:00:00 1970 From: mpe@ellerman.id.au (Michael Ellerman) Date: Tue, 17 Apr 2018 22:53:53 +1000 Subject: [PATCH 01/12] iommu-common: move to arch/sparc In-Reply-To: References: <20180415145947.1248-1-hch@lst.de> <20180415145947.1248-2-hch@lst.de> <20180416.095833.969403163564136309.davem@davemloft.net> Message-ID: <87wox60za6.fsf@concordia.ellerman.id.au> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Anshuman Khandual writes: > On 04/16/2018 07:28 PM, David Miller wrote: >> From: Anshuman Khandual >> Date: Mon, 16 Apr 2018 14:26:07 +0530 >> >>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote: >>>> This code is only used by sparc, and all new iommu drivers should use the >>>> drivers/iommu/ framework. Also remove the unused exports. >>>> >>>> Signed-off-by: Christoph Hellwig >>> >>> Right, these functions are used only from SPARC architecture. Simple >>> git grep confirms it as well. Hence it makes sense to move them into >>> arch code instead. >> >> Well, we put these into a common location and used type friendly for >> powerpc because we hoped powerpc would convert over to using this >> common piece of code as well. >> >> But nobody did the powerpc work. Sorry. >> If you look at the powerpc iommu support, it's the same code basically >> for entry allocation. > > I understand. But there are some differences in iommu_table structure, > how both regular and large IOMMU pools are being initialized etc. So > if the movement of code into SPARC help cleaning up these generic config > options in general, I guess we should do that. But I will leave it upto > others who have more experience in this area. > > +mpe This is the first I've heard of it, I guess it's probably somewhere on Ben's append-only TODO list. Some of the code does look very similar, but not 100%. So someone would need to do some work to reconcile the two and test the result. TBH I doubt we're going to get around to it any time soon. Unless we have a volunteer? cheers