On Thu, Dec 04, 2014 at 07:42:28PM +, Robin Murphy wrote:
On 04/12/14 17:58, Grant Likely wrote:
[...]
+struct of_iommu_node {
+ struct list_head list;
+ struct device_node *np;
+ struct iommu_ops *ops;
Why can't this be const? Why would anyone ever need to
On Friday 05 December 2014 12:10:37 Will Deacon wrote:
On Thu, Dec 04, 2014 at 07:42:28PM +, Robin Murphy wrote:
On 04/12/14 17:58, Grant Likely wrote:
[...]
+struct of_iommu_node {
+ struct list_head list;
+ struct device_node *np;
+ struct iommu_ops *ops;
Hi Will,
On 05/12/14 12:10, Will Deacon wrote:
[...]
Do you expect drivers to modify that *priv pointer after the ops
structure is registered? I'd be very surprised if that was the use
case. It's fine for the driver to register a non-const version, but
once it is registered, the infrastructure
On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Will,
On 05/12/14 12:10, Will Deacon wrote:
[...]
Do you expect drivers to modify that *priv pointer after the ops
structure is registered? I'd be very surprised if that was the use
case. It's fine for the driver
On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote:
On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Will,
On 05/12/14 12:10, Will Deacon wrote:
[...]
Do you expect drivers to modify that *priv pointer after the ops
structure is registered? I'd
On Fri, Dec 5, 2014 at 1:18 PM, Thierry Reding thierry.red...@gmail.com wrote:
On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote:
On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Will,
On 05/12/14 12:10, Will Deacon wrote:
[...]
Do you expect
On Fri, Dec 05, 2014 at 01:21:31PM +, Grant Likely wrote:
On Fri, Dec 5, 2014 at 1:18 PM, Thierry Reding thierry.red...@gmail.com
wrote:
On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote:
On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Will,
Hello,
On 2014-12-05 14:18, Thierry Reding wrote:
On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote:
On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Will,
On 05/12/14 12:10, Will Deacon wrote:
[...]
Do you expect drivers to modify that *priv pointer
On Wed, Dec 03, 2014 at 07:57:50PM +, 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 robherri...@gmail.com wrote:
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
+static inline void
On Thursday 04 December 2014 09:49:53 Will Deacon wrote:
On Wed, Dec 03, 2014 at 07:57:50PM +, 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 robherri...@gmail.com
wrote:
On Mon, Dec 1, 2014 at 10:57 AM,
On Thu, Dec 04, 2014 at 10:10:17AM +, Arnd Bergmann wrote:
On Thursday 04 December 2014 09:49:53 Will Deacon wrote:
On Wed, Dec 03, 2014 at 07:57:50PM +, 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
On Thursday 04 December 2014 10:21:27 Will Deacon wrote:
On Thu, Dec 04, 2014 at 10:10:17AM +, Arnd Bergmann wrote:
On Thursday 04 December 2014 09:49:53 Will Deacon wrote:
On Wed, Dec 03, 2014 at 07:57:50PM +, Arnd Bergmann wrote:
On Tuesday 02 December 2014 14:16:57 Grant
On Thu, Dec 4, 2014 at 11:19 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 04 December 2014 10:21:27 Will Deacon wrote:
On Thu, Dec 04, 2014 at 10:10:17AM +, Arnd Bergmann wrote:
On Thursday 04 December 2014 09:49:53 Will Deacon wrote:
On Wed, Dec 03, 2014 at 07:57:50PM +, Arnd
On Thu, Dec 04, 2014 at 11:25:35AM +, Grant Likely wrote:
On Thu, Dec 4, 2014 at 11:19 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 04 December 2014 10:21:27 Will Deacon wrote:
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
Hi Arnd,
On 03/12/14 19:57, Arnd Bergmann wrote:
[...]
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.
On Thu, Dec 4, 2014 at 12:26 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Arnd,
On 03/12/14 19:57, Arnd Bergmann wrote:
[...]
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
On Thu, Dec 4, 2014 at 11:52 AM, Will Deacon will.dea...@arm.com wrote:
On Thu, Dec 04, 2014 at 11:25:35AM +, Grant Likely wrote:
On Thu, Dec 4, 2014 at 11:19 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 04 December 2014 10:21:27 Will Deacon wrote:
Sure, I'll add this to my list
On Thursday 04 December 2014 12:26:58 Robin Murphy wrote:
+struct of_iommu_node {
+ struct hlist_node list;
+ struct device_node *np;
+ const struct iommu_ops *ops;
+};
+static HLIST_HEAD(of_iommu_list);
+static DEFINE_SPINLOCK(of_iommu_lock);
Looks good to me. For
Hi Grant, thanks for the advice - silly micro-optimisations removed, and
I'll make a note to do so from my in-development code, too ;)
I didn't much like the casting either, so rather than push it elsewhere
or out to the caller I've just changed the prototype to obviate it
completely. Since
On Thu, Dec 4, 2014 at 1:43 PM, Robin Murphy robin.mur...@arm.com wrote:
Hi Grant, thanks for the advice - silly micro-optimisations removed, and
I'll make a note to do so from my in-development code, too ;)
I didn't much like the casting either, so rather than push it elsewhere or
out to the
Hi Grant,
On 04/12/14 17:58, Grant Likely wrote:
[...]
+struct of_iommu_node {
+ struct list_head list;
+ struct device_node *np;
+ struct iommu_ops *ops;
Why can't this be const? Why would anyone ever need to modify it? Also
drivers do define their iommu_ops structures
On Tuesday 02 December 2014 14:16:57 Grant Likely wrote:
On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring robherri...@gmail.com wrote:
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
+static inline void of_iommu_set_ops(struct device_node *np,
+
Hello,
On 2014-12-02 00:54, Rob Herring wrote:
Adding Grant and Pantelis...
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't be configured for the bus in
On Tuesday 02 December 2014 10:23:00 Marek Szyprowski 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
On Tue, Dec 02, 2014 at 09:36:59AM +, Arnd Bergmann wrote:
On Tuesday 02 December 2014 10:23:00 Marek Szyprowski wrote:
+static inline void of_iommu_set_ops(struct device_node *np,
+ const struct iommu_ops *ops)
+{
+ np-data = (struct
On Tue, Dec 02, 2014 at 10:36:59AM +0100, Arnd Bergmann wrote:
On Tuesday 02 December 2014 10:23:00 Marek Szyprowski wrote:
+static inline void of_iommu_set_ops(struct device_node *np,
+ const struct iommu_ops *ops)
+{
+ np-data = (struct
On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring robherri...@gmail.com wrote:
Adding Grant and Pantelis...
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't be
Hi Rob,
On Dec 2, 2014, at 01:54 , Rob Herring robherri...@gmail.com wrote:
Adding Grant and Pantelis...
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't be configured for the bus in
question. To solve this, a number of IOMMU drivers use initcalls to
initialise the driver before anything has a chance to be probed.
Whilst this solves the
Adding Grant and Pantelis...
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't be configured for the bus in
question. To solve this, a number of IOMMU drivers
30 matches
Mail list logo
