[PATCH 0/6 v2] IOMMU: Make IOMMU-API ready for GART-like hardware

[PATCH 0/6 v2] IOMMU: Make IOMMU-API ready for GART-like hardware

[Joerg Roedel]

Hi,

here is the second version of this patch-set. For a full description
please see the first post:

	https://lkml.org/lkml/2012/1/19/170

Changes from v1->v2:

	* Changed u64 to dma_addr_t as suggested by Laurent Pinchart
	* Moved description of new iommu_ops members to first patch
	* Added the necessary changes for the Tegra IOMMUs as posted by
	  Hiroshi Doyu

As always, any feedback is appreciated :-)

Thanks,

	Joerg

Diffstat:

 drivers/iommu/amd_iommu.c   |    4 ++++
 drivers/iommu/intel-iommu.c |    4 ++++
 drivers/iommu/iommu.c       |   33 +++++++++++++++++++++++++++++++++
 drivers/iommu/msm_iommu.c   |    5 +++++
 drivers/iommu/omap-iommu.c  |    4 ++++
 drivers/iommu/tegra-gart.c  |    5 +++++
 drivers/iommu/tegra-smmu.c  |    5 +++++
 include/linux/iommu.h       |   36 +++++++++++++++++++++++++++++++++++-
 8 files changed, 95 insertions(+), 1 deletions(-)

[PATCH 1/6] iommu: Add domain-attribute handlers

[Joerg Roedel]

This patch introduces an extension to the iommu-api to get
and set attributes for an iommu_domain. Two functions are
introduced for this:

	* iommu_domain_get_attr()
	* iommu_domain_set_attr()

These functions will be used to make the iommu-api suitable
for GART-like IOMMUs and to implement hardware-specifc
api-extensions.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
 drivers/iommu/iommu.c |   20 ++++++++++++++++++++
 include/linux/iommu.h |   28 +++++++++++++++++++++++++++-
 2 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2198b2d..ef54718 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -341,3 +341,23 @@ int iommu_device_group(struct device *dev, unsigned int *groupid)
 	return -ENODEV;
 }
 EXPORT_SYMBOL_GPL(iommu_device_group);
+
+int iommu_domain_get_attr(struct iommu_domain *domain,
+			  enum iommu_attr attr, void *data)
+{
+	if (!domain->ops->domain_get_attr)
+		return -EINVAL;
+
+	return domain->ops->domain_get_attr(domain, attr, data);
+}
+EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
+
+int iommu_domain_set_attr(struct iommu_domain *domain,
+			  enum iommu_attr attr, void *data)
+{
+	if (!domain->ops->domain_set_attr)
+		return -EINVAL;
+
+	return domain->ops->domain_set_attr(domain, attr, data);
+}
+EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index d937580..8b66e84 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -46,6 +46,10 @@ struct iommu_domain {
 #define IOMMU_CAP_CACHE_COHERENCY	0x1
 #define IOMMU_CAP_INTR_REMAP		0x2	/* isolates device intrs */
 
+enum iommu_attr {
+	DOMAIN_ATTR_MAX,
+};
+
 #ifdef CONFIG_IOMMU_API
 
 /**
@@ -58,7 +62,8 @@ struct iommu_domain {
  * @unmap: unmap a physically contiguous memory region from an iommu domain
  * @iova_to_phys: translate iova to physical address
  * @domain_has_cap: domain capabilities query
- * @commit: commit iommu domain
+ * @domain_get_attr: Query domain attributes
+ * @domain_set_attr: Change domain attributes
  * @pgsize_bitmap: bitmap of supported page sizes
  */
 struct iommu_ops {
@@ -75,6 +80,10 @@ struct iommu_ops {
 	int (*domain_has_cap)(struct iommu_domain *domain,
 			      unsigned long cap);
 	int (*device_group)(struct device *dev, unsigned int *groupid);
+	int (*domain_get_attr)(struct iommu_domain *domain,
+			       enum iommu_attr attr, void *data);
+	int (*domain_set_attr)(struct iommu_domain *domain,
+			       enum iommu_attr attr, void *data);
 	unsigned long pgsize_bitmap;
 };
 
@@ -98,6 +107,11 @@ extern void iommu_set_fault_handler(struct iommu_domain *domain,
 					iommu_fault_handler_t handler);
 extern int iommu_device_group(struct device *dev, unsigned int *groupid);
 
+extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
+				 void *data);
+extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
+				 void *data);
+
 /**
  * report_iommu_fault() - report about an IOMMU fault to the IOMMU framework
  * @domain: the iommu domain where the fault has happened
@@ -200,6 +214,18 @@ static inline int iommu_device_group(struct device *dev, unsigned int *groupid)
 	return -ENODEV;
 }
 
+static inline int iommu_domain_get_attr(struct iommu_domain *domain,
+					enum iommu_attr attr, void *data)
+{
+	return -EINVAL;
+}
+
+static inline int iommu_domain_set_attr(struct iommu_domain *domain,
+					enum iommu_attr attr, void *data)
+{
+	return -EINVAL;
+}
+
 #endif /* CONFIG_IOMMU_API */
 
 #endif /* __LINUX_IOMMU_H */
-- 
1.7.5.4

[PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

Implement the attribute itself and add the code for the
AMD IOMMU driver.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
 drivers/iommu/amd_iommu.c |    4 ++++
 drivers/iommu/iommu.c     |   19 ++++++++++++++++---
 include/linux/iommu.h     |    8 ++++++++
 3 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f75e060..aa90be3 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3033,6 +3033,10 @@ static int amd_iommu_domain_init(struct iommu_domain *dom)
 
 	dom->priv = domain;
 
+	dom->geometry.aperture_start = 0;
+	dom->geometry.aperture_end   = ~0ULL;
+	dom->geometry.force_aperture = true;
+
 	return 0;
 
 out_free:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ef54718..3d0b0bf 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -345,10 +345,23 @@ EXPORT_SYMBOL_GPL(iommu_device_group);
 int iommu_domain_get_attr(struct iommu_domain *domain,
 			  enum iommu_attr attr, void *data)
 {
-	if (!domain->ops->domain_get_attr)
-		return -EINVAL;
+	struct iommu_domain_geometry *geometry;
+	int ret = 0;
+
+	switch (attr) {
+	case DOMAIN_ATTR_GEOMETRY:
+		geometry  = data;
+		*geometry = domain->geometry;
+
+		break;
+	default:
+		if (!domain->ops->domain_get_attr)
+			return -EINVAL;
 
-	return domain->ops->domain_get_attr(domain, attr, data);
+		ret = domain->ops->domain_get_attr(domain, attr, data);
+	}
+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
 
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 8b66e84..ba77bf9 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -37,16 +37,24 @@ struct iommu_domain;
 typedef int (*iommu_fault_handler_t)(struct iommu_domain *,
 				struct device *, unsigned long, int);
 
+struct iommu_domain_geometry {
+	dma_addr_t aperture_start; /* First address that can be mapped    */
+	dma_addr_t aperture_end;   /* Last address that can be mapped     */
+	bool force_aperture;	   /* DMA only allowed in mappable range? */
+};
+
 struct iommu_domain {
 	struct iommu_ops *ops;
 	void *priv;
 	iommu_fault_handler_t handler;
+	struct iommu_domain_geometry geometry;
 };
 
 #define IOMMU_CAP_CACHE_COHERENCY	0x1
 #define IOMMU_CAP_INTR_REMAP		0x2	/* isolates device intrs */
 
 enum iommu_attr {
+	DOMAIN_ATTR_GEOMETRY,	/* struct iommu_domain_geometry */
 	DOMAIN_ATTR_MAX,
 };
 
-- 
1.7.5.4

[PATCH 3/6] iommu/vt-d: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

Implement the attribute for the Intel IOMMU driver.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
 drivers/iommu/intel-iommu.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c9c6053..12e7dc1 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3917,6 +3917,10 @@ static int intel_iommu_domain_init(struct iommu_domain *domain)
 	domain_update_iommu_cap(dmar_domain);
 	domain->priv = dmar_domain;
 
+	domain->geometry.aperture_start = 0;
+	domain->geometry.aperture_end   = __DOMAIN_MAX_ADDR(dmar_domain->gaw);
+	domain->geometry.force_aperture = true;
+
 	return 0;
 }
 
-- 
1.7.5.4

[PATCH 4/6] iommu/omap: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

Implement the attribute for the OMAP IOMMU driver.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
 drivers/iommu/omap-iommu.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d8edd97..40ad992 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1140,6 +1140,10 @@ static int omap_iommu_domain_init(struct iommu_domain *domain)
 
 	domain->priv = omap_domain;
 
+	domain->geometry.aperture_start = 0;
+	domain->geometry.aperture_end   = (1ULL << 32) - 1;
+	domain->geometry.force_aperture = true;
+
 	return 0;
 
 fail_nomem:
-- 
1.7.5.4

[PATCH 5/6] iommu/msm: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

Implement the attribute for the MSM IOMMU driver.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
 drivers/iommu/msm_iommu.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 08a90b8..ea6b7f7 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -226,6 +226,11 @@ static int msm_iommu_domain_init(struct iommu_domain *domain)
 
 	memset(priv->pgtable, 0, SZ_16K);
 	domain->priv = priv;
+
+	domain->geometry.aperture_start = 0;
+	domain->geometry.aperture_end   = (1ULL << 32) - 1;
+	domain->geometry.force_aperture = true;
+
 	return 0;
 
 fail_nomem:
-- 
1.7.5.4

[PATCH 6/6] iommu/tegra: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

From: Hiroshi DOYU <hdoyu@nvidia.com>

Implement the attribute for the Tegra IOMMU drivers.

Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
 drivers/iommu/tegra-gart.c |    5 +++++
 drivers/iommu/tegra-smmu.c |    5 +++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index b21598f..b60ee49 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -163,6 +163,11 @@ static int gart_iommu_attach_dev(struct iommu_domain *domain,
 		return -EINVAL;
 	domain->priv = gart;
 
+	domain->geometry.aperture_start = gart->iovmm_base;
+	domain->geometry.aperture_end   = gart->iovmm_base +
+					gart->page_count * GART_PAGE_SIZE - 1;
+	domain->geometry.force_aperture = true;
+
 	client = devm_kzalloc(gart->dev, sizeof(*c), GFP_KERNEL);
 	if (!client)
 		return -ENOMEM;
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index eb93c82..9614702 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -807,6 +807,11 @@ found:
 	spin_unlock_irqrestore(&as->lock, flags);
 	domain->priv = as;
 
+	domain->geometry.aperture_start = smmu->iovmm_base;
+	domain->geometry.aperture_end   = smmu->iovmm_base +
+		smmu->page_count * SMMU_PAGE_SIZE - 1;
+	domain->geometry.force_aperture = true;
+
 	dev_dbg(smmu->dev, "smmu_as@%p\n", as);
 	return 0;
 
-- 
1.7.5.4

Re: [PATCH 5/6] iommu/msm: Implement DOMAIN_ATTR_GEOMETRY attribute

[David Brown]

On Thu, Jan 26, 2012 at 07:40:56PM +0100, Joerg Roedel wrote:
> Implement the attribute for the MSM IOMMU driver.
> 
> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
> ---
>  drivers/iommu/msm_iommu.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)

Acked-by: David Brown <davidb@codeaurora.org>

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Ohad Ben-Cohen]

Hi Joerg,

On Thu, Jan 26, 2012 at 8:40 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> Implement the attribute itself and add the code for the
> AMD IOMMU driver.

It's somewhat non-intuitive to have the generic attribute code bundled
with the AMD implementation in the same patch (took me some time to
find it here :).

Maybe split this to two patches ?

> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index ef54718..3d0b0bf 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -345,10 +345,23 @@ EXPORT_SYMBOL_GPL(iommu_device_group);
>  int iommu_domain_get_attr(struct iommu_domain *domain,
>                          enum iommu_attr attr, void *data)
>  {
> -       if (!domain->ops->domain_get_attr)
> -               return -EINVAL;
> +       struct iommu_domain_geometry *geometry;
> +       int ret = 0;
> +
> +       switch (attr) {
> +       case DOMAIN_ATTR_GEOMETRY:
> +               geometry  = data;
> +               *geometry = domain->geometry;

This is not type-safe and will surely bite someone some day.

Sure, we can't have type safety in a multi-purpose generic interface,
but I wonder whether this is the right interface for getting the
geometry ? I.e. why not have a dedicated API for this ?

Thanks,
Ohad.

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

Hi Ohad,

On Fri, Jan 27, 2012 at 09:08:44AM +0200, Ohad Ben-Cohen wrote:
> On Thu, Jan 26, 2012 at 8:40 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> > Implement the attribute itself and add the code for the
> > AMD IOMMU driver.
> 
> It's somewhat non-intuitive to have the generic attribute code bundled
> with the AMD implementation in the same patch (took me some time to
> find it here :).
> 
> Maybe split this to two patches ?

Yes, that is not ideal. I'll probably split it or move the generic part
to the first patch.

> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index ef54718..3d0b0bf 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -345,10 +345,23 @@ EXPORT_SYMBOL_GPL(iommu_device_group);
> >  int iommu_domain_get_attr(struct iommu_domain *domain,
> >                          enum iommu_attr attr, void *data)
> >  {
> > -       if (!domain->ops->domain_get_attr)
> > -               return -EINVAL;
> > +       struct iommu_domain_geometry *geometry;
> > +       int ret = 0;
> > +
> > +       switch (attr) {
> > +       case DOMAIN_ATTR_GEOMETRY:
> > +               geometry  = data;
> > +               *geometry = domain->geometry;
> 
> This is not type-safe and will surely bite someone some day.
> 
> Sure, we can't have type safety in a multi-purpose generic interface,
> but I wonder whether this is the right interface for getting the
> geometry ? I.e. why not have a dedicated API for this ?

I fell also uncomfortable with the missing type-safety of this
interface. But the alternative is to have dedicated functions for
set/get each attribute. Well, it depends on how many attributes we have
in the end, but given that the PAMU guys already have need for a number
of hardware specific attributes it is likely that having individual
functions makes the api too complex in the end.

But probably we can replace the 'void *data' with a 'union
domain_attr'? This will give us some type-safety.


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Ohad Ben-Cohen]

On Fri, Jan 27, 2012 at 12:26 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> I fell also uncomfortable with the missing type-safety of this
> interface. But the alternative is to have dedicated functions for
> set/get each attribute. Well, it depends on how many attributes we have
> in the end, but given that the PAMU guys already have need for a number
> of hardware specific attributes it is likely that having individual
> functions makes the api too complex in the end.
>
> But probably we can replace the 'void *data' with a 'union
> domain_attr'? This will give us some type-safety.
>

I was thinking that since the geometry concept is actually handled by
the core itself, it could probably have its own dedicated function.

Not sure how many other functions like that we might end up having
eventually, but I personally prefer the dedicated API over a single
multiplexer which is prone to error and (somewhat) harder to
debug/read.

Real vendor-specific attributes do probably justifies an all-catch
attribute API, I agree. Though we should probably try to minimize
them, and where possible, implement them in the core too, for the
benefit of everyone.

Thanks,
Ohad.

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

On Fri, Jan 27, 2012 at 01:00:02PM +0200, Ohad Ben-Cohen wrote:
> On Fri, Jan 27, 2012 at 12:26 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> > But probably we can replace the 'void *data' with a 'union
> > domain_attr'? This will give us some type-safety.
> 
> I was thinking that since the geometry concept is actually handled by
> the core itself, it could probably have its own dedicated function.

Note that only the read-side is handled by the core. An IOMMU driver may
decide to implement a write-side for the geometry which would be not in
the core then. Having a dedicated function for the write-side does not
make sense because (for now) there is only one upcoming driver requiring
this. So we either end up with an asymetric interface for read and write
or with an api function implemented by only one driver.

I think dedicated functions also make the API harder to use because a
developer first needs to find out if a property is read/written by a
dedicated function or the set/get-attr interface.

The next attribute I have in mind btw. is the default-domain attribute
which can be used set by the core to tell the iommu driver that dma-api
specific optimizations can be applied to this domain.


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Ohad Ben-Cohen]

On Fri, Jan 27, 2012 at 3:03 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> Note that only the read-side is handled by the core. An IOMMU driver may
> decide to implement a write-side for the geometry which would be not in
> the core then. Having a dedicated function for the write-side does not
> make sense because (for now) there is only one upcoming driver requiring
> this.

I'd still go with a type-safe interface here, but maybe it's only me.

> I think dedicated functions also make the API harder to use because a
> developer first needs to find out if a property is read/written by a
> dedicated function or the set/get-attr interface.

I'm not so sure how would drivers use these "hardware-specific api
attr extensions" in general.

Is the intention that only hardware-specific drivers will use them ? I
guess that generic drivers won't be able to use them, because their
behavior will not be well-defined across all hardware implementations.

Thanks,
Ohad.

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Joerg Roedel]

On Sat, Jan 28, 2012 at 10:44:22PM +0200, Ohad Ben-Cohen wrote:
> On Fri, Jan 27, 2012 at 3:03 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> > Note that only the read-side is handled by the core. An IOMMU driver may
> > decide to implement a write-side for the geometry which would be not in
> > the core then. Having a dedicated function for the write-side does not
> > make sense because (for now) there is only one upcoming driver requiring
> > this.
> 
> I'd still go with a type-safe interface here, but maybe it's only me.

Well, the idea still stands to replace 'void *data' with something like
'union domain_attr *data'. This isn't as type-safe as dedicated
functions, but still better than void*.

> I'm not so sure how would drivers use these "hardware-specific api
> attr extensions" in general.

Depends on the attribute. For the geometry attribute drivers that
allocate a domain should read out the geometry and only use the range
returned for map/unmap (or fail initialization when the domain geometry
is unexpected).

> Is the intention that only hardware-specific drivers will use them ? I
> guess that generic drivers won't be able to use them, because their
> behavior will not be well-defined across all hardware implementations.

Hardware specific attributes are intended, but not limited to hardware
specific drivers. A generic driver that _may_ run on a given hardware
can use a hardware specific attribute too. If it doesn't run on this
hardware it will just get -EINVAL back.

Regards,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

[Ohad Ben-Cohen]

On Mon, Jan 30, 2012 at 4:49 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hardware specific attributes are intended, but not limited to hardware
> specific drivers. A generic driver that _may_ run on a given hardware
> can use a hardware specific attribute too. If it doesn't run on this
> hardware it will just get -EINVAL back.

That sounds good.

But I'm still not sure what's the advantage of the attribute API on
top of regular, type-safe, dedicated API for every attribute: it
doesn't sound like there's a vast number of attributes, only a
handful, and dedicated API just sound (to me) much more readable and
less prone to error.

But, again, maybe it's only me :)

Thanks,
Ohad.