date:20170420

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

2017-04-20 Thread Daniel Vetter

On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
> in highmem.h, the former can be aliased if any dma-buf user includes
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] https://www.spinics.net/lists/target-devel/msg15070.html
> 
> Signed-off-by: Logan Gunthorpe 
> Reviewed-by: Sinclair Yeh 

Acked-by: Daniel Vetter 

Probably simplest if we pull this in through the drm-misc tree for 4.12.
Can we have an ack for the v4l side for that pls?

Thanks, Daniel

> ---
> 
> Changes since v1:
> 
> - Added the missing tegra driver (noticed by kbuild robot)
> - Rebased off of drm-intel-next to get the i915 selftest that is new
> - Fixed nits Sinclair pointed out.
> 
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  8 
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  14 files changed, 61 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f72aaac..512bdbc 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
> 
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
> 
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
> 
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
> 
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
> 
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
> 
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
> 
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
> 
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
> - .kmap   = armada_gem_dmabuf_no_kmap,
> - .kunmap = armada_gem_dmabuf_no_kunmap,
> + .map_atomic = armada_gem_dmabuf_no_kmap,
> + .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
> + .map= armada_gem_dmabuf_no_kmap,
> + .unmap  = armada_

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

2017-04-20 Thread Sumit Semwal

Hi Logan,

Thanks for the patch.

On 20 April 2017 at 13:21, Daniel Vetter  wrote:
> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>> in highmem.h, the former can be aliased if any dma-buf user includes
>> that header.
>>
>> I'm personally trying to include highmem.h inside scatterlist.h and this
>> breaks the dma-buf code proper.
>>
>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
>>
>> To maintain consistency I've renamed all four of kmap* and kunmap* to be
>> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
>>
>> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>>
>> Signed-off-by: Logan Gunthorpe 
>> Reviewed-by: Sinclair Yeh 
>
> Acked-by: Daniel Vetter 
Acked-by: Sumit Semwal 
>
> Probably simplest if we pull this in through the drm-misc tree for 4.12.
> Can we have an ack for the v4l side for that pls?
>
> Thanks, Daniel
>
>> ---
>>
>> Changes since v1:
>>
>> - Added the missing tegra driver (noticed by kbuild robot)
>> - Rebased off of drm-intel-next to get the i915 selftest that is new
>> - Fixed nits Sinclair pointed out.
>>
>>  drivers/dma-buf/dma-buf.c  | 16 
>>  drivers/gpu/drm/armada/armada_gem.c|  8 
>>  drivers/gpu/drm/drm_prime.c|  8 
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>>  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>>  drivers/gpu/drm/tegra/gem.c|  8 
>>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>>  drivers/staging/android/ion/ion.c  |  8 
>>  include/linux/dma-buf.h| 22 +++---
>>  14 files changed, 61 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index f72aaac..512bdbc 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>> || !exp_info->ops->map_dma_buf
>> || !exp_info->ops->unmap_dma_buf
>> || !exp_info->ops->release
>> -   || !exp_info->ops->kmap_atomic
>> -   || !exp_info->ops->kmap
>> +   || !exp_info->ops->map_atomic
>> +   || !exp_info->ops->map
>> || !exp_info->ops->mmap)) {
>>   return ERR_PTR(-EINVAL);
>>   }
>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
>> unsigned long page_num)
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
>> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>
>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
>> unsigned long page_num,
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - if (dmabuf->ops->kunmap_atomic)
>> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
>> + if (dmabuf->ops->unmap_atomic)
>> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>>
>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
>> page_num)
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - return dmabuf->ops->kmap(dmabuf, page_num);
>> + return dmabuf->ops->map(dmabuf, page_num);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>>
>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned 
>> long page_num,
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - if (dmabuf->ops->kunmap)
>> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
>> + if (dmabuf->ops->unmap)
>> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>>
>> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
>> b/drivers/gpu/drm/armada/armada_gem.c
>> index 1597458..d6c2a5d 100644
>> --- a/drivers/gpu/drm/armada/armada_gem.c
>> +++ b/drivers/gpu/drm/armada/armada_gem.c
>> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
>> armada_gem_prime_dmabuf_ops = {
>>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>>   .release= drm_gem_dmabuf_release,
>> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
>> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
>> - .kmap   = armada_gem_dmabuf_no_kmap,
>> - .kunmap = armad

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

2017-04-20 Thread Sumit Semwal

Hi Marek,

Thanks!

On 20 April 2017 at 13:36, Marek Szyprowski  wrote:
> Hi All,
>
> On 2017-04-20 09:51, Daniel Vetter wrote:
>>
>> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>>>
>>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>>> in highmem.h, the former can be aliased if any dma-buf user includes
>>> that header.
>>>
>>> I'm personally trying to include highmem.h inside scatterlist.h and this
>>> breaks the dma-buf code proper.
>>>
>>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
>>>
>>> To maintain consistency I've renamed all four of kmap* and kunmap* to be
>>> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
>>>
>>> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>>>
>>> Signed-off-by: Logan Gunthorpe 
>>> Reviewed-by: Sinclair Yeh 
>>
>> Acked-by: Daniel Vetter 
>>
>> Probably simplest if we pull this in through the drm-misc tree for 4.12.
>> Can we have an ack for the v4l side for that pls?
>
>
> For the V4L2/videobuf2:
> Acked-by: Marek Szyprowski 
>
I will queue it up for drm-misc-fixes so it gets into 4.12.
>
>
>> Thanks, Daniel
Best,
Sumit.

>>>
>>> ---
>>>
>>> Changes since v1:
>>>
>>> - Added the missing tegra driver (noticed by kbuild robot)
>>> - Rebased off of drm-intel-next to get the i915 selftest that is new
>>> - Fixed nits Sinclair pointed out.
>>>
>>>   drivers/dma-buf/dma-buf.c  | 16 
>>>   drivers/gpu/drm/armada/armada_gem.c|  8 
>>>   drivers/gpu/drm/drm_prime.c|  8 
>>>   drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>>>   drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>>>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>>>   drivers/gpu/drm/tegra/gem.c|  8 
>>>   drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>>>   drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>>>   drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>>>   drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>>>   drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>>>   drivers/staging/android/ion/ion.c  |  8 
>>>   include/linux/dma-buf.h| 22
>>> +++---
>>>   14 files changed, 61 insertions(+), 61 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index f72aaac..512bdbc 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct
>>> dma_buf_export_info *exp_info)
>>>   || !exp_info->ops->map_dma_buf
>>>   || !exp_info->ops->unmap_dma_buf
>>>   || !exp_info->ops->release
>>> - || !exp_info->ops->kmap_atomic
>>> - || !exp_info->ops->kmap
>>> + || !exp_info->ops->map_atomic
>>> + || !exp_info->ops->map
>>>   || !exp_info->ops->mmap)) {
>>> return ERR_PTR(-EINVAL);
>>> }
>>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
>>> unsigned long page_num)
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
>>> +   return dmabuf->ops->map_atomic(dmabuf, page_num);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>>
>>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
>>> unsigned long page_num,
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   if (dmabuf->ops->kunmap_atomic)
>>> -   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
>>> +   if (dmabuf->ops->unmap_atomic)
>>> +   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>>>
>>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned
>>> long page_num)
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   return dmabuf->ops->kmap(dmabuf, page_num);
>>> +   return dmabuf->ops->map(dmabuf, page_num);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kmap);
>>>
>>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned
>>> long page_num,
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   if (dmabuf->ops->kunmap)
>>> -   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
>>> +   if (dmabuf->ops->unmap)
>>> +   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>>>
>>> diff --git a/drivers/gpu/drm/armada/armada_gem.c
>>> b/drivers/gpu/drm/armada/armada_gem.c
>>> index 1597458..d6c2a5d 100644
>>> --- a/drivers/gpu/drm/armada/armada_gem.c
>>> +++ b/drivers/gpu/drm/armada/armada_gem.c
>>> @@ -529,10 +529,10 @@ static const struct dma_buf_ops
>>> armada_gem_prime_dmabuf_ops = {
>>>

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

2017-04-20 Thread Marek Szyprowski


Hi All,

On 2017-04-20 09:51, Daniel Vetter wrote:

On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 

Acked-by: Daniel Vetter 

Probably simplest if we pull this in through the drm-misc tree for 4.12.
Can we have an ack for the v4l side for that pls?


For the V4L2/videobuf2:
Acked-by: Marek Szyprowski 



Thanks, Daniel

---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

  drivers/dma-buf/dma-buf.c  | 16 
  drivers/gpu/drm/armada/armada_gem.c|  8 
  drivers/gpu/drm/drm_prime.c|  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
  drivers/gpu/drm/tegra/gem.c|  8 
  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
  drivers/staging/android/ion/ion.c  |  8 
  include/linux/dma-buf.h| 22 +++---
  14 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f72aaac..512bdbc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  || !exp_info->ops->map_dma_buf
  || !exp_info->ops->unmap_dma_buf
  || !exp_info->ops->release
- || !exp_info->ops->kmap_atomic
- || !exp_info->ops->kmap
+ || !exp_info->ops->map_atomic
+ || !exp_info->ops->map
  || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num)
  {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
+   return dmabuf->ops->map_atomic(dmabuf, page_num);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);

@@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num,
  {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap_atomic)
-   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap_atomic)
+   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);

@@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
page_num)
  {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap(dmabuf, page_num);
+   return dmabuf->ops->map(dmabuf, page_num);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kmap);

@@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
  {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap)
-   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap)
+   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kunmap);

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 1597458..d6c2a5d 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -529,10 +529,10 @@ static const struct dma_buf_ops 
armada_gem_prime_dmabuf_ops = {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
-   .kmap_atomic= armada_gem_dmabuf_no_kmap,
-   .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
-   .kmap   = armada_gem_dmabuf_no_kmap,
-   .kunmap = armada_gem_dmabuf_no_kunmap,
+   .map_atomic = armada_gem_dmabuf_no_kmap,
+   .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
+   .map= armada_gem_dmabuf_no_kmap,
+   .unmap  = armada_gem_dmabuf_no_kunmap,

RE: [PATCH v2 8/9] staging: fsl-dpaa2/eth: Add TODO file

2017-04-20 Thread Ruxandra Ioana Radulescu

> -Original Message-
> From: Stuart Yoder [mailto:stuyo...@gmail.com]
> Sent: Wednesday, April 19, 2017 6:44 AM
> To: Ruxandra Ioana Radulescu 
> Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; Alexander Graf ; Arnd Bergmann
> ; linux-arm-ker...@lists.infradead.org; Alexandru
> Marginean ; Bogdan Hamciuc
> ; Laurentiu Tudor ;
> Roy Pledge ; Haiying Wang
> 
> Subject: Re: [PATCH v2 8/9] staging: fsl-dpaa2/eth: Add TODO file
> 
> On Wed, Apr 12, 2017 at 11:25 AM, Ioana Radulescu
>  wrote:
> > Add a list of TODO items for the Ethernet driver
> >
> > Signed-off-by: Ioana Radulescu 
> > ---
> > v2: Add note
> >
> >  drivers/staging/fsl-dpaa2/ethernet/TODO | 14 ++
> >  1 file changed, 14 insertions(+)
> >  create mode 100644 drivers/staging/fsl-dpaa2/ethernet/TODO
> >
> > diff --git a/drivers/staging/fsl-dpaa2/ethernet/TODO b/drivers/staging/fsl-
> dpaa2/ethernet/TODO
> > new file mode 100644
> > index ..110e66d44b42
> > --- /dev/null
> > +++ b/drivers/staging/fsl-dpaa2/ethernet/TODO
> > @@ -0,0 +1,14 @@
> > +* Add a DPAA2 MAC kernel driver in order to allow PHY management;
> currently
> > +  the DPMAC objects and their link to DPNIs are handled by MC internally
> > +  and all PHYs are seen as fixed-link
> > +* add more debug support: decide how to expose detailed debug
> statistics,
> > +  add ingress error queue support
> > +* MC firmware uprev; the DPAA2 objects used by the Ethernet driver
> need to
> > +  be kept in sync with binary interface changes in MC
> > +* refine README file
> > +* cleanup
> > +
> > +NOTE: None of the above is must-have before getting the DPAA2
> Ethernet driver
> > +out of staging. The main requirement for that is to have the drivers it
> > +depends on, fsl-mc bus and DPIO driver, moved to drivers/bus and
> drivers/soc
> > +respectively.
> 
> The TODO file should have contact info (I think)...look at other
> drivers/staging TODO
> for examples.

Thanks Stuart, I missed that. If I send a v3 of this patchset I'll include
this update, otherwise I'll send a separate patch for it.

Ioana
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/9] staging: ccree: add Arm TrustZone CryptoCell REE driver

2017-04-20 Thread Gilad Ben-Yossef

Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
accelerators. It is supported by a long lived series of out of tree
drivers, which I am now in the process of unifying and upstreaming.
This is the first drop, supporting the new CryptoCell 712 REE.

The code still needs some cleanup before maturing to a proper
upstream driver, which I am in the process of doing. However,
as discussion of some of the capabilities of the hardware and
its application to some dm-crypt and dm-verity features recently
took place I though it is better to do this in the open via the
staging tree.

A Git repository based off of Linux 4.11-rc7 is also available at
https://github.com/gby/linux.git branch ccree_v2 for those inclined.

Signed-off-by: Gilad Ben-Yossef 
CC: Binoy Jayan 
CC: Ofir Drang 
CC: Stuart Yoder 

Changes from v1:
- Broke up patch set into smaller units for mailing list review as per
  Greg KH's indication.
- Changed DT binding compatible tag as per Mark Rutland suggestion.
- Moved DT binding document inside the staging directory and added DT binding
  review to TODO list as per Mark Rutland's request.

Many thanks to all reviewers :-)

Gilad Ben-Yossef (9):
  staging: ccree: introduce CryptoCell HW driver
  staging: ccree: add ahash support
  staging: ccree: add skcipher support
  staging: ccree: add IV generation support
  staging: ccree: add AEAD support
  staging: ccree: add FIPS support
  staging: ccree: add TODO list
  staging: ccree: add DT bindings for Arm CryptoCell
  MAINTAINERS: add Gilad BY as ccree maintainer

 MAINTAINERS|7 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |2 +-
 .../devicetree/bindings/crypto/arm-cryptocell.txt  |   27 +
 drivers/staging/ccree/Kconfig  |   43 +
 drivers/staging/ccree/Makefile |3 +
 drivers/staging/ccree/TODO |   28 +
 drivers/staging/ccree/bsp.h|   21 +
 drivers/staging/ccree/cc_bitops.h  |   62 +
 drivers/staging/ccree/cc_crypto_ctx.h  |  299 +++
 drivers/staging/ccree/cc_hal.h |   35 +
 drivers/staging/ccree/cc_hw_queue_defs.h   |  603 +
 drivers/staging/ccree/cc_lli_defs.h|   57 +
 drivers/staging/ccree/cc_pal_log.h |  188 ++
 drivers/staging/ccree/cc_pal_log_plat.h|   33 +
 drivers/staging/ccree/cc_pal_types.h   |   97 +
 drivers/staging/ccree/cc_pal_types_plat.h  |   29 +
 drivers/staging/ccree/cc_regs.h|  106 +
 drivers/staging/ccree/dx_crys_kernel.h |  180 ++
 drivers/staging/ccree/dx_env.h |  224 ++
 drivers/staging/ccree/dx_host.h|  155 ++
 drivers/staging/ccree/dx_reg_base_host.h   |   34 +
 drivers/staging/ccree/dx_reg_common.h  |   26 +
 drivers/staging/ccree/hash_defs.h  |   78 +
 drivers/staging/ccree/hw_queue_defs_plat.h |   43 +
 drivers/staging/ccree/ssi_aead.c   | 2832 
 drivers/staging/ccree/ssi_aead.h   |  120 +
 drivers/staging/ccree/ssi_buffer_mgr.c | 1876 +
 drivers/staging/ccree/ssi_buffer_mgr.h |  105 +
 drivers/staging/ccree/ssi_cipher.c | 1503 +++
 drivers/staging/ccree/ssi_cipher.h |   89 +
 drivers/staging/ccree/ssi_config.h |   61 +
 drivers/staging/ccree/ssi_driver.c |  557 
 drivers/staging/ccree/ssi_driver.h |  228 ++
 drivers/staging/ccree/ssi_fips.c   |   65 +
 drivers/staging/ccree/ssi_fips.h   |   70 +
 drivers/staging/ccree/ssi_fips_data.h  |  315 +++
 drivers/staging/ccree/ssi_fips_ext.c   |   96 +
 drivers/staging/ccree/ssi_fips_ll.c| 1681 
 drivers/staging/ccree/ssi_fips_local.c |  369 +++
 drivers/staging/ccree/ssi_fips_local.h |   77 +
 drivers/staging/ccree/ssi_hash.c   | 2751 +++
 drivers/staging/ccree/ssi_hash.h   |  101 +
 drivers/staging/ccree/ssi_ivgen.c  |  301 +++
 drivers/staging/ccree/ssi_ivgen.h  |   72 +
 drivers/staging/ccree/ssi_pm.c |  150 ++
 drivers/staging/ccree/ssi_pm.h |   46 +
 drivers/staging/ccree/ssi_pm_ext.c |   60 +
 drivers/staging/ccree/ssi_pm_ext.h |   33 +
 drivers/staging/ccree/ssi_request_mgr.c|  713 +
 drivers/staging/ccree/ssi_request_mgr.h|   60 +
 drivers/staging/ccree/ssi_sram_mgr.c   |  138 +
 drivers/staging/ccree/ssi_sram_mgr.h   |   80 +
 drivers/staging/ccree/ssi_sysfs.c  |  440 +++
 drivers/staging/ccree/ssi_sysfs.h

[PATCH v2 3/9] staging: ccree: add skcipher support

2017-04-20 Thread Gilad Ben-Yossef

Add CryptoCell skcipher support

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |8 +
 drivers/staging/ccree/Makefile |2 +-
 drivers/staging/ccree/cc_crypto_ctx.h  |   21 +
 drivers/staging/ccree/ssi_buffer_mgr.c |  147 
 drivers/staging/ccree/ssi_buffer_mgr.h |   16 +
 drivers/staging/ccree/ssi_cipher.c | 1440 
 drivers/staging/ccree/ssi_cipher.h |   88 ++
 drivers/staging/ccree/ssi_driver.c |   14 +
 drivers/staging/ccree/ssi_driver.h |   30 +
 9 files changed, 1765 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/ccree/ssi_cipher.c
 create mode 100644 drivers/staging/ccree/ssi_cipher.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index a528a99..3fff040 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -3,11 +3,19 @@ config CRYPTO_DEV_CCREE
depends on CRYPTO_HW && OF && HAS_DMA
default n
select CRYPTO_HASH
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_DES
+   select CRYPTO_AUTHENC
select CRYPTO_SHA1
select CRYPTO_MD5
select CRYPTO_SHA256
select CRYPTO_SHA512
select CRYPTO_HMAC
+   select CRYPTO_AES
+   select CRYPTO_CBC
+   select CRYPTO_ECB
+   select CRYPTO_CTR
+   select CRYPTO_XTS
help
  Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
  C7xx. Currently only the CryptoCell 712 REE is supported.
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index f94e225..21a80d5 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index fedf259..f198779 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -242,6 +242,27 @@ struct drv_ctx_hmac {
CC_DIGEST_SIZE_MAX - CC_HMAC_BLOCK_SIZE_MAX];
 };
 
+struct drv_ctx_cipher {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_AES */
+   enum drv_cipher_mode mode;
+   enum drv_crypto_direction direction;
+   enum drv_crypto_key_type crypto_key_type;
+   enum drv_crypto_padding_type padding_type;
+   uint32_t key_size; /* numeric value in bytes   */
+   uint32_t data_unit_size; /* required for XTS */
+   /* block_state is the AES engine block state.
+   *  It is used by the host to pass IV or counter at initialization.
+   *  It is used by SeP for intermediate block chaining state and for
+   *  returning MAC algorithms results.   */
+   uint8_t block_state[CC_AES_BLOCK_SIZE];
+   uint8_t key[CC_AES_KEY_SIZE_MAX];
+   uint8_t xex_key[CC_AES_KEY_SIZE_MAX];
+   /* reserve to end of allocated context size */
+   uint32_t reserved[CC_DRV_CTX_SIZE_WORDS - 7 -
+   CC_AES_BLOCK_SIZE/sizeof(uint32_t) - 2 *
+   (CC_AES_KEY_SIZE_MAX/sizeof(uint32_t))];
+};
+
 /***/
 /* MESSAGE BASED CONTEXTS **/
 /***/
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 5144eaa..a0fafa9 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -28,6 +28,7 @@
 
 #include "ssi_buffer_mgr.h"
 #include "cc_lli_defs.h"
+#include "ssi_cipher.h"
 #include "ssi_hash.h"
 
 #define LLI_MAX_NUM_OF_DATA_ENTRIES 128
@@ -517,6 +518,152 @@ static inline int ssi_ahash_handle_curr_buf(struct device 
*dev,
return 0;
 }
 
+void ssi_buffer_mgr_unmap_blkcipher_request(
+   struct device *dev,
+   void *ctx,
+   unsigned int ivsize,
+   struct scatterlist *src,
+   struct scatterlist *dst)
+{
+   struct blkcipher_req_ctx *req_ctx = (struct blkcipher_req_ctx *)ctx;
+
+   if (likely(req_ctx->gen_ctx.iv_dma_addr != 0)) {
+   SSI_LOG_DEBUG("Unmapped iv: iv_dma_addr=0x%llX iv_size=%u\n", 
+   (unsigned long long)req_ctx->gen_ctx.iv_dma_addr,
+   ivsize);
+   SSI_RESTORE_DMA_ADDR_TO_48BIT(req_ctx->gen_ctx.iv_dma_addr);
+   dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr, 
+ivsize, 
+DMA_TO_DEVICE);
+   }
+   /* Release pool */
+   if (req_ctx->dma_buf_type == SSI_DMA_BUF_MLLI) {
+   
SSI_RESTORE_DMA_ADDR_TO_48BIT(req_ctx->mlli_params.mlli_dma_addr);
+

[PATCH v2 2/9] staging: ccree: add ahash support

2017-04-20 Thread Gilad Ben-Yossef

Add CryptoCell async. hash and HMAC support.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |6 +
 drivers/staging/ccree/Makefile |2 +-
 drivers/staging/ccree/cc_crypto_ctx.h  |   22 +
 drivers/staging/ccree/hash_defs.h  |   78 +
 drivers/staging/ccree/ssi_buffer_mgr.c |  311 +++-
 drivers/staging/ccree/ssi_buffer_mgr.h |6 +
 drivers/staging/ccree/ssi_driver.c |   11 +-
 drivers/staging/ccree/ssi_driver.h |4 +-
 drivers/staging/ccree/ssi_hash.c   | 2732 
 drivers/staging/ccree/ssi_hash.h   |  101 ++
 drivers/staging/ccree/ssi_pm.c |4 +
 11 files changed, 3263 insertions(+), 14 deletions(-)
 create mode 100644 drivers/staging/ccree/hash_defs.h
 create mode 100644 drivers/staging/ccree/ssi_hash.c
 create mode 100644 drivers/staging/ccree/ssi_hash.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 0f723d7..a528a99 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -2,6 +2,12 @@ config CRYPTO_DEV_CCREE
tristate "Support for ARM TrustZone CryptoCell C7XX family of Crypto 
accelerators"
depends on CRYPTO_HW && OF && HAS_DMA
default n
+   select CRYPTO_HASH
+   select CRYPTO_SHA1
+   select CRYPTO_MD5
+   select CRYPTO_SHA256
+   select CRYPTO_SHA512
+   select CRYPTO_HMAC
help
  Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
  C7xx. Currently only the CryptoCell 712 REE is supported.
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 972af69..f94e225 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 8b8aea2..fedf259 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -220,6 +220,28 @@ struct drv_ctx_generic {
 } __attribute__((__may_alias__));
 
 
+struct drv_ctx_hash {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HASH */
+   enum drv_hash_mode mode;
+   uint8_t digest[CC_DIGEST_SIZE_MAX];
+   /* reserve to end of allocated context size */
+   uint8_t reserved[CC_CTX_SIZE - 2 * sizeof(uint32_t) -
+   CC_DIGEST_SIZE_MAX];
+};
+
+/*  drv_ctx_hmac should have the same structure as drv_ctx_hash except
+   k0, k0_size fields */
+struct drv_ctx_hmac {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HMAC */
+   enum drv_hash_mode mode;
+   uint8_t digest[CC_DIGEST_SIZE_MAX];
+   uint32_t k0[CC_HMAC_BLOCK_SIZE_MAX/sizeof(uint32_t)];
+   uint32_t k0_size;
+   /* reserve to end of allocated context size */
+   uint8_t reserved[CC_CTX_SIZE - 3 * sizeof(uint32_t) -
+   CC_DIGEST_SIZE_MAX - CC_HMAC_BLOCK_SIZE_MAX];
+};
+
 /***/
 /* MESSAGE BASED CONTEXTS **/
 /***/
diff --git a/drivers/staging/ccree/hash_defs.h 
b/drivers/staging/ccree/hash_defs.h
new file mode 100644
index 000..0cd6909
--- /dev/null
+++ b/drivers/staging/ccree/hash_defs.h
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2012-2016 ARM Limited or its affiliates.
+ * 
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#ifndef  _HASH_DEFS_H__
+#define  _HASH_DEFS_H__
+
+#include "cc_crypto_ctx.h"
+
+/* this files provides definitions required for hash engine drivers */
+#ifndef CC_CONFIG_HASH_SHA_512_SUPPORTED
+#define SEP_HASH_LENGTH_WORDS  2
+#else
+#define SEP_HASH_LENGTH_WORDS  4
+#endif
+
+#ifdef BIG__ENDIAN
+#define OPAD_CURRENT_LENGTH 0x4000, 0x , 0x, 0x
+#define HASH_LARVAL_MD5  0x76543210, 0xFEDCBA98, 0x89ABCDEF, 0x01234567
+#define HASH_LARVAL_SHA1 0xF0E1D2C3, 0x76543210, 0xFEDCBA98, 0x89ABCDEF, 
0x01234567
+#define HASH_LARVAL_SHA224 0XA44

[PATCH v2 4/9] staging: ccree: add IV generation support

2017-04-20 Thread Gilad Ben-Yossef

Add CryptoCell IV hardware generation support.

This patch adds the needed support to drive the HW but does not expose
the ability via the kernel crypto API yet.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile  |   2 +-
 drivers/staging/ccree/ssi_buffer_mgr.c  |   2 +
 drivers/staging/ccree/ssi_cipher.c  |  11 ++
 drivers/staging/ccree/ssi_cipher.h  |   1 +
 drivers/staging/ccree/ssi_driver.c  |   9 +
 drivers/staging/ccree/ssi_driver.h  |   7 +
 drivers/staging/ccree/ssi_ivgen.c   | 301 
 drivers/staging/ccree/ssi_ivgen.h   |  72 
 drivers/staging/ccree/ssi_pm.c  |   2 +
 drivers/staging/ccree/ssi_request_mgr.c |  33 +++-
 10 files changed, 438 insertions(+), 2 deletions(-)
 create mode 100644 drivers/staging/ccree/ssi_ivgen.c
 create mode 100644 drivers/staging/ccree/ssi_ivgen.h

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 21a80d5..89afe9a 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index a0fafa9..6a9c964 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -534,6 +534,7 @@ void ssi_buffer_mgr_unmap_blkcipher_request(
SSI_RESTORE_DMA_ADDR_TO_48BIT(req_ctx->gen_ctx.iv_dma_addr);
dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr, 
 ivsize, 
+req_ctx->is_giv ? DMA_BIDIRECTIONAL :
 DMA_TO_DEVICE);
}
/* Release pool */
@@ -587,6 +588,7 @@ int ssi_buffer_mgr_map_blkcipher_request(
req_ctx->gen_ctx.iv_dma_addr = 
dma_map_single(dev, (void *)info, 
   ivsize, 
+  req_ctx->is_giv ? DMA_BIDIRECTIONAL:
   DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, 
req_ctx->gen_ctx.iv_dma_addr))) {
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 01467e8..2e4ce90 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -819,6 +819,13 @@ static int ssi_blkcipher_process(
  areq,
  desc, &seq_len);
 
+   /* do we need to generate IV? */
+   if (req_ctx->is_giv == true) {
+   ssi_req.ivgen_dma_addr[0] = req_ctx->gen_ctx.iv_dma_addr;
+   ssi_req.ivgen_dma_addr_len = 1;
+   /* set the IV size (8/16 B long)*/
+   ssi_req.ivgen_size = ivsize;
+   }
END_CYCLE_COUNT(ssi_req.op_type, STAT_PHASE_2);
 
/* STAT_PHASE_3: Lock HW and push sequence */
@@ -901,6 +908,7 @@ static int ssi_sblkcipher_encrypt(struct blkcipher_desc 
*desc,
unsigned int ivsize = crypto_blkcipher_ivsize(blk_tfm);
 
req_ctx->backup_info = desc->info;
+   req_ctx->is_giv = false;
 
return ssi_blkcipher_process(tfm, req_ctx, dst, src, nbytes, 
desc->info, ivsize, NULL, DRV_CRYPTO_DIRECTION_ENCRYPT);
 }
@@ -916,6 +924,7 @@ static int ssi_sblkcipher_decrypt(struct blkcipher_desc 
*desc,
unsigned int ivsize = crypto_blkcipher_ivsize(blk_tfm);
 
req_ctx->backup_info = desc->info;
+   req_ctx->is_giv = false;
 
return ssi_blkcipher_process(tfm, req_ctx, dst, src, nbytes, 
desc->info, ivsize, NULL, DRV_CRYPTO_DIRECTION_DECRYPT);
 }
@@ -948,6 +957,7 @@ static int ssi_ablkcipher_encrypt(struct ablkcipher_request 
*req)
unsigned int ivsize = crypto_ablkcipher_ivsize(ablk_tfm);
 
req_ctx->backup_info = req->info;
+   req_ctx->is_giv = false;
 
return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src, 
req->nbytes, req->info, ivsize, (void *)req, DRV_CRYPTO_DIRECTION_ENCRYPT);
 }
@@ -960,6 +970,7 @@ static int ssi_ablkcipher_decrypt(struct ablkcipher_request 
*req)
unsigned int ivsize = crypto_ablkcipher_ivsize(ablk_tfm);
 
req_ctx->backup_info = req->info;
+   req_ctx->is_giv = false;
return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src, 
req->nbytes, req->info, ivsize, (void *)req, DRV_CRYPTO_DIRECTION_DECRYPT);
 }
 
diff --git a/drivers/staging/ccree/ssi_cipher.h 
b/drivers/staging/ccree/ssi_cipher.h
index 511800f1..d1a98f9 100644
--- a/drivers/staging/ccree/ssi_cipher.h
+++ b/drivers/staging/ccree/ssi_cipher.h
@@ -45,6 +45,7 @@ struct blkcipher_req_ctx {

[PATCH v2 7/9] staging: ccree: add TODO list

2017-04-20 Thread Gilad Ben-Yossef

Add TODO list for moving out of staging tree for ccree crypto driver

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/TODO | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 drivers/staging/ccree/TODO

diff --git a/drivers/staging/ccree/TODO b/drivers/staging/ccree/TODO
new file mode 100644
index 000..3f1d61d
--- /dev/null
+++ b/drivers/staging/ccree/TODO
@@ -0,0 +1,28 @@
+
+
+*
+*  *
+* Arm Trust Zone CryptoCell REE Linux driver upstreaming TODO items*
+*  *
+*
+
+ccree specific items
+a.k.a stuff fixing for this driver to move out of staging
+~
+
+1.  Move to using Crypto Engine to handle backlog queueing.
+2.  Remove synchronous algorithm support leftovers.
+3.  Separate platform specific code for FIPS and power management into 
separate platform modules.
+4.  Drop legacy kernel support code.
+5.  Move most (all?) #ifdef CONFIG into inline functions.
+6.  Remove all unused definitions.
+7.  Re-factor to accomediate newer/older HW revisions besides the 712.
+8.  Handle the many checkpatch errors.
+9.  Implement ahash import/export correctly.
+10. Go through a proper review of DT bindings and sysfs ABI
+
+Kernel infrastructure items
+a.k.a stuff we either neither need to fix in the kernel or understand what 
we're doing wrong
+
+1. ahash import/export context has a PAGE_SIZE/8 size limit.  We need more.
+2. Crypto Engine seems to be built for HW with hardware queue depth of 1, we 
have 600++.
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 5/9] staging: ccree: add AEAD support

2017-04-20 Thread Gilad Ben-Yossef

Add CryptoCell AEAD support

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |1 +
 drivers/staging/ccree/Makefile |2 +-
 drivers/staging/ccree/cc_crypto_ctx.h  |   21 +
 drivers/staging/ccree/ssi_aead.c   | 2826 
 drivers/staging/ccree/ssi_aead.h   |  120 ++
 drivers/staging/ccree/ssi_buffer_mgr.c |  899 ++
 drivers/staging/ccree/ssi_buffer_mgr.h |4 +
 drivers/staging/ccree/ssi_driver.c |   11 +
 drivers/staging/ccree/ssi_driver.h |4 +
 9 files changed, 3887 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/ccree/ssi_aead.c
 create mode 100644 drivers/staging/ccree/ssi_aead.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 3fff040..2d11223 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -5,6 +5,7 @@ config CRYPTO_DEV_CCREE
select CRYPTO_HASH
select CRYPTO_BLKCIPHER
select CRYPTO_DES
+   select CRYPTO_AEAD
select CRYPTO_AUTHENC
select CRYPTO_SHA1
select CRYPTO_MD5
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 89afe9a..b9285c0 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index f198779..743461f 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -263,6 +263,27 @@ struct drv_ctx_cipher {
(CC_AES_KEY_SIZE_MAX/sizeof(uint32_t))];
 };
 
+/* authentication and encryption with associated data class */
+struct drv_ctx_aead {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_AES */
+   enum drv_cipher_mode mode;
+   enum drv_crypto_direction direction;
+   uint32_t key_size; /* numeric value in bytes   */
+   uint32_t nonce_size; /* nonce size (octets) */
+   uint32_t header_size; /* finit additional data size (octets) */
+   uint32_t text_size; /* finit text data size (octets) */
+   uint32_t tag_size; /* mac size, element of {4, 6, 8, 10, 12, 14, 16} */
+   /* block_state1/2 is the AES engine block state */
+   uint8_t block_state[CC_AES_BLOCK_SIZE];
+   uint8_t mac_state[CC_AES_BLOCK_SIZE]; /* MAC result */
+   uint8_t nonce[CC_AES_BLOCK_SIZE]; /* nonce buffer */
+   uint8_t key[CC_AES_KEY_SIZE_MAX];
+   /* reserve to end of allocated context size */
+   uint32_t reserved[CC_DRV_CTX_SIZE_WORDS - 8 -
+   3 * (CC_AES_BLOCK_SIZE/sizeof(uint32_t)) -
+   CC_AES_KEY_SIZE_MAX/sizeof(uint32_t)];
+};
+
 /***/
 /* MESSAGE BASED CONTEXTS **/
 /***/
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
new file mode 100644
index 000..1d2890e
--- /dev/null
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -0,0 +1,2826 @@
+/*
+ * Copyright (C) 2012-2016 ARM Limited or its affiliates.
+ * 
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ssi_config.h"
+#include "ssi_driver.h"
+#include "ssi_buffer_mgr.h"
+#include "ssi_aead.h"
+#include "ssi_request_mgr.h"
+#include "ssi_hash.h"
+#include "ssi_sysfs.h"
+#include "ssi_sram_mgr.h"
+
+#define template_aead  template_u.aead
+
+#define MAX_AEAD_SETKEY_SEQ 12
+#define MAX_AEAD_PROCESS_SEQ 23
+
+#define MAX_HMAC_DIGEST_SIZE (SHA256_DIGEST_SIZE)
+#define MAX_HMAC_BLOCK_SIZE (SHA256_BLOCK_SIZE)
+
+#define AES_CCM_RFC4309_NONCE_SIZE 3
+#define MAX_NONCE_SIZE CTR_RFC3686_NONCE_SIZE
+
+
+/* Value of each ICV_CMP byte (of 8) in case of success */
+#define ICV_VERIF_OK 0x01

[PATCH v2 6/9] staging: ccree: add FIPS support

2017-04-20 Thread Gilad Ben-Yossef

Add FIPS mode support to CryptoCell driver

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig   |9 +
 drivers/staging/ccree/Makefile  |1 +
 drivers/staging/ccree/ssi_aead.c|6 +
 drivers/staging/ccree/ssi_cipher.c  |   52 +
 drivers/staging/ccree/ssi_driver.c  |   19 +-
 drivers/staging/ccree/ssi_driver.h  |2 +
 drivers/staging/ccree/ssi_fips.c|   65 ++
 drivers/staging/ccree/ssi_fips.h|   70 ++
 drivers/staging/ccree/ssi_fips_data.h   |  315 ++
 drivers/staging/ccree/ssi_fips_ext.c|   96 ++
 drivers/staging/ccree/ssi_fips_ll.c | 1681 +++
 drivers/staging/ccree/ssi_fips_local.c  |  369 +++
 drivers/staging/ccree/ssi_fips_local.h  |   77 ++
 drivers/staging/ccree/ssi_hash.c|   21 +-
 drivers/staging/ccree/ssi_request_mgr.c |2 +
 15 files changed, 2783 insertions(+), 2 deletions(-)
 create mode 100644 drivers/staging/ccree/ssi_fips.c
 create mode 100644 drivers/staging/ccree/ssi_fips.h
 create mode 100644 drivers/staging/ccree/ssi_fips_data.h
 create mode 100644 drivers/staging/ccree/ssi_fips_ext.c
 create mode 100644 drivers/staging/ccree/ssi_fips_ll.c
 create mode 100644 drivers/staging/ccree/ssi_fips_local.c
 create mode 100644 drivers/staging/ccree/ssi_fips_local.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 2d11223..ae62704 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -24,6 +24,15 @@ config CRYPTO_DEV_CCREE
  cryptographic operations on the system REE.
  If unsure say Y.
 
+config CCREE_FIPS_SUPPORT
+   bool "Turn on CryptoCell 7XX REE FIPS mode support"
+   depends on CRYPTO_DEV_CCREE
+   default n
+   help
+ Say 'Y' to enable support for FIPS compliant mode by the
+ CCREE driver.
+ If unsure say N.
+
 config CCREE_DISABLE_COHERENT_DMA_OPS
bool "Disable Coherent DMA operations for the CCREE driver"
depends on CRYPTO_DEV_CCREE
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index b9285c0..44f3e3e 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
 ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 1d2890e..3ab958b 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -36,6 +36,7 @@
 #include "ssi_hash.h"
 #include "ssi_sysfs.h"
 #include "ssi_sram_mgr.h"
+#include "ssi_fips_local.h"
 
 #define template_aead  template_u.aead
 
@@ -153,6 +154,8 @@ static int ssi_aead_init(struct crypto_aead *tfm)
container_of(alg, struct ssi_crypto_alg, aead_alg);
SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx, 
crypto_tfm_alg_name(&(tfm->base)));
 
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
+
/* Initialize modes in instance */
ctx->cipher_mode = ssi_alg->cipher_mode;
ctx->flow_mode = ssi_alg->flow_mode;
@@ -572,6 +575,7 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key, 
unsigned int keylen)
SSI_LOG_DEBUG("Setting key in context @%p for %s. key=%p keylen=%u\n",
ctx, crypto_tfm_alg_name(crypto_aead_tfm(tfm)), key, keylen);
 
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
/* STAT_PHASE_0: Init and sanity checks */
START_CYCLE_COUNT();
 
@@ -699,6 +703,7 @@ static int ssi_aead_setauthsize(
 {
struct ssi_aead_ctx *ctx = crypto_aead_ctx(authenc);

+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
/* Unsupported auth. sizes */
if ((authsize == 0) ||
(authsize >crypto_aead_maxauthsize(authenc))) {
@@ -2006,6 +2011,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
SSI_LOG_DEBUG("%s context=%p req=%p iv=%p src=%p src_ofs=%d dst=%p 
dst_ofs=%d cryptolen=%d\n",
((direct==DRV_CRYPTO_DIRECTION_ENCRYPT)?"Encrypt":"Decrypt"), 
ctx, req, req->iv,
sg_virt(req->src), req->src->offset, sg_virt(req->dst), 
req->dst->offset, req->cryptlen);
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
/* STAT_PHASE_0: Init and sanity checks */
START_CYCLE_COUNT();
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 2e4ce90..e8a4071 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -31,6 +31,7 @@
 #include "ssi_cipher.h"
 #include "ssi_request_mgr.h"
 #include "ssi_sysfs.h"
+#include "ssi_fips_local.h"
 
 #define MAX_ABLKCIPHER_SEQ_LEN 6
 
@@ -191,6 +192,7 @@ static int ssi_blkcipher_init(struct crypto_tfm *tfm)
SSI_LOG_DEBUG

[PATCH v2 9/9] MAINTAINERS: add Gilad BY as ccree maintainer

2017-04-20 Thread Gilad Ben-Yossef

I work for Arm on maintaining the TrustZone CryptoCell driver.

Signed-off-by: Gilad Ben-Yossef 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 676c139..f21caa1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3066,6 +3066,13 @@ F:   drivers/net/ieee802154/cc2520.c
 F: include/linux/spi/cc2520.h
 F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
 
+CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
+M: Gilad Ben-Yossef 
+L: linux-cry...@vger.kernel.org
+S: Supported
+F: drivers/staging/ccree/
+W: 
https://developer.arm.com/products/system-ip/trustzone-cryptocell/cryptocell-700-family
+
 CEC DRIVER
 M: Hans Verkuil 
 L: linux-me...@vger.kernel.org
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 8/9] staging: ccree: add DT bindings for Arm CryptoCell

2017-04-20 Thread Gilad Ben-Yossef

This adds DT bindings for the Arm TrustZone CryptoCell cryptographic
accelerator IP.

Signed-off-by: Gilad Ben-Yossef 
---
 .../devicetree/bindings/crypto/arm-cryptocell.txt  | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 
drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt

diff --git 
a/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
 
b/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
new file mode 100644
index 000..2ea6517
--- /dev/null
+++ 
b/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
@@ -0,0 +1,27 @@
+Arm TrustZone CryptoCell cryptographic accelerators
+
+Required properties:
+- compatible: must be "arm,cryptocell-712-ree".
+- reg: shall contain base register location and length.
+   Typically length is 0x1.
+- interrupts: shall contain the interrupt for the device.
+
+Optional properties:
+- interrupt-parent: can designate the interrupt controller the
+   device interrupt is connected to, if needed.
+- clocks: may contain the clock handling the device, if needed.
+- power-domains: may contain a reference to the PM domain, if applicable.
+
+
+Examples:
+
+Zynq FPGA device
+
+
+   arm_cc7x: arm_cc7x@8000 {
+   compatible = "arm,cryptocell-712-ree";
+   interrupt-parent = <&intc>;
+   interrupts = < 0 30 4 >;
+   reg = < 0x8000 0x1 >;
+   };
+
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 0/9] staging: ccree: add Arm TrustZone CryptoCell REE driver

2017-04-20 Thread Greg Kroah-Hartman

On Thu, Apr 20, 2017 at 04:12:54PM +0300, Gilad Ben-Yossef wrote:
> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> accelerators. It is supported by a long lived series of out of tree
> drivers, which I am now in the process of unifying and upstreaming.
> This is the first drop, supporting the new CryptoCell 712 REE.
> 
> The code still needs some cleanup before maturing to a proper
> upstream driver, which I am in the process of doing. However,
> as discussion of some of the capabilities of the hardware and
> its application to some dm-crypt and dm-verity features recently
> took place I though it is better to do this in the open via the
> staging tree.
> 
> A Git repository based off of Linux 4.11-rc7 is also available at
> https://github.com/gby/linux.git branch ccree_v2 for those inclined.

If you want this in staging, I'll be glad to take it, but note then you
can't work off of an external repo, as syncing the two is almost
impossible and more work than you want to go through.

So, as long as this builds properly, want me to queue these up in my
tree?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

2017-04-20 Thread Greg Kroah-Hartman

On Thu, Apr 20, 2017 at 04:12:55PM +0300, Gilad Ben-Yossef wrote:
> +++ b/drivers/staging/ccree/bsp.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (C) 2012-2016 ARM Limited or its affiliates.
> + * 
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.

Oh, I have to ask, do you really mean "any later version" here and
elsewhere?

If so, then your MODULE_LICENSE() marking is wrong, please fix that up,
or fix up the license text, I can't take incompatible ones without
getting angry emails from legal people sent to me...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 0/9] staging: ccree: add Arm TrustZone CryptoCell REE driver

2017-04-20 Thread Gilad Ben-Yossef

On Thu, Apr 20, 2017 at 4:30 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Apr 20, 2017 at 04:12:54PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is also available at
>> https://github.com/gby/linux.git branch ccree_v2 for those inclined.
>
> If you want this in staging, I'll be glad to take it, but note then you
> can't work off of an external repo, as syncing the two is almost
> impossible and more work than you want to go through.

Once it's in the staging tree I don't need a separate repo. It was only useful
so long as I did not have an upstream tree to point people to.
>
> So, as long as this builds properly, want me to queue these up in my
> tree?

Yes, please.

Thanks,
Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

2017-04-20 Thread Gilad Ben-Yossef

On Thu, Apr 20, 2017 at 4:33 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Apr 20, 2017 at 04:12:55PM +0300, Gilad Ben-Yossef wrote:
>> +++ b/drivers/staging/ccree/bsp.h
>> @@ -0,0 +1,21 @@
>> +/*
>> + * Copyright (C) 2012-2016 ARM Limited or its affiliates.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the 
>> Free
>> + * Software Foundation; either version 2 of the License, or (at your option)
>> + * any later version.
>
> Oh, I have to ask, do you really mean "any later version" here and
> elsewhere?
>
> If so, then your MODULE_LICENSE() marking is wrong, please fix that up,
> or fix up the license text, I can't take incompatible ones without
> getting angry emails from legal people sent to me...
>

Thanks for noticing this.

The copyright + license notice is a boilerplate I got from the powers
that be here.

I'll consult internally what is the proper action. I don't want to
make legal mad either... :-)


Thanks again,

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

2017-04-20 Thread Stephan Müller

Am Donnerstag, 20. April 2017, 15:13:00 CEST schrieb Gilad Ben-Yossef:

Hi Gilad,

> +/* The function verifies that tdes keys are not weak.*/
> +static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen)
> +{
> +#ifdef CCREE_FIPS_SUPPORT
> +tdes_keys_t *tdes_key = (tdes_keys_t*)key;
> +
> + /* verify key1 != key2 and key3 != key2*/

I do not think that this check is necessary. There is no FIPS requirement or 
IG that mandates this (unlike the XTS key check).

If there would be such requirement, we would need a common service function 
for all TDES implementations

> +if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2,
> sizeof(tdes_key->key1)) == 0) || +  
> (memcmp((u8*)tdes_key->key3,
> (u8*)tdes_key->key2, sizeof(tdes_key->key3)) == 0) )) { +   
> return -ENOEXEC;
> +}
> +#endif /* CCREE_FIPS_SUPPORT */
> +
> +return 0;
> +}
> +
> +/* The function verifies that xts keys are not weak.*/
> +static int ssi_fips_verify_xts_keys(const u8 *key, unsigned int keylen)
> +{
> +#ifdef CCREE_FIPS_SUPPORT
> +/* Weak key is define as key that its first half (128/256 lsb)
> equals its second half (128/256 msb) */ +int singleKeySize = keylen
> >> 1;
> +
> + if (unlikely(memcmp(key, &key[singleKeySize], singleKeySize) == 0)) {
> + return -ENOEXEC;

Use xts_check_key.

> +The test vectors were taken from:
> +
> +* AES
> +NIST Special Publication 800-38A 2001 Edition
> +Recommendation for Block Cipher Modes of Operation
> +http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
> +Appendix F: Example Vectors for Modes of Operation of the AES
> +
> +* AES CTS
> +Advanced Encryption Standard (AES) Encryption for Kerberos 5
> +February 2005
> +https://tools.ietf.org/html/rfc3962#appendix-B
> +B.  Sample Test Vectors
> +
> +* AES XTS
> +http://csrc.nist.gov/groups/STM/cavp/#08
> +http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip
> +
> +* AES CMAC
> +http://csrc.nist.gov/groups/STM/cavp/index.html#07
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/cmactestvectors.zip
> +
> +* AES-CCM
> +http://csrc.nist.gov/groups/STM/cavp/#07
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip
> +
> +* AES-GCM
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmtestvectors.zip
> +
> +* Triple-DES
> +NIST Special Publication 800-67 January 2012
> +Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
> +http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf
> +APPENDIX B: EXAMPLE OF TDEA FORWARD AND INVERSE CIPHER OPERATIONS +and
> +http://csrc.nist.gov/groups/STM/cavp/#01
> +http://csrc.nist.gov/groups/STM/cavp/documents/des/tdesmct_intermediate.zip
> +
> +* HASH
> +http://csrc.nist.gov/groups/STM/cavp/#03
> +http://csrc.nist.gov/groups/STM/cavp/documents/shs/shabytetestvectors.zip
> +
> +* HMAC
> +http://csrc.nist.gov/groups/STM/cavp/#07
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/hmactestvectors.zip
> +
> +*/

Is this test vector business really needed? Why do you think that testmgr.c is 
not sufficient? Other successful FIPS validations of the kernel crypto API 
managed without such special code.

Also, your entire API seems to implement the approach that if there is a self 
test error, you disable the cipher functions, but leave the rest in-tact. The 
standard kernel crypto API handling logic is to simply panic the kernel. Is it 
really necessary to implement a special case for your driver?


Ciao
Stephan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

2017-04-20 Thread Greg Kroah-Hartman

On Thu, Apr 20, 2017 at 04:40:56PM +0300, Gilad Ben-Yossef wrote:
> On Thu, Apr 20, 2017 at 4:33 PM, Greg Kroah-Hartman
>  wrote:
> > On Thu, Apr 20, 2017 at 04:12:55PM +0300, Gilad Ben-Yossef wrote:
> >> +++ b/drivers/staging/ccree/bsp.h
> >> @@ -0,0 +1,21 @@
> >> +/*
> >> + * Copyright (C) 2012-2016 ARM Limited or its affiliates.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General Public License as published by the 
> >> Free
> >> + * Software Foundation; either version 2 of the License, or (at your 
> >> option)
> >> + * any later version.
> >
> > Oh, I have to ask, do you really mean "any later version" here and
> > elsewhere?
> >
> > If so, then your MODULE_LICENSE() marking is wrong, please fix that up,
> > or fix up the license text, I can't take incompatible ones without
> > getting angry emails from legal people sent to me...
> >
> 
> Thanks for noticing this.
> 
> The copyright + license notice is a boilerplate I got from the powers
> that be here.
> 
> I'll consult internally what is the proper action. I don't want to
> make legal mad either... :-)

Ok, I'll drop this patch series then, and wait for an updated one with
this fixed up.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: most: core: add autoconf ability

2017-04-20 Thread Christian Gromm

This patch extends the driver with the possibility of automatic
configuration. This covers channel settings and connection establishing of
a MOST device interface while it is registered with the core.

Making use of auto configuration will significantly cut the start-up
overhead and the duration until the driver is available in userspace.
Since the configuration depends on the type of network interface controller
its setup and the peripheral interface, it can _not_ be part of the kernel
and needs to be added once the system has been engineered.

Signed-off-by: Andrey Shvetsov 
Signed-off-by: Christian Gromm 
---
 drivers/staging/most/mostcore/core.c | 120 ++-
 drivers/staging/most/mostcore/mostcore.h |  66 -
 2 files changed, 167 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/most/mostcore/core.c 
b/drivers/staging/most/mostcore/core.c
index 675b2a9..cd2d20a 100644
--- a/drivers/staging/most/mostcore/core.c
+++ b/drivers/staging/most/mostcore/core.c
@@ -36,6 +36,8 @@
 static struct device *core_dev;
 static struct ida mdev_id;
 static int dummy_num_buffers;
+static struct list_head config_probes;
+struct mutex config_probes_mt; /* config_probes */
 
 struct most_c_aim_obj {
struct most_aim *ptr;
@@ -926,6 +928,30 @@ most_c_obj *get_channel_by_name(char *mdev, char *mdev_ch)
return c;
 }
 
+static int link_channel_to_aim(struct most_c_obj *c, struct most_aim *aim,
+  char *aim_param)
+{
+   int ret;
+   struct most_aim **aim_ptr;
+
+   if (!c->aim0.ptr)
+   aim_ptr = &c->aim0.ptr;
+   else if (!c->aim1.ptr)
+   aim_ptr = &c->aim1.ptr;
+   else
+   return -ENOSPC;
+
+   *aim_ptr = aim;
+   ret = aim->probe_channel(c->iface, c->channel_id,
+&c->cfg, &c->kobj, aim_param);
+   if (ret) {
+   *aim_ptr = NULL;
+   return ret;
+   }
+
+   return 0;
+}
+
 /**
  * add_link_store - store() function for add_link attribute
  * @aim_obj: pointer to AIM object
@@ -954,45 +980,33 @@ static ssize_t add_link_store(struct most_aim_obj 
*aim_obj,
  size_t len)
 {
struct most_c_obj *c;
-   struct most_aim **aim_ptr;
char buffer[STRING_SIZE];
char *mdev;
char *mdev_ch;
-   char *mdev_devnod;
+   char *aim_param;
char devnod_buf[STRING_SIZE];
int ret;
size_t max_len = min_t(size_t, len + 1, STRING_SIZE);
 
strlcpy(buffer, buf, max_len);
 
-   ret = split_string(buffer, &mdev, &mdev_ch, &mdev_devnod);
+   ret = split_string(buffer, &mdev, &mdev_ch, &aim_param);
if (ret)
return ret;
 
-   if (!mdev_devnod || *mdev_devnod == 0) {
+   if (!aim_param || *aim_param == 0) {
snprintf(devnod_buf, sizeof(devnod_buf), "%s-%s", mdev,
 mdev_ch);
-   mdev_devnod = devnod_buf;
+   aim_param = devnod_buf;
}
 
c = get_channel_by_name(mdev, mdev_ch);
if (IS_ERR(c))
return -ENODEV;
 
-   if (!c->aim0.ptr)
-   aim_ptr = &c->aim0.ptr;
-   else if (!c->aim1.ptr)
-   aim_ptr = &c->aim1.ptr;
-   else
-   return -ENOSPC;
-
-   *aim_ptr = aim_obj->driver;
-   ret = aim_obj->driver->probe_channel(c->iface, c->channel_id,
-&c->cfg, &c->kobj, mdev_devnod);
-   if (ret) {
-   *aim_ptr = NULL;
+   ret = link_channel_to_aim(c, aim_obj->driver, aim_param);
+   if (ret)
return ret;
-   }
 
return len;
 }
@@ -1685,6 +1699,73 @@ int most_deregister_aim(struct most_aim *aim)
 }
 EXPORT_SYMBOL_GPL(most_deregister_aim);
 
+void most_register_config_set(struct most_config_set *cfg_set)
+{
+   mutex_lock(&config_probes_mt);
+   list_add(&cfg_set->list, &config_probes);
+   mutex_unlock(&config_probes_mt);
+}
+EXPORT_SYMBOL(most_register_config_set);
+
+void most_deregister_config_set(struct most_config_set *cfg_set)
+{
+   mutex_lock(&config_probes_mt);
+   list_del(&cfg_set->list);
+   mutex_unlock(&config_probes_mt);
+}
+EXPORT_SYMBOL(most_deregister_config_set);
+
+static int probe_aim(struct most_c_obj *c,
+const char *aim_name, const char *aim_param)
+{
+   struct most_aim_obj *aim_obj;
+   char buf[STRING_SIZE];
+
+   list_for_each_entry(aim_obj, &aim_list, list) {
+   if (!strcmp(aim_obj->driver->name, aim_name)) {
+   strlcpy(buf, aim_param ? aim_param : "", sizeof(buf));
+   return link_channel_to_aim(c, aim_obj->driver, buf);
+   }
+   }
+   return 0;
+}
+
+static bool probe_config_set(struct most_c_obj *c,
+const char *dev_name, const char *ch_name,
+c

Re: [PATCH] staging: most: core: add autoconf ability

2017-04-20 Thread Greg KH

On Thu, Apr 20, 2017 at 05:01:49PM +0200, Christian Gromm wrote:
> This patch extends the driver with the possibility of automatic
> configuration. This covers channel settings and connection establishing of
> a MOST device interface while it is registered with the core.
> 
> Making use of auto configuration will significantly cut the start-up
> overhead and the duration until the driver is available in userspace.
> Since the configuration depends on the type of network interface controller
> its setup and the peripheral interface, it can _not_ be part of the kernel
> and needs to be added once the system has been engineered.

I don't understand, what is using this new api you have added?  What is
missing here?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

2017-04-20 Thread Haiyang Zhang

From: Haiyang Zhang 

This patch uses the lower 16 bits of the serial number as PCI
domain, otherwise some drivers may not be able to handle it.

Signed-off-by: Haiyang Zhang 
---
 drivers/pci/host/pci-hyperv.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index e73880c..b18dff3 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1334,9 +1334,11 @@ static void put_pcichild(struct hv_pci_dev *hpdev,
 * can have shorter names than based on the bus instance UUID.
 * Only the first device serial number is used for domain, so the
 * domain number will not change after the first device is added.
+* The lower 16 bits of the serial number is used, otherwise some
+* drivers may not be able to handle it.
 */
if (list_empty(&hbus->children))
-   hbus->sysdata.domain = desc->ser;
+   hbus->sysdata.domain = desc->ser & 0x;
list_add_tail(&hpdev->list_entry, &hbus->children);
spin_unlock_irqrestore(&hbus->device_list_lock, flags);
return hpdev;
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

2017-04-20 Thread kbuild test robot

drivers/staging/ccree/ssi_buffer_mgr.c:530:3-19: WARNING: NULL check before 
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or 
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid 
passing NULL values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_buffer_mgr.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -526,8 +526,7 @@ int ssi_buffer_mgr_fini(struct ssi_drvda
struct buff_mgr_handle *buff_mgr_handle = drvdata->buff_mgr_handle;
 
if (buff_mgr_handle  != NULL) {
-   if (buff_mgr_handle->mlli_buffs_pool != NULL)
-   dma_pool_destroy(buff_mgr_handle->mlli_buffs_pool);
+   dma_pool_destroy(buff_mgr_handle->mlli_buffs_pool);
kfree(drvdata->buff_mgr_handle);
drvdata->buff_mgr_handle = NULL;
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ccree: fix array_size.cocci warnings

2017-04-20 Thread kbuild test robot

drivers/staging/ccree/ssi_sysfs.c:319:34-35: WARNING: Use ARRAY_SIZE
drivers/staging/ccree/ssi_sysfs.c:429:34-35: WARNING: Use ARRAY_SIZE

 Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element

Semantic patch information:
 This makes an effort to find cases where ARRAY_SIZE can be used such as
 where there is a division of sizeof the array by the sizeof its first
 element or by any indexed element or the element type. It replaces the
 division of the two sizeofs by ARRAY_SIZE.

Generated by: scripts/coccinelle/misc/array_size.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_sysfs.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/staging/ccree/ssi_sysfs.c
+++ b/drivers/staging/ccree/ssi_sysfs.c
@@ -316,7 +316,7 @@ static ssize_t ssi_sys_help_show(struct
int i=0, offset = 0;
 
offset += scnprintf(buf + offset, PAGE_SIZE - offset, "Usage:\n");
-   for ( i = 0; i < (sizeof(help_str)/sizeof(help_str[0])); i+=2) {
+   for ( i = 0; i < ARRAY_SIZE(help_str); i+=2) {
   offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s\t\t%s\n", 
help_str[i], help_str[i+1]);
}
return offset;
@@ -426,8 +426,7 @@ int ssi_sysfs_init(struct kobject *sys_d
/* Initialize top directory */
retval = sys_init_dir(&sys_top_dir, drvdata, sys_dev_obj,
"cc_info", ssi_sys_top_level_attrs,
-   sizeof(ssi_sys_top_level_attrs) /
-   sizeof(struct kobj_attribute));
+   ARRAY_SIZE(ssi_sys_top_level_attrs));
return retval;
 }
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ccree: fix platform_no_drv_owner.cocci warnings

2017-04-20 Thread kbuild test robot

drivers/staging/ccree/ssi_driver.c:484:6-11: No need to set .owner here. The 
core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_driver.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -481,7 +481,6 @@ MODULE_DEVICE_TABLE(of, arm_cc7x_dev_of_
 static struct platform_driver cc7x_driver = {
.driver = {
   .name = "cc7xree",
-  .owner = THIS_MODULE,
 #ifdef CONFIG_OF
   .of_match_table = arm_cc7x_dev_of_match,
 #endif
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

2017-04-20 Thread kbuild test robot

Hi Gilad,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_driver.c:60:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_driver.c: In function 'cc_isr':
>> drivers/staging/ccree/cc_hal.h:33:38: error: implicit declaration of 
>> function 'READ_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_READ_REGISTER(offset) READ_REGISTER(cc_base + offset)
 ^
>> drivers/staging/ccree/ssi_driver.c:120:8: note: in expansion of macro 
>> 'CC_HAL_READ_REGISTER'
 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR));
   ^~~~
>> drivers/staging/ccree/cc_hal.h:32:44: error: implicit declaration of 
>> function 'WRITE_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_WRITE_REGISTER(offset, val) WRITE_REGISTER(cc_base + offset, 
val)
   ^
>> drivers/staging/ccree/ssi_driver.c:129:2: note: in expansion of macro 
>> 'CC_HAL_WRITE_REGISTER'
 CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_ICR), irr);
 ^
   cc1: some warnings being treated as errors
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_sysfs.c:19:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_sysfs.c: In function 'ssi_sys_regdump_show':
>> drivers/staging/ccree/cc_hal.h:33:38: error: implicit declaration of 
>> function 'READ_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_READ_REGISTER(offset) READ_REGISTER(cc_base + offset)
 ^
>> drivers/staging/ccree/ssi_sysfs.c:291:19: note: in expansion of macro 
>> 'CC_HAL_READ_REGISTER'
 register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, 
HOST_SIGNATURE));
  ^~~~
   cc1: some warnings being treated as errors
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_buffer_mgr.h:27,
from drivers/staging/ccree/ssi_buffer_mgr.c:28:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_request_mgr.c:27:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_request_mgr.c: In function 'request_mgr_init':
>> drivers/staging/ccree/ssi_request_mgr.c:198:29: error: implicit declaration 
>> of function 'READ_REGISTER' [-Werror=implicit-function-declaration]
 req_mgr_h->hw_queue_size = READ_REGISTER(drvdata->cc_base +
^
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_request_mgr.c:27:
   drivers/staging/ccree/ssi_request_mgr.c: In function 'comp_handler':
>> drivers/staging/ccree/cc_hal.h:32:44: error: implicit declaration of 
>> function 'WRITE_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_WRITE_REGISTER(offset, val) WRITE_REGISTER(cc_base + offset, 
val)
   ^
>> drivers/staging/ccree/ssi_request_mgr.c:595:3: note: in expansion of macro 
>> 'CC_HAL_WRITE_REGISTER'
  CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_ICR), 
SSI_COMP_IRQ_MASK);
  ^
   cc1: some warnings being treated as errors
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_pm.c:24:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_pm.c: In funct

[PATCH] staging: ccree: fix semicolon.cocci warnings

2017-04-20 Thread kbuild test robot

drivers/staging/ccree/ssi_request_mgr.c:623:3-4: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_request_mgr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -620,7 +620,7 @@ static void comp_handler(unsigned long d
/* Avoid race with above clear: Test completion counter 
once more */
request_mgr_handle->axi_completed += 
CC_REG_FLD_GET(CRY_KERNEL, AXIM_MON_COMP, VALUE, 
CC_HAL_READ_REGISTER(AXIM_MON_BASE_OFFSET));
-   };
+   }

}
/* after verifing that there is nothing to do, Unmask AXI completion 
interrupt */
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: comedi: support vm_access_process for mmap'd buffer

2017-04-20 Thread Ian Abbott

If a process that has mmap'd a COMEDI buffer is being run under a
debugger such as GDB, the buffer contents are inaccessible from the
debugger.  Support the `access()` VM operation to allow the buffer
contents to be accessed by another process.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/comedi_buf.c  | 24 
 drivers/staging/comedi/comedi_fops.c | 15 +++
 drivers/staging/comedi/comedi_internal.h |  2 ++
 3 files changed, 41 insertions(+)

diff --git a/drivers/staging/comedi/comedi_buf.c 
b/drivers/staging/comedi/comedi_buf.c
index 1e1df89b5018..8e9b30b26810 100644
--- a/drivers/staging/comedi/comedi_buf.c
+++ b/drivers/staging/comedi/comedi_buf.c
@@ -161,6 +161,30 @@ int comedi_buf_map_put(struct comedi_buf_map *bm)
return 1;
 }
 
+/* helper for "access" vm operation */
+int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
+ void *buf, int len, int write)
+{
+   unsigned int pgoff = offset & ~PAGE_MASK;
+   unsigned long pg = offset >> PAGE_SHIFT;
+   int done = 0;
+
+   while (done < len && pg < bm->n_pages) {
+   int l = min_t(int, len - done, PAGE_SIZE - pgoff);
+   void *b = bm->page_list[pg].virt_addr + pgoff;
+
+   if (write)
+   memcpy(b, buf, l);
+   else
+   memcpy(buf, b, l);
+   buf += l;
+   done += l;
+   pg++;
+   pgoff = 0;
+   }
+   return done;
+}
+
 /* returns s->async->buf_map and increments its kref refcount */
 struct comedi_buf_map *
 comedi_buf_map_from_subdev_get(struct comedi_subdevice *s)
diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 92d864fc08ac..2a8a39653c94 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2165,9 +2165,24 @@ static void comedi_vm_close(struct vm_area_struct *area)
comedi_buf_map_put(bm);
 }
 
+static int comedi_vm_access(struct vm_area_struct *vma, unsigned long addr,
+   void *buf, int len, int write)
+{
+   struct comedi_buf_map *bm = vma->vm_private_data;
+   unsigned long offset =
+   addr - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT);
+
+   if (len < 0)
+   return -EINVAL;
+   if (len > vma->vm_end - vma->vm_start)
+   len = vma->vm_end - vma->vm_start;
+   return comedi_buf_map_access(bm, offset, buf, len, write);
+}
+
 static const struct vm_operations_struct comedi_vm_ops = {
.open = comedi_vm_open,
.close = comedi_vm_close,
+   .access = comedi_vm_access,
 };
 
 static int comedi_mmap(struct file *file, struct vm_area_struct *vma)
diff --git a/drivers/staging/comedi/comedi_internal.h 
b/drivers/staging/comedi/comedi_internal.h
index 534415e331b6..6246f4a78ca6 100644
--- a/drivers/staging/comedi/comedi_internal.h
+++ b/drivers/staging/comedi/comedi_internal.h
@@ -29,6 +29,8 @@ void comedi_buf_reset(struct comedi_subdevice *s);
 bool comedi_buf_is_mmapped(struct comedi_subdevice *s);
 void comedi_buf_map_get(struct comedi_buf_map *bm);
 int comedi_buf_map_put(struct comedi_buf_map *bm);
+int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
+ void *buf, int len, int write);
 struct comedi_buf_map *comedi_buf_map_from_subdev_get(
struct comedi_subdevice *s);
 unsigned int comedi_buf_write_n_available(struct comedi_subdevice *s);
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: comedi: support vm_access_process for mmap'd buffer

2017-04-20 Thread Ian Abbott

If a process that has mmap'd a COMEDI buffer is being run under a
debugger such as GDB, the buffer contents are inaccessible from the
debugger.  Support the `access()` VM operation to allow the buffer
contents to be accessed by another process.

Signed-off-by: Ian Abbott 
---
v2: correct maximum length in `comedi_vm_access()`.
---
 drivers/staging/comedi/comedi_buf.c  | 24 
 drivers/staging/comedi/comedi_fops.c | 15 +++
 drivers/staging/comedi/comedi_internal.h |  2 ++
 3 files changed, 41 insertions(+)

diff --git a/drivers/staging/comedi/comedi_buf.c 
b/drivers/staging/comedi/comedi_buf.c
index 1e1df89b5018..8e9b30b26810 100644
--- a/drivers/staging/comedi/comedi_buf.c
+++ b/drivers/staging/comedi/comedi_buf.c
@@ -161,6 +161,30 @@ int comedi_buf_map_put(struct comedi_buf_map *bm)
return 1;
 }
 
+/* helper for "access" vm operation */
+int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
+ void *buf, int len, int write)
+{
+   unsigned int pgoff = offset & ~PAGE_MASK;
+   unsigned long pg = offset >> PAGE_SHIFT;
+   int done = 0;
+
+   while (done < len && pg < bm->n_pages) {
+   int l = min_t(int, len - done, PAGE_SIZE - pgoff);
+   void *b = bm->page_list[pg].virt_addr + pgoff;
+
+   if (write)
+   memcpy(b, buf, l);
+   else
+   memcpy(buf, b, l);
+   buf += l;
+   done += l;
+   pg++;
+   pgoff = 0;
+   }
+   return done;
+}
+
 /* returns s->async->buf_map and increments its kref refcount */
 struct comedi_buf_map *
 comedi_buf_map_from_subdev_get(struct comedi_subdevice *s)
diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 92d864fc08ac..f191c2a75732 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2165,9 +2165,24 @@ static void comedi_vm_close(struct vm_area_struct *area)
comedi_buf_map_put(bm);
 }
 
+static int comedi_vm_access(struct vm_area_struct *vma, unsigned long addr,
+   void *buf, int len, int write)
+{
+   struct comedi_buf_map *bm = vma->vm_private_data;
+   unsigned long offset =
+   addr - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT);
+
+   if (len < 0)
+   return -EINVAL;
+   if (len > vma->vm_end - addr)
+   len = vma->vm_end - addr;
+   return comedi_buf_map_access(bm, offset, buf, len, write);
+}
+
 static const struct vm_operations_struct comedi_vm_ops = {
.open = comedi_vm_open,
.close = comedi_vm_close,
+   .access = comedi_vm_access,
 };
 
 static int comedi_mmap(struct file *file, struct vm_area_struct *vma)
diff --git a/drivers/staging/comedi/comedi_internal.h 
b/drivers/staging/comedi/comedi_internal.h
index 534415e331b6..6246f4a78ca6 100644
--- a/drivers/staging/comedi/comedi_internal.h
+++ b/drivers/staging/comedi/comedi_internal.h
@@ -29,6 +29,8 @@ void comedi_buf_reset(struct comedi_subdevice *s);
 bool comedi_buf_is_mmapped(struct comedi_subdevice *s);
 void comedi_buf_map_get(struct comedi_buf_map *bm);
 int comedi_buf_map_put(struct comedi_buf_map *bm);
+int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
+ void *buf, int len, int write);
 struct comedi_buf_map *comedi_buf_map_from_subdev_get(
struct comedi_subdevice *s);
 unsigned int comedi_buf_write_n_available(struct comedi_subdevice *s);
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 2/9] staging: ccree: add ahash support

2017-04-20 Thread kbuild test robot

Hi Gilad,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023

coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/ccree/ssi_hash.c:317:2-7: WARNING: NULL check before freeing
>> functions like kfree, debugfs_remove, debugfs_remove_recursive or
>> usb_free_urb is not needed. Maybe consider reorganizing relevant code to
>> avoid passing NULL values.
drivers/staging/ccree/ssi_hash.c:320:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:323:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:373:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:375:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:377:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:379:3-8: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:381:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.
drivers/staging/ccree/ssi_hash.c:383:2-7: WARNING: NULL check before freeing
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL
values.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

2017-04-20 Thread kbuild test robot

drivers/staging/ccree/ssi_hash.c:317:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:320:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:323:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:373:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:375:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:377:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:379:3-8: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:381:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:383:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_hash.c |   27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -313,14 +313,11 @@ fail4:
state->digest_buff_dma_addr = 0;
}
 fail3:
-   if (state->opad_digest_buff != NULL)
-   kfree(state->opad_digest_buff);
+   kfree(state->opad_digest_buff);
 fail2:
-   if (state->digest_bytes_len != NULL)
-   kfree(state->digest_bytes_len);
+   kfree(state->digest_bytes_len);
 fail1:
-   if (state->digest_buff != NULL)
-   kfree(state->digest_buff);
+kfree(state->digest_buff);
 fail_digest_result_buff:
 if (state->digest_result_buff != NULL) {
 kfree(state->digest_result_buff);
@@ -369,18 +366,12 @@ static void ssi_hash_unmap_request(struc
state->opad_digest_dma_addr = 0;
}
 
-   if (state->opad_digest_buff != NULL)
-   kfree(state->opad_digest_buff);
-   if (state->digest_bytes_len != NULL)
-   kfree(state->digest_bytes_len);
-   if (state->digest_buff != NULL)
-   kfree(state->digest_buff);
-   if (state->digest_result_buff != NULL) 
-   kfree(state->digest_result_buff);
-   if (state->buff1 != NULL) 
-   kfree(state->buff1);
-   if (state->buff0 != NULL)
-   kfree(state->buff0);
+   kfree(state->opad_digest_buff);
+   kfree(state->digest_bytes_len);
+   kfree(state->digest_buff);
+   kfree(state->digest_result_buff);
+   kfree(state->buff1);
+   kfree(state->buff0);
 }
 
 static void ssi_hash_unmap_result(struct device *dev, 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Bug] VCHIQ functional test broken

2017-04-20 Thread Eric Anholt

Rabin Vincent  writes:

> On Thu, Apr 13, 2017 at 11:29:15PM +0100, Russell King - ARM Linux wrote:
>> > 00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
>> > commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
>> > Author: Rabin Vincent 
>> > Date:   Tue Nov 8 09:21:19 2016 +0100
>> > 
>> > ARM: 8627/1: avoid cache flushing in flush_dcache_page()
>> > 
>> > When the data cache is PIPT or VIPT non-aliasing, and cache operations
>> > are broadcast by the hardware, we can always postpone the flush in
>> > flush_dcache_page().  A similar change was done for ARM64 in commit
>> > b5b6c9e9149d ("arm64: Avoid cache flushing in flush_dcache_page()").
>> > 
>> > Reviewed-by: Catalin Marinas 
>> > Signed-off-by: Rabin Vincent 
>> > Signed-off-by: Russell King 
>> > 
>> > It seems that staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm
>> > relies on the behavior of flush_dcache_page before this patch get
>> > applied. Any advices to fix this issues are appreciated.
>> 
>> Any ideas why this causes a problem for this driver?  From what I can see,
>> it doesn't make use of flush_dcache_page().
>
> The driver's create_pagelist() uses get_free_pages(), and
> get_free_pages() calls flush_dcache_page().
>
> The problem is that the driver fails to flush the pages which it
> acquires via get_free_pages().  It's clear that the driver needs to do
> it, since there is a flush in the is_vmalloc_addr() path in the same
> function.  The driver probably worked earlier because of the unecessary
> flush in flush_dcache_page() which existed before this patch, but the
> purpose of that flush was not DMA coherency and it was never guaranteed
> that it would flush all the way to the point that devices could see the
> data.
>
> See radeon_ttm_tt_pin_userptr() in drivers/gpu/drm/radeon/radeon_ttm.c
> for an example of how a driver can ensure cache coherency using the DMA
> mapping API if it intends to DMA from/to pages acquired by
> get_free_pages().
>
> The rest of the driver should also be converted to the DMA mapping API
> instead of abusing the API's private functions (dmac_map_area etc.)

I'm confused by what you're saying here.  The driver has already been
converted to not use dmac_map_area (commit
cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
matching the radeon driver you give as a model as far as I can see.
That commit is in v4.11-rc6 from Stefan's regression report.


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

2017-04-20 Thread Bjorn Helgaas

On Thu, Apr 20, 2017 at 11:35 AM, Haiyang Zhang
 wrote:
> From: Haiyang Zhang 
>
> This patch uses the lower 16 bits of the serial number as PCI
> domain, otherwise some drivers may not be able to handle it.

Can you give any more details about this?  Which drivers, for
instance?  Why do drivers care about the domain at all?  Can we or
should we make this more explicit and consistent in the PCI core,
e.g., pci_domain_nr() is currently defined to return "int"; maybe it
should be u32?  (Although I think "int" is the same size as "u32" on
all arches anyway).

> Signed-off-by: Haiyang Zhang 
> ---
>  drivers/pci/host/pci-hyperv.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index e73880c..b18dff3 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1334,9 +1334,11 @@ static void put_pcichild(struct hv_pci_dev *hpdev,
>  * can have shorter names than based on the bus instance UUID.
>  * Only the first device serial number is used for domain, so the
>  * domain number will not change after the first device is added.
> +* The lower 16 bits of the serial number is used, otherwise some
> +* drivers may not be able to handle it.
>  */
> if (list_empty(&hbus->children))
> -   hbus->sysdata.domain = desc->ser;
> +   hbus->sysdata.domain = desc->ser & 0x;
> list_add_tail(&hpdev->list_entry, &hbus->children);
> spin_unlock_irqrestore(&hbus->device_list_lock, flags);
> return hpdev;
> --
> 1.7.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

2017-04-20 Thread Haiyang Zhang

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Thursday, April 20, 2017 2:33 PM
> To: Haiyang Zhang 
> Cc: linux-...@vger.kernel.org; KY Srinivasan ;
> Stephen Hemminger ; o...@aepfle.de;
> vkuzn...@redhat.com; driverdev-devel@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain
> 
> On Thu, Apr 20, 2017 at 11:35 AM, Haiyang Zhang
>  wrote:
> > From: Haiyang Zhang 
> >
> > This patch uses the lower 16 bits of the serial number as PCI
> > domain, otherwise some drivers may not be able to handle it.
> 
> Can you give any more details about this?  Which drivers, for
> instance?  Why do drivers care about the domain at all?  Can we or
> should we make this more explicit and consistent in the PCI core,
> e.g., pci_domain_nr() is currently defined to return "int"; maybe it
> should be u32?  (Although I think "int" is the same size as "u32" on
> all arches anyway).

It's Nvidia driver.

Piotr, could you explain why the driver expects 16 bit domain number?

Thanks,
- Haiyang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 5/9] staging: ccree: add AEAD support

2017-04-20 Thread kbuild test robot

Hi Gilad,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023


coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/ccree/ssi_buffer_mgr.c:758:2-4: ERROR: test of a 
>> variable/field address

vim +758 drivers/staging/ccree/ssi_buffer_mgr.c

   742  
   743  if (areq_ctx->gcm_iv_inc2_dma_addr != 0) {
   744  
SSI_RESTORE_DMA_ADDR_TO_48BIT(areq_ctx->gcm_iv_inc2_dma_addr);
   745  dma_unmap_single(dev, 
areq_ctx->gcm_iv_inc2_dma_addr, 
   746  AES_BLOCK_SIZE, DMA_TO_DEVICE);
   747  }
   748  }
   749  #endif
   750  
   751  if (areq_ctx->ccm_hdr_size != ccm_header_size_null) {
   752  if (areq_ctx->ccm_iv0_dma_addr != 0) {
   753  
SSI_RESTORE_DMA_ADDR_TO_48BIT(areq_ctx->ccm_iv0_dma_addr);
   754  dma_unmap_single(dev, 
areq_ctx->ccm_iv0_dma_addr, 
   755  AES_BLOCK_SIZE, DMA_TO_DEVICE);
   756  }
   757  
 > 758  if (&areq_ctx->ccm_adata_sg != NULL)
   759  dma_unmap_sg(dev, &areq_ctx->ccm_adata_sg,
   760  1, DMA_TO_DEVICE);
   761  }
   762  if (areq_ctx->gen_ctx.iv_dma_addr != 0) {
   763  
SSI_RESTORE_DMA_ADDR_TO_48BIT(areq_ctx->gen_ctx.iv_dma_addr);
   764  dma_unmap_single(dev, areq_ctx->gen_ctx.iv_dma_addr,
   765   hw_iv_size, DMA_BIDIRECTIONAL);
   766  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: ks7010: Change capability field to __le16

2017-04-20 Thread Johan Svensson


On 2017-04-18 20:38, Greg KH wrote:
> On Tue, Apr 18, 2017 at 08:24:01PM +0200, Johan Svensson wrote:
>> Change capability field to __le16 in struct ap_info_t,
>> struct link_ap_info_t, and struct local_ap_t.
>> This fixes a sparse warning.
> What warning is it fixing?  And are you sure this is the correct fix?
> How did you test it?
>
> thanks,
>
> greg k-h
Without the patch, sparse reports:
drivers/staging/ks7010/ks_wlan_net.c:1459:24: warning: cast to restricted __le16

The capability field in the structs that are changed are already being treated 
as little endian i.e. the patch is correct if the le16_to_cpu conversion in 
ks_wlan_net.c:1459 is correct.

regards,
Johan Svensson
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

2017-04-20 Thread Christoph Hellwig

On Thu, Apr 20, 2017 at 06:37:35PM +, Haiyang Zhang wrote:
> It's Nvidia driver.

Which of the many nvidia drivers in the tree?  Just fix it instead of
coming up with stupid workarounds like this.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Bug] VCHIQ functional test broken

2017-04-20 Thread Rabin Vincent

On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> I'm confused by what you're saying here.  The driver has already been
> converted to not use dmac_map_area (commit
> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
> matching the radeon driver you give as a model as far as I can see.
> That commit is in v4.11-rc6 from Stefan's regression report.

Right.  Sorry.  I must have had an old tag checked out when I looked at
the driver earlier.  The DMA API usage in the driver in v4.11-rc6 and
current master looks fine, except for one thing:

The flush in flush_dcache_page() (from get_user_pages()) was done with a
v6_flush_kern_dcache_page() which always did a clean+invalidate while
the DMA API only does what is required by the direction, which is only a
invalidate for DMA_FROM_DEVICE.  Since the driver calls dma_from_sg() on
the entire page, even if userspace sent in an offset into the page,
unrelated data in userspace may be thrown away.

Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
test pass?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Bug] VCHIQ functional test broken

2017-04-20 Thread Eric Anholt

Rabin Vincent  writes:

> On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
>> I'm confused by what you're saying here.  The driver has already been
>> converted to not use dmac_map_area (commit
>> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
>> matching the radeon driver you give as a model as far as I can see.
>> That commit is in v4.11-rc6 from Stefan's regression report.
>
> Right.  Sorry.  I must have had an old tag checked out when I looked at
> the driver earlier.  The DMA API usage in the driver in v4.11-rc6 and
> current master looks fine, except for one thing:
>
> The flush in flush_dcache_page() (from get_user_pages()) was done with a
> v6_flush_kern_dcache_page() which always did a clean+invalidate while
> the DMA API only does what is required by the direction, which is only a
> invalidate for DMA_FROM_DEVICE.  Since the driver calls dma_from_sg() on
> the entire page, even if userspace sent in an offset into the page,
> unrelated data in userspace may be thrown away.
>
> Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
> test pass?

Oh, that's a neat explanation for what might be wrong, and there seem to
be tests trying to poke at that within the functional test code.
Hopefully Stefan can try that out.


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: android: ion: Remove whitespace before quoted newline

2017-04-20 Thread Paolo Cretaro


On 19/04/2017 09:34, Paolo Cretaro wrote:

Fix checkpatch.pl warning about unnecessary whitespace before a
quoted newline.

Signed-off-by: Paolo Cretaro 
---
  drivers/staging/android/ion/ion_chunk_heap.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f604e22..8111a28b3ade 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -151,7 +151,7 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
  chunk_heap->heap.ops = &chunk_heap_ops;
  chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
  chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-pr_debug("%s: base %lu size %zu \n", __func__,
+pr_debug("%s: base %lu size %zu\n", __func__,
   chunk_heap->base, heap_data->size);

  return &chunk_heap->heap;


Ah! I missed that in the meanwhile another commit changed that line,
so my patch doesn't cleanly apply anymore.
Resending v2 rebased against next-20170420
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: android: ion: Remove whitespace before quoted newline

2017-04-20 Thread Paolo Cretaro


Fix checkpatch.pl warning about unnecessary whitespace before a
quoted newline.

Signed-off-by: Paolo Cretaro 
---
 drivers/staging/android/ion/ion_chunk_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 9c257c7a2ba0..102c09398317 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -150,7 +150,7 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = &chunk_heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-   pr_debug("%s: base %pa size %zu \n", __func__,
+   pr_debug("%s: base %pa size %zu\n", __func__,
 &chunk_heap->base, heap_data->size);
 
 	return &chunk_heap->heap;

--
2.12.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: comedi: support vm_access_process for mmap'd buffer

2017-04-20 Thread Ian Abbott


On 20/04/17 18:39, Ian Abbott wrote:

If a process that has mmap'd a COMEDI buffer is being run under a
debugger such as GDB, the buffer contents are inaccessible from the
debugger.  Support the `access()` VM operation to allow the buffer
contents to be accessed by another process.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/comedi_buf.c  | 24 
 drivers/staging/comedi/comedi_fops.c | 15 +++
 drivers/staging/comedi/comedi_internal.h |  2 ++
 3 files changed, 41 insertions(+)

diff --git a/drivers/staging/comedi/comedi_buf.c 
b/drivers/staging/comedi/comedi_buf.c
index 1e1df89b5018..8e9b30b26810 100644
--- a/drivers/staging/comedi/comedi_buf.c
+++ b/drivers/staging/comedi/comedi_buf.c
@@ -161,6 +161,30 @@ int comedi_buf_map_put(struct comedi_buf_map *bm)
return 1;
 }

+/* helper for "access" vm operation */
+int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
+ void *buf, int len, int write)
+{
+   unsigned int pgoff = offset & ~PAGE_MASK;
+   unsigned long pg = offset >> PAGE_SHIFT;
+   int done = 0;
+
+   while (done < len && pg < bm->n_pages) {
+   int l = min_t(int, len - done, PAGE_SIZE - pgoff);
+   void *b = bm->page_list[pg].virt_addr + pgoff;
+
+   if (write)
+   memcpy(b, buf, l);
+   else
+   memcpy(buf, b, l);
+   buf += l;
+   done += l;
+   pg++;
+   pgoff = 0;
+   }
+   return done;
+}
+
 /* returns s->async->buf_map and increments its kref refcount */
 struct comedi_buf_map *
 comedi_buf_map_from_subdev_get(struct comedi_subdevice *s)
diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 92d864fc08ac..2a8a39653c94 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2165,9 +2165,24 @@ static void comedi_vm_close(struct vm_area_struct *area)
comedi_buf_map_put(bm);
 }

+static int comedi_vm_access(struct vm_area_struct *vma, unsigned long addr,
+   void *buf, int len, int write)
+{
+   struct comedi_buf_map *bm = vma->vm_private_data;
+   unsigned long offset =
+   addr - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT);
+
+   if (len < 0)
+   return -EINVAL;
+   if (len > vma->vm_end - vma->vm_start)
+   len = vma->vm_end - vma->vm_start;


Actually, this limit isn't correct as it doesn't take the offset from 
`vma->vm_start` to `addr` into account.  I'll send another version of 
the patch to sort that out.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Order

2017-04-20 Thread Damian Colins

Hi ,

I would like to place an order for some items which I want to know the below :

Do you ship to Liechtenstein ?
Do you accept Credit Card payment 

Also send me your current product price list.
Thanks




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging : rtl8188eu : remove void function return

2017-04-20 Thread surenderpolsani

kernel coding style doesn't allow the return statement
in void function.

Signed-off-by: Surenderp 
---
Changes for v2:
corrected subject line as suggested
Changes for v3:
modified from line as suggested by Greg KH
placed a semicolon in label for fixing build error
---
 drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
index d04b7fb..428996e 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
@@ -165,7 +165,7 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter)
 skip_dm:
/*  Check GPIO to determine current RF on/off and Pbc status. */
/*  Check Hardware Radio ON/OFF or not */
-   return;
+   ;
 }
 
 void rtw_hal_dm_init(struct adapter *Adapter)
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Added paranthesis around complex define statements

2017-04-20 Thread Andriy Gelman

This is a patch to the ks_wlan_ioctl.h file that fixes paranthesis error
found by the checkpatch.pl tool

Signed-off-by: Andriy Gelman 
---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 53 +-
 1 file changed, 26 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 8e62b10..851f563 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream 11b/g wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -18,38 +18,38 @@
 /* SIOCIWFIRSTPRIV + 0 */
 /* former KS_WLAN_GET_DRIVER_VERSION   SIOCIWFIRSTPRIV + 1 */
 /* SIOCIWFIRSTPRIV + 2 */
-#define KS_WLAN_GET_FIRM_VERSION   SIOCIWFIRSTPRIV + 3
+#define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
-#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5
-#define KS_WLAN_SET_WPS_PROBE_REQ  SIOCIWFIRSTPRIV + 6
+#define KS_WLAN_SET_WPS_ENABLE  (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE  (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
-#define KS_WLAN_GET_EEPROM_CKSUM   SIOCIWFIRSTPRIV + 7
-#define KS_WLAN_SET_PREAMBLE   SIOCIWFIRSTPRIV + 8
-#define KS_WLAN_GET_PREAMBLE   SIOCIWFIRSTPRIV + 9
-#define KS_WLAN_SET_POWER_SAVE SIOCIWFIRSTPRIV + 10
-#define KS_WLAN_GET_POWER_SAVE SIOCIWFIRSTPRIV + 11
-#define KS_WLAN_SET_SCAN_TYPE  SIOCIWFIRSTPRIV + 12
-#define KS_WLAN_GET_SCAN_TYPE  SIOCIWFIRSTPRIV + 13
-#define KS_WLAN_SET_RX_GAINSIOCIWFIRSTPRIV + 14
-#define KS_WLAN_GET_RX_GAINSIOCIWFIRSTPRIV + 15
-#define KS_WLAN_HOSTT  SIOCIWFIRSTPRIV + 16/* unused */
+#define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
+#define KS_WLAN_SET_PREAMBLE   (SIOCIWFIRSTPRIV + 8)
+#define KS_WLAN_GET_PREAMBLE   (SIOCIWFIRSTPRIV + 9)
+#define KS_WLAN_SET_POWER_SAVE (SIOCIWFIRSTPRIV + 10)
+#define KS_WLAN_GET_POWER_SAVE (SIOCIWFIRSTPRIV + 11)
+#define KS_WLAN_SET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 12)
+#define KS_WLAN_GET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 13)
+#define KS_WLAN_SET_RX_GAIN(SIOCIWFIRSTPRIV + 14)
+#define KS_WLAN_GET_RX_GAIN(SIOCIWFIRSTPRIV + 15)
+#define KS_WLAN_HOSTT   (SIOCIWFIRSTPRIV + 16) /* unused */
 //#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV + 17
-#define KS_WLAN_SET_BEACON_LOSTSIOCIWFIRSTPRIV + 18
-#define KS_WLAN_GET_BEACON_LOSTSIOCIWFIRSTPRIV + 19
+#define KS_WLAN_SET_BEACON_LOST(SIOCIWFIRSTPRIV + 18)
+#define KS_WLAN_GET_BEACON_LOST(SIOCIWFIRSTPRIV + 19)
 
-#define KS_WLAN_SET_TX_GAINSIOCIWFIRSTPRIV + 20
-#define KS_WLAN_GET_TX_GAINSIOCIWFIRSTPRIV + 21
+#define KS_WLAN_SET_TX_GAIN(SIOCIWFIRSTPRIV + 20)
+#define KS_WLAN_GET_TX_GAIN(SIOCIWFIRSTPRIV + 21)
 
 /* for KS7010 */
-#define KS_WLAN_SET_PHY_TYPE   SIOCIWFIRSTPRIV + 22
-#define KS_WLAN_GET_PHY_TYPE   SIOCIWFIRSTPRIV + 23
-#define KS_WLAN_SET_CTS_MODE   SIOCIWFIRSTPRIV + 24
-#define KS_WLAN_GET_CTS_MODE   SIOCIWFIRSTPRIV + 25
+#define KS_WLAN_SET_PHY_TYPE   (SIOCIWFIRSTPRIV + 22)
+#define KS_WLAN_GET_PHY_TYPE   (SIOCIWFIRSTPRIV + 23)
+#define KS_WLAN_SET_CTS_MODE   (SIOCIWFIRSTPRIV + 24)
+#define KS_WLAN_GET_CTS_MODE   (SIOCIWFIRSTPRIV + 25)
 /* SIOCIWFIRSTPRIV + 26 */
 /* SIOCIWFIRSTPRIV + 27 */
-#define KS_WLAN_SET_SLEEP_MODE SIOCIWFIRSTPRIV + 28/* sleep mode */
-#define KS_WLAN_GET_SLEEP_MODE SIOCIWFIRSTPRIV + 29/* sleep mode */
+#define KS_WLAN_SET_SLEEP_MODE (SIOCIWFIRSTPRIV + 28)  /* sleep mode */
+#define KS_WLAN_GET_SLEEP_MODE (SIOCIWFIRSTPRIV + 29)  /* sleep mode */
 /* SIOCIWFIRSTPRIV + 30 */
 /* SIOCIWFIRSTPRIV + 31 */
 
@@ -59,8 +59,7 @@
 #include 
 
 int ks_wlan_read_config_file(struct ks_wlan_private *priv);
-int ks_wlan_setup_parameter(struct ks_wlan_private *priv,
-unsigned int commit_flag);
+int ks_wlan_setup_parameter(struct ks_wlan_private *priv, int commit_flag);
 
 #endif /* __KERNEL__ */
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Added paranthesis around complex define statements

2017-04-20 Thread Greg KH

On Fri, Apr 21, 2017 at 05:15:46AM +, Andriy Gelman wrote:
> This is a patch to the ks_wlan_ioctl.h file that fixes paranthesis error
> found by the checkpatch.pl tool

No, it also does other things :(

Also, please fix up the subject to look like other patches done for this
file/driver.

And fix the spelling mistake :)

> 
> Signed-off-by: Andriy Gelman 
> ---
>  drivers/staging/ks7010/ks_wlan_ioctl.h | 53 
> +-
>  1 file changed, 26 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
> b/drivers/staging/ks7010/ks_wlan_ioctl.h
> index 8e62b10..851f563 100644
> --- a/drivers/staging/ks7010/ks_wlan_ioctl.h
> +++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
> @@ -1,6 +1,6 @@
>  /*
>   *   Driver for KeyStream 11b/g wireless LAN
> - *   
> + *

This is not a () change :(

Please only do one type of thing in each patch.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

47 matches

Mail list logo