From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers Date: Thu, 4 Dec 2014 11:25:35 +0000 Message-ID: References: <1417453034-21379-1-git-send-email-will.deacon@arm.com> <3152553.esaQuZiCgi@wuerfel> <20141204102127.GF13224@arm.com> <5643715.BADzWxcqOQ@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5643715.BADzWxcqOQ@wuerfel> 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: Arnd Bergmann Cc: "jroedel-l3A5Bk7waGM@public.gmane.org" , Will Deacon , Pantelis Antoniou , Linux IOMMU , Thierry Reding , Rob Herring , Laurent Pinchart , Varun Sethi , David Woodhouse , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: iommu@lists.linux-foundation.org On Thu, Dec 4, 2014 at 11:19 AM, Arnd Bergmann wrote: > On Thursday 04 December 2014 10:21:27 Will Deacon wrote: >> On Thu, Dec 04, 2014 at 10:10:17AM +0000, Arnd Bergmann wrote: >> > On Thursday 04 December 2014 09:49:53 Will Deacon wrote: >> > > On Wed, Dec 03, 2014 at 07:57:50PM +0000, Arnd Bergmann wrote: >> > > > On Tuesday 02 December 2014 14:16:57 Grant Likely wrote: >> > > > > On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring wrote: >> > > > > > On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon wrote: >> > > > > >> >> > > > > >> +static inline void of_iommu_set_ops(struct device_node *np, >> > > > > >> + const struct iommu_ops *ops) >> > > > > >> +{ >> > > > > >> + np->data = (struct iommu_ops *)ops; >> > > > > >> +} >> > > > > >> + >> > > > > >> +static inline struct iommu_ops *of_iommu_get_ops(struct device_node *np) >> > > > > >> +{ >> > > > > >> + return np->data; >> > > > > >> +} >> > > > > > >> > > > > > This may collide with other users. While use of it is rare, PPC uses >> > > > > > it in its PCI code. The OF_DYNAMIC code frees it but never actually >> > > > > > sets it. There may be some coming usage with the DT overlay code or >> > > > > > that's just a bug. Pantelis or Grant can comment. If not, I think we >> > > > > > really should try to get rid of this pointer rather than expand it's >> > > > > > usage. >> > > > > > >> > > > > > I didn't see a user of this. I'm guessing that is coming in a SMMU patch? >> > > > > >> > > > > Good catch. This is not good. The data pointer should be avoided since >> > > > > there are no controls over its use. Until a better solution can be >> > > > > implemented, probably the safest thing to do is add a struct iommu_ops >> > > > > pointer to struct device_node. However, assuming that only a small >> > > > > portion of nodes will actually have iommu_ops set, I'd rather see a >> > > > > separate registry that matches device_nodes to iommu_ops. >> > > > >> > > > Fair enough. Will, can you take a copy of drivers/dma/of-dma.c and >> > > > adapt it as needed? It should be exactly what we need to start >> > > > out and can be extended and generalized later. >> > > >> > > Sure, I'll add this to my list of stuff to do for 3.20. >> > >> > Does that mean the we don't get any of the patches for 3.19 despite the >> > Acks? >> >> Hmm, I don't know how useful they are without the get/set ops and I don't >> think I can get those ready for 3.19 given where we currently are. >> >> Grant's suggestion of adding an iommu_ops pointer to device_node would work >> as a temporary hack, but anything more advanced is going to need proper >> review. > > Right. I guess it doesn't hurt much if we put the new pointer inside > #ifdef CONFIG_OF_IOMMU, then at least there is no significant size > increase in most DT based platforms. Yes, I can live with that hack on the proviso that it will be removed by v3.20 Oh, and please put an ugly /* */ comment block in the #ifdef CONFIG_OF_IOMMU section that makes it really clear that it is an ugly hack and will be removed in the next release. I don't want anyone getting ideas that adding pointers to struct device_node is a good idea. g. From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@linaro.org (Grant Likely) Date: Thu, 4 Dec 2014 11:25:35 +0000 Subject: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers In-Reply-To: <5643715.BADzWxcqOQ@wuerfel> References: <1417453034-21379-1-git-send-email-will.deacon@arm.com> <3152553.esaQuZiCgi@wuerfel> <20141204102127.GF13224@arm.com> <5643715.BADzWxcqOQ@wuerfel> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Dec 4, 2014 at 11:19 AM, Arnd Bergmann wrote: > On Thursday 04 December 2014 10:21:27 Will Deacon wrote: >> On Thu, Dec 04, 2014 at 10:10:17AM +0000, Arnd Bergmann wrote: >> > On Thursday 04 December 2014 09:49:53 Will Deacon wrote: >> > > On Wed, Dec 03, 2014 at 07:57:50PM +0000, Arnd Bergmann wrote: >> > > > On Tuesday 02 December 2014 14:16:57 Grant Likely wrote: >> > > > > On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring wrote: >> > > > > > On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon wrote: >> > > > > >> >> > > > > >> +static inline void of_iommu_set_ops(struct device_node *np, >> > > > > >> + const struct iommu_ops *ops) >> > > > > >> +{ >> > > > > >> + np->data = (struct iommu_ops *)ops; >> > > > > >> +} >> > > > > >> + >> > > > > >> +static inline struct iommu_ops *of_iommu_get_ops(struct device_node *np) >> > > > > >> +{ >> > > > > >> + return np->data; >> > > > > >> +} >> > > > > > >> > > > > > This may collide with other users. While use of it is rare, PPC uses >> > > > > > it in its PCI code. The OF_DYNAMIC code frees it but never actually >> > > > > > sets it. There may be some coming usage with the DT overlay code or >> > > > > > that's just a bug. Pantelis or Grant can comment. If not, I think we >> > > > > > really should try to get rid of this pointer rather than expand it's >> > > > > > usage. >> > > > > > >> > > > > > I didn't see a user of this. I'm guessing that is coming in a SMMU patch? >> > > > > >> > > > > Good catch. This is not good. The data pointer should be avoided since >> > > > > there are no controls over its use. Until a better solution can be >> > > > > implemented, probably the safest thing to do is add a struct iommu_ops >> > > > > pointer to struct device_node. However, assuming that only a small >> > > > > portion of nodes will actually have iommu_ops set, I'd rather see a >> > > > > separate registry that matches device_nodes to iommu_ops. >> > > > >> > > > Fair enough. Will, can you take a copy of drivers/dma/of-dma.c and >> > > > adapt it as needed? It should be exactly what we need to start >> > > > out and can be extended and generalized later. >> > > >> > > Sure, I'll add this to my list of stuff to do for 3.20. >> > >> > Does that mean the we don't get any of the patches for 3.19 despite the >> > Acks? >> >> Hmm, I don't know how useful they are without the get/set ops and I don't >> think I can get those ready for 3.19 given where we currently are. >> >> Grant's suggestion of adding an iommu_ops pointer to device_node would work >> as a temporary hack, but anything more advanced is going to need proper >> review. > > Right. I guess it doesn't hurt much if we put the new pointer inside > #ifdef CONFIG_OF_IOMMU, then at least there is no significant size > increase in most DT based platforms. Yes, I can live with that hack on the proviso that it will be removed by v3.20 Oh, and please put an ugly /* */ comment block in the #ifdef CONFIG_OF_IOMMU section that makes it really clear that it is an ugly hack and will be removed in the next release. I don't want anyone getting ideas that adding pointers to struct device_node is a good idea. g.