[PATCH linux-next] staging: vchiq_arm: coding style

[Sergiy Redko]

fix coding style: move brace to the line above

Signed-off-by: Sergiy Redko 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index 48984abc3854..ca896a518e15 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -797,8 +797,7 @@ int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T 
handle, short *peer_ve
 {
int32_t ret = -1;
SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
-   if (service)
-   {
+   if (service) {
VCHIQ_STATUS_T status;
 
status = vchiq_get_peer_version(service->handle, peer_version);
-- 
2.12.0

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

[PATCH v2 5/5] staging: rtl8712: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---

 v2:
   -Moved pcontext to the previous line

 drivers/staging/rtl8712/rtl8712_recv.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c 
b/drivers/staging/rtl8712/rtl8712_recv.c
index 20fe45a..266ffef 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -444,9 +444,9 @@ void r8712_rxcmd_event_hdl(struct _adapter *padapter, void 
*prxcmdbuf)
u16 cmd_len, drvinfo_sz;
struct recv_stat *prxstat;
 
-   poffset = (u8 *)prxcmdbuf;
+   poffset = prxcmdbuf;
voffset = *(__le32 *)poffset;
-   prxstat = (struct recv_stat *)prxcmdbuf;
+   prxstat = prxcmdbuf;
drvinfo_sz = (le32_to_cpu(prxstat->rxdw0) & 0x000f) >> 16;
drvinfo_sz <<= 3;
poffset += RXDESC_SIZE + drvinfo_sz;
@@ -634,8 +634,7 @@ static int recv_indicatepkt_reorder(struct _adapter 
*padapter,
 void r8712_reordering_ctrl_timeout_handler(void *pcontext)
 {
unsigned long irql;
-   struct recv_reorder_ctrl *preorder_ctrl =
-(struct recv_reorder_ctrl *)pcontext;
+   struct recv_reorder_ctrl *preorder_ctrl = pcontext;
struct _adapter *padapter = preorder_ctrl->padapter;
struct  __queue *ppending_recvframe_queue =
 &preorder_ctrl->pending_recvframe_queue;
@@ -976,7 +975,7 @@ int recv_func(struct _adapter *padapter, void *pcontext)
struct  __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
struct  mlme_priv   *pmlmepriv = &padapter->mlmepriv;
 
-   prframe = (union recv_frame *)pcontext;
+   prframe = pcontext;
orig_prframe = prframe;
pattrib = &prframe->u.hdr.attrib;
if (check_fwstate(pmlmepriv, WIFI_MP_STATE)) {
@@ -1124,7 +1123,7 @@ static int recvbuf2recvframe(struct _adapter *padapter, 
struct sk_buff *pskb)
 static void recv_tasklet(void *priv)
 {
struct sk_buff *pskb;
-   struct _adapter *padapter = (struct _adapter *)priv;
+   struct _adapter *padapter = priv;
struct recv_priv *precvpriv = &padapter->recvpriv;
 
while (NULL != (pskb = skb_dequeue(&precvpriv->rx_skb_queue))) {
-- 
2.7.4

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

Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

[Hillf Danton]

On March 03, 2017 5:45 AM Laura Abbott wrote: 
> 
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> + if (!new_table)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
> + if (ret) {
> + kfree(table);

Free new table?

> + return ERR_PTR(-ENOMEM);
> + }
> +
> + new_sg = new_table->sgl;
> + for_each_sg(table->sgl, sg, table->nents, i) {
> + memcpy(new_sg, sg, sizeof(*sg));
> + sg->dma_address = 0;
> + new_sg = sg_next(new_sg);
> + }
> +

Do we need a helper, sg_copy_table(dst_table, src_table)?

> + return new_table;
> +}
> +

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

[PATCH v2 4/5] staging: rts5208: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---

 v2:
   -Moved buf to the previous line.

 drivers/staging/rts5208/rtsx_transport.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 2379901..8b57e17 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -766,8 +766,7 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, 
void *buf, size_t len,
return -EIO;
 
if (use_sg) {
-   err = rtsx_transfer_sglist_adma(chip, card,
-   (struct scatterlist *)buf,
+   err = rtsx_transfer_sglist_adma(chip, card, buf,
use_sg, dma_dir, timeout);
} else {
err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
-- 
2.7.4

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

Re: [PATCH linux-next] staging: vchiq_arm: coding style

[Stefan Wahren]

Hi Sergiy,

Am 03.03.2017 um 09:05 schrieb Sergiy Redko:
> fix coding style: move brace to the line above

please make the subject of your patch more distinct. We get a lot of
coding style fixes for vchiq.

Btw it looks you missed to add Greg as staging maintainer.

>
> Signed-off-by: Sergiy Redko 
> ---
>  drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c 
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> index 48984abc3854..ca896a518e15 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> @@ -797,8 +797,7 @@ int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T 
> handle, short *peer_ve
>  {
>   int32_t ret = -1;
>   SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> - if (service)
> - {
> + if (service) {

Since you want to fix coding stlye i think it's better to leave an empty
line between the declaration and the if statement.

Stefan

>   VCHIQ_STATUS_T status;
>  
>   status = vchiq_get_peer_version(service->handle, peer_version);


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

Re: [PATCH] staging: speakup: replace simple_strtoul with kstrtou8

[Marcin Ciupak]

On Thu, Mar 02, 2017 at 04:17:12PM +0100, Samuel Thibault wrote:
> Marcin Ciupak, on jeu. 02 mars 2017 15:28:23 +0100, wrote:
> > -   int val;
> > +   int ret;
> >  
> > -   val = simple_strtoul(skip_spaces(start), &start, 10);
> > +   ret = kstrtou8(skip_spaces(start), 10, dest);
> 
> This is not the same, you need to have start properly move, since it's
> used below:
> 
> > if (*start == ',')
> > start++;
> > -   *dest = (u_char)val;
> > return start;
> 
> Samuel

You are right, start is not updated by kstrtou8 like it is by
simple_strtoul.

If I understand it correctly simple_strtoul cannot be replaced by
kstrtou8 here.

Please discard this patch.

Marcin

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

Re: [Outreachy kernel] [PATCH v2 4/5] staging: rts5208: Remove unnecessary cast on void pointer

[Julia Lawall]

When you send a v2 for a patch in a series, you need to send a v2 for all
of the patches in the series.

julia

On Fri, 3 Mar 2017, simran singhal wrote:

> The following Coccinelle script was used to detect this:
> @r@
> expression x;
> void* e;
> type T;
> identifier f;
> @@
> (
>   *((T *)e)
> |
>   ((T *)x)[...]
> |
>   ((T*)x)->f
> |
> - (T*)
>   e
> )
>
> Signed-off-by: simran singhal 
> ---
>
>  v2:
>-Moved buf to the previous line.
>
>  drivers/staging/rts5208/rtsx_transport.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rts5208/rtsx_transport.c 
> b/drivers/staging/rts5208/rtsx_transport.c
> index 2379901..8b57e17 100644
> --- a/drivers/staging/rts5208/rtsx_transport.c
> +++ b/drivers/staging/rts5208/rtsx_transport.c
> @@ -766,8 +766,7 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, 
> void *buf, size_t len,
>   return -EIO;
>
>   if (use_sg) {
> - err = rtsx_transfer_sglist_adma(chip, card,
> - (struct scatterlist *)buf,
> + err = rtsx_transfer_sglist_adma(chip, card, buf,
>   use_sg, dma_dir, timeout);
>   } else {
>   err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170303083130.GA25123%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> 
> 
> Now that we call dma_map in the dma_buf API callbacks there is no need
> to use the existing cache APIs. Remove the sync ioctl and the existing
> bad dma_sync calls. Explicit caching can be handled with the dma_buf
> sync API.
> 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/ion/ion-ioctl.c |  5 
>  drivers/staging/android/ion/ion.c   | 40 
> -
>  drivers/staging/android/ion/ion_carveout_heap.c |  6 
>  drivers/staging/android/ion/ion_chunk_heap.c|  6 
>  drivers/staging/android/ion/ion_page_pool.c |  3 --
>  drivers/staging/android/ion/ion_system_heap.c   |  5 
>  6 files changed, 65 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
> b/drivers/staging/android/ion/ion-ioctl.c
> index 5b2e93f..f820d77 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
> unsigned long arg)
>   data.handle.handle = handle->id;
>   break;
>   }
> - case ION_IOC_SYNC:
> - {
> - ret = ion_sync_for_device(client, data.fd.fd);
> - break;
> - }

You missed the case ION_IOC_SYNC: in compat_ion.c.

While at it: Should we also remove the entire custom_ioctl infrastructure?
It's entirely unused afaict, and for a pure buffer allocator I don't see
any need to have custom ioctl.

More code to remove potentially:
- The entire compat ioctl stuff - would be an abi break, but I guess if we
  pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
  would allow us to remove compat_ion.c entirely.

- ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
  still need to be able to import anything. All the cache flushing/mapping
  is done through dma-buf ops/ioctls.


With the case in compat_ion.c also removed, this patch is:

Reviewed-by: Daniel Vetter 

>   case ION_IOC_CUSTOM:
>   {
>   if (!dev->custom_ioctl)
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 8eef1d7..c3c316f 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
> *attachment,
>   free_duped_table(table);
>  }
>  
> -void ion_pages_sync_for_device(struct device *dev, struct page *page,
> -size_t size, enum dma_data_direction dir)
> -{
> - struct scatterlist sg;
> -
> - sg_init_table(&sg, 1);
> - sg_set_page(&sg, page, size, 0);
> - /*
> -  * This is not correct - sg_dma_address needs a dma_addr_t that is valid
> -  * for the targeted device, but this works on the currently targeted
> -  * hardware.
> -  */
> - sg_dma_address(&sg) = page_to_phys(page);
> - dma_sync_sg_for_device(dev, &sg, 1, dir);
> -}
> -
>  static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>  {
>   struct ion_buffer *buffer = dmabuf->priv;
> @@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct 
> ion_client *client, int fd)
>  }
>  EXPORT_SYMBOL(ion_import_dma_buf_fd);
>  
> -int ion_sync_for_device(struct ion_client *client, int fd)
> -{
> - struct dma_buf *dmabuf;
> - struct ion_buffer *buffer;
> -
> - dmabuf = dma_buf_get(fd);
> - if (IS_ERR(dmabuf))
> - return PTR_ERR(dmabuf);
> -
> - /* if this memory came from ion */
> - if (dmabuf->ops != &dma_buf_ops) {
> - pr_err("%s: can not sync dmabuf from another exporter\n",
> -__func__);
> - dma_buf_put(dmabuf);
> - return -EINVAL;
> - }
> - buffer = dmabuf->priv;
> -
> - dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
> -buffer->sg_table->nents, DMA_BIDIRECTIONAL);
> - dma_buf_put(dmabuf);
> - return 0;
> -}
> -
>  int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
>  {
>   struct ion_device *dev = client->dev;
> diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
> b/drivers/staging/android/ion/ion_carveout_heap.c
> index 9bf8e98..e0e360f 100644
> --- a/drivers/staging/android/ion/ion_carveout_heap.c
> +++ b/drivers/staging/android/ion/ion_carveout_heap.c
> @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer 
> *buffer)
>  
>   ion_heap_buffer_zero(buffer);
>  
> - if (ion_buffer_cached(buffer))
> - dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> -DMA_BIDIRECTIONAL);
> -
>   ion_carveout_free(heap, paddr, buffer->size);
>   sg_free_table(table);
>   kfree(table);
> @@ -128,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct 
> ion_platform_heap *heap_data)
>   page = pfn_to_

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.
> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.
> 
> Feedback appreciated.

Imo looks all good. And I just realized that cross-checking with the TODO,
the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.

Otherwise I looked through the patches, looks all really reasonable.

Wrt merging, my experience from destaging the android syncpt stuff was
that merging the patches through the staging tree lead to lots of
cross-tree issues with the gpu folks wanting to use that. Ion will
probably run into similar things, so I'd propose we pull these cleanup
patches and the eventual de-staging in throught drm. Yes that defacto
means I'm also volunteering myself a bit :-)

In the end we could put it all into drivers/gpu/ion or something like
that.

Thoughts? Greg?
-Daniel


> 
> Thanks,
> Laura
> 
> [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> 
> Laura Abbott (12):
>   staging: android: ion: Remove dmap_cnt
>   staging: android: ion: Remove alignment from allocation field
>   staging: android: ion: Duplicate sg_table
>   staging: android: ion: Call dma_map_sg for syncing and mapping
>   staging: android: ion: Remove page faulting support
>   staging: android: ion: Remove crufty cache support
>   staging: android: ion: Remove old platform support
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Make Ion heaps selectable
>   staging; android: ion: Enumerate all available heaps
> 
>  drivers/base/dma-contiguous.c  |   5 +-
>  drivers/staging/android/ion/Kconfig|  51 ++--
>  drivers/staging/android/ion/Makefile   |  14 +-
>  drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
>  drivers/staging/android/ion/hisilicon/Makefile |   1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
>  drivers/staging/android/ion/ion-ioctl.c|   6 -
>  drivers/staging/android/ion/ion.c  | 282 
> ++---
>  drivers/staging/android/ion/ion.h  |   5 +-
>  drivers/staging/android/ion/ion_carveout_heap.c|  16 +-
>  drivers/staging/android/ion/ion_chunk_heap.c   |  15 +-
>  drivers/staging/android/ion/ion_cma_heap.c | 102 ++--
>  drivers/staging/android/ion/ion_dummy_driver.c | 156 
>  drivers/staging/android/ion/ion_enumerate.c|  89 +++
>  drivers/staging/android/ion/ion_of.c   | 184 --
>  drivers/staging/android/ion/ion_of.h   |  37 ---
>  drivers/staging/android/ion/ion_page_pool.c|   3 -
>  drivers/staging/android/ion/ion_priv.h |  57 -
>  drivers/staging/android/ion/ion_system_heap.c  |  14 +-
>  drivers/staging/android/ion/tegra/Makefile |   1 -
>  drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
>  include/linux/cma.h|   6 +-
>  mm/cma.c   |  25 +-
>  mm/cma.h   |   1 +
>  mm/cma_debug.c |   2 +-
>  25 files changed, 312 insertions(+), 958 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>  delet

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> > 
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keeping Ion since it works reasonablly well.
> > This series does what should be the final clean ups for it to possibly be
> > moved out of staging.
> > 
> > This includes the following:
> > - Some general clean up and removal of features that never got a lot of use
> >   as far as I can tell.
> > - Fixing up the caching. This is the series I proposed back in December[2]
> >   but never heard any feedback on. It will certainly break existing
> >   applications that rely on the implicit caching. I'd rather make an effort
> >   to move to a model that isn't going directly against the establishement
> >   though.
> > - Fixing up the platform support. The devicetree approach was never well
> >   recieved by DT maintainers. The proposal here is to think of Ion less as
> >   specifying requirements and more of a framework for exposing memory to
> >   userspace.
> > - CMA allocations now happen without the need of a dummy device structure.
> >   This fixes a bunch of the reasons why I attempted to add devicetree
> >   support before.
> > 
> > I've had problems getting feedback in the past so if I don't hear any major
> > objections I'm going to send out with the RFC dropped to be picked up.
> > The only reason there isn't a patch to come out of staging is to discuss any
> > other changes to the ABI people might want. Once this comes out of staging,
> > I really don't want to mess with the ABI.
> > 
> > Feedback appreciated.
> 
> Imo looks all good. And I just realized that cross-checking with the TODO,
> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.

One more for the todo: Add rst/sphinx documentation for ION. That's also
always a good excuse to review the internal interfaces and exported
symbols. But we can do that after destaging ...
-Daniel

> 
> Otherwise I looked through the patches, looks all really reasonable.
> 
> Wrt merging, my experience from destaging the android syncpt stuff was
> that merging the patches through the staging tree lead to lots of
> cross-tree issues with the gpu folks wanting to use that. Ion will
> probably run into similar things, so I'd propose we pull these cleanup
> patches and the eventual de-staging in throught drm. Yes that defacto
> means I'm also volunteering myself a bit :-)
> 
> In the end we could put it all into drivers/gpu/ion or something like
> that.
> 
> Thoughts? Greg?
> -Daniel
> 
> 
> > 
> > Thanks,
> > Laura
> > 
> > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> > 
> > Laura Abbott (12):
> >   staging: android: ion: Remove dmap_cnt
> >   staging: android: ion: Remove alignment from allocation field
> >   staging: android: ion: Duplicate sg_table
> >   staging: android: ion: Call dma_map_sg for syncing and mapping
> >   staging: android: ion: Remove page faulting support
> >   staging: android: ion: Remove crufty cache support
> >   staging: android: ion: Remove old platform support
> >   cma: Store a name in the cma structure
> >   cma: Introduce cma_for_each_area
> >   staging: android: ion: Use CMA APIs directly
> >   staging: android: ion: Make Ion heaps selectable
> >   staging; android: ion: Enumerate all available heaps
> > 
> >  drivers/base/dma-contiguous.c  |   5 +-
> >  drivers/staging/android/ion/Kconfig|  51 ++--
> >  drivers/staging/android/ion/Makefile   |  14 +-
> >  drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
> >  drivers/staging/android/ion/hisilicon/Makefile |   1 -
> >  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
> >  drivers/staging/android/ion/ion-ioctl.c|   6 -
> >  drivers/staging/android/ion/ion.c  | 282 
> > ++---
> >  drivers/staging/android/ion/ion.h  |   5 +-
> >  drivers/staging/android/ion/ion_carveout_heap.c|  16 +-
> >  drivers/staging/android/ion/ion_chunk_heap.c   |  15 +-
> >  drivers/staging/android/ion/ion_cma_heap.c | 102 ++--
> >  drivers/staging/android/ion/ion_dummy_driver.c | 156 
> >  drivers/staging/android/ion/ion_enumerate.c|  89 +++
> >  drivers/staging/android/ion/ion_of.c   | 184 --
> >  drivers/staging/android/ion/ion_of.h   |  37 ---
> >  drivers/staging/android/ion/ion_page_pool.c|   3 -
> >  drivers/staging/android/ion/ion_priv.h |  57 -
> >  drivers/staging/android/ion/ion_system_heap.c  |  14 +-
> >  drivers/staging/android/ion/tegra/Makefile |   1 -
> >  drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
> >  include/linux/cma.h|   6 +-
> >  mm/cma

Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote:
> 
> Currently, all heaps are compiled in all the time. In switching to
> a better platform model, let's allow these to be compiled out for good
> measure.
> 
> Signed-off-by: Laura Abbott 

I'm not the biggest fan of making everything Kconfig-selectable. And the
#ifdef stuff doesn't look all that pretty. If we'd also use this
opportunity to split each heap into their own file I think this patch here
would be a lot more useful.

Anyway, no real opinion from me on this, just an idea.
-Daniel

> ---
>  drivers/staging/android/ion/Kconfig| 32 
>  drivers/staging/android/ion/Makefile   |  8 +++--
>  drivers/staging/android/ion/ion_priv.h | 53 
> --
>  3 files changed, 87 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index 0c91b2b..2e97990 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -17,3 +17,35 @@ config ION_TEST
> Choose this option to create a device that can be used to test the
> kernel and device side ION functions.
>  
> +config ION_SYSTEM_HEAP
> + bool "Ion system heap"
> + depends on ION
> + help
> +   Choose this option to enable the Ion system heap. The system heap
> +   is backed by pages from the buddy allocator. If in doubt, say Y.
> +
> +config ION_CARVEOUT_HEAP
> + bool "Ion carveout heap support"
> + depends on ION
> + help
> +   Choose this option to enable carveout heaps with Ion. Carveout heaps
> +   are backed by memory reserved from the system. Allocation times are
> +   typically faster at the cost of memory not being used. Unless you
> +   know your system has these regions, you should say N here.
> +
> +config ION_CHUNK_HEAP
> + bool "Ion chunk heap support"
> + depends on ION
> + help
> +  Choose this option to enable chunk heaps with Ion. This heap is
> +   similar in function the carveout heap but memory is broken down
> +   into smaller chunk sizes, typically corresponding to a TLB size.
> +   Unless you know your system has these regions, you should say N here.
> +
> +config ION_CMA_HEAP
> + bool "Ion CMA heap support"
> + depends on ION && CMA
> + help
> +   Choose this option to enable CMA heaps with Ion. This heap is backed
> +   by the Contiguous Memory Allocator (CMA). If your system has these
> +   regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile 
> b/drivers/staging/android/ion/Makefile
> index 9457090..eef022b 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,8 @@
> -obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
> - ion_page_pool.o ion_system_heap.o \
> - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> +obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
> +obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
> +obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
> +obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>  obj-$(CONFIG_ION_TEST) += ion_test.o
>  ifdef CONFIG_COMPAT
>  obj-$(CONFIG_ION) += compat_ion.o
> diff --git a/drivers/staging/android/ion/ion_priv.h 
> b/drivers/staging/android/ion/ion_priv.h
> index b09bc7c..6eafe0d 100644
> --- a/drivers/staging/android/ion/ion_priv.h
> +++ b/drivers/staging/android/ion/ion_priv.h
> @@ -369,21 +369,68 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
>   * heaps as appropriate.
>   */
>  
> +
>  struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
>  void ion_heap_destroy(struct ion_heap *heap);
> +
> +#ifdef CONFIG_ION_SYSTEM_HEAP
>  struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
>  void ion_system_heap_destroy(struct ion_heap *heap);
> -
>  struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap 
> *heap);
>  void ion_system_contig_heap_destroy(struct ion_heap *heap);
> -
> +#else
> +static inline struct ion_heap * ion_system_heap_create(
> + struct ion_platform_heap *unused)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_system_heap_destroy(struct ion_heap *heap) { }
> +
> +static inline struct ion_heap *ion_system_contig_heap_create(
> + struct ion_platform_heap *heap)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +
> +static inline void ion_system_contig_heap_destroy(struct ion_heap *heap) { }
> +#endif
> +
> +#ifdef CONFIG_ION_CARVEOUT_HEAP
>  struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap 
> *heap_data);
>  void ion_carveout_heap_destroy(struct ion_heap *heap);
> -
> +#else
> +static inline struct ion_heap *ion_carveout_heap_create(
> + struct ion_platform_heap *heap_data)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +stati

Re: [RFC PATCH 12/12] staging; android: ion: Enumerate all available heaps

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:44PM -0800, Laura Abbott wrote:
> 
> Practiaclly speaking, most Ion heaps are either going to be available
> all the time (system heaps) or found based off of the reserved-memory
> node. Parse the CMA and reserved-memory nodes to assign the heaps.
> 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/ion/Makefile|  2 +-
>  drivers/staging/android/ion/ion_enumerate.c | 89 
> +
>  2 files changed, 90 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
> 
> diff --git a/drivers/staging/android/ion/Makefile 
> b/drivers/staging/android/ion/Makefile
> index eef022b..4ebf655 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,4 +1,4 @@
> -obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
> +obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o ion_enumerate.o
>  obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
>  obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
>  obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
> diff --git a/drivers/staging/android/ion/ion_enumerate.c 
> b/drivers/staging/android/ion/ion_enumerate.c
> new file mode 100644
> index 000..21344c7
> --- /dev/null
> +++ b/drivers/staging/android/ion/ion_enumerate.c
> @@ -0,0 +1,89 @@
> +#include 
> +#include 
> +
> +#include "ion.h"
> +#include "ion_priv.h"
> +
> +static struct ion_device *internal_dev;
> +static int heap_id = 2;
> +
> +static int ion_add_system_heap(void)
> +{
> +#ifdef CONFIG_ION_SYSTEM_HEAP
> + struct ion_platform_heap pheap;
> + struct ion_heap *heap;
> +
> + pheap.type = ION_HEAP_TYPE_SYSTEM;
> + pheap.id = heap_id++;
> + pheap.name = "ion_system_heap";
> +
> + heap = ion_heap_create(&pheap);
> + if (!heap)
> + return -ENODEV;
> +
> + ion_device_add_heap(internal_dev, heap);
> +#endif
> + return 0;
> +}
> +
> +static int ion_add_system_contig_heap(void)
> +{
> +#ifdef CONFIG_ION_SYSTEM_HEAP
> + struct ion_platform_heap pheap;
> + struct ion_heap *heap;
> +
> + pheap.type = ION_HEAP_TYPE_SYSTEM_CONTIG;
> + pheap.id = heap_id++;
> + pheap.name = "ion_system_contig_heap";
> +
> + heap = ion_heap_create(&pheap);
> + if (!heap)
> + return -ENODEV;
> +
> + ion_device_add_heap(internal_dev, heap);
> +#endif
> + return 0;
> +}
> +
> +#ifdef CONFIG_ION_CMA_HEAP
> +int __ion_add_cma_heaps(struct cma *cma, void *data)
> +{
> + struct ion_heap *heap;
> + struct ion_platform_heap pheap;
> +
> + pheap.type = ION_HEAP_TYPE_DMA;
> + pheap.id = heap_id++;
> + pheap.name = cma_get_name(cma);
> + pheap.priv = cma;
> +
> + heap = ion_heap_create(&pheap);
> + if (!heap)
> + return -ENODEV;
> +
> + ion_device_add_heap(internal_dev, heap);
> + return 0;
> +}
> +#endif
> +
> +
> +static int ion_add_cma_heaps(void)
> +{
> +#ifdef CONFIG_ION_CMA_HEAP
> + cma_for_each_area(__ion_add_cma_heaps, NULL);
> +#endif
> + return 0;
> +}
> +
> +int ion_enumerate(void)
> +{
> + internal_dev = ion_device_create(NULL);
> + if (IS_ERR(internal_dev))
> + return PTR_ERR(internal_dev);
> +
> + ion_add_system_heap();
> + ion_add_system_contig_heap();
> +
> + ion_add_cma_heaps();
> + return 0;
> +}
> +subsys_initcall(ion_enumerate);

If we'd split each heap into its own file I think we could just put
initcalls into each of them, avoiding the need for so much #ifdef all
over.

That should also help when we add more specific heaps like the SMA one.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 07/12] staging: android: ion: Remove old platform support

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:39PM -0800, Laura Abbott wrote:
> 
> Device specific platform support has been haphazard for Ion. There have
> been several independent attempts and there are still objections to
> what bindings exist right now. Just remove everything for a fresh start.
> 
> Signed-off-by: Laura Abbott 

It looks like with this we could remove a lot of the EXPORT_SYMBOL
statements from the ion code. Might be good to follow up with a patch to
clean those out.

Otherwise a patch that only removes code, what's not to love!

Reviewed-by: Daniel Vetter 

> ---
>  drivers/staging/android/ion/Kconfig|  35 
>  drivers/staging/android/ion/Makefile   |   6 -
>  drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
>  drivers/staging/android/ion/hisilicon/Makefile |   1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
>  drivers/staging/android/ion/ion_dummy_driver.c | 156 -
>  drivers/staging/android/ion/ion_of.c   | 184 
> -
>  drivers/staging/android/ion/ion_of.h   |  37 -
>  drivers/staging/android/ion/tegra/Makefile |   1 -
>  drivers/staging/android/ion/tegra/tegra_ion.c  |  80 -
>  10 files changed, 618 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.h
>  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
> 
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index c8fb413..0c91b2b 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -17,38 +17,3 @@ config ION_TEST
> Choose this option to create a device that can be used to test the
> kernel and device side ION functions.
>  
> -config ION_DUMMY
> - bool "Dummy Ion driver"
> - depends on ION
> - help
> -   Provides a dummy ION driver that registers the
> -   /dev/ion device and some basic heaps. This can
> -   be used for testing the ION infrastructure if
> -   one doesn't have access to hardware drivers that
> -   use ION.
> -
> -config ION_TEGRA
> - tristate "Ion for Tegra"
> - depends on ARCH_TEGRA && ION
> - help
> -   Choose this option if you wish to use ion on an nVidia Tegra.
> -
> -config ION_HISI
> - tristate "Ion for Hisilicon"
> - depends on ARCH_HISI && ION
> - select ION_OF
> - help
> -   Choose this option if you wish to use ion on Hisilicon Platform.
> -
> -source "drivers/staging/android/ion/hisilicon/Kconfig"
> -
> -config ION_OF
> - bool "Devicetree support for Ion"
> - depends on ION && OF_ADDRESS
> - help
> -   Provides base support for defining Ion heaps in devicetree
> -   and setting them up. Also includes functions for platforms
> -   to parse the devicetree and expand for their own custom
> -   extensions
> -
> -   If using Ion and devicetree, you should say Y here
> diff --git a/drivers/staging/android/ion/Makefile 
> b/drivers/staging/android/ion/Makefile
> index 5d630a0..9457090 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -5,9 +5,3 @@ obj-$(CONFIG_ION_TEST) += ion_test.o
>  ifdef CONFIG_COMPAT
>  obj-$(CONFIG_ION) += compat_ion.o
>  endif
> -
> -obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
> -obj-$(CONFIG_ION_TEGRA) += tegra/
> -obj-$(CONFIG_ION_HISI) += hisilicon/
> -obj-$(CONFIG_ION_OF) += ion_of.o
> -
> diff --git a/drivers/staging/android/ion/hisilicon/Kconfig 
> b/drivers/staging/android/ion/hisilicon/Kconfig
> deleted file mode 100644
> index 2b4bd07..000
> --- a/drivers/staging/android/ion/hisilicon/Kconfig
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -config HI6220_ION
> -bool "Hi6220 ION Driver"
> -depends on ARCH_HISI && ION
> -help
> -  Build the Hisilicon Hi6220 ion driver.
> diff --git a/drivers/staging/android/ion/hisilicon/Makefile 
> b/drivers/staging/android/ion/hisilicon/Makefile
> deleted file mode 100644
> index 2a89414..000
> --- a/drivers/staging/android/ion/hisilicon/Makefile
> +++ /dev/null
> @@ -1 +0,0 @@
> -obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
> diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
> b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
> deleted file mode 100644
> index 0de7897..000
> --- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
> +++ /dev/null
> @@ -1,113 +0,0 @@
> -/*
> - * Hisilicon Hi6220 ION Driver
> - *
> - * Copyright (c) 2015 Hisilicon Limited.
> - *
> - * Author: C

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Dan Carpenter]

On Thu, Mar 02, 2017 at 01:44:36PM -0800, Laura Abbott wrote:
>  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment 
> *attachment,
>   enum dma_data_direction direction)
>  {
>   struct dma_buf *dmabuf = attachment->dmabuf;
>   struct ion_buffer *buffer = dmabuf->priv;
> + struct sg_table *table;
> + int ret;
> +
> + /*
> +  * TODO: Need to sync wrt CPU or device completely owning?
> +  */
> +
> + table = dup_sg_table(buffer->sg_table);
>  
> - ion_buffer_sync_for_device(buffer, attachment->dev, direction);
> - return dup_sg_table(buffer->sg_table);
> + if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> + direction)){
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> +err:
> + free_duped_table(table);
> + return ERR_PTR(ret);

ret isn't initialized on success.

>  }
>  

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

Re: [PATCH 2/2] Fix endiannes error

[Dan Carpenter]

These patches look good but you need to resend with a correct subsystem
prefix in the subject.  It should be:

[PATCH 2/2] Staging: wlan-ng: Fix endiannes error

Hm...  Also "endiannes" doesn't look like correct spelling.  Just say
"endian".

On Thu, Mar 02, 2017 at 09:30:12PM +0100, Adrien Descamps wrote:
> sparse report fixed:
> drivers/staging//wlan-ng//hfa384x_usb.c:3517:35: warning: restricted __be64 
> degrades to integer
> drivers/staging//wlan-ng//hfa384x_usb.c:3517:33: warning: incorrect type in 
> assignment (different base types)
> drivers/staging//wlan-ng//hfa384x_usb.c:3517:33:expected restricted 
> __be64 [usertype] mactime
> drivers/staging//wlan-ng//hfa384x_usb.c:3517:33:got unsigned long long
> 
> Computation on the value should be done when in machine format, not in big 
> endian format.
> Compile tested only.

Generally we like to put the "Compile tested only" bit under the ---
cut off so that our patches look more confident and authoritative.  ;)

> 
> Signed-off-by: Adrien Descamps 
> ---

Put it here.

>  drivers/staging/wlan-ng/hfa384x_usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 


regards,
dan carpenter

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

[PATCH v3 0/5] Fixed compilation error

[simran singhal]

Fixed compilation warning in lustre/lustre/llite/range_lock.c

simran singhal (5):
  staging: nvec: Remove unnecessary cast on void pointer
  staging: lustre: Remove unnecessary cast on void pointer
  staging: lustre: lustre: Remove unnecessary cast on void pointer
  staging: rts5208: Remove unnecessary cast on void pointer
  staging: rtl8712: Remove unnecessary cast on void pointer

 drivers/staging/lustre/lustre/llite/range_lock.c |  2 +-
 drivers/staging/lustre/lustre/lmv/lmv_obd.c  |  4 ++--
 drivers/staging/lustre/lustre/mgc/mgc_request.c  |  2 +-
 drivers/staging/nvec/nvec_kbd.c  |  2 +-
 drivers/staging/rtl8712/rtl8712_recv.c   | 11 +--
 drivers/staging/rts5208/rtsx_transport.c |  3 +--
 6 files changed, 11 insertions(+), 13 deletions(-)

-- 
2.7.4

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

[PATCH v3 2/5] staging: lustre: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/lustre/lustre/lmv/lmv_obd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c 
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 271e189..09b46924 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -640,7 +640,7 @@ static int lmv_fid2path(struct obd_export *exp, int len, 
void *karg,
int remote_gf_size = 0;
int rc;
 
-   gf = (struct getinfo_fid2path *)karg;
+   gf = karg;
tgt = lmv_find_target(lmv, &gf->gf_fid);
if (IS_ERR(tgt))
return PTR_ERR(tgt);
@@ -657,7 +657,7 @@ static int lmv_fid2path(struct obd_export *exp, int len, 
void *karg,
struct getinfo_fid2path *ori_gf;
char *ptr;
 
-   ori_gf = (struct getinfo_fid2path *)karg;
+   ori_gf = karg;
if (strlen(ori_gf->gf_path) +
strlen(gf->gf_path) > ori_gf->gf_pathlen) {
rc = -EOVERFLOW;
-- 
2.7.4

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

[PATCH v3 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/lustre/lustre/llite/range_lock.c | 2 +-
 drivers/staging/lustre/lustre/mgc/mgc_request.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/range_lock.c 
b/drivers/staging/lustre/lustre/llite/range_lock.c
index 14148a0..161391b 100644
--- a/drivers/staging/lustre/lustre/llite/range_lock.c
+++ b/drivers/staging/lustre/lustre/llite/range_lock.c
@@ -174,7 +174,7 @@ void range_unlock(struct range_lock_tree *tree, struct 
range_lock *lock)
  */
 static enum interval_iter range_lock_cb(struct interval_node *node, void *arg)
 {
-   struct range_lock *lock = (struct range_lock *)arg;
+   struct range_lock *lock = arg;
struct range_lock *overlap = node2rangelock(node);
 
lock->rl_blocking_ranges += overlap->rl_lock_count + 1;
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index 6a76605..8ca0a04 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -1050,7 +1050,7 @@ static int mgc_set_info_async(const struct lu_env *env, 
struct obd_export *exp,
sptlrpc_flavor2name(&cli->cl_flvr_mgc,
str, sizeof(str));
LCONSOLE_ERROR("asking sptlrpc flavor %s to MGS but 
currently %s is in use\n",
-  (char *)val, str);
+  val, str);
rc = -EPERM;
}
return rc;
-- 
2.7.4

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

[PATCH v3 4/5] staging: rts5208: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/rts5208/rtsx_transport.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 2379901..8b57e17 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -766,8 +766,7 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, 
void *buf, size_t len,
return -EIO;
 
if (use_sg) {
-   err = rtsx_transfer_sglist_adma(chip, card,
-   (struct scatterlist *)buf,
+   err = rtsx_transfer_sglist_adma(chip, card, buf,
use_sg, dma_dir, timeout);
} else {
err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
-- 
2.7.4

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

[PATCH v3 1/5] staging: nvec: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:

@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/nvec/nvec_kbd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/nvec/nvec_kbd.c b/drivers/staging/nvec/nvec_kbd.c
index e881e6b..a01f486 100644
--- a/drivers/staging/nvec/nvec_kbd.c
+++ b/drivers/staging/nvec/nvec_kbd.c
@@ -58,7 +58,7 @@ static int nvec_keys_notifier(struct notifier_block *nb,
  unsigned long event_type, void *data)
 {
int code, state;
-   unsigned char *msg = (unsigned char *)data;
+   unsigned char *msg = data;
 
if (event_type == NVEC_KB_EVT) {
int _size = (msg[0] & (3 << 5)) >> 5;
-- 
2.7.4

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

[PATCH v3 5/5] staging: rtl8712: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8712/rtl8712_recv.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c 
b/drivers/staging/rtl8712/rtl8712_recv.c
index 20fe45a..266ffef 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -444,9 +444,9 @@ void r8712_rxcmd_event_hdl(struct _adapter *padapter, void 
*prxcmdbuf)
u16 cmd_len, drvinfo_sz;
struct recv_stat *prxstat;
 
-   poffset = (u8 *)prxcmdbuf;
+   poffset = prxcmdbuf;
voffset = *(__le32 *)poffset;
-   prxstat = (struct recv_stat *)prxcmdbuf;
+   prxstat = prxcmdbuf;
drvinfo_sz = (le32_to_cpu(prxstat->rxdw0) & 0x000f) >> 16;
drvinfo_sz <<= 3;
poffset += RXDESC_SIZE + drvinfo_sz;
@@ -634,8 +634,7 @@ static int recv_indicatepkt_reorder(struct _adapter 
*padapter,
 void r8712_reordering_ctrl_timeout_handler(void *pcontext)
 {
unsigned long irql;
-   struct recv_reorder_ctrl *preorder_ctrl =
-(struct recv_reorder_ctrl *)pcontext;
+   struct recv_reorder_ctrl *preorder_ctrl = pcontext;
struct _adapter *padapter = preorder_ctrl->padapter;
struct  __queue *ppending_recvframe_queue =
 &preorder_ctrl->pending_recvframe_queue;
@@ -976,7 +975,7 @@ int recv_func(struct _adapter *padapter, void *pcontext)
struct  __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
struct  mlme_priv   *pmlmepriv = &padapter->mlmepriv;
 
-   prframe = (union recv_frame *)pcontext;
+   prframe = pcontext;
orig_prframe = prframe;
pattrib = &prframe->u.hdr.attrib;
if (check_fwstate(pmlmepriv, WIFI_MP_STATE)) {
@@ -1124,7 +1123,7 @@ static int recvbuf2recvframe(struct _adapter *padapter, 
struct sk_buff *pskb)
 static void recv_tasklet(void *priv)
 {
struct sk_buff *pskb;
-   struct _adapter *padapter = (struct _adapter *)priv;
+   struct _adapter *padapter = priv;
struct recv_priv *precvpriv = &padapter->recvpriv;
 
while (NULL != (pskb = skb_dequeue(&precvpriv->rx_skb_queue))) {
-- 
2.7.4

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

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

[Sakari Ailus]

On Thu, Mar 02, 2017 at 03:07:21PM -0800, Steve Longerbeam wrote:
> 
> 
> On 03/02/2017 07:53 AM, Sakari Ailus wrote:
> >Hi Steve,
> >
> >On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote:
> >>Add a new FRAME_TIMEOUT event to signal that a video capture or
> >>output device has timed out waiting for reception or transmit
> >>completion of a video frame.
> >>
> >>Signed-off-by: Steve Longerbeam 
> >>---
> >> Documentation/media/uapi/v4l/vidioc-dqevent.rst | 5 +
> >> Documentation/media/videodev2.h.rst.exceptions  | 1 +
> >> include/uapi/linux/videodev2.h  | 1 +
> >> 3 files changed, 7 insertions(+)
> >>
> >>diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
> >>b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> >>index 8d663a7..dd77d9b 100644
> >>--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> >>+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> >>@@ -197,6 +197,11 @@ call.
> >>the regions changes. This event has a struct
> >>:c:type:`v4l2_event_motion_det`
> >>associated with it.
> >>+* - ``V4L2_EVENT_FRAME_TIMEOUT``
> >>+  - 7
> >>+  - This event is triggered when the video capture or output device
> >>+   has timed out waiting for the reception or transmit completion of
> >>+   a frame of video.
> >
> >As you're adding a new interface, I suppose you have an implementation
> >around. How do you determine what that timeout should be?
> 
> The imx-media driver sets the timeout to 1 second, or 30 frame
> periods at 30 fps.

The frame rate is not necessarily constant during streaming. It may well
change as a result of lighting conditions. I wouldn't add an event for this:
this is unreliable and 30 times the frame period is an arbitrary value
anyway. No other drivers do this either.

The user space is generally in control of the frame period (or on some
devices it could be the sensor, too, but *not* the CSI-2 receiver driver),
so detecting the condition of not receiving any frames is more reliably done
in the user space --- if needed.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/4] Fix multiple checkpatch issues

[Dan Carpenter]

Looks good.  Thanks.

regards,
dan carpenter

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

Re: [PATCH v2 3/6] staging: wlan-ng: Fix sparse warnings in hfa384x_usb.c

[Dan Carpenter]

Ugh...  No.  This is totally wrong.

Please review how endianness works.

regards,
dan carpenter


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

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Eric Engestrom]

On Friday, 2017-03-03 14:04:26 +0300, Dan Carpenter wrote:
> On Thu, Mar 02, 2017 at 01:44:36PM -0800, Laura Abbott wrote:
> >  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment 
> > *attachment,
> > enum dma_data_direction direction)
> >  {
> > struct dma_buf *dmabuf = attachment->dmabuf;
> > struct ion_buffer *buffer = dmabuf->priv;
> > +   struct sg_table *table;
> > +   int ret;
> > +
> > +   /*
> > +* TODO: Need to sync wrt CPU or device completely owning?
> > +*/
> > +
> > +   table = dup_sg_table(buffer->sg_table);
> >  
> > -   ion_buffer_sync_for_device(buffer, attachment->dev, direction);
> > -   return dup_sg_table(buffer->sg_table);
> > +   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> > +   direction)){
> > +   ret = -ENOMEM;
> > +   goto err;
> > +   }

Actually, I think `ret` should be left uninitialised on success,
what's really missing is this return before the `err:` label:

+   return table;


> > +
> > +err:
> > +   free_duped_table(table);
> > +   return ERR_PTR(ret);
> 
> ret isn't initialized on success.
> 
> >  }
> >  
> 
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-03 11:27 GMT+01:00 Daniel Vetter :
> On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
>> > Hi,
>> >
>> > There's been some recent discussions[1] about Ion-like frameworks. There's
>> > apparently interest in just keeping Ion since it works reasonablly well.
>> > This series does what should be the final clean ups for it to possibly be
>> > moved out of staging.
>> >
>> > This includes the following:
>> > - Some general clean up and removal of features that never got a lot of use
>> >   as far as I can tell.
>> > - Fixing up the caching. This is the series I proposed back in December[2]
>> >   but never heard any feedback on. It will certainly break existing
>> >   applications that rely on the implicit caching. I'd rather make an effort
>> >   to move to a model that isn't going directly against the establishement
>> >   though.
>> > - Fixing up the platform support. The devicetree approach was never well
>> >   recieved by DT maintainers. The proposal here is to think of Ion less as
>> >   specifying requirements and more of a framework for exposing memory to
>> >   userspace.
>> > - CMA allocations now happen without the need of a dummy device structure.
>> >   This fixes a bunch of the reasons why I attempted to add devicetree
>> >   support before.
>> >
>> > I've had problems getting feedback in the past so if I don't hear any major
>> > objections I'm going to send out with the RFC dropped to be picked up.
>> > The only reason there isn't a patch to come out of staging is to discuss 
>> > any
>> > other changes to the ABI people might want. Once this comes out of staging,
>> > I really don't want to mess with the ABI.
>> >
>> > Feedback appreciated.
>>
>> Imo looks all good. And I just realized that cross-checking with the TODO,
>> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.
>
> One more for the todo: Add rst/sphinx documentation for ION. That's also
> always a good excuse to review the internal interfaces and exported
> symbols. But we can do that after destaging ...
> -Daniel

Removing alignment looks good for me but why not also remove it from
struct ion_allocation_data since the field become useless ?

Also does someone use ion_user_handle_t handle ? Can we directly export
a dma-buf file descriptor ?

Benjamin

>
>>
>> Otherwise I looked through the patches, looks all really reasonable.
>>
>> Wrt merging, my experience from destaging the android syncpt stuff was
>> that merging the patches through the staging tree lead to lots of
>> cross-tree issues with the gpu folks wanting to use that. Ion will
>> probably run into similar things, so I'd propose we pull these cleanup
>> patches and the eventual de-staging in throught drm. Yes that defacto
>> means I'm also volunteering myself a bit :-)
>>
>> In the end we could put it all into drivers/gpu/ion or something like
>> that.
>>
>> Thoughts? Greg?
>> -Daniel
>>
>>
>> >
>> > Thanks,
>> > Laura
>> >
>> > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
>> > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
>> >
>> > Laura Abbott (12):
>> >   staging: android: ion: Remove dmap_cnt
>> >   staging: android: ion: Remove alignment from allocation field
>> >   staging: android: ion: Duplicate sg_table
>> >   staging: android: ion: Call dma_map_sg for syncing and mapping
>> >   staging: android: ion: Remove page faulting support
>> >   staging: android: ion: Remove crufty cache support
>> >   staging: android: ion: Remove old platform support
>> >   cma: Store a name in the cma structure
>> >   cma: Introduce cma_for_each_area
>> >   staging: android: ion: Use CMA APIs directly
>> >   staging: android: ion: Make Ion heaps selectable
>> >   staging; android: ion: Enumerate all available heaps
>> >
>> >  drivers/base/dma-contiguous.c  |   5 +-
>> >  drivers/staging/android/ion/Kconfig|  51 ++--
>> >  drivers/staging/android/ion/Makefile   |  14 +-
>> >  drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
>> >  drivers/staging/android/ion/hisilicon/Makefile |   1 -
>> >  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
>> >  drivers/staging/android/ion/ion-ioctl.c|   6 -
>> >  drivers/staging/android/ion/ion.c  | 282 
>> > ++---
>> >  drivers/staging/android/ion/ion.h  |   5 +-
>> >  drivers/staging/android/ion/ion_carveout_heap.c|  16 +-
>> >  drivers/staging/android/ion/ion_chunk_heap.c   |  15 +-
>> >  drivers/staging/android/ion/ion_cma_heap.c | 102 ++--
>> >  drivers/staging/android/ion/ion_dummy_driver.c | 156 
>> >  drivers/staging/android/ion/ion_enumerate.c|  89 +++
>> >  drivers/staging/android/ion/ion_of.c   | 184 --
>> >  drivers/staging/android/ion/ion_of.h   |  37 ---
>> >  drivers/staging/android

[PATCH v3 0/3] x86/vdso: Add Hyper-V TSC page clocksource support

[Vitaly Kuznetsov]

Hi,

merge window is about to close so I hope it's OK to make another try here.

Changes since v2:
- Add explicit READ_ONCE() to not rely on 'volatile' [Andy Lutomirski]
- rdtsc() -> rdtsc_ordered() [Andy Lutomirski]
- virt_rmb() -> smp_rmb() [Thomas Gleixner, Andy Lutomirski]

Thomas, Andy, it seems the only blocker for the series was the ambiguity with
TSC page read algorithm. I contacted Microsoft (through K. Y.) and asked what
we should do when we see 'seq=0'. The answer is:

"I have confirmed that the only invalid value is 0 (notwithstanding what the
spec says). I have asked the Spec to be updated and the current code we have
is correct - it treats 0 as the only invalid value. The invalid value indicates
that the TSC page cannot be used as a time source and a different source is to
be used and this state is going to persist and so looping is not an option."

I agree it would be wiser to have two invalid values - one for 'try again' and
another for permanent failure in case it is needed. But this is not the case.

So I keep my algorithm untouched.

I can see two more reasons for us to keep it:
1) It is what we already have in kernel.
2) It is what Windows does (see the disassembly in c35b82ef0294.

Original description:

Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol
defined by the hypervisor is different from VCLOCK_PVCLOCK. Implemented the
required support. Simple sysbench test shows the following results:

Before:
# time sysbench --test=memory --max-requests=50 run
...
real1m22.618s
user0m50.193s
sys 0m32.268s

After:
# time sysbench --test=memory --max-requests=50 run
...
real0m47.241s
user0m47.117s
sys 0m0.008s

Vitaly Kuznetsov (3):
  x86/hyperv: implement hv_get_tsc_page()
  x86/hyperv: move TSC reading method to asm/mshyperv.h
  x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

 arch/x86/entry/vdso/vclock_gettime.c  | 24 +++
 arch/x86/entry/vdso/vdso-layout.lds.S |  3 +-
 arch/x86/entry/vdso/vdso2c.c  |  3 ++
 arch/x86/entry/vdso/vma.c |  7 +
 arch/x86/hyperv/hv_init.c | 48 +
 arch/x86/include/asm/clocksource.h|  3 +-
 arch/x86/include/asm/mshyperv.h   | 58 +++
 arch/x86/include/asm/vdso.h   |  1 +
 drivers/hv/Kconfig|  3 ++
 9 files changed, 114 insertions(+), 36 deletions(-)

-- 
2.9.3

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

[PATCH v3 1/3] x86/hyperv: implement hv_get_tsc_page()

[Vitaly Kuznetsov]

To use Hyper-V TSC page clocksource from vDSO we need to make tsc_pg
available. Implement hv_get_tsc_page() and add CONFIG_HYPERV_TSCPAGE to
make #ifdef-s simple.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/hyperv/hv_init.c   | 9 +++--
 arch/x86/include/asm/mshyperv.h | 8 
 drivers/hv/Kconfig  | 3 +++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index db64baf0..6b64cae 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -27,10 +27,15 @@
 #include 
 
 
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
 
 static struct ms_hyperv_tsc_page *tsc_pg;
 
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
+{
+   return tsc_pg;
+}
+
 static u64 read_hv_clock_tsc(struct clocksource *arg)
 {
u64 current_tick;
@@ -139,7 +144,7 @@ void hyperv_init(void)
/*
 * Register Hyper-V specific clocksource.
 */
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_HYPERV_TSCPAGE
if (ms_hyperv.features & HV_X64_MSR_REFERENCE_TSC_AVAILABLE) {
union hv_x64_msr_hypercall_contents tsc_msr;
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 7c9c895..d324dce 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -176,4 +176,12 @@ void hyperv_report_panic(struct pt_regs *regs);
 bool hv_is_hypercall_page_setup(void);
 void hyperv_cleanup(void);
 #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
+#else
+static inline struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
+{
+   return NULL;
+}
+#endif
 #endif
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 0403b51..c29cd53 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -7,6 +7,9 @@ config HYPERV
  Select this option to run Linux as a Hyper-V client operating
  system.
 
+config HYPERV_TSCPAGE
+   def_bool HYPERV && X86_64
+
 config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
depends on HYPERV && CONNECTOR && NLS
-- 
2.9.3

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

[PATCH v3 3/3] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Vitaly Kuznetsov]

Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol
defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the
required support by adding hvclock_page VVAR.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/entry/vdso/vclock_gettime.c  | 24 
 arch/x86/entry/vdso/vdso-layout.lds.S |  3 ++-
 arch/x86/entry/vdso/vdso2c.c  |  3 +++
 arch/x86/entry/vdso/vma.c |  7 +++
 arch/x86/hyperv/hv_init.c |  3 +++
 arch/x86/include/asm/clocksource.h|  3 ++-
 arch/x86/include/asm/vdso.h   |  1 +
 7 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index 9d4d6e1..fa8dbfc 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,11 @@ extern u8 pvclock_page
__attribute__((visibility("hidden")));
 #endif
 
+#ifdef CONFIG_HYPERV_TSCPAGE
+extern u8 hvclock_page
+   __attribute__((visibility("hidden")));
+#endif
+
 #ifndef BUILD_VDSO32
 
 notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
@@ -141,6 +147,20 @@ static notrace u64 vread_pvclock(int *mode)
return last;
 }
 #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+static notrace u64 vread_hvclock(int *mode)
+{
+   const struct ms_hyperv_tsc_page *tsc_pg =
+   (const struct ms_hyperv_tsc_page *)&hvclock_page;
+   u64 current_tick = hv_read_tsc_page(tsc_pg);
+
+   if (current_tick != U64_MAX)
+   return current_tick;
+
+   *mode = VCLOCK_NONE;
+   return 0;
+}
+#endif
 
 notrace static u64 vread_tsc(void)
 {
@@ -173,6 +193,10 @@ notrace static inline u64 vgetsns(int *mode)
else if (gtod->vclock_mode == VCLOCK_PVCLOCK)
cycles = vread_pvclock(mode);
 #endif
+#ifdef CONFIG_HYPERV_TSCPAGE
+   else if (gtod->vclock_mode == VCLOCK_HVCLOCK)
+   cycles = vread_hvclock(mode);
+#endif
else
return 0;
v = (cycles - gtod->cycle_last) & gtod->mask;
diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S 
b/arch/x86/entry/vdso/vdso-layout.lds.S
index a708aa9..8ebb4b6 100644
--- a/arch/x86/entry/vdso/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/vdso-layout.lds.S
@@ -25,7 +25,7 @@ SECTIONS
 * segment.
 */
 
-   vvar_start = . - 2 * PAGE_SIZE;
+   vvar_start = . - 3 * PAGE_SIZE;
vvar_page = vvar_start;
 
/* Place all vvars at the offsets in asm/vvar.h. */
@@ -36,6 +36,7 @@ SECTIONS
 #undef EMIT_VVAR
 
pvclock_page = vvar_start + PAGE_SIZE;
+   hvclock_page = vvar_start + 2 * PAGE_SIZE;
 
. = SIZEOF_HEADERS;
 
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 491020b..0780a44 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -74,6 +74,7 @@ enum {
sym_vvar_page,
sym_hpet_page,
sym_pvclock_page,
+   sym_hvclock_page,
sym_VDSO_FAKE_SECTION_TABLE_START,
sym_VDSO_FAKE_SECTION_TABLE_END,
 };
@@ -82,6 +83,7 @@ const int special_pages[] = {
sym_vvar_page,
sym_hpet_page,
sym_pvclock_page,
+   sym_hvclock_page,
 };
 
 struct vdso_sym {
@@ -94,6 +96,7 @@ struct vdso_sym required_syms[] = {
[sym_vvar_page] = {"vvar_page", true},
[sym_hpet_page] = {"hpet_page", true},
[sym_pvclock_page] = {"pvclock_page", true},
+   [sym_hvclock_page] = {"hvclock_page", true},
[sym_VDSO_FAKE_SECTION_TABLE_START] = {
"VDSO_FAKE_SECTION_TABLE_START", false
},
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 572cee3..71f5d3a 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_X86_64)
 unsigned int __read_mostly vdso64_enabled = 1;
@@ -120,6 +121,12 @@ static int vvar_fault(const struct vm_special_mapping *sm,
vmf->address,
__pa(pvti) >> PAGE_SHIFT);
}
+   } else if (sym_offset == image->sym_hvclock_page) {
+   struct ms_hyperv_tsc_page *tsc_pg = hv_get_tsc_page();
+
+   if (tsc_pg && vclock_was_used(VCLOCK_HVCLOCK))
+   ret = vm_insert_pfn(vma, vmf->address,
+   vmalloc_to_pfn(tsc_pg));
}
 
if (ret == 0 || ret == -EBUSY)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 63dd00e..d08ac5e 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -132,6 +132,9 @@ void hyperv_init(void)
tsc_msr.guest_physical_address = vmalloc_to_pfn(tsc_pg);
 
wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr.as_uint64);
+
+   hyperv_cs_tsc.archdata.vcl

[PATCH v3 2/3] x86/hyperv: move TSC reading method to asm/mshyperv.h

[Vitaly Kuznetsov]

As a preparation to making Hyper-V TSC page suitable for vDSO move
the TSC page reading logic to asm/mshyperv.h. While on it, do the
following
- Document the reading algorithm.
- Simplify the code a bit.
- Add explicit READ_ONCE() to not rely on 'volatile'.
- Add explicit barriers to prevent re-ordering (we need to read sequence
  strictly before and after)
- Use mul_u64_u64_shr() instead of assembly, gcc generates a single 'mul'
  instruction on x86_64 anyway.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/hyperv/hv_init.c   | 36 -
 arch/x86/include/asm/mshyperv.h | 50 +
 2 files changed, 54 insertions(+), 32 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 6b64cae..63dd00e 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -38,39 +38,11 @@ struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
 
 static u64 read_hv_clock_tsc(struct clocksource *arg)
 {
-   u64 current_tick;
+   u64 current_tick = hv_read_tsc_page(tsc_pg);
+
+   if (current_tick == U64_MAX)
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
 
-   if (tsc_pg->tsc_sequence != 0) {
-   /*
-* Use the tsc page to compute the value.
-*/
-
-   while (1) {
-   u64 tmp;
-   u32 sequence = tsc_pg->tsc_sequence;
-   u64 cur_tsc;
-   u64 scale = tsc_pg->tsc_scale;
-   s64 offset = tsc_pg->tsc_offset;
-
-   rdtscll(cur_tsc);
-   /* current_tick = ((cur_tsc *scale) >> 64) + offset */
-   asm("mulq %3"
-   : "=d" (current_tick), "=a" (tmp)
-   : "a" (cur_tsc), "r" (scale));
-
-   current_tick += offset;
-   if (tsc_pg->tsc_sequence == sequence)
-   return current_tick;
-
-   if (tsc_pg->tsc_sequence != 0)
-   continue;
-   /*
-* Fallback using MSR method.
-*/
-   break;
-   }
-   }
-   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
return current_tick;
 }
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index d324dce..4ff25436 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -178,6 +178,56 @@ void hyperv_cleanup(void);
 #endif
 #ifdef CONFIG_HYPERV_TSCPAGE
 struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
+static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
+{
+   u64 scale, offset, current_tick, cur_tsc;
+   u32 sequence;
+
+   /*
+* The protocol for reading Hyper-V TSC page is specified in Hypervisor
+* Top-Level Functional Specification ver. 3.0 and above. To get the
+* reference time we must do the following:
+* - READ ReferenceTscSequence
+*   A special '0' value indicates the time source is unreliable and we
+*   need to use something else. The currently published specification
+*   versions (up to 4.0b) contain a mistake and wrongly claim '-1'
+*   instead of '0' as the special value, see commit c35b82ef0294.
+* - ReferenceTime =
+*((RDTSC() * ReferenceTscScale) >> 64) + ReferenceTscOffset
+* - READ ReferenceTscSequence again. In case its value has changed
+*   since our first reading we need to discard ReferenceTime and repeat
+*   the whole sequence as the hypervisor was updating the page in
+*   between.
+*/
+   while (1) {
+   sequence = READ_ONCE(tsc_pg->tsc_sequence);
+   if (!sequence)
+   break;
+   /*
+* Make sure we read sequence before we read other values from
+* TSC page.
+*/
+   smp_rmb();
+
+   scale = READ_ONCE(tsc_pg->tsc_scale);
+   offset = READ_ONCE(tsc_pg->tsc_offset);
+   cur_tsc = rdtsc_ordered();
+
+   current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
+
+   /*
+* Make sure we read sequence after we read all other values
+* from TSC page.
+*/
+   smp_rmb();
+
+   if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
+   return current_tick;
+   }
+
+   return U64_MAX;
+}
+
 #else
 static inline struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
 {
-- 
2.9.3

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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Michal Hocko]

On Thu 02-03-17 13:44:32, Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.
> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.

Could you recapitulate concerns preventing the code being merged
normally rather than through the staging tree and how they were
addressed?
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

[Andy Shevchenko]

On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote:
> Hi Mark,
> 
> On 03/02/2017 11:39 AM, Mark Rutland wrote:
> > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote:

> > > 
> > > +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \
> > >   ccp-ops.o \
> > >   ccp-dev-v3.o \
> > >   ccp-dev-v5.o \
> > > - ccp-platform.o \
> > >   ccp-dmaengine.o
> > 
> > It looks like ccp-platform.c has morphed into sp-platform.c (judging
> > by
> > the compatible string and general shape of the code), and the
> > original
> > ccp-platform.c is no longer built.
> > 
> > Shouldn't ccp-platform.c be deleted by this patch?
> > 
> 
> Good catch. Both ccp-platform.c and ccp-pci.c should have been
> deleted 
> by this patch. I missed deleting it, will fix in next rev.

Don't forget to use -M -C when preparing / sending patches.

-- 
Andy Shevchenko 
Intel Finland Oy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: rtl8192u: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index f0fba81..3ca7f7d 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -918,7 +918,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 
int i;
struct ieee80211_rxb *rxb = NULL;
-   // cheat the the hdr type
+   // cheat the hdr type
hdr = (struct rtl_80211_hdr_4addr *)skb->data;
stats = &ieee->stats;
 
-- 
2.7.4

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

[PATCH 3/3] staging: unisys: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1d54190..e7b04b6 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -778,7 +778,7 @@ write_vbus_dev_info(struct visorchannel *chan,
 /*
  * fix_vbus_dev_info() - for a child device just created on a client bus, fill
  *   in information about the driver that is controlling
- *   this device into the the appropriate slot within the
+ *   this device into the appropriate slot within the
  *   vbus channel of the bus instance
  * @visordev: struct visor_device for the desired device
  */
-- 
2.7.4

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

Re: [Outreachy kernel] [PATCH 1/3] staging: wlan-ng: Replace "the the " with "the"

[Julia Lawall]

You should have a cover letter for the series.

julia

On Fri, 3 Mar 2017, simran singhal wrote:

> This patch replace "the the " with "the". The replacement couldn't be
> automated because sometimes the first "the" was meant to be another
> word.
>
> Signed-off-by: simran singhal 
> ---
>  drivers/staging/wlan-ng/prism2sta.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wlan-ng/prism2sta.c 
> b/drivers/staging/wlan-ng/prism2sta.c
> index 82d3a70..3ef85ac 100644
> --- a/drivers/staging/wlan-ng/prism2sta.c
> +++ b/drivers/staging/wlan-ng/prism2sta.c
> @@ -1310,7 +1310,7 @@ void prism2sta_processing_defer(struct work_struct 
> *data)
>   /* This one indicates that the MAC has decided to and
>* successfully completed a change to another AP.  We
>* should probably implement a reassociation indication
> -  * in response to this one.  I'm thinking that the the
> +  * in response to this one.  I'm thinking that the
>* p80211 layer needs to be notified in case of
>* buffering/queueing issues.  User mode also needs to be
>* notified so that any BSS dependent elements can be
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1488554140-28805-1-git-send-email-singhalsimran0%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: wlan-ng: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 82d3a70..3ef85ac 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1310,7 +1310,7 @@ void prism2sta_processing_defer(struct work_struct *data)
/* This one indicates that the MAC has decided to and
 * successfully completed a change to another AP.  We
 * should probably implement a reassociation indication
-* in response to this one.  I'm thinking that the the
+* in response to this one.  I'm thinking that the
 * p80211 layer needs to be notified in case of
 * buffering/queueing issues.  User mode also needs to be
 * notified so that any BSS dependent elements can be
-- 
2.7.4

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

[PATCH v2 1/3] staging: wlan-ng: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 82d3a70..3ef85ac 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1310,7 +1310,7 @@ void prism2sta_processing_defer(struct work_struct *data)
/* This one indicates that the MAC has decided to and
 * successfully completed a change to another AP.  We
 * should probably implement a reassociation indication
-* in response to this one.  I'm thinking that the the
+* in response to this one.  I'm thinking that the
 * p80211 layer needs to be notified in case of
 * buffering/queueing issues.  User mode also needs to be
 * notified so that any BSS dependent elements can be
-- 
2.7.4

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

[PATCH v2 1/3] staging: wlan-ng: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 82d3a70..3ef85ac 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1310,7 +1310,7 @@ void prism2sta_processing_defer(struct work_struct *data)
/* This one indicates that the MAC has decided to and
 * successfully completed a change to another AP.  We
 * should probably implement a reassociation indication
-* in response to this one.  I'm thinking that the the
+* in response to this one.  I'm thinking that the
 * p80211 layer needs to be notified in case of
 * buffering/queueing issues.  User mode also needs to be
 * notified so that any BSS dependent elements can be
-- 
2.7.4

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

[PATCH v2 0/3] Replace "the the " with "the"

[simran singhal]

This patch series replace "the the " with "the" in various drivers.

v2:
  -Adding cover-letter for the series.

simran singhal (3):
  staging: wlan-ng: Replace "the the " with "the"
  staging: rtl8192u: Replace "the the " with "the"
  staging: unisys: Replace "the the " with "the"

 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 2 +-
 drivers/staging/wlan-ng/prism2sta.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[PATCH v2 2/3] staging: rtl8192u: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index f0fba81..3ca7f7d 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -918,7 +918,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 
int i;
struct ieee80211_rxb *rxb = NULL;
-   // cheat the the hdr type
+   // cheat the hdr type
hdr = (struct rtl_80211_hdr_4addr *)skb->data;
stats = &ieee->stats;
 
-- 
2.7.4

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

[PATCH v2 3/3] staging: unisys: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1d54190..e7b04b6 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -778,7 +778,7 @@ write_vbus_dev_info(struct visorchannel *chan,
 /*
  * fix_vbus_dev_info() - for a child device just created on a client bus, fill
  *   in information about the driver that is controlling
- *   this device into the the appropriate slot within the
+ *   this device into the appropriate slot within the
  *   vbus channel of the bus instance
  * @visordev: struct visor_device for the desired device
  */
-- 
2.7.4

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

Re: [Outreachy kernel] Re: [PATCH v2 0/3] Replace "the the " with "the"

[Julia Lawall]

On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote:

> Please ignore this patch as on this wrong version is written.

What is wrong?

julia

>
> On Friday, March 3, 2017 at 9:06:52 PM UTC+5:30, SIMRAN SINGHAL wrote:
>   Please ignore this patch as on this wrong version is written.
>
>   On Friday, March 3, 2017 at 9:05:05 PM UTC+5:30, SIMRAN SINGHAL
>   wrote:
> This patch series replace "the the " with "the" in
> various drivers.
>
> v2:
>   -Adding cover-letter for the series.
>
> simran singhal (3):
>   staging: wlan-ng: Replace "the the " with "the"
>   staging: rtl8192u: Replace "the the " with "the"
>   staging: unisys: Replace "the the " with "the"
>
>  drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c |
> 2 +-
>  drivers/staging/unisys/visorbus/visorbus_main.c   |
> 2 +-
>  drivers/staging/wlan-ng/prism2sta.c               |
> 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/1c412adb-4f88-47e2-aa29-
> 016e62fc882a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 0/3] Replace "the the " with "the"

[simran singhal]

This patch series replace "the the " with "the" in various drivers. 

v1: 
  -Adding cover-letter for the series. 

simran singhal (3):
  staging: wlan-ng: Replace "the the " with "the"
  staging: rtl8192u: Replace "the the " with "the"
  staging: unisys: Replace "the the " with "the"

 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 2 +-
 drivers/staging/wlan-ng/prism2sta.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[PATCH v1 3/3] staging: unisys: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1d54190..e7b04b6 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -778,7 +778,7 @@ write_vbus_dev_info(struct visorchannel *chan,
 /*
  * fix_vbus_dev_info() - for a child device just created on a client bus, fill
  *   in information about the driver that is controlling
- *   this device into the the appropriate slot within the
+ *   this device into the appropriate slot within the
  *   vbus channel of the bus instance
  * @visordev: struct visor_device for the desired device
  */
-- 
2.7.4

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

[PATCH v1 1/3] staging: wlan-ng: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 82d3a70..3ef85ac 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1310,7 +1310,7 @@ void prism2sta_processing_defer(struct work_struct *data)
/* This one indicates that the MAC has decided to and
 * successfully completed a change to another AP.  We
 * should probably implement a reassociation indication
-* in response to this one.  I'm thinking that the the
+* in response to this one.  I'm thinking that the
 * p80211 layer needs to be notified in case of
 * buffering/queueing issues.  User mode also needs to be
 * notified so that any BSS dependent elements can be
-- 
2.7.4

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

[PATCH v1 2/3] staging: rtl8192u: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index f0fba81..3ca7f7d 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -918,7 +918,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 
int i;
struct ieee80211_rxb *rxb = NULL;
-   // cheat the the hdr type
+   // cheat the hdr type
hdr = (struct rtl_80211_hdr_4addr *)skb->data;
stats = &ieee->stats;
 
-- 
2.7.4

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

[PATCH] staging: speakup: else is not generally useful after a break or return

[Arushi Singhal]

fixed checkpatch.pl warning: else is not generally useful after a break
or return.
Removed the else without affecting the logic.
Dead code is also eliminated.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/keyhelp.c | 53 ++-
 1 file changed, 19 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/speakup/keyhelp.c 
b/drivers/staging/speakup/keyhelp.c
index 4e6e5daba50c..ad3efded37c1 100644
--- a/drivers/staging/speakup/keyhelp.c
+++ b/drivers/staging/speakup/keyhelp.c
@@ -176,43 +176,28 @@ int spk_handle_help(struct vc_data *vc, u_char type, 
u_char ch, u_short key)
synth_printf("%s\n", spk_msg_get(MSG_HELP_INFO));
build_key_data(); /* rebuild each time in case new mapping */
return 1;
-   } else {
-   name = NULL;
-   if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
-   synth_printf("%s\n",
-spk_msg_get(MSG_KEYNAMES_START + key - 1));
-   return 1;
-   }
-   for (i = 0; funcvals[i] != 0 && !name; i++) {
-   if (ch == funcvals[i])
-   name = spk_msg_get(MSG_FUNCNAMES_START + i);
-   }
-   if (!name)
-   return -1;
-   kp = spk_our_keys[key] + 1;
-   for (i = 0; i < nstates; i++) {
-   if (ch == kp[i])
-   break;
-   }
-   key += (state_tbl[i] << 8);
-   say_key(key);
-   synth_printf(spk_msg_get(MSG_KEYDESC), name);
-   synth_printf("\n");
-   return 1;
}
-   name = spk_msg_get(MSG_FUNCNAMES_START + cur_item);
-   func = funcvals[cur_item];
-   synth_printf("%s", name);
-   if (key_offsets[func] == 0) {
-   synth_printf(" %s\n", spk_msg_get(MSG_IS_UNASSIGNED));
+
+   name = NULL;
+   if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
+   synth_printf("%s\n",
+spk_msg_get(MSG_KEYNAMES_START + key - 1));
return 1;
}
-   p_keys = key_data + key_offsets[func];
-   for (n = 0; p_keys[n]; n++) {
-   val = p_keys[n];
-   if (n > 0)
-   synth_printf("%s ", spk_msg_get(MSG_DISJUNCTION));
-   say_key(val);
+   for (i = 0; funcvals[i] != 0 && !name; i++) {
+   if (ch == funcvals[i])
+   name = spk_msg_get(MSG_FUNCNAMES_START + i);
+   }
+   if (!name)
+   return -1;
+   kp = spk_our_keys[key] + 1;
+   for (i = 0; i < nstates; i++) {
+   if (ch == kp[i])
+   break;
}
+   key += (state_tbl[i] << 8);
+   say_key(key);
+   synth_printf(spk_msg_get(MSG_KEYDESC), name);
+   synth_printf("\n");
return 1;
 }
-- 
2.11.0

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

[PATCH v3 2/3] staging: rtl8192u: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index f0fba81..3ca7f7d 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -918,7 +918,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 
int i;
struct ieee80211_rxb *rxb = NULL;
-   // cheat the the hdr type
+   // cheat the hdr type
hdr = (struct rtl_80211_hdr_4addr *)skb->data;
stats = &ieee->stats;
 
-- 
2.7.4

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

[PATCH v3 3/3] staging: unisys: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1d54190..e7b04b6 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -778,7 +778,7 @@ write_vbus_dev_info(struct visorchannel *chan,
 /*
  * fix_vbus_dev_info() - for a child device just created on a client bus, fill
  *   in information about the driver that is controlling
- *   this device into the the appropriate slot within the
+ *   this device into the appropriate slot within the
  *   vbus channel of the bus instance
  * @visordev: struct visor_device for the desired device
  */
-- 
2.7.4

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

[PATCH v3 1/3] staging: wlan-ng: Replace "the the " with "the"

[simran singhal]

This patch replace "the the " with "the". The replacement couldn't be
automated because sometimes the first "the" was meant to be another
word.

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 82d3a70..3ef85ac 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1310,7 +1310,7 @@ void prism2sta_processing_defer(struct work_struct *data)
/* This one indicates that the MAC has decided to and
 * successfully completed a change to another AP.  We
 * should probably implement a reassociation indication
-* in response to this one.  I'm thinking that the the
+* in response to this one.  I'm thinking that the
 * p80211 layer needs to be notified in case of
 * buffering/queueing issues.  User mode also needs to be
 * notified so that any BSS dependent elements can be
-- 
2.7.4

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

[PATCH v3 0/3] Replace "the the " with "the"

[simran singhal]

This patch series replace "the the " with "the" in various drivers.

v3:
  -Resend the complete patch series.


simran singhal (3):
  staging: wlan-ng: Replace "the the " with "the"
  staging: rtl8192u: Replace "the the " with "the"
  staging: unisys: Replace "the the " with "the"

 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 2 +-
 drivers/staging/wlan-ng/prism2sta.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

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

Re: [Outreachy kernel] [PATCH] staging: speakup: else is not generally useful after a break or return

[Julia Lawall]

On Fri, 3 Mar 2017, Arushi Singhal wrote:

> fixed checkpatch.pl warning: else is not generally useful after a break
> or return.
> Removed the else without affecting the logic.
> Dead code is also eliminated.

The chhange is not correct.  There is a big chain of if/else if.  The if
(type == KT_LATIN) can reach the code at the end of the file.

julia

>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/keyhelp.c | 53 
> ++-
>  1 file changed, 19 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/staging/speakup/keyhelp.c 
> b/drivers/staging/speakup/keyhelp.c
> index 4e6e5daba50c..ad3efded37c1 100644
> --- a/drivers/staging/speakup/keyhelp.c
> +++ b/drivers/staging/speakup/keyhelp.c
> @@ -176,43 +176,28 @@ int spk_handle_help(struct vc_data *vc, u_char type, 
> u_char ch, u_short key)
>   synth_printf("%s\n", spk_msg_get(MSG_HELP_INFO));
>   build_key_data(); /* rebuild each time in case new mapping */
>   return 1;
> - } else {
> - name = NULL;
> - if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
> - synth_printf("%s\n",
> -  spk_msg_get(MSG_KEYNAMES_START + key - 1));
> - return 1;
> - }
> - for (i = 0; funcvals[i] != 0 && !name; i++) {
> - if (ch == funcvals[i])
> - name = spk_msg_get(MSG_FUNCNAMES_START + i);
> - }
> - if (!name)
> - return -1;
> - kp = spk_our_keys[key] + 1;
> - for (i = 0; i < nstates; i++) {
> - if (ch == kp[i])
> - break;
> - }
> - key += (state_tbl[i] << 8);
> - say_key(key);
> - synth_printf(spk_msg_get(MSG_KEYDESC), name);
> - synth_printf("\n");
> - return 1;
>   }
> - name = spk_msg_get(MSG_FUNCNAMES_START + cur_item);
> - func = funcvals[cur_item];
> - synth_printf("%s", name);
> - if (key_offsets[func] == 0) {
> - synth_printf(" %s\n", spk_msg_get(MSG_IS_UNASSIGNED));
> +
> + name = NULL;
> + if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
> + synth_printf("%s\n",
> +  spk_msg_get(MSG_KEYNAMES_START + key - 1));
>   return 1;
>   }
> - p_keys = key_data + key_offsets[func];
> - for (n = 0; p_keys[n]; n++) {
> - val = p_keys[n];
> - if (n > 0)
> - synth_printf("%s ", spk_msg_get(MSG_DISJUNCTION));
> - say_key(val);
> + for (i = 0; funcvals[i] != 0 && !name; i++) {
> + if (ch == funcvals[i])
> + name = spk_msg_get(MSG_FUNCNAMES_START + i);
> + }
> + if (!name)
> + return -1;
> + kp = spk_our_keys[key] + 1;
> + for (i = 0; i < nstates; i++) {
> + if (ch == kp[i])
> + break;
>   }
> + key += (state_tbl[i] << 8);
> + say_key(key);
> + synth_printf(spk_msg_get(MSG_KEYDESC), name);
> + synth_printf("\n");
>   return 1;
>  }
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/2017030317.GA23744%40arushi-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 0/5] Fixed compilation error

[Joe Perches]

On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote:
> Fixed compilation warning in lustre/lustre/llite/range_lock.c

Really?  What compilation warning was removed?

> simran singhal (5):
>   staging: nvec: Remove unnecessary cast on void pointer
>   staging: lustre: Remove unnecessary cast on void pointer
>   staging: lustre: lustre: Remove unnecessary cast on void pointer
>   staging: rts5208: Remove unnecessary cast on void pointer
>   staging: rtl8712: Remove unnecessary cast on void pointer

What compiler warns about unnecessary casts?

>  drivers/staging/lustre/lustre/llite/range_lock.c |  2 +-
>  drivers/staging/lustre/lustre/lmv/lmv_obd.c  |  4 ++--
>  drivers/staging/lustre/lustre/mgc/mgc_request.c  |  2 +-
>  drivers/staging/nvec/nvec_kbd.c  |  2 +-
>  drivers/staging/rtl8712/rtl8712_recv.c   | 11 +--
>  drivers/staging/rts5208/rtsx_transport.c |  3 +--
>  6 files changed, 11 insertions(+), 13 deletions(-)
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the"

[Julia Lawall]

On Fri, 3 Mar 2017, simran singhal wrote:

> This patch series replace "the the " with "the" in various drivers.
>
> v3:
>   -Resend the complete patch series.

Acked-by: Julia Lawall 

>
>
> simran singhal (3):
>   staging: wlan-ng: Replace "the the " with "the"
>   staging: rtl8192u: Replace "the the " with "the"
>   staging: unisys: Replace "the the " with "the"
>
>  drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
>  drivers/staging/unisys/visorbus/visorbus_main.c   | 2 +-
>  drivers/staging/wlan-ng/prism2sta.c   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1488556746-599-1-git-send-email-singhalsimran0%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 0/5] Fixed compilation error

[SIMRAN SINGHAL]

On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches  wrote:
> On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote:
>> Fixed compilation warning in lustre/lustre/llite/range_lock.c
>
> Really?  What compilation warning was removed?

CC [M]  drivers/staging/lustre/lustre/mgc/mgc_request.o
drivers/staging/lustre/lustre/mgc/mgc_request.c: In function
‘mgc_set_info_async’:
drivers/staging/lustre/lustre/mgc/mgc_request.c:1036:115: warning:
format ‘%s’ expects argument of type ‘char *’, but argument 3 has type
‘void *’ [-Wformat=]

I was getting this warning because of changing (char *)val to val
where val is a pointer to void.
So I fixed this by reverting this change.

Simran

>
>> simran singhal (5):
>>   staging: nvec: Remove unnecessary cast on void pointer
>>   staging: lustre: Remove unnecessary cast on void pointer
>>   staging: lustre: lustre: Remove unnecessary cast on void pointer
>>   staging: rts5208: Remove unnecessary cast on void pointer
>>   staging: rtl8712: Remove unnecessary cast on void pointer
>
> What compiler warns about unnecessary casts?
>
>>  drivers/staging/lustre/lustre/llite/range_lock.c |  2 +-
>>  drivers/staging/lustre/lustre/lmv/lmv_obd.c  |  4 ++--
>>  drivers/staging/lustre/lustre/mgc/mgc_request.c  |  2 +-
>>  drivers/staging/nvec/nvec_kbd.c  |  2 +-
>>  drivers/staging/rtl8712/rtl8712_recv.c   | 11 +--
>>  drivers/staging/rts5208/rtsx_transport.c |  3 +--
>>  6 files changed, 11 insertions(+), 13 deletions(-)
>>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

Hi Laura,

Thank you for the patches.

On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.

That's where most of my concerns with ion are. I still strongly believe that 
the heap-based approach is inherently flawed, as it would need to be 
configured for each device according to product-specific use cases. That's not 
something that could be easily shipped with a generic distribution. We should 
replace that with a constraint-based system.

> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.
> 
> Feedback appreciated.
> 
> Thanks,
> Laura
> 
> [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> 
> Laura Abbott (12):
>   staging: android: ion: Remove dmap_cnt
>   staging: android: ion: Remove alignment from allocation field
>   staging: android: ion: Duplicate sg_table
>   staging: android: ion: Call dma_map_sg for syncing and mapping
>   staging: android: ion: Remove page faulting support
>   staging: android: ion: Remove crufty cache support
>   staging: android: ion: Remove old platform support
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Make Ion heaps selectable
>   staging; android: ion: Enumerate all available heaps
> 
>  drivers/base/dma-contiguous.c  |   5 +-
>  drivers/staging/android/ion/Kconfig|  51 ++--
>  drivers/staging/android/ion/Makefile   |  14 +-
>  drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
>  drivers/staging/android/ion/hisilicon/Makefile |   1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
>  drivers/staging/android/ion/ion-ioctl.c|   6 -
>  drivers/staging/android/ion/ion.c  | 282 +-
>  drivers/staging/android/ion/ion.h  |   5 +-
>  drivers/staging/android/ion/ion_carveout_heap.c|  16 +-
>  drivers/staging/android/ion/ion_chunk_heap.c   |  15 +-
>  drivers/staging/android/ion/ion_cma_heap.c | 102 ++--
>  drivers/staging/android/ion/ion_dummy_driver.c | 156 
>  drivers/staging/android/ion/ion_enumerate.c|  89 +++
>  drivers/staging/android/ion/ion_of.c   | 184 --
>  drivers/staging/android/ion/ion_of.h   |  37 ---
>  drivers/staging/android/ion/ion_page_pool.c|   3 -
>  drivers/staging/android/ion/ion_priv.h |  57 -
>  drivers/staging/android/ion/ion_system_heap.c  |  14 +-
>  drivers/staging/android/ion/tegra/Makefile |   1 -
>  drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
>  include/linux/cma.h|   6 +-
>  mm/cma.c   |  25 +-
>  mm/cma.h   |   1 +
>  mm/cma_debug.c |   2 +-
>  25 files changed, 312 insertions(+), 958 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
>  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.h
>  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>  delete mode 100644 dri

Re: [Outreachy kernel] Re: [PATCH v3 0/5] Fixed compilation error

[Julia Lawall]

On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote:

> On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches  wrote:
> > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote:
> >> Fixed compilation warning in lustre/lustre/llite/range_lock.c
> >
> > Really?  What compilation warning was removed?
>
> CC [M]  drivers/staging/lustre/lustre/mgc/mgc_request.o
> drivers/staging/lustre/lustre/mgc/mgc_request.c: In function
> ‘mgc_set_info_async’:
> drivers/staging/lustre/lustre/mgc/mgc_request.c:1036:115: warning:
> format ‘%s’ expects argument of type ‘char *’, but argument 3 has type
> ‘void *’ [-Wformat=]
>
> I was getting this warning because of changing (char *)val to val
> where val is a pointer to void.
> So I fixed this by reverting this change.

Someone pointed out recently that when you make the cover letter for vn+1,
the subject should not change.  It doesn't describe what is new in the
version.  You put that in the message.

julia

>
> Simran
>
> >
> >> simran singhal (5):
> >>   staging: nvec: Remove unnecessary cast on void pointer
> >>   staging: lustre: Remove unnecessary cast on void pointer
> >>   staging: lustre: lustre: Remove unnecessary cast on void pointer
> >>   staging: rts5208: Remove unnecessary cast on void pointer
> >>   staging: rtl8712: Remove unnecessary cast on void pointer
> >
> > What compiler warns about unnecessary casts?
> >
> >>  drivers/staging/lustre/lustre/llite/range_lock.c |  2 +-
> >>  drivers/staging/lustre/lustre/lmv/lmv_obd.c  |  4 ++--
> >>  drivers/staging/lustre/lustre/mgc/mgc_request.c  |  2 +-
> >>  drivers/staging/nvec/nvec_kbd.c  |  2 +-
> >>  drivers/staging/rtl8712/rtl8712_recv.c   | 11 +--
> >>  drivers/staging/rts5208/rtsx_transport.c |  3 +--
> >>  6 files changed, 11 insertions(+), 13 deletions(-)
> >>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyMKJvhQMAdjtLWWKTtxOP%2BicRZ6bctB0bTtzA8gJi%2BwNA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] Re: [PATCH v3 0/5] Fixed compilation error

[SIMRAN SINGHAL]

On Fri, Mar 3, 2017 at 9:45 PM, Julia Lawall  wrote:
>
>
> On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote:
>
>> On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches  wrote:
>> > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote:
>> >> Fixed compilation warning in lustre/lustre/llite/range_lock.c
>> >
>> > Really?  What compilation warning was removed?
>>
>> CC [M]  drivers/staging/lustre/lustre/mgc/mgc_request.o
>> drivers/staging/lustre/lustre/mgc/mgc_request.c: In function
>> ‘mgc_set_info_async’:
>> drivers/staging/lustre/lustre/mgc/mgc_request.c:1036:115: warning:
>> format ‘%s’ expects argument of type ‘char *’, but argument 3 has type
>> ‘void *’ [-Wformat=]
>>
>> I was getting this warning because of changing (char *)val to val
>> where val is a pointer to void.
>> So I fixed this by reverting this change.
>
> Someone pointed out recently that when you make the cover letter for vn+1,
> the subject should not change.  It doesn't describe what is new in the
> version.  You put that in the message.
>
I will resend the complete patch series with changed subject of cover-patch.

> julia
>
>>
>> Simran
>>
>> >
>> >> simran singhal (5):
>> >>   staging: nvec: Remove unnecessary cast on void pointer
>> >>   staging: lustre: Remove unnecessary cast on void pointer
>> >>   staging: lustre: lustre: Remove unnecessary cast on void pointer
>> >>   staging: rts5208: Remove unnecessary cast on void pointer
>> >>   staging: rtl8712: Remove unnecessary cast on void pointer
>> >
>> > What compiler warns about unnecessary casts?
>> >
>> >>  drivers/staging/lustre/lustre/llite/range_lock.c |  2 +-
>> >>  drivers/staging/lustre/lustre/lmv/lmv_obd.c  |  4 ++--
>> >>  drivers/staging/lustre/lustre/mgc/mgc_request.c  |  2 +-
>> >>  drivers/staging/nvec/nvec_kbd.c  |  2 +-
>> >>  drivers/staging/rtl8712/rtl8712_recv.c   | 11 +--
>> >>  drivers/staging/rts5208/rtsx_transport.c |  3 +--
>> >>  6 files changed, 11 insertions(+), 13 deletions(-)
>> >>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyMKJvhQMAdjtLWWKTtxOP%2BicRZ6bctB0bTtzA8gJi%2BwNA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laurent Pinchart]

Hi Laura,

Thank you for the patch.

On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
> Technically, calling dma_buf_map_attachment should return a buffer
> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
> ensure this happens. As a side effect, this lets Ion buffers take
> advantage of the dma_buf sync ioctls.
> 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/ion/ion.c | 101 +--
>  1 file changed, 50 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c index ce4adac..a931b30 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
>  }
>  EXPORT_SYMBOL(ion_client_destroy);
> 
> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
> -struct device *dev,
> -enum dma_data_direction direction);
> -
>  static struct sg_table *dup_sg_table(struct sg_table *table)
>  {
>   struct sg_table *new_table;
> @@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table
> *table) return new_table;
>  }
> 
> +static void free_duped_table(struct sg_table *table)
> +{
> + sg_free_table(table);
> + kfree(table);
> +}
> +
>  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
> *attachment, enum dma_data_direction direction)
>  {
>   struct dma_buf *dmabuf = attachment->dmabuf;
>   struct ion_buffer *buffer = dmabuf->priv;
> + struct sg_table *table;
> + int ret;
> +
> + /*
> +  * TODO: Need to sync wrt CPU or device completely owning?
> +  */
> +
> + table = dup_sg_table(buffer->sg_table);
> 
> - ion_buffer_sync_for_device(buffer, attachment->dev, direction);
> - return dup_sg_table(buffer->sg_table);
> + if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> + direction)){
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> +err:
> + free_duped_table(table);
> + return ERR_PTR(ret);
>  }
> 
>  static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
> struct sg_table *table,
> enum dma_data_direction direction)
>  {
> - sg_free_table(table);
> - kfree(table);
> + dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> + free_duped_table(table);
>  }
> 
>  void ion_pages_sync_for_device(struct device *dev, struct page *page,
> @@ -864,38 +881,6 @@ struct ion_vma_list {
>   struct vm_area_struct *vma;
>  };
> 
> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
> -struct device *dev,
> -enum dma_data_direction dir)
> -{
> - struct ion_vma_list *vma_list;
> - int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
> - int i;
> -
> - pr_debug("%s: syncing for device %s\n", __func__,
> -  dev ? dev_name(dev) : "null");
> -
> - if (!ion_buffer_fault_user_mappings(buffer))
> - return;
> -
> - mutex_lock(&buffer->lock);
> - for (i = 0; i < pages; i++) {
> - struct page *page = buffer->pages[i];
> -
> - if (ion_buffer_page_is_dirty(page))
> - ion_pages_sync_for_device(dev, ion_buffer_page(page),
> -   PAGE_SIZE, dir);
> -
> - ion_buffer_page_clean(buffer->pages + i);
> - }
> - list_for_each_entry(vma_list, &buffer->vmas, list) {
> - struct vm_area_struct *vma = vma_list->vma;
> -
> - zap_page_range(vma, vma->vm_start, vma->vm_end - vma-
>vm_start);
> - }
> - mutex_unlock(&buffer->lock);
> -}
> -
>  static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>   struct ion_buffer *buffer = vma->vm_private_data;
> @@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct
> dma_buf *dmabuf, struct ion_buffer *buffer = dmabuf->priv;
>   void *vaddr;
> 
> - if (!buffer->heap->ops->map_kernel) {
> - pr_err("%s: map kernel is not implemented by this heap.\n",
> -__func__);
> - return -ENODEV;
> + /*
> +  * TODO: Move this elsewhere because we don't always need a vaddr
> +  */
> + if (buffer->heap->ops->map_kernel) {
> + mutex_lock(&buffer->lock);
> + vaddr = ion_buffer_kmap_get(buffer);
> + mutex_unlock(&buffer->lock);
>   }
> 
> - mutex_lock(&buffer->lock);
> - vaddr = ion_buffer_kmap_get(buffer);
> - mutex_unlock(&buffer->lock);
> - return PTR_ERR_OR_ZERO(vaddr);
> + /*
> +  * Close enough right now? Flag to skip sync?
> +  */
> + if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
> + buffer->

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laurent Pinchart]

Hi Daniel,

On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> > Now that we call dma_map in the dma_buf API callbacks there is no need
> > to use the existing cache APIs. Remove the sync ioctl and the existing
> > bad dma_sync calls. Explicit caching can be handled with the dma_buf
> > sync API.
> > 
> > Signed-off-by: Laura Abbott 
> > ---
> > 
> >  drivers/staging/android/ion/ion-ioctl.c |  5 
> >  drivers/staging/android/ion/ion.c   | 40 
> >  drivers/staging/android/ion/ion_carveout_heap.c |  6 
> >  drivers/staging/android/ion/ion_chunk_heap.c|  6 
> >  drivers/staging/android/ion/ion_page_pool.c |  3 --
> >  drivers/staging/android/ion/ion_system_heap.c   |  5 
> >  6 files changed, 65 deletions(-)
> > 
> > diff --git a/drivers/staging/android/ion/ion-ioctl.c
> > b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
> > --- a/drivers/staging/android/ion/ion-ioctl.c
> > +++ b/drivers/staging/android/ion/ion-ioctl.c
> > @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
> > unsigned long arg)> 
> > data.handle.handle = handle->id;
> > 
> > break;
> > 
> > }
> > 
> > -   case ION_IOC_SYNC:
> > -   {
> > -   ret = ion_sync_for_device(client, data.fd.fd);
> > -   break;
> > -   }
> 
> You missed the case ION_IOC_SYNC: in compat_ion.c.
> 
> While at it: Should we also remove the entire custom_ioctl infrastructure?
> It's entirely unused afaict, and for a pure buffer allocator I don't see
> any need to have custom ioctl.

I second that, if you want to make ion a standard API, then we certainly don't 
want any custom ioctl.

> More code to remove potentially:
> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>   would allow us to remove compat_ion.c entirely.
> 
> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>   still need to be able to import anything. All the cache flushing/mapping
>   is done through dma-buf ops/ioctls.
> 
> 
> With the case in compat_ion.c also removed, this patch is:
> 
> Reviewed-by: Daniel Vetter 
> 
> > case ION_IOC_CUSTOM:
> > {
> > 
> > if (!dev->custom_ioctl)
> > 
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c index 8eef1d7..c3c316f 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,> 
> > free_duped_table(table);
> >  
> >  }
> > 
> > -void ion_pages_sync_for_device(struct device *dev, struct page *page,
> > -  size_t size, enum dma_data_direction dir)
> > -{
> > -   struct scatterlist sg;
> > -
> > -   sg_init_table(&sg, 1);
> > -   sg_set_page(&sg, page, size, 0);
> > -   /*
> > -* This is not correct - sg_dma_address needs a dma_addr_t that is 
valid
> > -* for the targeted device, but this works on the currently targeted
> > -* hardware.
> > -*/
> > -   sg_dma_address(&sg) = page_to_phys(page);
> > -   dma_sync_sg_for_device(dev, &sg, 1, dir);
> > -}
> > -
> > 
> >  static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> >  {
> >  
> > struct ion_buffer *buffer = dmabuf->priv;
> > 
> > @@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct
> > ion_client *client, int fd)> 
> >  }
> >  EXPORT_SYMBOL(ion_import_dma_buf_fd);
> > 
> > -int ion_sync_for_device(struct ion_client *client, int fd)
> > -{
> > -   struct dma_buf *dmabuf;
> > -   struct ion_buffer *buffer;
> > -
> > -   dmabuf = dma_buf_get(fd);
> > -   if (IS_ERR(dmabuf))
> > -   return PTR_ERR(dmabuf);
> > -
> > -   /* if this memory came from ion */
> > -   if (dmabuf->ops != &dma_buf_ops) {
> > -   pr_err("%s: can not sync dmabuf from another exporter\n",
> > -  __func__);
> > -   dma_buf_put(dmabuf);
> > -   return -EINVAL;
> > -   }
> > -   buffer = dmabuf->priv;
> > -
> > -   dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
> > -  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
> > -   dma_buf_put(dmabuf);
> > -   return 0;
> > -}
> > -
> > 
> >  int ion_query_heaps(struct ion_client *client, struct ion_heap_query
> >  *query) {
> >  
> > struct ion_device *dev = client->dev;
> > 
> > diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
> > b/drivers/staging/android/ion/ion_carveout_heap.c index 9bf8e98..e0e360f
> > 100644
> > --- a/drivers/staging/android/ion/ion_carveout_heap.c
> > +++ b/drivers/staging/android/ion/ion_carveout_heap.c
> > @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer
> > *buffer)> 
> > ion_heap_buffer_zero(buffer);
> > 
> > -   if (io

Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable

[Vitaly Kuznetsov]

Dexuan Cui  writes:

> With the recent introduction of per-channel tasklet, we need to update
> the way we handle the 3 concurrency issues:
>
> 1. hv_process_channel_removal -> percpu_channel_deq vs.
>vmbus_chan_sched -> list_for_each_entry(..., percpu_list);
>
> 2. vmbus_process_offer -> percpu_channel_enq/deq vs. vmbus_chan_sched.
>
> 3. vmbus_close_internal vs. the per-channel tasklet vmbus_on_event;
>
> The first 2 issues can be handled by Stephen's recent patch
> "vmbus: use rcu for per-cpu channel list", and the third issue
> can be handled by calling tasklet_disable in vmbus_close_internal here.
>
> We don't need the original hv_event_tasklet_disable/enable since we
> now use per-channel tasklet instead of the previous per-CPU tasklet,
> and actually we must remove them due to the side effect now:
> vmbus_process_offer -> hv_event_tasklet_enable -> tasklet_schedule will
> start the per-channel callback prematurely, cauing NULL dereferencing
> (the channel may haven't been properly configured to run the callback yet).
>
> Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet")
>
> Signed-off-by: Dexuan Cui 
> Cc: "K. Y. Srinivasan" 
> Cc: Haiyang Zhang 
> Cc: Stephen Hemminger 

Tested-by: Vitaly Kuznetsov 

This patch fixes the following crash on boot:

[1.451648] BUG: unable to handle kernel NULL pointer dereference at 
0004
[1.452255] IP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
[1.452255] PGD 0 
[1.452255] 
[1.452255] Oops:  [#1] SMP
[1.452255] Modules linked in: hv_storvsc hv_netvsc(+) scsi_transport_fc 
hyperv_fb hyperv_keyboard hid_hyperv hv_vmbus
[1.452255] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 4.10.0_test+ #911
[1.452255] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
[1.452255] task: 880007fd2b00 task.stack: c9e34000
[1.452255] RIP: 0010:netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
...
[1.452255] Call Trace:
[1.452255]  vmbus_on_event+0x22/0x90 [hv_vmbus]
[1.452255]  tasklet_action+0x5e/0x110
[1.452255]  __do_softirq+0x104/0x2af
[1.452255]  run_ksoftirqd+0x29/0x40
...
[1.548068] RIP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc] RSP: 
c9e37d88
[1.548068] CR2: 0004
[1.548068] ---[ end trace 601fd9d6588b21e5 ]---
[1.548068] Kernel panic - not syncing: Fatal exception in interrupt
[1.548068] Kernel Offset: disabled
[1.548068] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
[1.572155] [ cut here ]

The crash is not imminent but it happens pretty often on boot, I think
we need to push it to 4.11.

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

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laurent Pinchart]

Hi Laura,

Thank you for the patch.

On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also avoids awkward
> caching questions.

If the DMA mapping API isn't suitable for today's requirements anymore, I 
believe that's what needs to be fixed, instead of working around the problem 
by introducing another use-case-specific API.

> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/ion/ion_cma_heap.c | 97 +++
>  1 file changed, 26 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> b/drivers/staging/android/ion/ion_cma_heap.c index d562fd7..6838825 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
> 
>  #include "ion.h"
>  #include "ion_priv.h"
> 
>  struct ion_cma_heap {
>   struct ion_heap heap;
> - struct device *dev;
> + struct cma *cma;
>  };
> 
>  #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
> 
> -struct ion_cma_buffer_info {
> - void *cpu_addr;
> - dma_addr_t handle;
> - struct sg_table *table;
> -};
> -
> 
>  /* ION CMA heap operations functions */
>  static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer
> *buffer, @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap
> *heap, struct ion_buffer *buffer, unsigned long flags)
>  {
>   struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info;
> -
> - dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> - if (buffer->flags & ION_FLAG_CACHED)
> - return -EINVAL;
> + struct sg_table *table;
> + struct page *pages;
> + int ret;
> 
> - info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info)
> + pages = cma_alloc(cma_heap->cma, len, 0);
> + if (!pages)
>   return -ENOMEM;
> 
> - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> - GFP_HIGHUSER | __GFP_ZERO);
> -
> - if (!info->cpu_addr) {
> - dev_err(dev, "Fail to allocate buffer\n");
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
>   goto err;
> - }
> 
> - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> - if (!info->table)
> + ret = sg_alloc_table(table, 1, GFP_KERNEL);
> + if (ret)
>   goto free_mem;
> 
> - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> - len))
> - goto free_table;
> - /* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
>   return 0;
> 
> -free_table:
> - kfree(info->table);
>  free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
>  err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
>   return -ENOMEM;
>  }
> 
>  static void ion_cma_free(struct ion_buffer *buffer)
>  {
>   struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> + struct page *pages = buffer->priv_virt;
> 
> - dev_dbg(dev, "Release buffer %p\n", buffer);
>   /* release memory */
> - dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
> + cma_release(cma_heap->cma, pages, buffer->size);
>   /* release sg table */
> - sg_free_table(info->table);
> - kfree(info->table);
> - kfree(info);
> -}
> -
> -static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
> - struct vm_area_struct *vma)
> -{
> - struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> -
> - return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
> -  buffer->size);
> -}
> -
> -static void *ion_cma_map_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> - /* kernel memory mapping has been done at 

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

Hi Daniel,

On Friday 03 Mar 2017 11:04:33 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> > 
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keeping Ion since it works reasonablly well.
> > This series does what should be the final clean ups for it to possibly be
> > moved out of staging.
> > 
> > This includes the following:
> > - Some general clean up and removal of features that never got a lot of
> >   use as far as I can tell.
> > 
> > - Fixing up the caching. This is the series I proposed back in December[2]
> >   but never heard any feedback on. It will certainly break existing
> >   applications that rely on the implicit caching. I'd rather make an
> >   effort to move to a model that isn't going directly against the
> >   establishement though.
> > 
> > - Fixing up the platform support. The devicetree approach was never well
> >   recieved by DT maintainers. The proposal here is to think of Ion less as
> >   specifying requirements and more of a framework for exposing memory to
> >   userspace.
> > 
> > - CMA allocations now happen without the need of a dummy device structure.
> >   This fixes a bunch of the reasons why I attempted to add devicetree
> >   support before.
> > 
> > I've had problems getting feedback in the past so if I don't hear any
> > major objections I'm going to send out with the RFC dropped to be picked
> > up. The only reason there isn't a patch to come out of staging is to
> > discuss any other changes to the ABI people might want. Once this comes
> > out of staging, I really don't want to mess with the ABI.
> > 
> > Feedback appreciated.
> 
> Imo looks all good. And I just realized that cross-checking with the TODO,
> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.
> 
> Otherwise I looked through the patches, looks all really reasonable.

Two more items that need to be addressed in my opinion :

- Let's not export the ion_client API, we don't want drivers to be ion-
specific. Only the dma-buf interface should be visible to drivers.

- I haven't seen any proposal how a heap-based solution could be used in a 
generic distribution. This needs to be figured out before committing to any 
API/ABI.

> Wrt merging, my experience from destaging the android syncpt stuff was
> that merging the patches through the staging tree lead to lots of
> cross-tree issues with the gpu folks wanting to use that. Ion will
> probably run into similar things, so I'd propose we pull these cleanup
> patches and the eventual de-staging in throught drm. Yes that defacto
> means I'm also volunteering myself a bit :-)
> 
> In the end we could put it all into drivers/gpu/ion or something like
> that.
> 
> Thoughts? Greg?
> -Daniel
> 
> > Thanks,
> > Laura
> > 
> > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> > 
> > Laura Abbott (12):
> >   staging: android: ion: Remove dmap_cnt
> >   staging: android: ion: Remove alignment from allocation field
> >   staging: android: ion: Duplicate sg_table
> >   staging: android: ion: Call dma_map_sg for syncing and mapping
> >   staging: android: ion: Remove page faulting support
> >   staging: android: ion: Remove crufty cache support
> >   staging: android: ion: Remove old platform support
> >   cma: Store a name in the cma structure
> >   cma: Introduce cma_for_each_area
> >   staging: android: ion: Use CMA APIs directly
> >   staging: android: ion: Make Ion heaps selectable
> >   staging; android: ion: Enumerate all available heaps
> >  
> >  drivers/base/dma-contiguous.c  |   5 +-
> >  drivers/staging/android/ion/Kconfig|  51 ++--
> >  drivers/staging/android/ion/Makefile   |  14 +-
> >  drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
> >  drivers/staging/android/ion/hisilicon/Makefile |   1 -
> >  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
> >  drivers/staging/android/ion/ion-ioctl.c|   6 -
> >  drivers/staging/android/ion/ion.c  | 282
> >  ++--- drivers/staging/android/ion/ion.h 
> >  |   5 +-
> >  drivers/staging/android/ion/ion_carveout_heap.c|  16 +-
> >  drivers/staging/android/ion/ion_chunk_heap.c   |  15 +-
> >  drivers/staging/android/ion/ion_cma_heap.c | 102 ++--
> >  drivers/staging/android/ion/ion_dummy_driver.c | 156 
> >  drivers/staging/android/ion/ion_enumerate.c|  89 +++
> >  drivers/staging/android/ion/ion_of.c   | 184 --
> >  drivers/staging/android/ion/ion_of.h   |  37 ---
> >  drivers/staging/android/ion/ion_page_pool.c|   3 -
> >  drivers/staging/android/ion/ion_priv.h |  57 -
> >  drivers/staging/android/ion/ion_system_heap.c  |  14 +-
> >  drivers/staging/android/ion/tegra/M

Re: [Outreachy kernel] [PATCH] staging: speakup: else is not generally useful after a break or return

[Julia Lawall]

On Fri, 3 Mar 2017, Arushi Singhal wrote:

>
>
> On Friday, March 3, 2017 at 9:33:22 PM UTC+5:30, Julia Lawall wrote:
>
>
>   On Fri, 3 Mar 2017, Arushi Singhal wrote:
>
>   > fixed checkpatch.pl warning: else is not generally useful
>   after a break
>   > or return.
>   > Removed the else without affecting the logic.
>   > Dead code is also eliminated.
>
>   The chhange is not correct.  There is a big chain of if/else if.
>    The if
>   (type == KT_LATIN) can reach the code at the end of the file.
>
> If there is else and all if/else have return statement so then the code will
> not reach at the end.

The first one does not end in a return.

julia

>  Thanks
> Aruhsi
>   \
>   julia
>
>   >
>   > Signed-off-by: Arushi Singhal 
>   > ---
>   >  drivers/staging/speakup/keyhelp.c | 53
>   ++-
>   >  1 file changed, 19 insertions(+), 34 deletions(-)
>   >
>   > diff --git a/drivers/staging/speakup/keyhelp.c
>   b/drivers/staging/speakup/keyhelp.c
>   > index 4e6e5daba50c..ad3efded37c1 100644
>   > --- a/drivers/staging/speakup/keyhelp.c
>   > +++ b/drivers/staging/speakup/keyhelp.c
>   > @@ -176,43 +176,28 @@ int spk_handle_help(struct vc_data *vc,
>   u_char type, u_char ch, u_short key)
>   >  synth_printf("%s\n",
>   spk_msg_get(MSG_HELP_INFO));
>   >  build_key_data(); /* rebuild each time in
>   case new mapping */
>   >  return 1;
>   > -} else {
>   > -name = NULL;
>   > -if ((type != KT_SPKUP) && (key > 0) && (key
>   <= num_key_names)) {
>   > -synth_printf("%s\n",
>   > -    
>   spk_msg_get(MSG_KEYNAMES_START + key - 1));
>   > -return 1;
>   > -}
>   > -for (i = 0; funcvals[i] != 0 && !name; i++) {
>   > -if (ch == funcvals[i])
>   > -name =
>   spk_msg_get(MSG_FUNCNAMES_START + i);
>   > -}
>   > -if (!name)
>   > -return -1;
>   > -kp = spk_our_keys[key] + 1;
>   > -for (i = 0; i < nstates; i++) {
>   > -if (ch == kp[i])
>   > -break;
>   > -}
>   > -key += (state_tbl[i] << 8);
>   > -say_key(key);
>   > -synth_printf(spk_msg_get(MSG_KEYDESC), name);
>   > -synth_printf("\n");
>   > -return 1;
>   >  }
>   > -name = spk_msg_get(MSG_FUNCNAMES_START + cur_item);
>   > -func = funcvals[cur_item];
>   > -synth_printf("%s", name);
>   > -if (key_offsets[func] == 0) {
>   > -synth_printf(" %s\n",
>   spk_msg_get(MSG_IS_UNASSIGNED));
>   > +
>   > +name = NULL;
>   > +if ((type != KT_SPKUP) && (key > 0) && (key <=
>   num_key_names)) {
>   > +synth_printf("%s\n",
>   > +     spk_msg_get(MSG_KEYNAMES_START +
>   key - 1));
>   >  return 1;
>   >  }
>   > -p_keys = key_data + key_offsets[func];
>   > -for (n = 0; p_keys[n]; n++) {
>   > -val = p_keys[n];
>   > -if (n > 0)
>   > -synth_printf("%s ",
>   spk_msg_get(MSG_DISJUNCTION));
>   > -say_key(val);
>   > +for (i = 0; funcvals[i] != 0 && !name; i++) {
>   > +if (ch == funcvals[i])
>   > +name =
>   spk_msg_get(MSG_FUNCNAMES_START + i);
>   > +}
>   > +if (!name)
>   > +return -1;
>   > +kp = spk_our_keys[key] + 1;
>   > +for (i = 0; i < nstates; i++) {
>   > +if (ch == kp[i])
>   > +break;
>   >  }
>   > +key += (state_tbl[i] << 8);
>   > +say_key(key);
>   > +synth_printf(spk_msg_get(MSG_KEYDESC), name);
>   > +synth_printf("\n");
>   >  return 1;
>   >  }
>   > --
>   > 2.11.0
>   >
>   > --
>   > You received this message because you are subscribed to the
>   Google Groups "outreachy-kernel" group.
>   > To unsubscribe from this group and stop receiving emails from
>   it, send an email to outreachy-kern...@googlegroups.com.
>   > To post to this group, send email to
>   outreach...@googlegroups.com.
>   > To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

[Borislav Petkov]

On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Update the CPU features to include identifying and reporting on the
> Secure Encrypted Virtualization (SEV) feature.  SME is identified by
> CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of
> MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR).  Only show the SEV feature
> as available if reported by CPUID and enabled by BIOS.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/cpufeatures.h |1 +
>  arch/x86/include/asm/msr-index.h   |2 ++
>  arch/x86/kernel/cpu/amd.c  |   22 ++
>  arch/x86/kernel/cpu/scattered.c|1 +
>  4 files changed, 22 insertions(+), 4 deletions(-)

So this patchset is not really ontop of Tom's patchset because this
patch doesn't apply. The reason is, Tom did the SME bit this way:

https://lkml.kernel.org/r/20170216154236.19244.7580.st...@tlendack-t1.amdoffice.net

but it should've been in scattered.c.

> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index cabda87..c3f58d9 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -31,6 +31,7 @@ static const struct cpuid_bit cpuid_bits[] = {
>   { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
>   { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
>   { X86_FEATURE_SME,  CPUID_EAX,  0, 0x801f, 0 },
> + { X86_FEATURE_SEV,  CPUID_EAX,  1, 0x801f, 0 },
>   { 0, 0, 0, 0, 0 }

... and here it is in scattered.c, as it should be. So you've used an
older version of the patch, it seems.

Please sync with Tom to see whether he's reworked the v4 version of that
patch already. If yes, then you could send only the SME and SEV adding
patches as a reply to this message so that I can continue reviewing in
the meantime.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: media: Remove parentheses from return arguments

[simran singhal]

The sematic patch used for this is:
@@
identifier i;
constant c;
@@
return
- (
\(i\|-i\|i(...)\|c\)
- )
  ;

Signed-off-by: simran singhal 
---
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c  | 20 ++--
 .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c   |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
index f39d6f5..1216efb 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
@@ -2009,7 +2009,7 @@ enum ia_css_err ia_css_suspend(void)
for(i=0;i after 1: seed %d 
(%p)\n", i, my_css_save.stream_seeds[i].stream);
ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_suspend() leave\n");
-   return(IA_CSS_SUCCESS);
+   return IA_CSS_SUCCESS;
 }
 
 enum ia_css_err
@@ -2021,10 +2021,10 @@ ia_css_resume(void)
 
err = ia_css_init(&(my_css_save.driver_env), my_css_save.loaded_fw, 
my_css_save.mmu_base, my_css_save.irq_type);
if (err != IA_CSS_SUCCESS)
-   return(err);
+   return err;
err = ia_css_start_sp();
if (err != IA_CSS_SUCCESS)
-   return(err);
+   return err;
my_css_save.mode = sh_css_mode_resume;
for(i=0;ihttp://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH] staging: media: Remove parentheses from return arguments

[Julia Lawall]

On Fri, 3 Mar 2017, simran singhal wrote:

> The sematic patch used for this is:
> @@
> identifier i;
> constant c;
> @@
> return
> - (
> \(i\|-i\|i(...)\|c\)
> - )
>   ;
>
> Signed-off-by: simran singhal 

Acked-by: Julia Lawall 


> ---
>  .../media/atomisp/pci/atomisp2/css2400/sh_css.c  | 20 
> ++--
>  .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c   |  2 +-
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> index f39d6f5..1216efb 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> @@ -2009,7 +2009,7 @@ enum ia_css_err ia_css_suspend(void)
>   for(i=0;i   ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "==*> after 1: seed %d 
> (%p)\n", i, my_css_save.stream_seeds[i].stream);
>   ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_suspend() leave\n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
>  }
>
>  enum ia_css_err
> @@ -2021,10 +2021,10 @@ ia_css_resume(void)
>
>   err = ia_css_init(&(my_css_save.driver_env), my_css_save.loaded_fw, 
> my_css_save.mmu_base, my_css_save.irq_type);
>   if (err != IA_CSS_SUCCESS)
> - return(err);
> + return err;
>   err = ia_css_start_sp();
>   if (err != IA_CSS_SUCCESS)
> - return(err);
> + return err;
>   my_css_save.mode = sh_css_mode_resume;
>   for(i=0;i   {
> @@ -2038,7 +2038,7 @@ ia_css_resume(void)
>   if (i)
>   for(j=0;j   
> ia_css_stream_unload(my_css_save.stream_seeds[j].stream);
> - return(err);
> + return err;
>   }
>   err = 
> ia_css_stream_start(my_css_save.stream_seeds[i].stream);
>   if (err != IA_CSS_SUCCESS)
> @@ -2048,7 +2048,7 @@ ia_css_resume(void)
>   
> ia_css_stream_stop(my_css_save.stream_seeds[j].stream);
>   
> ia_css_stream_unload(my_css_save.stream_seeds[j].stream);
>   }
> - return(err);
> + return err;
>   }
>   *my_css_save.stream_seeds[i].orig_stream = 
> my_css_save.stream_seeds[i].stream;
>   for(j=0;j @@ -2057,7 +2057,7 @@ ia_css_resume(void)
>   }
>   my_css_save.mode = sh_css_mode_working;
>   ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_resume() leave: 
> return_void\n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
>  }
>
>  enum ia_css_err
> @@ -10261,7 +10261,7 @@ ia_css_stream_load(struct ia_css_stream *stream)
>   for(k=0;k   
> ia_css_pipe_destroy(my_css_save.stream_seeds[i].pipes[k]);
>   }
> - return(err);
> + return err;
>   }
>   err = 
> ia_css_stream_create(&(my_css_save.stream_seeds[i].stream_config), 
> my_css_save.stream_seeds[i].num_pipes,
>   
> my_css_save.stream_seeds[i].pipes, &(my_css_save.stream_seeds[i].stream));
> @@ -10270,12 +10270,12 @@ ia_css_stream_load(struct ia_css_stream *stream)
>   ia_css_stream_destroy(stream);
>   
> for(j=0;j   
> ia_css_pipe_destroy(my_css_save.stream_seeds[i].pipes[j]);
> - return(err);
> + return err;
>   }
>   break;
>   }
>   ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_stream_load() exit, 
> \n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
>  #else
>   /* TODO remove function - DEPRECATED */
>   (void)stream;
> @@ -10416,7 +10416,7 @@ ia_css_stream_unload(struct ia_css_stream *stream)
>   break;
>   }
>   ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_stream_unload() exit, 
> \n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
>  }
>
>  #endif
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> index b7db3de..d3567ac 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> @@ -74,7 +74,7 @@ static struct fw_param *fw_minibuffer;
>
>  char *sh_css_

Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable

[Stephen Hemminger]

On Fri, 03 Mar 2017 17:40:47 +0100
Vitaly Kuznetsov  wrote:

> Dexuan Cui  writes:
> 
> > With the recent introduction of per-channel tasklet, we need to update
> > the way we handle the 3 concurrency issues:
> >
> > 1. hv_process_channel_removal -> percpu_channel_deq vs.
> >vmbus_chan_sched -> list_for_each_entry(..., percpu_list);
> >
> > 2. vmbus_process_offer -> percpu_channel_enq/deq vs. vmbus_chan_sched.
> >
> > 3. vmbus_close_internal vs. the per-channel tasklet vmbus_on_event;
> >
> > The first 2 issues can be handled by Stephen's recent patch
> > "vmbus: use rcu for per-cpu channel list", and the third issue
> > can be handled by calling tasklet_disable in vmbus_close_internal here.
> >
> > We don't need the original hv_event_tasklet_disable/enable since we
> > now use per-channel tasklet instead of the previous per-CPU tasklet,
> > and actually we must remove them due to the side effect now:
> > vmbus_process_offer -> hv_event_tasklet_enable -> tasklet_schedule will
> > start the per-channel callback prematurely, cauing NULL dereferencing
> > (the channel may haven't been properly configured to run the callback yet).
> >
> > Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet")
> >
> > Signed-off-by: Dexuan Cui 
> > Cc: "K. Y. Srinivasan" 
> > Cc: Haiyang Zhang 
> > Cc: Stephen Hemminger   
> 
> Tested-by: Vitaly Kuznetsov 
> 
> This patch fixes the following crash on boot:
> 
> [1.451648] BUG: unable to handle kernel NULL pointer dereference at 
> 0004
> [1.452255] IP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
> [1.452255] PGD 0 
> [1.452255] 
> [1.452255] Oops:  [#1] SMP
> [1.452255] Modules linked in: hv_storvsc hv_netvsc(+) scsi_transport_fc 
> hyperv_fb hyperv_keyboard hid_hyperv hv_vmbus
> [1.452255] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 4.10.0_test+ #911
> [1.452255] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
> Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
> [1.452255] task: 880007fd2b00 task.stack: c9e34000
> [1.452255] RIP: 0010:netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
> ...
> [1.452255] Call Trace:
> [1.452255]  vmbus_on_event+0x22/0x90 [hv_vmbus]
> [1.452255]  tasklet_action+0x5e/0x110
> [1.452255]  __do_softirq+0x104/0x2af
> [1.452255]  run_ksoftirqd+0x29/0x40
> ...
> [1.548068] RIP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc] RSP: 
> c9e37d88
> [1.548068] CR2: 0004
> [1.548068] ---[ end trace 601fd9d6588b21e5 ]---
> [1.548068] Kernel panic - not syncing: Fatal exception in interrupt
> [1.548068] Kernel Offset: disabled
> [1.548068] ---[ end Kernel panic - not syncing: Fatal exception in 
> interrupt
> [1.572155] [ cut here ]
> 
> The crash is not imminent but it happens pretty often on boot, I think
> we need to push it to 4.11.
> 

Agree that this needs to be in 4.11, but when NAPI is merged it also will not 
happen.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the"

[Kershner, David A]

> -Original Message-
> From: Julia Lawall [mailto:julia.law...@lip6.fr]
> Sent: Friday, March 3, 2017 11:07 AM
> To: simran singhal 
> Cc: gre...@linuxfoundation.org; Kershner, David A
> ; *S-Par-Maintainer
> ; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; larry.fin...@lwfinger.net;
> florian.c.schilha...@googlemail.com; outreachy-ker...@googlegroups.com
> Subject: Re: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the"
> 
> 
> 
> On Fri, 3 Mar 2017, simran singhal wrote:
> 
> > This patch series replace "the the " with "the" in various drivers.
> >
> > v3:
> >   -Resend the complete patch series.
> 
> Acked-by: Julia Lawall 

Acked-by: David Kershner 

> 
> >
> >
> > simran singhal (3):
> >   staging: wlan-ng: Replace "the the " with "the"
> >   staging: rtl8192u: Replace "the the " with "the"
> >   staging: unisys: Replace "the the " with "the"
> >
> >  drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
> >  drivers/staging/unisys/visorbus/visorbus_main.c   | 2 +-
> >  drivers/staging/wlan-ng/prism2sta.c   | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > --
> > 2.7.4
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/1488556746-599-1-
> git-send-email-singhalsimran0%40gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/03/2017 05:29 AM, Michal Hocko wrote:
> On Thu 02-03-17 13:44:32, Laura Abbott wrote:
>> Hi,
>>
>> There's been some recent discussions[1] about Ion-like frameworks. There's
>> apparently interest in just keeping Ion since it works reasonablly well.
>> This series does what should be the final clean ups for it to possibly be
>> moved out of staging.
>>
>> This includes the following:
>> - Some general clean up and removal of features that never got a lot of use
>>   as far as I can tell.
>> - Fixing up the caching. This is the series I proposed back in December[2]
>>   but never heard any feedback on. It will certainly break existing
>>   applications that rely on the implicit caching. I'd rather make an effort
>>   to move to a model that isn't going directly against the establishement
>>   though.
>> - Fixing up the platform support. The devicetree approach was never well
>>   recieved by DT maintainers. The proposal here is to think of Ion less as
>>   specifying requirements and more of a framework for exposing memory to
>>   userspace.
>> - CMA allocations now happen without the need of a dummy device structure.
>>   This fixes a bunch of the reasons why I attempted to add devicetree
>>   support before.
>>
>> I've had problems getting feedback in the past so if I don't hear any major
>> objections I'm going to send out with the RFC dropped to be picked up.
>> The only reason there isn't a patch to come out of staging is to discuss any
>> other changes to the ABI people might want. Once this comes out of staging,
>> I really don't want to mess with the ABI.
> 
> Could you recapitulate concerns preventing the code being merged
> normally rather than through the staging tree and how they were
> addressed?
> 

Sorry, I'm really not understanding your question here, can you
clarify?

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

Re: [PATCH 1/7] staging: media: Remove unnecessary typecast of c90 int constant

[Sakari Ailus]

Hi Simran,

On Fri, Mar 03, 2017 at 01:21:56AM +0530, simran singhal wrote:
> This patch removes unnecessary typecast of c90 int constant.
> 
> WARNING: Unnecessary typecast of c90 int constant
> 
> Signed-off-by: simran singhal 

Which tree are these patches based on?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH] staging: speakup: else is not generally useful after a break or return

[Dan Carpenter]

On Fri, Mar 03, 2017 at 05:03:09PM +0100, Julia Lawall wrote:
> 
> 
> On Fri, 3 Mar 2017, Arushi Singhal wrote:
> 
> > fixed checkpatch.pl warning: else is not generally useful after a break
> > or return.
> > Removed the else without affecting the logic.
> > Dead code is also eliminated.
> 
> The chhange is not correct.  There is a big chain of if/else if.  The if
> (type == KT_LATIN) can reach the code at the end of the file.
> 

Yeah.  And KT_CUR as well.

regards,
dan carpenter

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

[PATCH v4 0/5] Remove unnecessary cast on void pointer

[simran singhal]

This patch-series removes unnecessary cast on void pointer in various 
drivers.

v4:
  -change the cover-letter subject
v3:
  -Fixed compilation warning in lustre/lustre/llite/range_lock.c

simran singhal (5):
  staging: nvec: Remove unnecessary cast on void pointer
  staging: lustre: Remove unnecessary cast on void pointer
  staging: lustre: lustre: Remove unnecessary cast on void pointer
  staging: rts5208: Remove unnecessary cast on void pointer
  staging: rtl8712: Remove unnecessary cast on void pointer

 drivers/staging/lustre/lustre/llite/range_lock.c |  2 +-
 drivers/staging/lustre/lustre/lmv/lmv_obd.c  |  4 ++--
 drivers/staging/lustre/lustre/mgc/mgc_request.c  |  2 +-
 drivers/staging/nvec/nvec_kbd.c  |  2 +-
 drivers/staging/rtl8712/rtl8712_recv.c   | 11 +--
 drivers/staging/rts5208/rtsx_transport.c |  3 +--
 6 files changed, 11 insertions(+), 13 deletions(-)

-- 
2.7.4

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

[PATCH v4 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/lustre/lustre/llite/range_lock.c | 2 +-
 drivers/staging/lustre/lustre/mgc/mgc_request.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/range_lock.c 
b/drivers/staging/lustre/lustre/llite/range_lock.c
index 14148a0..161391b 100644
--- a/drivers/staging/lustre/lustre/llite/range_lock.c
+++ b/drivers/staging/lustre/lustre/llite/range_lock.c
@@ -174,7 +174,7 @@ void range_unlock(struct range_lock_tree *tree, struct 
range_lock *lock)
  */
 static enum interval_iter range_lock_cb(struct interval_node *node, void *arg)
 {
-   struct range_lock *lock = (struct range_lock *)arg;
+   struct range_lock *lock = arg;
struct range_lock *overlap = node2rangelock(node);
 
lock->rl_blocking_ranges += overlap->rl_lock_count + 1;
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index 6a76605..8ca0a04 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -1050,7 +1050,7 @@ static int mgc_set_info_async(const struct lu_env *env, 
struct obd_export *exp,
sptlrpc_flavor2name(&cli->cl_flvr_mgc,
str, sizeof(str));
LCONSOLE_ERROR("asking sptlrpc flavor %s to MGS but 
currently %s is in use\n",
-  (char *)val, str);
+  val, str);
rc = -EPERM;
}
return rc;
-- 
2.7.4

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

[PATCH v4 1/5] staging: nvec: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:

@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/nvec/nvec_kbd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/nvec/nvec_kbd.c b/drivers/staging/nvec/nvec_kbd.c
index e881e6b..a01f486 100644
--- a/drivers/staging/nvec/nvec_kbd.c
+++ b/drivers/staging/nvec/nvec_kbd.c
@@ -58,7 +58,7 @@ static int nvec_keys_notifier(struct notifier_block *nb,
  unsigned long event_type, void *data)
 {
int code, state;
-   unsigned char *msg = (unsigned char *)data;
+   unsigned char *msg = data;
 
if (event_type == NVEC_KB_EVT) {
int _size = (msg[0] & (3 << 5)) >> 5;
-- 
2.7.4

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

[PATCH v4 5/5] staging: rtl8712: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8712/rtl8712_recv.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c 
b/drivers/staging/rtl8712/rtl8712_recv.c
index 20fe45a..266ffef 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -444,9 +444,9 @@ void r8712_rxcmd_event_hdl(struct _adapter *padapter, void 
*prxcmdbuf)
u16 cmd_len, drvinfo_sz;
struct recv_stat *prxstat;
 
-   poffset = (u8 *)prxcmdbuf;
+   poffset = prxcmdbuf;
voffset = *(__le32 *)poffset;
-   prxstat = (struct recv_stat *)prxcmdbuf;
+   prxstat = prxcmdbuf;
drvinfo_sz = (le32_to_cpu(prxstat->rxdw0) & 0x000f) >> 16;
drvinfo_sz <<= 3;
poffset += RXDESC_SIZE + drvinfo_sz;
@@ -634,8 +634,7 @@ static int recv_indicatepkt_reorder(struct _adapter 
*padapter,
 void r8712_reordering_ctrl_timeout_handler(void *pcontext)
 {
unsigned long irql;
-   struct recv_reorder_ctrl *preorder_ctrl =
-(struct recv_reorder_ctrl *)pcontext;
+   struct recv_reorder_ctrl *preorder_ctrl = pcontext;
struct _adapter *padapter = preorder_ctrl->padapter;
struct  __queue *ppending_recvframe_queue =
 &preorder_ctrl->pending_recvframe_queue;
@@ -976,7 +975,7 @@ int recv_func(struct _adapter *padapter, void *pcontext)
struct  __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
struct  mlme_priv   *pmlmepriv = &padapter->mlmepriv;
 
-   prframe = (union recv_frame *)pcontext;
+   prframe = pcontext;
orig_prframe = prframe;
pattrib = &prframe->u.hdr.attrib;
if (check_fwstate(pmlmepriv, WIFI_MP_STATE)) {
@@ -1124,7 +1123,7 @@ static int recvbuf2recvframe(struct _adapter *padapter, 
struct sk_buff *pskb)
 static void recv_tasklet(void *priv)
 {
struct sk_buff *pskb;
-   struct _adapter *padapter = (struct _adapter *)priv;
+   struct _adapter *padapter = priv;
struct recv_priv *precvpriv = &padapter->recvpriv;
 
while (NULL != (pskb = skb_dequeue(&precvpriv->rx_skb_queue))) {
-- 
2.7.4

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

[PATCH v4 2/5] staging: lustre: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/lustre/lustre/lmv/lmv_obd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c 
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 271e189..09b46924 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -640,7 +640,7 @@ static int lmv_fid2path(struct obd_export *exp, int len, 
void *karg,
int remote_gf_size = 0;
int rc;
 
-   gf = (struct getinfo_fid2path *)karg;
+   gf = karg;
tgt = lmv_find_target(lmv, &gf->gf_fid);
if (IS_ERR(tgt))
return PTR_ERR(tgt);
@@ -657,7 +657,7 @@ static int lmv_fid2path(struct obd_export *exp, int len, 
void *karg,
struct getinfo_fid2path *ori_gf;
char *ptr;
 
-   ori_gf = (struct getinfo_fid2path *)karg;
+   ori_gf = karg;
if (strlen(ori_gf->gf_path) +
strlen(gf->gf_path) > ori_gf->gf_pathlen) {
rc = -EOVERFLOW;
-- 
2.7.4

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

[PATCH v4 4/5] staging: rts5208: Remove unnecessary cast on void pointer

[simran singhal]

The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
  *((T *)e)
|
  ((T *)x)[...]
|
  ((T*)x)->f
|
- (T*)
  e
)

Signed-off-by: simran singhal 
---
 drivers/staging/rts5208/rtsx_transport.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 2379901..8b57e17 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -766,8 +766,7 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, 
void *buf, size_t len,
return -EIO;
 
if (use_sg) {
-   err = rtsx_transfer_sglist_adma(chip, card,
-   (struct scatterlist *)buf,
+   err = rtsx_transfer_sglist_adma(chip, card, buf,
use_sg, dma_dir, timeout);
} else {
err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
-- 
2.7.4

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

Re: [PATCH 1/7] staging: media: Remove unnecessary typecast of c90 int constant

[SIMRAN SINGHAL]

On Fri, Mar 3, 2017 at 11:15 PM, Sakari Ailus  wrote:
> Hi Simran,
>
> On Fri, Mar 03, 2017 at 01:21:56AM +0530, simran singhal wrote:
>> This patch removes unnecessary typecast of c90 int constant.
>>
>> WARNING: Unnecessary typecast of c90 int constant
>>
>> Signed-off-by: simran singhal 
>
> Which tree are these patches based on?
Can you please explain what's the problem with this patch. And
please elaborate your question.

>
> --
> Regards,
>
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] Re: [PATCH 1/7] staging: media: Remove unnecessary typecast of c90 int constant

[Julia Lawall]

On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote:

> On Fri, Mar 3, 2017 at 11:15 PM, Sakari Ailus  wrote:
> > Hi Simran,
> >
> > On Fri, Mar 03, 2017 at 01:21:56AM +0530, simran singhal wrote:
> >> This patch removes unnecessary typecast of c90 int constant.
> >>
> >> WARNING: Unnecessary typecast of c90 int constant
> >>
> >> Signed-off-by: simran singhal 
> >
> > Which tree are these patches based on?
> Can you please explain what's the problem with this patch. And
> please elaborate your question.

It is probably staging-testing.

julia


>
> >
> > --
> > Regards,
> >
> > Sakari Ailus
> > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyOeOK2k1K8Z2Yt3SmvJQ8A%2BvigNBsd39-paPwkRAY6CVQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/6] staging: speakup: Add blank line after function/struct/union/enum declarations

[Arushi Singhal]

This patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 1 +
 drivers/staging/speakup/serialio.c | 1 +
 drivers/staging/speakup/speakup_dtlk.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 01eabc19039c..17df20ec94be 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -108,6 +108,7 @@ enum {
CT_Window,
CT_Max
 };
+
 #define read_all_mode CT_Max
 
 static struct tty_struct *tty;
diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 7e6bc3b05da3..9b2626e85042 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -21,6 +21,7 @@ static void start_serial_interrupt(int irq);
 static const struct old_serial_port rs_table[] = {
SERIAL_PORT_DFNS
 };
+
 static const struct old_serial_port *serstate;
 static int timeouts;
 
diff --git a/drivers/staging/speakup/speakup_dtlk.c 
b/drivers/staging/speakup/speakup_dtlk.c
index 1ebe5012ec0b..e36360f65f36 100644
--- a/drivers/staging/speakup/speakup_dtlk.c
+++ b/drivers/staging/speakup/speakup_dtlk.c
@@ -43,6 +43,7 @@ static int port_forced;
 static unsigned int synth_portlist[] = {
 0x25e, 0x29e, 0x2de, 0x31e, 0x35e, 0x39e, 0
 };
+
 static u_char synth_status;
 
 static struct var_t vars[] = {
-- 
2.11.0

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

[PATCH 2/6] staging: speakup: simple_strtoul is replaced with kstrtoul

[Arushi Singhal]

This patch fixes "simple_strtoul is obsolete, use kstrtoul instead"
warning.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/kobjects.c| 4 ++--
 drivers/staging/speakup/main.c| 2 +-
 drivers/staging/speakup/varhandlers.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index edde9e68779e..a82698c66568 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -152,7 +152,7 @@ static ssize_t chars_chartab_store(struct kobject *kobj,
continue;
}
 
-   index = simple_strtoul(cp, &temp, 10);
+   index = kstrtoul(cp, &temp, 10);
if (index > 255) {
rejected++;
cp = linefeed + 1;
@@ -785,7 +785,7 @@ static ssize_t message_store_helper(const char *buf, size_t 
count,
continue;
}
 
-   index = simple_strtoul(cp, &temp, 10);
+   index = kstrtoul(cp, &temp, 10);
 
while ((temp < linefeed) && (*temp == ' ' || *temp == '\t'))
temp++;
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 17df20ec94be..b43e2e156602 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1945,7 +1945,7 @@ static int handle_goto(struct vc_data *vc, u_char type, 
u_char ch, u_short key)
return 1;
}
 
-   goto_pos = simple_strtoul(goto_buf, &cp, 10);
+   goto_pos = kstrtoul(goto_buf, &cp, 10);
 
if (*cp == 'x') {
if (*goto_buf < '0')
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..5107533bb45a 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -325,7 +325,7 @@ char *spk_s2uchar(char *start, char *dest)
 {
int val;
 
-   val = simple_strtoul(skip_spaces(start), &start, 10);
+   val = kstrtoul(skip_spaces(start), &start, 10);
if (*start == ',')
start++;
*dest = (u_char)val;
-- 
2.11.0

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

[PATCH 3/6] staging: speakup: Logical continuations should be on the previous line

[Arushi Singhal]

This patch fixes the checkpatch issue:
CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index b43e2e156602..4c3b5c627718 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -564,18 +564,18 @@ static u_long get_word(struct vc_data *vc)
*buf = '\0';
synth_printf("%s\n", spk_msg_get(MSG_SPACE));
return 0;
-   } else if ((tmpx < vc->vc_cols - 2)
-  && (ch == SPACE || ch == 0 || IS_WDLM(ch))
-  && ((char)get_char(vc, (u_short *)&tmp_pos + 1, &temp) >
-  SPACE)) {
+   } else if ((tmpx < vc->vc_cols - 2) &&
+  (ch == SPACE || ch == 0 || IS_WDLM(ch)) &&
+  ((char)get_char(vc, (u_short *)&tmp_pos + 1, &temp) >
+   SPACE)) {
tmp_pos += 2;
tmpx++;
} else
while (tmpx > 0) {
ch = (char)get_char(vc, (u_short *)tmp_pos - 1, &temp);
-   if ((ch == SPACE || ch == 0 || IS_WDLM(ch))
-   && ((char)get_char(vc, (u_short *)tmp_pos, &temp) >
-   SPACE))
+   if ((ch == SPACE || ch == 0 || IS_WDLM(ch)) &&
+   ((char)get_char(vc, (u_short *)tmp_pos, &temp) >
+SPACE))
break;
tmp_pos -= 2;
tmpx--;
@@ -586,8 +586,8 @@ static u_long get_word(struct vc_data *vc)
tmp_pos += 2;
tmpx++;
ch = (char)get_char(vc, (u_short *)tmp_pos, &temp);
-   if ((ch == SPACE) || ch == 0
-   || (IS_WDLM(buf[cnt - 1]) && (ch > SPACE)))
+   if ((ch == SPACE) || ch == 0 ||
+   (IS_WDLM(buf[cnt - 1]) && (ch > SPACE)))
break;
buf[cnt++] = ch;
}
@@ -725,8 +725,8 @@ static void spell_word(struct vc_data *vc)
synth_printf("%s", str_cap);
last_cap = str_cap;
}
-   if (this_speakup_key == SPELL_PHONETIC
-   && (isascii(ch) && isalpha(ch))) {
+   if (this_speakup_key == SPELL_PHONETIC &&
+   (isascii(ch) && isalpha(ch))) {
ch &= 31;
cp1 = phonetic[--ch];
} else {
@@ -895,8 +895,8 @@ static int get_sentence_buf(struct vc_data *vc, int 
read_punc)
while (start < end) {
sentbuf[bn][i] = (char)get_char(vc, (u_short *)start, &tmp);
if (i > 0) {
-   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == '.'
-   && numsentences[bn] < 9) {
+   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == 
'.' &&
+   numsentences[bn] < 9) {
/* Sentence Marker */
numsentences[bn]++;
sentmarks[bn][numsentences[bn]] =
@@ -1280,8 +1280,8 @@ void spk_reset_default_chars(void)
 
/* First, free any non-default */
for (i = 0; i < 256; i++) {
-   if (spk_characters[i]
-   && (spk_characters[i] != spk_default_chars[i]))
+   if (spk_characters[i] &&
+   (spk_characters[i] != spk_default_chars[i]))
kfree(spk_characters[i]);
}
 
@@ -2073,8 +2073,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
tty = vc->port.tty;
if (type >= 0xf0)
type -= 0xf0;
-   if (type == KT_PAD
-   && (vt_get_leds(fg_console, VC_NUMLOCK))) {
+   if (type == KT_PAD &&
+   (vt_get_leds(fg_console, VC_NUMLOCK))) {
if (up_flag) {
spk_keydown = 0;
goto out;
-- 
2.11.0

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

[PATCH 0/6] multiple checkpatch issues

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (6):
  staging: speakup: Add blank line after function/struct/union/enum
declarations
  staging: speakup: simple_strtoul is replaced with kstrtoul
  staging: speakup: Logical continuations should be on the previous line
  staging: speakup: Blank lines removed after an open brace '{'
  staging: speakup: Avoid multiple assignments on same line
  staging: speakup: fixes braces {} should be used on all arms of this
statement

 drivers/staging/speakup/kobjects.c |  5 +-
 drivers/staging/speakup/main.c | 84 --
 drivers/staging/speakup/serialio.c |  1 +
 drivers/staging/speakup/speakup_dtlk.c |  1 +
 drivers/staging/speakup/varhandlers.c  |  2 +-
 5 files changed, 55 insertions(+), 38 deletions(-)

-- 
2.11.0

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

[PATCH 6/6] staging: speakup: fixes braces {} should be used on all arms of this statement

[Arushi Singhal]

This patch fixes the checks reported by checkpatch.pl
for braces {} should be used on all arms of this statement.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 7915e75664f4..6179e0aafa25 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -640,8 +640,9 @@ static void say_prev_word(struct vc_data *vc)
break;
spk_y--;
spk_x = vc->vc_cols - 1;
-   } else
+   } else{
spk_x--;
+   }
spk_pos -= 2;
ch = (char)get_char(vc, (u_short *)spk_pos, &temp);
if (ch == SPACE || ch == 0)
@@ -694,8 +695,9 @@ static void say_next_word(struct vc_data *vc)
spk_y++;
spk_x = 0;
edge_said = edge_right;
-   } else
+   } else {
spk_x++;
+   }
spk_pos += 2;
last_state = state;
}
@@ -722,8 +724,9 @@ static void spell_word(struct vc_data *vc)
spk_pitch_shift++;
else/* synth has no pitch */
last_cap = spk_str_caps_stop;
-   } else
+   } else {
str_cap = spk_str_caps_stop;
+   }
if (str_cap != last_cap) {
synth_printf("%s", str_cap);
last_cap = str_cap;
@@ -1331,8 +1334,9 @@ static int speakup_allocate(struct vc_data *vc)
if (!speakup_console[vc_num])
return -ENOMEM;
speakup_date(vc);
-   } else if (!spk_parked)
+   } else if (!spk_parked) {
speakup_date(vc);
+   }
 
return 0;
 }
@@ -1385,8 +1389,9 @@ static void read_all_doc(struct vc_data *vc)
prev_cursor_track = cursor_track;
cursor_track = read_all_mode;
spk_reset_index_count(0);
-   if (get_sentence_buf(vc, 0) == -1)
+   if (get_sentence_buf(vc, 0) == -1) {
kbd_fakekey2(vc, RA_DOWN_ARROW);
+   }
else {
say_sentence_num(0, 0);
synth_insert_next_index(0);
@@ -1434,8 +1439,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
if (!say_sentence_num(sentcount + 1, 1)) {
sn = 1;
spk_reset_index_count(sn);
-   } else
+   } else {
synth_insert_next_index(0);
+   }
if (!say_sentence_num(sn, 0)) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
return;
@@ -1464,8 +1470,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
rv = get_sentence_buf(vc, 0);
if (rv == -1)
read_all_doc(vc);
-   if (rv == 0)
+   if (rv == 0) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
+   }
else {
say_sentence_num(1, 0);
synth_insert_next_index(0);
@@ -2162,10 +2169,11 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (type == KT_SPEC && value == 1) {
value = '\n';
type = KT_LATIN;
-   } else if (type == KT_LETTER)
+   } else if (type == KT_LETTER) {
type = KT_LATIN;
-   else if (value == 0x7f)
+   } else if (value == 0x7f) {
value = 8;  /* make del = backspace */
+   }
ret = (*spk_special_handler) (vc, type, value, keycode);
spk_close_press = 0;
if (ret < 0)
@@ -2259,8 +2267,9 @@ static int vt_notifier_call(struct notifier_block *nb,
speakup_deallocate(vc);
break;
case VT_WRITE:
-   if (param->c == '\b')
+   if (param->c == '\b') {
speakup_bs(vc);
+   }
else if (param->c < 0x100) {
char d = param->c;
 
-- 
2.11.0

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

[PATCH 4/6] staging: speakup: Blank lines removed after an open brace '{'

[Arushi Singhal]

Blank lines aren't necessary after an open brace '{' as reported by
Checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/kobjects.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index a82698c66568..16c4d3d1e873 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -761,7 +761,6 @@ static ssize_t message_store_helper(const char *buf, size_t 
count,
enum msg_index_t curmessage;
 
while (cp < end) {
-
while ((cp < end) && (*cp == ' ' || *cp == '\t'))
cp++;
 
-- 
2.11.0

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

[PATCH 5/6] staging: speakup: Avoid multiple assignments on same line

[Arushi Singhal]

This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 4c3b5c627718..7915e75664f4 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -269,9 +269,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
u16 *pos)
 
 static void speakup_date(struct vc_data *vc)
 {
-   spk_x = spk_cx = vc->vc_x;
-   spk_y = spk_cy = vc->vc_y;
-   spk_pos = spk_cp = vc->vc_pos;
+   spk_x = vc->vc_x;
+   spk_cx = vc->vc_x;
+   spk_y = vc->vc_y;
+   spk_cy = vc->vc_y;
+   spk_pos = vc->vc_pos;
+   spk_cp = vc->vc_pos;
spk_old_attr = spk_attr;
spk_attr = get_attributes(vc, (u_short *)spk_pos);
 }
@@ -1643,9 +1646,12 @@ static int speak_highlight(struct vc_data *vc)
spk_do_flush();
spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
speakup_console[vc_num]->ht.highsize[hc]);
-   spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
-   spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
-   spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
+   spk_pos = speakup_console[vc_num]->ht.rpos[hc];
+   spk_cp = speakup_console[vc_num]->ht.rpos[hc];
+   spk_x = speakup_console[vc_num]->ht.rx[hc];
+   spk_cx = speakup_console[vc_num]->ht.rx[hc];
+   spk_y = speakup_console[vc_num]->ht.ry[hc];
+   spk_cy = speakup_console[vc_num]->ht.ry[hc];
return 1;
}
return 0;
-- 
2.11.0

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

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laura Abbott]

On 03/03/2017 08:37 AM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patch.
> 
> On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
>> Technically, calling dma_buf_map_attachment should return a buffer
>> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
>> ensure this happens. As a side effect, this lets Ion buffers take
>> advantage of the dma_buf sync ioctls.
>>
>> Signed-off-by: Laura Abbott 
>> ---
>>  drivers/staging/android/ion/ion.c | 101 +--
>>  1 file changed, 50 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c index ce4adac..a931b30 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
>>  }
>>  EXPORT_SYMBOL(ion_client_destroy);
>>
>> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
>> -   struct device *dev,
>> -   enum dma_data_direction direction);
>> -
>>  static struct sg_table *dup_sg_table(struct sg_table *table)
>>  {
>>  struct sg_table *new_table;
>> @@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table
>> *table) return new_table;
>>  }
>>
>> +static void free_duped_table(struct sg_table *table)
>> +{
>> +sg_free_table(table);
>> +kfree(table);
>> +}
>> +
>>  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
>> *attachment, enum dma_data_direction direction)
>>  {
>>  struct dma_buf *dmabuf = attachment->dmabuf;
>>  struct ion_buffer *buffer = dmabuf->priv;
>> +struct sg_table *table;
>> +int ret;
>> +
>> +/*
>> + * TODO: Need to sync wrt CPU or device completely owning?
>> + */
>> +
>> +table = dup_sg_table(buffer->sg_table);
>>
>> -ion_buffer_sync_for_device(buffer, attachment->dev, direction);
>> -return dup_sg_table(buffer->sg_table);
>> +if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>> +direction)){
>> +ret = -ENOMEM;
>> +goto err;
>> +}
>> +
>> +err:
>> +free_duped_table(table);
>> +return ERR_PTR(ret);
>>  }
>>
>>  static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
>>struct sg_table *table,
>>enum dma_data_direction direction)
>>  {
>> -sg_free_table(table);
>> -kfree(table);
>> +dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>> +free_duped_table(table);
>>  }
>>
>>  void ion_pages_sync_for_device(struct device *dev, struct page *page,
>> @@ -864,38 +881,6 @@ struct ion_vma_list {
>>  struct vm_area_struct *vma;
>>  };
>>
>> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
>> -   struct device *dev,
>> -   enum dma_data_direction dir)
>> -{
>> -struct ion_vma_list *vma_list;
>> -int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
>> -int i;
>> -
>> -pr_debug("%s: syncing for device %s\n", __func__,
>> - dev ? dev_name(dev) : "null");
>> -
>> -if (!ion_buffer_fault_user_mappings(buffer))
>> -return;
>> -
>> -mutex_lock(&buffer->lock);
>> -for (i = 0; i < pages; i++) {
>> -struct page *page = buffer->pages[i];
>> -
>> -if (ion_buffer_page_is_dirty(page))
>> -ion_pages_sync_for_device(dev, ion_buffer_page(page),
>> -  PAGE_SIZE, dir);
>> -
>> -ion_buffer_page_clean(buffer->pages + i);
>> -}
>> -list_for_each_entry(vma_list, &buffer->vmas, list) {
>> -struct vm_area_struct *vma = vma_list->vma;
>> -
>> -zap_page_range(vma, vma->vm_start, vma->vm_end - vma-
>> vm_start);
>> -}
>> -mutex_unlock(&buffer->lock);
>> -}
>> -
>>  static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>  {
>>  struct ion_buffer *buffer = vma->vm_private_data;
>> @@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct
>> dma_buf *dmabuf, struct ion_buffer *buffer = dmabuf->priv;
>>  void *vaddr;
>>
>> -if (!buffer->heap->ops->map_kernel) {
>> -pr_err("%s: map kernel is not implemented by this heap.\n",
>> -   __func__);
>> -return -ENODEV;
>> +/*
>> + * TODO: Move this elsewhere because we don't always need a vaddr
>> + */
>> +if (buffer->heap->ops->map_kernel) {
>> +mutex_lock(&buffer->lock);
>> +vaddr = ion_buffer_kmap_get(buffer);
>> +mutex_unlock(&buffer->lock);
>>  }
>>
>> -mutex_lock(&buffer->lock);
>> -vaddr = ion_buffer_kmap_get(buffer);
>> -mutex_unlock(&buffer->lock);
>> -return PTR_ERR_OR_ZERO(vaddr);
>> +/*
>> + * Close enough right now? Flag to skip sync?
>> +   

Re: [Outreachy kernel] [PATCH 6/6] staging: speakup: fixes braces {} should be used on all arms of this statement

[Julia Lawall]

On Sat, 4 Mar 2017, Arushi Singhal wrote:

> This patch fixes the checks reported by checkpatch.pl
> for braces {} should be used on all arms of this statement.
>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 7915e75664f4..6179e0aafa25 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -640,8 +640,9 @@ static void say_prev_word(struct vc_data *vc)
>   break;
>   spk_y--;
>   spk_x = vc->vc_cols - 1;
> - } else
> + } else{

else needs a space after it.

julia

>   spk_x--;
> + }
>   spk_pos -= 2;
>   ch = (char)get_char(vc, (u_short *)spk_pos, &temp);
>   if (ch == SPACE || ch == 0)
> @@ -694,8 +695,9 @@ static void say_next_word(struct vc_data *vc)
>   spk_y++;
>   spk_x = 0;
>   edge_said = edge_right;
> - } else
> + } else {
>   spk_x++;
> + }
>   spk_pos += 2;
>   last_state = state;
>   }
> @@ -722,8 +724,9 @@ static void spell_word(struct vc_data *vc)
>   spk_pitch_shift++;
>   else/* synth has no pitch */
>   last_cap = spk_str_caps_stop;
> - } else
> + } else {
>   str_cap = spk_str_caps_stop;
> + }
>   if (str_cap != last_cap) {
>   synth_printf("%s", str_cap);
>   last_cap = str_cap;
> @@ -1331,8 +1334,9 @@ static int speakup_allocate(struct vc_data *vc)
>   if (!speakup_console[vc_num])
>   return -ENOMEM;
>   speakup_date(vc);
> - } else if (!spk_parked)
> + } else if (!spk_parked) {
>   speakup_date(vc);
> + }
>
>   return 0;
>  }
> @@ -1385,8 +1389,9 @@ static void read_all_doc(struct vc_data *vc)
>   prev_cursor_track = cursor_track;
>   cursor_track = read_all_mode;
>   spk_reset_index_count(0);
> - if (get_sentence_buf(vc, 0) == -1)
> + if (get_sentence_buf(vc, 0) == -1) {
>   kbd_fakekey2(vc, RA_DOWN_ARROW);
> + }
>   else {
>   say_sentence_num(0, 0);
>   synth_insert_next_index(0);
> @@ -1434,8 +1439,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
> int command)
>   if (!say_sentence_num(sentcount + 1, 1)) {
>   sn = 1;
>   spk_reset_index_count(sn);
> - } else
> + } else {
>   synth_insert_next_index(0);
> + }
>   if (!say_sentence_num(sn, 0)) {
>   kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
>   return;
> @@ -1464,8 +1470,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
> int command)
>   rv = get_sentence_buf(vc, 0);
>   if (rv == -1)
>   read_all_doc(vc);
> - if (rv == 0)
> + if (rv == 0) {
>   kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
> + }
>   else {
>   say_sentence_num(1, 0);
>   synth_insert_next_index(0);
> @@ -2162,10 +2169,11 @@ speakup_key(struct vc_data *vc, int shift_state, int 
> keycode, u_short keysym,
>   if (type == KT_SPEC && value == 1) {
>   value = '\n';
>   type = KT_LATIN;
> - } else if (type == KT_LETTER)
> + } else if (type == KT_LETTER) {
>   type = KT_LATIN;
> - else if (value == 0x7f)
> + } else if (value == 0x7f) {
>   value = 8;  /* make del = backspace */
> + }
>   ret = (*spk_special_handler) (vc, type, value, keycode);
>   spk_close_press = 0;
>   if (ret < 0)
> @@ -2259,8 +2267,9 @@ static int vt_notifier_call(struct notifier_block *nb,
>   speakup_deallocate(vc);
>   break;
>   case VT_WRITE:
> - if (param->c == '\b')
> + if (param->c == '\b') {
>   speakup_bs(vc);
> + }
>   else if (param->c < 0x100) {
>   char d = param->c;
>
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> T

Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

[Laura Abbott]

On 03/03/2017 12:18 AM, Hillf Danton wrote:
> 
> On March 03, 2017 5:45 AM Laura Abbott wrote: 
>>
>> +static struct sg_table *dup_sg_table(struct sg_table *table)
>> +{
>> +struct sg_table *new_table;
>> +int ret, i;
>> +struct scatterlist *sg, *new_sg;
>> +
>> +new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
>> +if (!new_table)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
>> +if (ret) {
>> +kfree(table);
> 
> Free new table?
> 
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +new_sg = new_table->sgl;
>> +for_each_sg(table->sgl, sg, table->nents, i) {
>> +memcpy(new_sg, sg, sizeof(*sg));
>> +sg->dma_address = 0;
>> +new_sg = sg_next(new_sg);
>> +}
>> +
> 
> Do we need a helper, sg_copy_table(dst_table, src_table)?
> 
>> +return new_table;
>> +}
>> +

Yes, that would probably be good since I've seen this
code elsewhere.

Thanks,
Laura

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

Re: [Outreachy kernel] [PATCH 5/6] staging: speakup: Avoid multiple assignments on same line

[Julia Lawall]

On Sat, 4 Mar 2017, Arushi Singhal wrote:

> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."
>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 4c3b5c627718..7915e75664f4 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -269,9 +269,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
> u16 *pos)
>
>  static void speakup_date(struct vc_data *vc)
>  {
> - spk_x = spk_cx = vc->vc_x;
> - spk_y = spk_cy = vc->vc_y;
> - spk_pos = spk_cp = vc->vc_pos;
> + spk_x = vc->vc_x;
> + spk_cx = vc->vc_x;
> + spk_y = vc->vc_y;
> + spk_cy = vc->vc_y;
> + spk_pos = vc->vc_pos;
> + spk_cp = vc->vc_pos;
>   spk_old_attr = spk_attr;
>   spk_attr = get_attributes(vc, (u_short *)spk_pos);
>  }
> @@ -1643,9 +1646,12 @@ static int speak_highlight(struct vc_data *vc)
>   spk_do_flush();
>   spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
>   speakup_console[vc_num]->ht.highsize[hc]);
> - spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
> - spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
> - spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
> + spk_pos = speakup_console[vc_num]->ht.rpos[hc];
> + spk_cp = speakup_console[vc_num]->ht.rpos[hc];
> + spk_x = speakup_console[vc_num]->ht.rx[hc];
> + spk_cx = speakup_console[vc_num]->ht.rx[hc];
> + spk_y = speakup_console[vc_num]->ht.ry[hc];
> + spk_cy = speakup_console[vc_num]->ht.ry[hc];

It could be better to put eg spk_cp = spk_pos;.  Repeating th big
expression on the right hand side could be error prone in the long term.

julia

>   return 1;
>   }
>   return 0;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170303183707.14830-6-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH 2/6] staging: speakup: simple_strtoul is replaced with kstrtoul

[Julia Lawall]

On Sat, 4 Mar 2017, Arushi Singhal wrote:

> This patch fixes "simple_strtoul is obsolete, use kstrtoul instead"
> warning.
>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/kobjects.c| 4 ++--
>  drivers/staging/speakup/main.c| 2 +-
>  drivers/staging/speakup/varhandlers.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/speakup/kobjects.c 
> b/drivers/staging/speakup/kobjects.c
> index edde9e68779e..a82698c66568 100644
> --- a/drivers/staging/speakup/kobjects.c
> +++ b/drivers/staging/speakup/kobjects.c
> @@ -152,7 +152,7 @@ static ssize_t chars_chartab_store(struct kobject *kobj,
>   continue;
>   }
>
> - index = simple_strtoul(cp, &temp, 10);
> + index = kstrtoul(cp, &temp, 10);

It seems unlikely that you actually compiled this code.  The argument list
for kstrtoul has a completely different set of types.

julia

>   if (index > 255) {
>   rejected++;
>   cp = linefeed + 1;
> @@ -785,7 +785,7 @@ static ssize_t message_store_helper(const char *buf, 
> size_t count,
>   continue;
>   }
>
> - index = simple_strtoul(cp, &temp, 10);
> + index = kstrtoul(cp, &temp, 10);
>
>   while ((temp < linefeed) && (*temp == ' ' || *temp == '\t'))
>   temp++;
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 17df20ec94be..b43e2e156602 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1945,7 +1945,7 @@ static int handle_goto(struct vc_data *vc, u_char type, 
> u_char ch, u_short key)
>   return 1;
>   }
>
> - goto_pos = simple_strtoul(goto_buf, &cp, 10);
> + goto_pos = kstrtoul(goto_buf, &cp, 10);
>
>   if (*cp == 'x') {
>   if (*goto_buf < '0')
> diff --git a/drivers/staging/speakup/varhandlers.c 
> b/drivers/staging/speakup/varhandlers.c
> index cc984196020f..5107533bb45a 100644
> --- a/drivers/staging/speakup/varhandlers.c
> +++ b/drivers/staging/speakup/varhandlers.c
> @@ -325,7 +325,7 @@ char *spk_s2uchar(char *start, char *dest)
>  {
>   int val;
>
> - val = simple_strtoul(skip_spaces(start), &start, 10);
> + val = kstrtoul(skip_spaces(start), &start, 10);
>   if (*start == ',')
>   start++;
>   *dest = (u_char)val;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170303183707.14830-3-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laura Abbott]

On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>>> Now that we call dma_map in the dma_buf API callbacks there is no need
>>> to use the existing cache APIs. Remove the sync ioctl and the existing
>>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>>> sync API.
>>>
>>> Signed-off-by: Laura Abbott 
>>> ---
>>>
>>>  drivers/staging/android/ion/ion-ioctl.c |  5 
>>>  drivers/staging/android/ion/ion.c   | 40 
>>>  drivers/staging/android/ion/ion_carveout_heap.c |  6 
>>>  drivers/staging/android/ion/ion_chunk_heap.c|  6 
>>>  drivers/staging/android/ion/ion_page_pool.c |  3 --
>>>  drivers/staging/android/ion/ion_system_heap.c   |  5 
>>>  6 files changed, 65 deletions(-)
>>>
>>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>>> --- a/drivers/staging/android/ion/ion-ioctl.c
>>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>>> unsigned long arg)> 
>>> data.handle.handle = handle->id;
>>> 
>>> break;
>>> 
>>> }
>>>
>>> -   case ION_IOC_SYNC:
>>> -   {
>>> -   ret = ion_sync_for_device(client, data.fd.fd);
>>> -   break;
>>> -   }
>>
>> You missed the case ION_IOC_SYNC: in compat_ion.c.
>>
>> While at it: Should we also remove the entire custom_ioctl infrastructure?
>> It's entirely unused afaict, and for a pure buffer allocator I don't see
>> any need to have custom ioctl.
> 
> I second that, if you want to make ion a standard API, then we certainly 
> don't 
> want any custom ioctl.
> 
>> More code to remove potentially:
>> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>>   would allow us to remove compat_ion.c entirely.
>>
>> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>>   still need to be able to import anything. All the cache flushing/mapping
>>   is done through dma-buf ops/ioctls.
>>
>>

Good point to all of the above. I was considering keeping the import around
for backwards compatibility reasons but given how much other stuff is being
potentially broken, everything should just get ripped out.

Thanks,
Laura

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

Re: [patch 1/3] speakup: extend synth buffer to 16bit unicode characters

[Chris Brannon]

Samuel Thibault  writes:

> This extends the synth buffer slots to 16bit, so as to hold 16bit
> unicode characters.
>
> synth_buffer_getc and synth_buffer_peek now return 16bit characters.
> Speech synthesizers which do not support characters beyond latin1 can
> use the synth_buffer_skip_nonlatin1() helper to skip the non-latin1
> characters before getting or peeking. All synthesizers are made to use
> it for now.
>
> This makes synth_buffer_add take a 16bit character. For simplicity for
> now, synth_printf is left to using latin1 formats and strings.
> synth_putwc, synth_putwc_s, synth_putws and synth_putws_s helpers are
> however added to put 16bit characters and strings.
>
> Signed-off-by: Samuel Thibault 


Reviewed-by: Chris Brannon 


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

Re: [patch 3/3] speakup: add unicode variant of /dev/softsynth

[Chris Brannon]

Samuel Thibault  writes:

> This adds /dev/softsynthu, along /dev/softsynth, which emits output in
> UTF-8 encoding, thus allowing to support 16bit characters.  Most of the
> code is shared, only the read function has to behave differently in
> latin1 and in unicode mode.  Since Linux only supports 16bit characters,
> we can just hardcode the UTF-8 encoding.
>
> Signed-off-by: Samuel Thibault 


Reviewed-by: Chris Brannon 

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

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laura Abbott]

On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patch.
> 
> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
>> When CMA was first introduced, its primary use was for DMA allocation
>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>> put Ion in an awkward position since there was no device structure
>> readily available and setting one up messed up the coherency model.
>> These days, CMA can be allocated directly from the APIs. Switch to using
>> this model to avoid needing a dummy device. This also avoids awkward
>> caching questions.
> 
> If the DMA mapping API isn't suitable for today's requirements anymore, I 
> believe that's what needs to be fixed, instead of working around the problem 
> by introducing another use-case-specific API.
> 

I don't think this is a usecase specific API. CMA has been decoupled from
DMA already because it's used in other places. The trying to go through
DMA was just another layer of abstraction, especially since there isn't
a device available for allocation.

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

[PATCH 0/2] Clean up tests if NULL returned on failure

[simran singhal]

This patch series tests if functions like kmalloc/kzalloc return NULL 
on failure. When NULL represents failure, !x is commonly used.

simran singhal (2):
  staging: media: Clean up tests if NULL returned on failure
  staging: rtl8192e: Clean up tests if NULL returned on failure

 drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c | 2 +-
 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c  | 4 ++--
 drivers/staging/media/lirc/lirc_zilog.c   | 6 +++---
 drivers/staging/rtl8192e/rtllib_crypt_ccmp.c  | 2 +-
 drivers/staging/rtl8192e/rtllib_crypt_tkip.c  | 2 +-
 drivers/staging/rtl8192e/rtllib_crypt_wep.c   | 2 +-
 drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
 drivers/staging/rtl8192e/rtllib_wx.c  | 4 ++--
 8 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.7.4

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

[PATCH 2/2] staging: rtl8192e: Clean up tests if NULL returned on failure

[simran singhal]

Some functions like kmalloc/kzalloc return NULL on failure.
When NULL represents failure, !x is commonly used.

This was done using Coccinelle:
@@
expression *e;
identifier l1;
@@

e = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\)(...);
...
- e == NULL
+ !e

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 2 +-
 drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 2 +-
 drivers/staging/rtl8192e/rtllib_crypt_wep.c  | 2 +-
 drivers/staging/rtl8192e/rtllib_softmac.c| 2 +-
 drivers/staging/rtl8192e/rtllib_wx.c | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c 
b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
index bc45cf0..ed2e06f 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
@@ -63,7 +63,7 @@ static void *rtllib_ccmp_init(int key_idx)
struct rtllib_ccmp_data *priv;
 
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
-   if (priv == NULL)
+   if (!priv)
goto fail;
priv->key_idx = key_idx;
 
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c 
b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
index ae103b0..580b57a 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
@@ -63,7 +63,7 @@ static void *rtllib_tkip_init(int key_idx)
struct rtllib_tkip_data *priv;
 
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
-   if (priv == NULL)
+   if (!priv)
goto fail;
priv->key_idx = key_idx;
priv->tx_tfm_arc4 = crypto_alloc_skcipher("ecb(arc4)", 0,
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_wep.c 
b/drivers/staging/rtl8192e/rtllib_crypt_wep.c
index b3343a5..f5a1bc5 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_wep.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_wep.c
@@ -37,7 +37,7 @@ static void *prism2_wep_init(int keyidx)
struct prism2_wep_data *priv;
 
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
-   if (priv == NULL)
+   if (!priv)
goto fail;
priv->key_idx = keyidx;
 
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index eeda17d..4bdc3ba 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -3328,7 +3328,7 @@ static int rtllib_wpa_set_encryption(struct rtllib_device 
*ieee,
lib80211_crypt_delayed_deinit(&ieee->crypt_info, crypt);
 
new_crypt = kzalloc(sizeof(*new_crypt), GFP_KERNEL);
-   if (new_crypt == NULL) {
+   if (!new_crypt) {
ret = -ENOMEM;
goto done;
}
diff --git a/drivers/staging/rtl8192e/rtllib_wx.c 
b/drivers/staging/rtl8192e/rtllib_wx.c
index b1500ee..9f3824a 100644
--- a/drivers/staging/rtl8192e/rtllib_wx.c
+++ b/drivers/staging/rtl8192e/rtllib_wx.c
@@ -373,7 +373,7 @@ int rtllib_wx_set_encode(struct rtllib_device *ieee,
/* take WEP into use */
new_crypt = kzalloc(sizeof(struct lib80211_crypt_data),
GFP_KERNEL);
-   if (new_crypt == NULL)
+   if (!new_crypt)
return -ENOMEM;
new_crypt->ops = lib80211_get_crypto_ops("R-WEP");
if (!new_crypt->ops) {
@@ -618,7 +618,7 @@ int rtllib_wx_set_encode_ext(struct rtllib_device *ieee,
lib80211_crypt_delayed_deinit(&ieee->crypt_info, crypt);
 
new_crypt = kzalloc(sizeof(*new_crypt), GFP_KERNEL);
-   if (new_crypt == NULL) {
+   if (!new_crypt) {
ret = -ENOMEM;
goto done;
}
-- 
2.7.4

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

[PATCH 1/2] staging: media: Clean up tests if NULL returned on failure

[simran singhal]

Some functions like kmalloc/kzalloc return NULL on failure.
When NULL represents failure, !x is commonly used.

This was done using Coccinelle:
@@
expression *e;
identifier l1;
@@

e = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\)(...);
...
- e == NULL
+ !e

Signed-off-by: simran singhal 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c | 2 +-
 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c  | 4 ++--
 drivers/staging/media/lirc/lirc_zilog.c   | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
index 20e581e..e5a7407 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
@@ -1100,7 +1100,7 @@ int atomisp_videobuf_mmap_mapper(struct videobuf_queue *q,
continue;
 
map = kzalloc(sizeof(struct videobuf_mapping), GFP_KERNEL);
-   if (map == NULL) {
+   if (!map) {
mutex_unlock(&q->vb_lock);
return -ENOMEM;
}
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c 
b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
index 32109cd..bffe215 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
@@ -228,7 +228,7 @@ static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
 
vpfe_dev->clks = kcalloc(vpfe_cfg->num_clocks,
 sizeof(*vpfe_dev->clks), GFP_KERNEL);
-   if (vpfe_dev->clks == NULL)
+   if (!vpfe_dev->clks)
return -ENOMEM;
 
for (i = 0; i < vpfe_cfg->num_clocks; i++) {
@@ -348,7 +348,7 @@ static int register_i2c_devices(struct vpfe_device 
*vpfe_dev)
vpfe_dev->sd =
  kcalloc(num_subdevs, sizeof(struct v4l2_subdev *),
  GFP_KERNEL);
-   if (vpfe_dev->sd == NULL)
+   if (!vpfe_dev->sd)
return -ENOMEM;
 
for (i = 0, k = 0; i < num_subdevs; i++) {
diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
index 34aac3e..4836182 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -1475,7 +1475,7 @@ static int ir_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
ir = get_ir_device_by_adapter(adap);
if (ir == NULL) {
ir = kzalloc(sizeof(struct IR), GFP_KERNEL);
-   if (ir == NULL) {
+   if (!ir) {
ret = -ENOMEM;
goto out_no_ir;
}
@@ -1515,7 +1515,7 @@ static int ir_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
/* Set up a struct IR_tx instance */
tx = kzalloc(sizeof(struct IR_tx), GFP_KERNEL);
-   if (tx == NULL) {
+   if (!tx) {
ret = -ENOMEM;
goto out_put_xx;
}
@@ -1559,7 +1559,7 @@ static int ir_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
/* Set up a struct IR_rx instance */
rx = kzalloc(sizeof(struct IR_rx), GFP_KERNEL);
-   if (rx == NULL) {
+   if (!rx) {
ret = -ENOMEM;
goto out_put_xx;
}
-- 
2.7.4

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

[PATCH 2/2] Staging: wlan-ng: Fix endian error

[Adrien Descamps]

sparse report fixed:
drivers/staging//wlan-ng//hfa384x_usb.c:3517:35: warning: restricted __be64 
degrades to integer
drivers/staging//wlan-ng//hfa384x_usb.c:3517:33: warning: incorrect type in 
assignment (different base types)
drivers/staging//wlan-ng//hfa384x_usb.c:3517:33:expected restricted __be64 
[usertype] mactime
drivers/staging//wlan-ng//hfa384x_usb.c:3517:33:got unsigned long long

Computation on the value should be done when in machine format, not in big 
endian format.

Signed-off-by: Adrien Descamps 
---
Compile tested only
 drivers/staging/wlan-ng/hfa384x_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c 
b/drivers/staging/wlan-ng/hfa384x_usb.c
index f26cc19..29b059f 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3514,7 +3514,7 @@ static void hfa384x_int_rxmonitor(struct wlandevice 
*wlandev,
 
caphdr->version = htonl(P80211CAPTURE_VERSION);
caphdr->length = htonl(sizeof(struct p80211_caphdr));
-   caphdr->mactime = __cpu_to_be64(rxdesc->time) * 1000;
+   caphdr->mactime = __cpu_to_be64(rxdesc->time * 1000);
caphdr->hosttime = __cpu_to_be64(jiffies);
caphdr->phytype = htonl(4); /* dss_dot11_b */
caphdr->channel = htonl(hw->sniff_channel);
-- 
2.1.4

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