From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer Date: Wed, 30 Oct 2013 15:58:58 -0600 Message-ID: <52718122.9000206@wwwdotorg.org> References: <20131024.122115.1035609747068925560.hdoyu@nvidia.com> <20131025001038.77299C403B6@trevor.secretlab.ca> <20131025075652.GB19622@ulmo.nvidia.com> <20131025.112549.2040849946958069337.hdoyu@nvidia.com> <20131025091104.GG19622@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131025091104.GG19622-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 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: Thierry Reding , Hiroshi Doyu Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Stephen Warren , "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" List-Id: devicetree@vger.kernel.org On 10/25/2013 03:11 AM, Thierry Reding wrote: ... > So my proposed solution for the IOMMU case is to treat it the same > as any other resources. Perhaps resource isn't the right word, but > at the core the issue is the same. A device requires the services > of an IOMMU so that it can be put into the correct address space. > If the IOMMU is not available yet it cannot do that, so we simply > return -EPROBE_DEFER and cause the probe to be retried later. Personally, I view deferred probe as being used when one device requires either a resource /or/ a service provided by another, not /just/ when there's a resource dependency. Hence, I think it fits perfectly here. So I agree with Thierry: In other words, I think the solution is for all devices that are affected by an IOMMU to have a property such as: iommu = <&iommu_phandle iommu_specifier>; (and the DT node for the IOMMU will contain e.g. an #iommu-cells property) ... and for the driver to explicitly parse that property, and wait until the driver for iommu_phandle is ready. Exactly the same as any other resource/service dependency. That will solve all the problems. The only downside is that every driver needs to contain code to parse that property. However, I think that's just one function call; the actual implementation of that function can be unified somewhere inside core code in drivers/iommu/.