On Tue, Nov 29, 2016 at 05:05:49PM +0100, Joerg Roedel wrote:
> On Wed, Nov 16, 2016 at 09:56:15AM +, Lorenzo Pieralisi wrote:
> > I can easily make the changes Robin suggests above, I need to know
> > what to do with this patch it is the last blocking point for this
> > series and time is
On Tue, Nov 29, 2016 at 05:05:49PM +0100, Joerg Roedel wrote:
> On Wed, Nov 16, 2016 at 09:56:15AM +, Lorenzo Pieralisi wrote:
> > I can easily make the changes Robin suggests above, I need to know
> > what to do with this patch it is the last blocking point for this
> > series and time is
On Wed, Nov 16, 2016 at 09:56:15AM +, Lorenzo Pieralisi wrote:
> I can easily make the changes Robin suggests above, I need to know
> what to do with this patch it is the last blocking point for this
> series and time is running out I can revert to using dev->bus to
> retrieve iommu_ops (even
On Wed, Nov 16, 2016 at 09:56:15AM +, Lorenzo Pieralisi wrote:
> I can easily make the changes Robin suggests above, I need to know
> what to do with this patch it is the last blocking point for this
> series and time is running out I can revert to using dev->bus to
> retrieve iommu_ops (even
Hi Joerg,
On Mon, Nov 14, 2016 at 06:25:16PM +, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to
Hi Joerg,
On Mon, Nov 14, 2016 at 06:25:16PM +, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to
On Mon, Nov 14, 2016 at 06:25:16PM +, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to deliberately introduce
On Mon, Nov 14, 2016 at 06:25:16PM +, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to deliberately introduce
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch
On Mon, Nov 14, 2016 at 04:52:23PM +0100, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> > If we've already made the decision to move away from bus ops, I don't
> > see that it makes sense to deliberately introduce new dependencies on
> > them. Besides, as it
On Mon, Nov 14, 2016 at 04:52:23PM +0100, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> > If we've already made the decision to move away from bus ops, I don't
> > see that it makes sense to deliberately introduce new dependencies on
> > them. Besides, as it
On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which
On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which
On 14/11/16 10:26, Lorenzo Pieralisi wrote:
> Hi Robin, Joerg,
>
> On Fri, Nov 11, 2016 at 05:43:39PM +, Robin Murphy wrote:
>> On 11/11/16 16:27, Joerg Roedel wrote:
>>> On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
In the original of_iommu_configure design, the thought
On 14/11/16 10:26, Lorenzo Pieralisi wrote:
> Hi Robin, Joerg,
>
> On Fri, Nov 11, 2016 at 05:43:39PM +, Robin Murphy wrote:
>> On 11/11/16 16:27, Joerg Roedel wrote:
>>> On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
In the original of_iommu_configure design, the thought
Hi Robin, Joerg,
On Fri, Nov 11, 2016 at 05:43:39PM +, Robin Murphy wrote:
> On 11/11/16 16:27, Joerg Roedel wrote:
> > On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
> >> In the original of_iommu_configure design, the thought was that an ops
> >> structure could be
Hi Robin, Joerg,
On Fri, Nov 11, 2016 at 05:43:39PM +, Robin Murphy wrote:
> On 11/11/16 16:27, Joerg Roedel wrote:
> > On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
> >> In the original of_iommu_configure design, the thought was that an ops
> >> structure could be
On 11/11/16 16:27, Joerg Roedel wrote:
> On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
>> In the original of_iommu_configure design, the thought was that an ops
>> structure could be IOMMU-instance-specific (hence the later-removed
>> "priv" member), so I suppose right now it is
On 11/11/16 16:27, Joerg Roedel wrote:
> On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
>> In the original of_iommu_configure design, the thought was that an ops
>> structure could be IOMMU-instance-specific (hence the later-removed
>> "priv" member), so I suppose right now it is
On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
> In the original of_iommu_configure design, the thought was that an ops
> structure could be IOMMU-instance-specific (hence the later-removed
> "priv" member), so I suppose right now it is mostly a hangover from
> that. However, it's
On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
> In the original of_iommu_configure design, the thought was that an ops
> structure could be IOMMU-instance-specific (hence the later-removed
> "priv" member), so I suppose right now it is mostly a hangover from
> that. However, it's
On 11/11/16 15:22, Joerg Roedel wrote:
> On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote:
>> +struct iommu_fwentry {
>> +struct list_head list;
>> +struct fwnode_handle *fwnode;
>> +const struct iommu_ops *ops;
>> +};
>
> Is there a reason the iommu_ops need to be
On 11/11/16 15:22, Joerg Roedel wrote:
> On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote:
>> +struct iommu_fwentry {
>> +struct list_head list;
>> +struct fwnode_handle *fwnode;
>> +const struct iommu_ops *ops;
>> +};
>
> Is there a reason the iommu_ops need to be
On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote:
> +struct iommu_fwentry {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
Is there a reason the iommu_ops need to be stored there? Currently it
seems that the ops are
On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote:
> +struct iommu_fwentry {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
Is there a reason the iommu_ops need to be stored there? Currently it
seems that the ops are
On Wed, Nov 09, 2016 at 02:40:08PM +, Robin Murphy wrote:
[...]
> > +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > +
> > + if
On Wed, Nov 09, 2016 at 02:40:08PM +, Robin Murphy wrote:
[...]
> > +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > +
> > + if
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a device tree node,
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a device tree node,
The of_iommu_{set/get}_ops() API is used to associate a device
tree node with a specific set of IOMMU operations. The same
kernel interface is required on systems booting with ACPI, where
devices are not associated with a device tree node, therefore
the interface requires generalization.
The
The of_iommu_{set/get}_ops() API is used to associate a device
tree node with a specific set of IOMMU operations. The same
kernel interface is required on systems booting with ACPI, where
devices are not associated with a device tree node, therefore
the interface requires generalization.
The
32 matches
Mail list logo
