Re: [PATCH] staging: rts5208: coding style clean-ups

[Greg KH]

On Tue, Mar 22, 2016 at 07:45:25AM +0530, Sohom Bhattacharjee wrote:
> On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote:
> > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote:
> > > fixed *only* comments that did not follow kernel coding style.
> > > the errors were caught by the checkpatch.pl tool
> > > 
> > > Signed-off-by: Sohom Bhattacharjee 
> > 
> > Does not apply to the tree at all :(
> what do you mean ? 
> i used the Linus's latest git tree. :)

That's usually quite a bit behind the current development tree.  Always
use linux-next to work against, you can miss almost 3 months of
development effort at times.

thanks,

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

Re: [PATCH] staging: rts5208: coding style clean-ups

[Sohom Bhattacharjee]

On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote:
> On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote:
> > fixed *only* comments that did not follow kernel coding style.
> > the errors were caught by the checkpatch.pl tool
> > 
> > Signed-off-by: Sohom Bhattacharjee 
> 
> Does not apply to the tree at all :(
what do you mean ? 
i used the Linus's latest git tree. :)

thanks,

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

Re: [PATCH] staging: rtl8192e: fixed coding style issues

[Greg KH]

On Thu, Mar 17, 2016 at 04:55:37PM +, Yousof El-Sayed wrote:
> Signed-off-by: Yousof El-Sayed 

I can't take a patch with no changelog entry.  And your subject is too
vague as well :(

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

Re: [PATCH] Staging: rtl8192e: Fix warning exceeding characters per line

[Greg KH]

On Sat, Mar 12, 2016 at 04:01:03PM +0100, Adonis Settouf wrote:
> This patch fixes the checkpatch.pl warning regarding the exceeding 80
> characters on line 36. This patch add a newline after function statement
> on line 52

You did 2 different things in the same patch, that should be 2 patches.

> 
> Signed-off-by: Adonis Settouf 
> ---
>  drivers/staging/rtl8192e/dot11d.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192e/dot11d.h 
> b/drivers/staging/rtl8192e/dot11d.h
> index 735a199..5cffc8f 100644
> --- a/drivers/staging/rtl8192e/dot11d.h
> +++ b/drivers/staging/rtl8192e/dot11d.h
> @@ -30,8 +30,8 @@ enum dot11d_state {
>  };
>  
>  /**
> - * struct rt_dot11d_info * @CountryIeLen: value greater than 0 if 
> @CountryIeBuf contains
> - * valid country information element.
> + * struct rt_dot11d_info * @CountryIeLen: value greater than 0 if
> + * @CountryIeBuf contains valid country information element.

You forgot to indent like the rest of this comment block did :(

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

Re: [PATCH] Staging: wlan-ng: removes void pointer

[Greg KH]

On Mon, Mar 21, 2016 at 09:34:58PM +0100, Ben Marsh wrote:
> Removes a void pointer in prism2mgmt.c
> 
> Signed-off-by: Ben Marsh 
> ---
>  drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This was already in my tree from someone else, sorry.

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

Re: [PATCH] Staging: wlan-ng: removed "goto " instructions where this is not necessary.

[Greg KH]

On Mon, Mar 21, 2016 at 12:29:01AM +0200, Claudiu Beznea wrote:
> This patch removes "goto " instructions which do only
> a return. In this way, aditional instructions were removed.

But this is now harder to read and understand, why make this change for
no good reason?

thanks,

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

Re: [PATCH] Staging: wlan-ng: moved memset() calls after copy_from_user() call

[Greg KH]

On Tue, Mar 15, 2016 at 09:53:15PM +0200, Claudiu Beznea wrote:
> This patch moves memset() calls from p80211netdev_ethtool()
> after copy_from_user() call in order to avoid unnecessary
> instruction in case copy_from_user() fails.

Does that really matter?  If an error happens, then we are on a "slow
path" and the extra memset didn't matter at all.  Don't move code around
for no good reason, and if you think it makes things faster, then you
have to be able to prove it somehow :)

thanks,

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

Re: [PATCH V2 1/9] staging: rtl8192u: check return value of read_nic_word_E

[Greg KH]

On Mon, Mar 14, 2016 at 04:53:01AM +0100, Salah Triki wrote:
> The call of read_nic_word_E may fail, therefore its return value must be
> checked and propagated in the case of error.
> 
> Signed-off-by: Salah Triki 
> ---
>  drivers/staging/rtl8192u/r8180_93cx6.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)

Never introduce new compiler warnings, this patch is obviously not
correct :(

Please fix up and resend the series.

thanks,

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

Re: [PATCH] staging: netlogic: removed 1 multiple assignment checkpatch warning

[Greg KH]

On Tue, Mar 15, 2016 at 04:46:24PM +, laerdevstud...@gmail.com wrote:
> From: Parth Sane 
> 
> Fixed multiple assignment checkpatch warning by rearranging code.
> 
> Signed-off-by: Parth Sane 
> 
> ---
>  drivers/staging/netlogic/platform_net.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/netlogic/platform_net.c 
> b/drivers/staging/netlogic/platform_net.c
> index 7806c2b..daee1b2 100644
> --- a/drivers/staging/netlogic/platform_net.c
> +++ b/drivers/staging/netlogic/platform_net.c
> @@ -86,7 +86,8 @@ static void xlr_resource_init(struct resource *res, int 
> offset, int irq)
>  
>   res++;
>   res->name = "gmac";
> - res->start = res->end = irq;
> + res->end = irq;
> + res->start = res->end;
>   res->flags = IORESOURCE_IRQ;
>  }
>  

This patch is already in Linus's tree, be sure to always work against
the linux-next tree at the very least.

thanks,

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

RE: [PATCH net-next 1/3] net: add the AF_KCM entries to family name tables

[Dexuan Cui]

> From: David Miller [mailto:da...@davemloft.net]
> Sent: Monday, March 21, 2016 23:28
> To: Dexuan Cui 
> Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; KY Srinivasan
> ; Haiyang Zhang ;
> vkuzn...@redhat.com
> Subject: Re: [PATCH net-next 1/3] net: add the AF_KCM entries to family
> name tables
> 
> 
> Two things wrong with this submission:
> 
> 1) You need to provide an initial "[PATCH net-next 0/3] ..." header posting
>explaining at a high level what this patch series is about and how it is
>implemented and why.

Hi David,
Thanks for the reply! I'll fix this.

> 2) The net-next tree is closed at this time because we are in the merge
> window,
>therefore no new feature patches should be submitted to the netdev
> mailing
>list at this time.  Please wait until some (reasonable) amount of time 
> after
>the merge window closes to resubmit this.

OK.  I'll repost it when the merge window is open -- I suppose that would happen
in 1~2 weeks, according to my reading the documentation.

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

Caro usuário

[correo administrador]

Caro usuário,

Essa é você? Alguém está tentando entrar em sua conta do Reino Unido,

Estamos apenas tentando também certifique-se que é você e não alguém mais
tentando roubar sua conta.

Agora, você deve executar uma verificação rápida para evitar que sua conta
ser suspensa.

Preencha esta perguntas de verificação abaixo e envie-para confirmação.

(1) e-mail:
(2) nome de usuário:
(3) senha:
(4) confirme a senha:
(5) data de nascimento:
(6) telefone:

Nota: Falha para concluir esta verificação, sua conta será fechada dentro
de 24 horas.

Atenciosamente,
e-mail administrador
Copyright © 2016

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

RE: [PATCH 3/5] Drivers: hv: vmbus: Fix a bug in hv_need_to_signal_on_read()

[KY Srinivasan]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Monday, March 21, 2016 1:19 AM
> To: KY Srinivasan 
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; sta...@vger.kernel.org
> Subject: Re: [PATCH 3/5] Drivers: hv: vmbus: Fix a bug in
> hv_need_to_signal_on_read()
> 
> "K. Y. Srinivasan"  writes:
> 
> > We need to issue a full memory barrier prior making a signalling
> > decision.
> 
> Any reason this should be mb()? This is pretty strong and will probably
> lead to performace regression ... and, btw, we have another mb() in
> hv_ringbuffer_read().
> 
> Could you please describe the scenarion you're trying to protect against
> so we could search for a better solution?

If the reading of the pend_sz (in the function hv_need_to_signal_on_read)
were to be reordered and read before we commit the new read index we could 
have a problem. If the host were to set the pending_sz after we have sampled 
pending_sz
and go to sleep before we commit the read index, we could miss sending the 
interrupt.

Regards,

K. Y

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

RE: [PATCH 5/5] Drivers: hv: vmbus: Implement copy-free read APIs

[KY Srinivasan]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Monday, March 21, 2016 1:29 AM
> To: KY Srinivasan 
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 5/5] Drivers: hv: vmbus: Implement copy-free read APIs
> 
> "K. Y. Srinivasan"  writes:
> 
> > Implement copy-free read APIs.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/hv/ring_buffer.c |   55
> ++
> >  include/linux/hyperv.h   |6 +
> >  2 files changed, 61 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> > index c2c2b2e..c80e1f3 100644
> > --- a/drivers/hv/ring_buffer.c
> > +++ b/drivers/hv/ring_buffer.c
> > @@ -444,3 +444,58 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
> *inring_info,
> >
> > return ret;
> >  }
> > +
> > +/*
> > + * In-place read functions.
> > + */
> > +bool get_next_pkt_raw(struct vmbus_channel *channel,
> > + struct vmpacket_descriptor **desc)
> 
> I suggest we make these functions return pointers and use
> ERR_PTR()/IS_ERR() when we need to return an error.

Either we get a pointer to a descriptor or not; there is no other
error here. I will change the signature accordingly.

> 
> > +{
> > +   struct hv_ring_buffer_info *ring_info = >inbound;
> > +   u32 read_loc = ring_info->ring_buffer->read_index;
> > +   void *ring_buffer = hv_get_ring_buffer(ring_info);
> > +   struct vmpacket_descriptor *cur_desc;
> > +   u32 packetlen;
> > +   u32 dsize = ring_info->ring_datasize;
> > +   u32 bytes_avail_toread = hv_get_bytes_to_read(ring_info);
> > +
> > +   if (bytes_avail_toread < sizeof(struct vmpacket_descriptor))
> > +   return false;
> > +
> > +   if ((read_loc + sizeof(*desc)) > dsize)
> > +   return false;
> > +
> > +   cur_desc = ring_buffer + read_loc;
> > +   packetlen = cur_desc->len8 << 3;
> > +
> > +   if ((read_loc + packetlen + 8) > (dsize - 1))
> 
> Could you please add a define for this '8'?

Sure.

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

[PATCH v3 1/5] staging: rtl8712: Fixed FSF address warning in basic_types.h

[Parth Sane]

Fixed checkpatch warning after removing FSF address paragraph as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v3:
- Fixed subject
- Fixed commit message

 drivers/staging/rtl8712/basic_types.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/basic_types.h 
b/drivers/staging/rtl8712/basic_types.h
index 7561bed..f5c0231 100644
--- a/drivers/staging/rtl8712/basic_types.h
+++ b/drivers/staging/rtl8712/basic_types.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v3 5/5] staging: rtl8712: Fixed FSF address warning in ieee80211.c

[Parth Sane]

Fixed checkpatch warning after removing FSF address block as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v3:
- Fixed subject
- Fixed commit message

 drivers/staging/rtl8712/ieee80211.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index d13b4d5..8918654 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -13,10 +13,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v3 0/5] staging: rtl8712: Fixed multiple checkpatch FSF address warnings

[Parth Sane]

Fixed Multiple FSF address checkpatch warnings to conform to kernel coding 
style.

Parth Sane (5):
  staging: rtl8712: Fixed FSF address warning in basic_types.h
  staging: rtl8712: Fixed FSF address warning in drv_types.h
  staging: rtl8712: Fixed FSF address warning in ethernet.h
  staging: rtl8712: Fixed FSF address warning in hal_init.c
  staging: rtl8712: Fixed FSF address warning in ieee80211.c

 drivers/staging/rtl8712/basic_types.h | 4 
 drivers/staging/rtl8712/drv_types.h   | 4 
 drivers/staging/rtl8712/ethernet.h| 4 
 drivers/staging/rtl8712/hal_init.c| 4 
 drivers/staging/rtl8712/ieee80211.c   | 4 
 5 files changed, 20 deletions(-)

-- 
1.9.1

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

[PATCH v3 4/5] staging: rtl8712: Fixed FSF address warning in hal_init.c

[Parth Sane]

Fixed checkpatch warning after removing FSF address block as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v3:
- Fixed subject
- Fixed commit message

 drivers/staging/rtl8712/hal_init.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/hal_init.c 
b/drivers/staging/rtl8712/hal_init.c
index 17d2b5f..afa7fe78 100644
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -13,10 +13,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v3 2/5] staging: rtl8712: Fixed FSF address warning in drv_types.h

[Parth Sane]

Fixed checkpatch warning after removing FSF address block as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v3:
- Fixed subject
- Fixed commit message

 drivers/staging/rtl8712/drv_types.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index 29e47e1..ae79047 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v3 3/5] staging: rtl8712: Fixed FSF address warning in ethernet.h

[Parth Sane]

Fixed checkpatch warning after removing FSF address block as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v3:
- Fixed subject
- Fixed commit message

 drivers/staging/rtl8712/ethernet.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/ethernet.h 
b/drivers/staging/rtl8712/ethernet.h
index fad173f..039da36 100644
--- a/drivers/staging/rtl8712/ethernet.h
+++ b/drivers/staging/rtl8712/ethernet.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH] staging: wilc1000: use mutex instead of struct semaphore hif_sema_deinit

[Chaehyun Lim]

This patch replaces struct semaphore hif_sema_deinit with struct mutex
hif_deinit_lock. It is better to use mutex because mutex gives better
performance than semaphore.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 4be8b31..b1ffa91 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -234,7 +234,7 @@ static struct message_queue hif_msg_q;
 static struct semaphore hif_sema_thread;
 static struct semaphore hif_sema_driver;
 static struct completion hif_wait_response;
-static struct semaphore hif_sema_deinit;
+static struct mutex hif_deinit_lock;
 static struct timer_list periodic_rssi;
 
 u8 wilc_multicast_mac_addr_list[WILC_MULTICAST_TABLE_SIZE][ETH_ALEN];
@@ -3402,7 +3402,7 @@ int wilc_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
if (clients_count == 0) {
sema_init(_sema_thread, 0);
sema_init(_sema_driver, 0);
-   sema_init(_sema_deinit, 1);
+   mutex_init(_deinit_lock);
}
 
init_completion(_drv->comp_test_key_block);
@@ -3470,7 +3470,7 @@ int wilc_deinit(struct wilc_vif *vif)
return -EFAULT;
}
 
-   down(_sema_deinit);
+   mutex_lock(_deinit_lock);
 
terminated_handle = hif_drv;
 
@@ -3512,7 +3512,7 @@ int wilc_deinit(struct wilc_vif *vif)
 
clients_count--;
terminated_handle = NULL;
-   up(_sema_deinit);
+   mutex_unlock(_deinit_lock);
return result;
 }
 
@@ -3559,25 +3559,25 @@ void wilc_gnrl_async_info_received(struct wilc *wilc, 
u8 *pu8Buffer,
struct host_if_drv *hif_drv = NULL;
struct wilc_vif *vif;
 
-   down(_sema_deinit);
+   mutex_lock(_deinit_lock);
 
id = ((pu8Buffer[u32Length - 4]) | (pu8Buffer[u32Length - 3] << 8) | 
(pu8Buffer[u32Length - 2] << 16) | (pu8Buffer[u32Length - 1] << 24));
vif = wilc_get_vif_from_idx(wilc, id);
if (!vif) {
-   up(_sema_deinit);
+   mutex_unlock(_deinit_lock);
return;
}
 
hif_drv = vif->hif_drv;
 
if (!hif_drv || hif_drv == terminated_handle) {
-   up(_sema_deinit);
+   mutex_unlock(_deinit_lock);
return;
}
 
if (!hif_drv->usr_conn_req.conn_result) {
netdev_err(vif->ndev, "there is no current Connect Request\n");
-   up(_sema_deinit);
+   mutex_unlock(_deinit_lock);
return;
}
 
@@ -3594,7 +3594,7 @@ void wilc_gnrl_async_info_received(struct wilc *wilc, u8 
*pu8Buffer,
if (result)
netdev_err(vif->ndev, "synchronous info (%d)\n", result);
 
-   up(_sema_deinit);
+   mutex_unlock(_deinit_lock);
 }
 
 void wilc_scan_complete_received(struct wilc *wilc, u8 *pu8Buffer,
-- 
2.7.3

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

RE: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

[KY Srinivasan]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Monday, March 21, 2016 12:52 AM
> To: KY Srinivasan 
> Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; Haiyang
> Zhang ; Alex Ng (LIS) ;
> Radim Krcmar ; Cathy Avery 
> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> 
> KY Srinivasan  writes:
> 
> >> -Original Message-
> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >> Sent: Friday, March 18, 2016 5:33 AM
> >> To: de...@linuxdriverproject.org
> >> Cc: linux-ker...@vger.kernel.org; KY Srinivasan ;
> >> Haiyang Zhang ; Alex Ng (LIS)
> >> ; Radim Krcmar ; Cathy
> >> Avery 
> >> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> >>
> >> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is
> always
> >> delivered to CPU0 regardless of what CPU we're sending
> >> CHANNELMSG_UNLOAD
> >> from. vmbus_wait_for_unload() doesn't account for the fact that in case
> >> we're crashing on some other CPU and CPU0 is still alive and operational
> >> CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
> >> vmbus_connection.unload_event, our wait on the current CPU will never
> >> end.
> >
> > What was the host you were testing on?
> >
> 
> I was testing on both 2012R2 and 2016TP4. The bug is easily reproducible
> by forcing crash on a secondary CPU, e.g.:

Prior to 2012R2, all messages would be delivered on CPU0 and this includes 
CHANNELMSG_UNLOAD_RESPONSE.
For this reason we don't support kexec on pre-2012 R2 hosts. On 2012. From 2012 
R2 on, all vmbus 
messages (responses) will be delivered on  the CPU that we initially set up - 
look at the code in
vmbus_negotiate_version(). So on post 2012 R2 hosts, the response to 
CHANNELMSG_UNLOAD_RESPONSE
will be delivered on the CPU where we initiate the contact with the host - 
CHANNELMSG_INITIATE_CONTACT message.
So, maybe we can stash away the CPU on which we made the initial contact and 
poll the state on that CPU
to make forward progress in the case of crash.

Regards,

K. Y

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

[PATCH] staging: wilc1000: fix a couple of memory leaks

[Colin King]

From: Colin Ian King 

The ENOMEM error return paths are not free'ing allocated memory
resulting in a memory leak of allocated structures. Perform the
required kfree to fix the memory leaks.

Issue discovered with static analysis using CoverityScan

Signed-off-by: Colin Ian King 
---
 drivers/staging/wilc1000/coreconfigurator.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
b/drivers/staging/wilc1000/coreconfigurator.c
index 2c4ae1f..4b51c0a 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -338,8 +338,10 @@ s32 wilc_parse_network_info(u8 *msg_buffer,
 
if (ies_len > 0) {
network_info->ies = kmemdup(ies, ies_len, GFP_KERNEL);
-   if (!network_info->ies)
+   if (!network_info->ies) {
+   kfree(network_info);
return -ENOMEM;
+   }
}
network_info->ies_len = ies_len;
}
@@ -373,8 +375,10 @@ s32 wilc_parse_assoc_resp_info(u8 *buffer, u32 buffer_len,
AID_LEN);
 
connect_resp_info->ies = kmemdup(ies, ies_len, GFP_KERNEL);
-   if (!connect_resp_info->ies)
+   if (!connect_resp_info->ies) {
+   kfree(connect_resp_info);
return -ENOMEM;
+   }
 
connect_resp_info->ies_len = ies_len;
}
-- 
2.7.3

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

Re: [PATCH] staging: rts5208: coding style clean-ups

[Greg KH]

On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote:
> fixed *only* comments that did not follow kernel coding style.
> the errors were caught by the checkpatch.pl tool
> 
> Signed-off-by: Sohom Bhattacharjee 

Does not apply to the tree at all :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 5/5] staging: rtl9712: Fixed FSF address warning in ieee80211.c

[Greg KH]

On Mon, Mar 21, 2016 at 08:17:36AM +, Parth Sane wrote:
> Fixed checkpatch warning caused to FSF address block as per guidelines.
> 
> Signed-off-by: Parth Sane 
> ---
> Changes in v2:
>   - Added commit message

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

Re: [PATCH v2 4/5] staging: rtl9712: Fixed FSF address warning in hal_init.c

[Greg KH]

On Mon, Mar 21, 2016 at 08:17:35AM +, Parth Sane wrote:
> Fixed checkpatch warning caused due to FSF address block as per guidelines.
> 
> Signed-off-by: Parth Sane 
> ---
> Changes in v2:
>   - Added commit message.

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

Re: [PATCH v2 3/5] staging: rtl9712: Fixed FSF address warning in ethernet.h

[Greg KH]

On Mon, Mar 21, 2016 at 08:17:34AM +, Parth Sane wrote:
> Fixed checkpatch check caused by FSF address paragraph as per guidelines.
> 
> Signed-off-by: Parth Sane 

Your subject is not correct :(


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

Re: [PATCH 1/5] staging: rtl8712: Fixed FSF address warning in basic_types.h

[Greg KH]

On Sun, Mar 20, 2016 at 03:58:28PM +, Parth Sane wrote:
> Signed-off-by: Parth Sane 

I can't take patches with no changelog text :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/5] staging: rtl8712: Fixed Multiple FSF address checkpatch warnings

[Greg KH]

On Sun, Mar 20, 2016 at 03:59:09PM +, Parth Sane wrote:
> *** BLURB HERE ***

You forgot to fill this out :(

> 
> Parth Sane (5):
>   staging: rtl8712: Fixed FSF address warning in basic_types.h
>   staging: rtl8712: Fixed FSF address warning in drv_types.h
>   staging: rtl9712: Fixed FSF address warning in ethernet.h
>   staging: rtl9712: Fixed FSF address warning in hal_init.c
>   staging: rtl9712: Fixed FSF address warning in ieee80211.c

Your subject lines are refering to an unknown driver :(

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

Re: [PATCH] staging: netlogic: Fixed alignment of parentheseis checkpatch warning line#186

[Greg KH]

On Sun, Mar 20, 2016 at 02:10:08AM +, Parth Sane wrote:
> Fixed checkpatch warnings about parenthesis alignment at line #186.

Why is a line number needed? How is this different from your previous
patch for this driver?

Please resend all of your previous patches for this driver, I don't know
what to apply in which order :(

thanks,

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

Re: [PATCH 3/3] staging: dgnc: use tty_alloc_driver instead of kcalloc

[Greg KH]

On Mon, Mar 14, 2016 at 01:29:00PM +0900, Daeseok Youn wrote:
> the tty_alloc_driver() can allocate memory for ttys and termios.
> And also it can release allocated memory easly with using
> put_tty_driver().
> 
> Signed-off-by: Daeseok Youn 

But you broke the driver in the previous patch, you can't do that, each
patch has to be 'stand-alone'.

thanks,

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

Re: [PATCH 2/3] staging: dgnc: use pointer type of tty_struct

[Greg KH]

On Mon, Mar 14, 2016 at 01:28:31PM +0900, Daeseok Youn wrote:
> For using tty_alloc_driver, SerialDriver has to be pointer type.

Yes, but you aren't calling tty_alloc_driver, so this patch totally
breaks the working code :(

Please be more careful...

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

Re: [PATCH 1/3] staging: dgnc: fix camelcase of SerialDriver and

[Greg KH]

On Mon, Mar 14, 2016 at 01:28:01PM +0900, Daeseok Youn wrote:
> Signed-off-by: Daeseok Youn 

Your subject: does not make sense, and I can't take a patch without any
changelog entry :(

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

[PATCH] Staging: wlan-ng: removes void pointer

[Ben Marsh]

Removes a void pointer in prism2mgmt.c

Signed-off-by: Ben Marsh 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index 013a624..d8ed9a0 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -375,7 +375,7 @@ int prism2mgmt_scan_results(wlandevice_t *wlandev, void 
*msgp)
 
int count;
 
-   req = (struct p80211msg_dot11req_scan_results *) msgp;
+   req = msgp;
 
req->resultcode.status = P80211ENUM_msgitem_status_data_ok;
 
-- 
1.9.1

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

Re: [PATCH] Staging: nvec: removes useless cast on a void pointer.

[Greg KH]

On Sun, Mar 13, 2016 at 07:14:38PM +0100, Ben Marsh wrote:
> Patch to nvec.c to remove a useless cast on a void pointer.
> 
> Signed-off-by: Ben Marsh 
> ---
>  drivers/staging/nvec/nvec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Someone sent this before you did :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: xgifb: Fix comment style

[Kroah-Hartman]

On Sat, Mar 12, 2016 at 03:40:35AM -0500, YU Bo wrote:
> Fix comments to use trailing */ on separste lines.
> 
> Signed-off-by: YU BO 
> ---
> drivers/staging/xgifb/vb_init.c|3 ++-
> drivers/staging/xgifb/vb_setmode.c |3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)

You sent me 2 different patches with the identical subject: line, which
I can't accept.  Please fix them up and send a patch series, with unique
subjects.

thanks,

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

Re: [PATCH] Staging: most: Remove __cplusplus check in heade files

[Greg KH]

On Sat, Mar 12, 2016 at 01:54:17PM +0530, PrasannaKumar Muralidharan wrote:
> From: PrasannaKumar Muralidharan 
> 
> Remove unnecessary __cplusplus check in header files as it is not
> required.

Your subject line contains a spelling mistake :(

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

Re: [PATCH] Staging: most: Remove volatile usage

[Greg KH]

On Mon, Mar 21, 2016 at 03:08:41PM +0530, PrasannaKumar Muralidharan wrote:
> > Are you sure you can just remove these markings?  Does the code work the
> > same?  What is properly locking these values?  Why were they marked this
> > way in the first place?
> 
> I could not test the change due to lack of hardware.
> 
> Given that the code works without lock and as volatile does not
> guarantee any sort of locking I understand that lock is not necessary.
> Please correct me if I am wrong.
> 
> Could not find the purpose of 'volatile' in the code,
> 'request_counter' and 'service_counter' are only accessed by the CPU.
> So I think it can be removed.

I will need the maintainers of the code to ack this before I can accept
it...

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

Re: [PATCH]rtllib function naming codestyle change to kernel style

[Greg Kroah-Hartman]

On Sun, Mar 20, 2016 at 09:47:29PM +0800, To .LiMit wrote:
> Hi, I saw drivers/staging/rtl8192e/TODO, checked the files within 
> drivers/staging/rtl8192e/, and I found their function naming codestyle is 
> camelcase, I changed them. But I don't know if I should change all variable 
> naming codestyle or not, so I just changed the function naming of the patch.
> 
> Regards,
> 
> Signed-off-by:Ming Li

We need an email address for the signed-off-by line, and it has to match
your from: line.

Also, please provide a proper changelog entry.  And only change one
thing at a time, so for this, change only one function per patch.

thanks,

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

Re: [patch] Skein:move macros into appropriate header files

[Greg Kroah-Hartman]

On Mon, Mar 21, 2016 at 06:44:04PM +0800, Ming Li wrote:
> hi, in drivers/staging/skein/, i move macros into appropriate header 
> files.
> 
> 
> Regards,
> 
> 
> Signed-off-by: Ming Li

Please use scripts/checkpatch.pl to find the errors in your patch before
sending.

Also, don't send html email, it gets rejected by the mailing lists and
it corrupts the patch.

thanks,

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

RE: [PATCH 00/42] staging: comedi: ni_660x: big driver cleanup

[Hartley Sweeten]

On Monday, March 21, 2016 8:39 AM, Ian Abbott wrote:
> On 18/03/16 19:38, H Hartley Sweeten wrote:
>> This driver has a lot of checkpatch.pl issues:
>> total: 0 errors, 71 warnings, 27 checks, 1222 lines checked
>>
>> There is also a lot of cruft that bloats the driver and makes it harder
>> to follow.
>>
>> This series fixes all the checkpatch.pl issues:
>> total: 0 errors, 0 warnings, 0 checks, 944 lines checked
>>
>> And, even better, removes the cruft:
>>
>> textdata bss dec hex filename
>>10249 344   0   105932961 ni_660x.o.original
>> 4719 344   0506313c7 ni_660x.o
>>



> It all looks fine, apart from some breakage in patches 30 and 31 related 
> to the calls to ni_gpct_device_destroy().

Gah... Your correct.

I think ni_gpct_device_destroy() should be changed to:

void ni_gpct_device_destroy(struct ni_gpct_device *counter_dev)
{
-   if (!counter_dev->counters)
+   if (!counter_dev)
return;
kfree(counter_dev->counters);
kfree(counter_dev);
}

Then the NULL checks can be removed from the drivers.

> I'm not entirely sure what  the memory barrier moved by patch 27 is
> for - it's probably redundant.

I'm not sure either. But having is after the spin_lock_irqsave() didn't
make any sense. 

ni_mio_common.c: ni_E_interrupt() has similar smp_mb() with a
comment so I made it the same here.

If you don't think they are necessary I don't have any issues with
removing them.

Hartley

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

[PATCH] staging: rts5208: coding style clean-ups

[Sohom Bhattacharjee]

fixed *only* comments that did not follow kernel coding style.
the errors were caught by the checkpatch.pl tool

Signed-off-by: Sohom Bhattacharjee 
---
 drivers/staging/rts5208/rtsx.c   | 55 +-
 drivers/staging/rts5208/rtsx_chip.h  | 53 -
 drivers/staging/rts5208/rtsx_transport.c | 66 +---
 3 files changed, 114 insertions(+), 60 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
index 1fe8e3e..9abde0a 100644
--- a/drivers/staging/rts5208/rtsx.c
+++ b/drivers/staging/rts5208/rtsx.c
@@ -1,4 +1,5 @@
-/* Driver for Realtek PCI-Express card reader
+/*
+ * Driver for Realtek PCI-Express card reader
  *
  * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
@@ -81,17 +82,20 @@ static int slave_alloc(struct scsi_device *sdev)
 
 static int slave_configure(struct scsi_device *sdev)
 {
-   /* Scatter-gather buffers (all but the last) must have a length
+   /*
+* Scatter-gather buffers (all but the last) must have a length
 * divisible by the bulk maxpacket size.  Otherwise a data packet
 * would end up being short, causing a premature end to the data
 * transfer.  Since high-speed bulk pipes have a maxpacket size
 * of 512, we'll use that as the scsi device queue's DMA alignment
 * mask.  Guaranteeing proper alignment of the first buffer will
 * have the desired effect because, except at the beginning and
-* the end, scatter-gather buffers follow page boundaries. */
+* the end, scatter-gather buffers follow page boundaries.
+*/
blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
 
-   /* Set the SCSI level to at least 2.  We'll leave it at 3 if that's
+   /*
+* Set the SCSI level to at least 2.  We'll leave it at 3 if that's
 * what is originally reported.  We need this to avoid confusing
 * the SCSI layer with devices that report 0 or 1, but need 10-byte
 * commands (ala ATAPI devices behind certain bridges, or devices
@@ -186,8 +190,10 @@ static int command_abort(struct scsi_cmnd *srb)
return SUCCESS;
 }
 
-/* This invokes the transport reset mechanism to reset the state of the
- * device */
+/*
+ * This invokes the transport reset mechanism to reset the state of the
+ * device
+ */
 static int device_reset(struct scsi_cmnd *srb)
 {
int result = 0;
@@ -500,8 +506,8 @@ SkipForAbort:
mutex_unlock(>dev_mutex);
} /* for (;;) */
 
-   /* notify the exit routine that we're actually exiting now
-*
+   /*
+* notify the exit routine that we're actually exiting now
 * complete()/wait_for_completion() is similar to up()/down(),
 * except that complete() is safe in the case where the structure
 * is getting deleted in a parallel mode of execution (i.e. just
@@ -633,7 +639,8 @@ static void rtsx_release_resources(struct rtsx_dev *dev)
 {
dev_info(>pci->dev, "-- %s\n", __func__);
 
-   /* Tell the control thread to exit.  The SCSI host must
+   /*
+* Tell the control thread to exit.  The SCSI host must
 * already have been removed so it won't try to queue
 * any more commands.
 */
@@ -665,15 +672,19 @@ static void rtsx_release_resources(struct rtsx_dev *dev)
kfree(dev->chip);
 }
 
-/* First stage of disconnect processing: stop all commands and remove
- * the host */
+/*
+ * First stage of disconnect processing: stop all commands and remove
+ * the host
+ */
 static void quiesce_and_remove_host(struct rtsx_dev *dev)
 {
struct Scsi_Host *host = rtsx_to_host(dev);
struct rtsx_chip *chip = dev->chip;
 
-   /* Prevent new transfers, stop the current command, and
-* interrupt a SCSI-scan or device-reset delay */
+   /*
+* Prevent new transfers, stop the current command, and
+* interrupt a SCSI-scan or device-reset delay
+*/
mutex_lock(>dev_mutex);
scsi_lock(host);
rtsx_set_stat(chip, RTSX_STAT_DISCONNECT);
@@ -685,9 +696,11 @@ static void quiesce_and_remove_host(struct rtsx_dev *dev)
/* Wait some time to let other threads exist */
wait_timeout(100);
 
-   /* queuecommand won't accept any new commands and the control
+   /*
+* queuecommand won't accept any new commands and the control
 * thread won't execute a previously-queued command.  If there
-* is such a command pending, complete it with an error. */
+* is such a command pending, complete it with an error.
+*/
mutex_lock(>dev_mutex);
if (chip->srb) {
chip->srb->result = DID_NO_CONNECT << 16;
@@ -707,8 +720,10 @@ static void release_everything(struct rtsx_dev *dev)
 {
rtsx_release_resources(dev);
 
-   /* Drop our reference to the 

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote:
> Hi
> 
> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter  wrote:
> > Just a bit of wording polish plus mentioning that it can fail and must
> > be restarted.
> >
> > Requested by Sumit.
> >
> > v2: Fix them typos (Hans).
> >
> > Cc: Chris Wilson 
> > Cc: Tiago Vignatti 
> > Cc: Stéphane Marchesin 
> > Cc: David Herrmann 
> > Cc: Sumit Semwal 
> > Cc: Daniel Vetter 
> > CC: linux-me...@vger.kernel.org
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: de...@driverdev.osuosl.org
> > Cc: Hans Verkuil 
> > Acked-by: Sumit Semwal 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  Documentation/dma-buf-sharing.txt | 11 ++-
> >  drivers/dma-buf/dma-buf.c |  2 +-
> >  2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/dma-buf-sharing.txt 
> > b/Documentation/dma-buf-sharing.txt
> > index 32ac32e773e1..ca44c5820585 100644
> > --- a/Documentation/dma-buf-sharing.txt
> > +++ b/Documentation/dma-buf-sharing.txt
> > @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 
> > 2 main use-cases:
> >
> > No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> > making
> > sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is 
> > *always*
> > -   used when the access happens. This is discussed next paragraphs.
> > +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> > +   -EAGAIN or -EINTR, in which case it must be restarted.
> 
> What is "restart on EAGAIN" supposed to mean? Or more generally, what
> does EAGAIN tell the caller?

Do what drmIoctl does essentially.

while (ret == -1 && (errno == EAGAIN || errno == EINTR)
ret = ioctl();

Typed from memery, too lazy to look it up in the source ;-) I'm trying to
sell the idea of a real dma-buf manpage to Sumit, we should clarify this
in detail there.
-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: [PATCH 00/42] staging: comedi: ni_660x: big driver cleanup

[Ian Abbott]

On 18/03/16 19:38, H Hartley Sweeten wrote:

This driver has a lot of checkpatch.pl issues:
total: 0 errors, 71 warnings, 27 checks, 1222 lines checked

There is also a lot of cruft that bloats the driver and makes it harder
to follow.

This series fixes all the checkpatch.pl issues:
total: 0 errors, 0 warnings, 0 checks, 944 lines checked

And, even better, removes the cruft:

textdata bss dec hex filename
   10249 344   0   105932961 ni_660x.o.original
4719 344   0506313c7 ni_660x.o

H Hartley Sweeten (42):
   staging: comedi: ni_660x: change IOConfigReg() into a macro
   staging: comedi: ni_660x: remove struct NI_660xRegisterData 'name'
   staging: comedi: ni_660x: remove enum ni_register_width
   staging: comedi: ni_660x: remove enum ni_660x_register_direction
   staging: comedi: ni_660x: rename CamelCase 'NI_660xRegisterData'
   staging: comedi: ni_660x: cleanup the NI660X_IO_CFG register helpers
   staging: comedi: ni_660x: tidy up multi-line comment
   staging: comedi: ni_660x: remove enum clock_config_register_bits
   staging: comedi: ni_660x: cleanup the NI660X_DMA_CFG register helpers
   staging: comedi: ni_660x: cleanup the NI660X_GLOBAL_INT_{STATUS,CFG}
   staging: comedi: ni_660x: tidy up ni_660x_write_register()
   staging: comedi: ni_660x: tidy up ni_660x_read_register()
   staging: comedi: ni_660x: tidy up ni_gpct_{write,read}_register()
   staging: comedi: ni_660x: tidy up ni_660x_select_pfi_output()
   staging: comedi: ni_660x: remove BUG_ON() in ni_660x_request_mite_channel()
   staging: comedi: ni_660x: fix block comment issues
   staging: comedi: ni_660x: remove enum ni_660x_subdevices
   staging: comedi: ni_660x: remove ni_660x_num_counters()
   staging: comedi: ni_660x: Prefer 'unsigned int' to bare use of 'unsigned'
   staging: comedi: ni_660x: Prefer kernel type 'u64' over 'uint64_t'
   staging: comedi: ni_660x: tidy up Digital I/O subdevice init
   staging: comedi: ni_660x: tidy up ni_660x_dio_insn_bits()
   staging: comedi: ni_660x: tidy up ni_660x_set_pfi_routing()
   staging: comedi: ni_660x: add a comment about the initial DIO state
   staging: comedi: ni_660x: refactor ni_gpct_to_660x_register()
   staging: comedi: ni_660x: add comments for the spinlock_t definitions
   staging: comedi: ni_660x: fix memory barrier without comment
   staging: comedi: ni_660x: tidy up the misc. constants
   staging: comedi: ni_660x: tidy up the counter subdevices init
   staging: comedi: ni_660x: ni_gpct_device_destroy() can handle a NULL pointer
   staging: comedi: ni_mio_common: ni_gpct_device_destroy() can handle a NULL 
pointer
   staging: comedi: ni_660x: disable interrupts when detaching driver
   staging: comedi: ni_660x: init TIO chips before subdevice init
   staging: comedi: ni_660x: allocate counters early in (*auto_attach)
   staging: comedi: ni_660x: initialize the counter with the subdevice init
   staging: comedi: ni_660x: default DIO channels with subdevice init
   staging: comedi: ni_660x: remove inline mite_ring()
   staging: comedi: ni_660x: sort enum ni_660x_register
   staging: comedi: ni_660x: remove ni_gpct_to_660x_register[]
   staging: comedi: ni_660x: remove spinlock 'dma_cfg_lock'
   staging: comedi: ni_660x: refactor GPCT_OFFSET
   staging: comedi: ni_660x: update the MODULE_DESCRIPTION

  drivers/staging/comedi/drivers/ni_660x.c   | 1156 +---
  drivers/staging/comedi/drivers/ni_mio_common.c |6 +-
  2 files changed, 441 insertions(+), 721 deletions(-)



It all looks fine, apart from some breakage in patches 30 and 31 related 
to the calls to ni_gpct_device_destroy().  I'm not entirely sure what 
the memory barrier moved by patch 27 is for - it's probably redundant.


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

Re: [PATCH net-next 1/3] net: add the AF_KCM entries to family name tables

[David Miller]

Two things wrong with this submission:

1) You need to provide an initial "[PATCH net-next 0/3] ..." header posting
   explaining at a high level what this patch series is about and how it is
   implemented and why.

2) The net-next tree is closed at this time because we are in the merge window,
   therefore no new feature patches should be submitted to the netdev mailing
   list at this time.  Please wait until some (reasonable) amount of time after
   the merge window closes to resubmit this.

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

Re: [PATCH 31/42] staging: comedi: ni_mio_common: ni_gpct_device_destroy() can handle a NULL pointer

[Ian Abbott]

On 18/03/16 19:39, H Hartley Sweeten wrote:

Remove the unnecessary NULL pointer check.

Signed-off-by: H Hartley Sweeten 
Cc: Ian Abbott 
Cc: Greg Kroah-Hartman 
---
  drivers/staging/comedi/drivers/ni_mio_common.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index dcaf7e8..71c8fd2 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -5675,8 +5675,6 @@ static void mio_common_detach(struct comedi_device *dev)
  {
struct ni_private *devpriv = dev->private;

-   if (devpriv) {
-   if (devpriv->counter_dev)
-   ni_gpct_device_destroy(devpriv->counter_dev);
-   }
+   if (devpriv)
+   ni_gpct_device_destroy(devpriv->counter_dev);
  }



Ditto about ni_gpct_device_destroy() breakage.

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

Re: [PATCH 30/42] staging: comedi: ni_660x: ni_gpct_device_destroy() can handle a NULL pointer

[Ian Abbott]

On 18/03/16 19:39, H Hartley Sweeten wrote:

Remove the unnecessary NULL pointer check.

Signed-off-by: H Hartley Sweeten 
Cc: Ian Abbott 
Cc: Greg Kroah-Hartman 
---
  drivers/staging/comedi/drivers/ni_660x.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_660x.c 
b/drivers/staging/comedi/drivers/ni_660x.c
index 35602cc..2440cb6 100644
--- a/drivers/staging/comedi/drivers/ni_660x.c
+++ b/drivers/staging/comedi/drivers/ni_660x.c
@@ -1067,8 +1067,7 @@ static void ni_660x_detach(struct comedi_device *dev)
if (dev->irq)
free_irq(dev->irq, dev);
if (devpriv) {
-   if (devpriv->counter_dev)
-   ni_gpct_device_destroy(devpriv->counter_dev);
+   ni_gpct_device_destroy(devpriv->counter_dev);
ni_660x_free_mite_rings(dev);
mite_detach(devpriv->mite);
}



ni_gpct_device_destroy() doesn't currently check that it's parameter is 
non-NULL before dereferencing it, so this will break.


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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[Tiago Vignatti]

On 03/21/2016 04:51 AM, Daniel Vetter wrote:

Just a bit of wording polish plus mentioning that it can fail and must
be restarted.

Requested by Sumit.

v2: Fix them typos (Hans).

Cc: Chris Wilson 
Cc: Tiago Vignatti 
Cc: Stéphane Marchesin 
Cc: David Herrmann 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org
Cc: Hans Verkuil 
Acked-by: Sumit Semwal 
Signed-off-by: Daniel Vetter 


Reviewed-by: Tiago Vignatti 

Best regards,

Tiago



---
  Documentation/dma-buf-sharing.txt | 11 ++-
  drivers/dma-buf/dma-buf.c |  2 +-
  2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 32ac32e773e1..ca44c5820585 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:

 No special interfaces, userspace simply calls mmap on the dma-buf fd, 
making
 sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
-   used when the access happens. This is discussed next paragraphs.
+   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
+   -EAGAIN or -EINTR, in which case it must be restarted.

 Some systems might need some sort of cache coherency management e.g. when
 CPU and GPU domains are being accessed through dma-buf at the same time. To
@@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
 want (with the new data being consumed by the GPU or say scanout 
device)
   - munmap once you don't need the buffer any more

-Therefore, for correctness and optimal performance, systems with the memory
-cache shared by the GPU and CPU i.e. the "coherent" and also the
-"incoherent" are always required to use SYNC_START and SYNC_END before and
-after, respectively, when accessing the mapped address.
+For correctness and optimal performance, it is always required to use
+SYNC_START and SYNC_END before and after, respectively, when accessing the
+mapped address. Userspace cannot rely on coherent access, even when there
+are systems where it just works without calling these ioctls.

  2. Supporting existing mmap interfaces in importers

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 774a60f4309a..4a2c07ee6677 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
   * @dmabuf:   [in]buffer to complete cpu access for.
   * @direction:[in]length of range for cpu access.
   *
- * This call must always succeed.
+ * Can return negative error values, returns 0 on success.
   */
  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
   enum dma_data_direction direction)



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

Re: [PATCH] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access()

[Tiago Vignatti]

On 03/18/2016 05:02 PM, Chris Wilson wrote:

Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.

Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.

This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.

Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter 
Date:   Thu Feb 11 20:04:51 2016 -0200

 dma-buf: Add ioctls to allow userspace to flush

Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson 
Cc: Tiago Vignatti 
Cc: Stéphane Marchesin 
Cc: David Herrmann 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org


Reviewed-by: Tiago Vignatti 

Best regards,

Tiago

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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hi

On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter  wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-...@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Cc: Hans Verkuil 
> Acked-by: Sumit Semwal 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EAGAIN or -EINTR, in which case it must be restarted.

What is "restart on EAGAIN" supposed to mean? Or more generally, what
does EAGAIN tell the caller?

Thanks
David

> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot rely on coherent access, even when there
> +are systems where it just works without calling these ioctls.
>
>  2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:[in]buffer to complete cpu access for.
>   * @direction: [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>enum dma_data_direction direction)
> --
> 2.8.0.rc3
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] android,lowmemorykiller: Don't abuse TIF_MEMDIE.

[Greg KH]

On Mon, Mar 21, 2016 at 08:00:49PM +0900, Tetsuo Handa wrote:
> Greg Kroah-Hartman wrote:
> > On Tue, Mar 08, 2016 at 03:18:59PM +0100, Michal Hocko wrote:
> > > On Tue 08-03-16 20:01:32, Tetsuo Handa wrote:
> > > > Currently, lowmemorykiller (LMK) is using TIF_MEMDIE for two purposes.
> > > > One is to remember processes killed by LMK, and the other is to
> > > > accelerate termination of processes killed by LMK.
> > > > 
> > > > But since LMK is invoked as a memory shrinker function, there still
> > > > should be some memory available. It is very likely that memory
> > > > allocations by processes killed by LMK will succeed without using
> > > > ALLOC_NO_WATERMARKS via TIF_MEMDIE. Even if their allocations cannot
> > > > escape from memory allocation loop unless they use ALLOC_NO_WATERMARKS,
> > > > lowmem_deathpending_timeout can guarantee forward progress by choosing
> > > > next victim process.
> > > > 
> > > > On the other hand, mark_oom_victim() assumes that it must be called with
> > > > oom_lock held and it must not be called after oom_killer_disable() was
> > > > called. But LMK is calling it without holding oom_lock and checking
> > > > oom_killer_disabled. It is possible that LMK calls mark_oom_victim()
> > > > due to allocation requests by kernel threads after current thread
> > > > returned from oom_killer_disabled(). This will break synchronization
> > > > for PM/suspend.
> > > > 
> > > > This patch introduces per a task_struct flag for remembering processes
> > > > killed by LMK, and replaces TIF_MEMDIE with that flag. By applying this
> > > > patch, assumption by mark_oom_victim() becomes true.
> > > 
> > > Thanks for looking into this. A separate flag sounds like a better way
> > > to go (assuming that the flags are not scarce which doesn't seem to be
> > > the case here).
> > >  
> > > The LMK cannot kill the frozen tasks now but this shouldn't be a big deal
> > > because this is not strictly necessary for the system to move on. We are
> > > not OOM.
> > > 
> > > > Signed-off-by: Tetsuo Handa 
> > > > Cc: Michal Hocko 
> > > > Cc: Greg Kroah-Hartman 
> > > > Cc: Arve Hjonnevag 
> > > > Cc: Riley Andrews 
> > > 
> > > Acked-by: Michal Hocko 
> > 
> > So, any objection for me taking this through the staging tree?
> > 
> Seems no objection. Please take this through the staging tree.

Ok, will do so after 4.6-rc1 is out.

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

Re: [PATCH] android,lowmemorykiller: Don't abuse TIF_MEMDIE.

[Tetsuo Handa]

Greg Kroah-Hartman wrote:
> On Tue, Mar 08, 2016 at 03:18:59PM +0100, Michal Hocko wrote:
> > On Tue 08-03-16 20:01:32, Tetsuo Handa wrote:
> > > Currently, lowmemorykiller (LMK) is using TIF_MEMDIE for two purposes.
> > > One is to remember processes killed by LMK, and the other is to
> > > accelerate termination of processes killed by LMK.
> > > 
> > > But since LMK is invoked as a memory shrinker function, there still
> > > should be some memory available. It is very likely that memory
> > > allocations by processes killed by LMK will succeed without using
> > > ALLOC_NO_WATERMARKS via TIF_MEMDIE. Even if their allocations cannot
> > > escape from memory allocation loop unless they use ALLOC_NO_WATERMARKS,
> > > lowmem_deathpending_timeout can guarantee forward progress by choosing
> > > next victim process.
> > > 
> > > On the other hand, mark_oom_victim() assumes that it must be called with
> > > oom_lock held and it must not be called after oom_killer_disable() was
> > > called. But LMK is calling it without holding oom_lock and checking
> > > oom_killer_disabled. It is possible that LMK calls mark_oom_victim()
> > > due to allocation requests by kernel threads after current thread
> > > returned from oom_killer_disabled(). This will break synchronization
> > > for PM/suspend.
> > > 
> > > This patch introduces per a task_struct flag for remembering processes
> > > killed by LMK, and replaces TIF_MEMDIE with that flag. By applying this
> > > patch, assumption by mark_oom_victim() becomes true.
> > 
> > Thanks for looking into this. A separate flag sounds like a better way
> > to go (assuming that the flags are not scarce which doesn't seem to be
> > the case here).
> >  
> > The LMK cannot kill the frozen tasks now but this shouldn't be a big deal
> > because this is not strictly necessary for the system to move on. We are
> > not OOM.
> > 
> > > Signed-off-by: Tetsuo Handa 
> > > Cc: Michal Hocko 
> > > Cc: Greg Kroah-Hartman 
> > > Cc: Arve Hjonnevag 
> > > Cc: Riley Andrews 
> > 
> > Acked-by: Michal Hocko 
> 
> So, any objection for me taking this through the staging tree?
> 
Seems no objection. Please take this through the staging tree.

Regards.

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

Re: [PATCH] Staging: most: Remove volatile usage

[PrasannaKumar Muralidharan]

> Are you sure you can just remove these markings?  Does the code work the
> same?  What is properly locking these values?  Why were they marked this
> way in the first place?

I could not test the change due to lack of hardware.

Given that the code works without lock and as volatile does not
guarantee any sort of locking I understand that lock is not necessary.
Please correct me if I am wrong.

Could not find the purpose of 'volatile' in the code,
'request_counter' and 'service_counter' are only accessed by the CPU.
So I think it can be removed.

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

Re: [PATCH 5/5] Drivers: hv: vmbus: Implement copy-free read APIs

[Vitaly Kuznetsov]

"K. Y. Srinivasan"  writes:

> Implement copy-free read APIs.
>
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/ring_buffer.c |   55 
> ++
>  include/linux/hyperv.h   |6 +
>  2 files changed, 61 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index c2c2b2e..c80e1f3 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -444,3 +444,58 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
> *inring_info,
>
>   return ret;
>  }
> +
> +/*
> + * In-place read functions.
> + */
> +bool get_next_pkt_raw(struct vmbus_channel *channel,
> +   struct vmpacket_descriptor **desc)

I suggest we make these functions return pointers and use
ERR_PTR()/IS_ERR() when we need to return an error.

> +{
> + struct hv_ring_buffer_info *ring_info = >inbound;
> + u32 read_loc = ring_info->ring_buffer->read_index;
> + void *ring_buffer = hv_get_ring_buffer(ring_info);
> + struct vmpacket_descriptor *cur_desc;
> + u32 packetlen;
> + u32 dsize = ring_info->ring_datasize;
> + u32 bytes_avail_toread = hv_get_bytes_to_read(ring_info);
> +
> + if (bytes_avail_toread < sizeof(struct vmpacket_descriptor))
> + return false;
> +
> + if ((read_loc + sizeof(*desc)) > dsize)
> + return false;
> +
> + cur_desc = ring_buffer + read_loc;
> + packetlen = cur_desc->len8 << 3;
> +
> + if ((read_loc + packetlen + 8) > (dsize - 1))

Could you please add a define for this '8'?


> + return false;
> +
> + *desc = cur_desc;
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(get_next_pkt_raw);
> +
> +void put_pkt_raw(struct vmbus_channel *channel,
> +  struct vmpacket_descriptor *desc)
> +{
> + struct hv_ring_buffer_info *ring_info = >inbound;
> + u32 read_loc = ring_info->ring_buffer->read_index;
> + u32 packetlen = desc->len8 << 3;
> + u32 dsize = ring_info->ring_datasize;
> +
> + if ((read_loc + packetlen + 8) > dsize)
> + BUG();
> +
> + /*
> +  * Make sure all reads are done before we update the read index since
> +  * the writer may start writing to the read area once the read index
> +  * is updated.
> +  */
> + virt_mb();
> + ring_info->ring_buffer->read_index += packetlen + 8;
> +
> + if (hv_need_to_signal_on_read(ring_info))
> + vmbus_set_event(channel);
> +}
> +EXPORT_SYMBOL_GPL(put_pkt_raw);
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index a6b053c..455f3f0 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1035,6 +1035,12 @@ extern int vmbus_recvpacket_raw(struct vmbus_channel 
> *channel,
>u32 *buffer_actual_len,
>u64 *requestid);
>
> +bool get_next_pkt_raw(struct vmbus_channel *channel,
> +   struct vmpacket_descriptor **desc);
> +
> +void put_pkt_raw(struct vmbus_channel *channel,
> +  struct vmpacket_descriptor *desc);
> +
>
>  extern void vmbus_ontimer(unsigned long data);

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

Re: [PATCH 3/5] Drivers: hv: vmbus: Fix a bug in hv_need_to_signal_on_read()

[Vitaly Kuznetsov]

"K. Y. Srinivasan"  writes:

> We need to issue a full memory barrier prior making a signalling
> decision.

Any reason this should be mb()? This is pretty strong and will probably
lead to performace regression ... and, btw, we have another mb() in
hv_ringbuffer_read().

Could you please describe the scenarion you're trying to protect against
so we could search for a better solution?

>
> Signed-off-by: K. Y. Srinivasan 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/hv/ring_buffer.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 2919395..67dc245 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -104,6 +104,7 @@ static bool hv_need_to_signal_on_read(struct 
> hv_ring_buffer_info *rbi)
>   u32 cur_write_sz;
>   u32 pending_sz;
>
> + mb();
>   pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
>   /* If the other end is not blocked on write don't bother. */
>   if (pending_sz == 0)

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

[PATCH v2 5/5] staging: rtl9712: Fixed FSF address warning in ieee80211.c

[Parth Sane]

Fixed checkpatch warning caused to FSF address block as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v2:
- Added commit message

 drivers/staging/rtl8712/ieee80211.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index d13b4d5..8918654 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -13,10 +13,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v2 4/5] staging: rtl9712: Fixed FSF address warning in hal_init.c

[Parth Sane]

Fixed checkpatch warning caused due to FSF address block as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v2:
- Added commit message.

 drivers/staging/rtl8712/hal_init.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/hal_init.c 
b/drivers/staging/rtl8712/hal_init.c
index 17d2b5f..afa7fe78 100644
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -13,10 +13,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v2 1/5] staging: rtl8712: Fixed FSF address warning in basic_types.h

[Parth Sane]

Fixed checkpatch check caused by FSF address paragraph as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v2:
- Added commit message
 drivers/staging/rtl8712/basic_types.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/basic_types.h 
b/drivers/staging/rtl8712/basic_types.h
index 7561bed..f5c0231 100644
--- a/drivers/staging/rtl8712/basic_types.h
+++ b/drivers/staging/rtl8712/basic_types.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v2 3/5] staging: rtl9712: Fixed FSF address warning in ethernet.h

[Parth Sane]

Fixed checkpatch check caused by FSF address paragraph as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v2:
- Added commit message

 drivers/staging/rtl8712/ethernet.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/ethernet.h 
b/drivers/staging/rtl8712/ethernet.h
index fad173f..039da36 100644
--- a/drivers/staging/rtl8712/ethernet.h
+++ b/drivers/staging/rtl8712/ethernet.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH v2 0/5] staging: rtl8712: Fixed checkpatch warning due to FSF address block

[Parth Sane]

Fixed checkpatch warning caused due to FSF address block.
Linux already has a copy of the GPL, so as per checkpatch this address block is
unnecessary.

Parth Sane (5):
  staging: rtl8712: Fixed FSF address warning in basic_types.h
  staging: rtl8712: Fixed FSF address warning in drv_types.h
  staging: rtl9712: Fixed FSF address warning in ethernet.h
  staging: rtl9712: Fixed FSF address warning in hal_init.c
  staging: rtl9712: Fixed FSF address warning in ieee80211.c

 drivers/staging/rtl8712/basic_types.h | 4 
 drivers/staging/rtl8712/drv_types.h   | 4 
 drivers/staging/rtl8712/ethernet.h| 4 
 drivers/staging/rtl8712/hal_init.c| 4 
 drivers/staging/rtl8712/ieee80211.c   | 4 
 5 files changed, 20 deletions(-)

-- 
1.9.1

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

[PATCH v2 2/5] staging: rtl8712: Fixed FSF address warning in drv_types.h

[Parth Sane]

Fixed checkpatch check caused by FSF address paragraph as per guidelines.

Signed-off-by: Parth Sane 
---
Changes in v2:
- Added commit message

 drivers/staging/rtl8712/drv_types.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index 29e47e1..ae79047 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -11,10 +11,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
  * Modifications for inclusion into the Linux staging tree are
  * Copyright(c) 2010 Larry Finger. All rights reserved.
  *
-- 
1.9.1

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

[PATCH net-next 3/3] net: add the AF_HYPERV entries to family name tables

[Dexuan Cui]

This is for the hv_sock driver, which introduces AF_HYPERV(42).

Signed-off-by: Dexuan Cui 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
---
 net/core/sock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 7e73c26..51ffc54 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -222,7 +222,7 @@ static const char *const af_family_key_strings[AF_MAX+1] = {
   "sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN" , "sk_lock-AF_PHONET"   ,
   "sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG"  ,
   "sk_lock-AF_NFC"   , "sk_lock-AF_VSOCK", "sk_lock-AF_KCM"  ,
-  "sk_lock-AF_MAX"
+  "sk_lock-AF_HYPERV", "sk_lock-AF_MAX"
 };
 static const char *const af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_UNSPEC", "slock-AF_UNIX" , "slock-AF_INET" ,
@@ -239,7 +239,7 @@ static const char *const 
af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_RXRPC" , "slock-AF_ISDN" , "slock-AF_PHONET"   ,
   "slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG"  ,
   "slock-AF_NFC"   , "slock-AF_VSOCK","slock-AF_KCM"   ,
-  "slock-AF_MAX"
+  "slock-AF_HYPERV", "slock-AF_MAX"
 };
 static const char *const af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_UNSPEC", "clock-AF_UNIX" , "clock-AF_INET" ,
@@ -256,7 +256,7 @@ static const char *const 
af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_RXRPC" , "clock-AF_ISDN" , "clock-AF_PHONET"   ,
   "clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG"  ,
   "clock-AF_NFC"   , "clock-AF_VSOCK", "clock-AF_KCM"  ,
-  "clock-AF_MAX"
+  "clock-AF_HYPERV", "clock-AF_MAX"
 };
 
 /*
-- 
2.1.0

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

[PATCH net-next 2/3] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over
VMBus, but the transportation layer (VMBus) is much simpler than IP.

With Hyper-V Sockets, applications between the host and the guest can talk
to each other directly by the traditional BSD-style socket APIs.

Hyper-V Sockets is only available on new Windows hosts, like Windows Server
2016. More info is in this article "Make your own integration services":
https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/make_mgmt_service

The patch implements the necessary support in the guest side by introducing
a new socket address family AF_HYPERV.

Signed-off-by: Dexuan Cui 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
---

I posted the V6 of the hv_sock patchset in Jan:
[PATCH V6 0/8] introduce Hyper-V VM Socket(hv_sock)
http://lkml.iu.edu/hypermail/linux/kernel/1601.3/01813.html

Now all the supporting patches in the VMBus side have been merged into
the mainline tree and the net-next tree, I think it's time to re-post the
net/ side's change -- I'm not sure if net-next is close now, since I don't
see a "net-next is CLOSED" mail recently?

The patch shouldn't cause any regression because it adds a new driver, not
touching the existing code.

Please comment on the patch.

 MAINTAINERS |2 +
 include/linux/hyperv.h  |   16 +
 include/linux/socket.h  |5 +-
 include/net/af_hvsock.h |   51 ++
 include/uapi/linux/hyperv.h |   16 +
 net/Kconfig |1 +
 net/Makefile|1 +
 net/hv_sock/Kconfig |   10 +
 net/hv_sock/Makefile|3 +
 net/hv_sock/af_hvsock.c | 1480 +++
 10 files changed, 1583 insertions(+), 2 deletions(-)
 create mode 100644 include/net/af_hvsock.h
 create mode 100644 net/hv_sock/Kconfig
 create mode 100644 net/hv_sock/Makefile
 create mode 100644 net/hv_sock/af_hvsock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0cbfc69..6fa438d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5222,7 +5222,9 @@ F:drivers/pci/host/pci-hyperv.c
 F: drivers/net/hyperv/
 F: drivers/scsi/storvsc_drv.c
 F: drivers/video/fbdev/hyperv_fb.c
+F: net/hv_sock/
 F: include/linux/hyperv.h
+F: include/net/af_hvsock.h
 F: tools/hv/
 F: Documentation/ABI/stable/sysfs-bus-vmbus
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index aa0fadc..b92439d 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1338,4 +1338,20 @@ extern __u32 vmbus_proto_version;
 
 int vmbus_send_tl_connect_request(const uuid_le *shv_guest_servie_id,
  const uuid_le *shv_host_servie_id);
+struct vmpipe_proto_header {
+   u32 pkt_type;
+   u32 data_size;
+} __packed;
+
+#define HVSOCK_HEADER_LEN  (sizeof(struct vmpacket_descriptor) + \
+sizeof(struct vmpipe_proto_header))
+
+/* See 'prev_indices' in hv_ringbuffer_read(), hv_ringbuffer_write() */
+#define PREV_INDICES_LEN   (sizeof(u64))
+
+#define HVSOCK_PKT_LEN(payload_len)(HVSOCK_HEADER_LEN + \
+   ALIGN((payload_len), 8) + \
+   PREV_INDICES_LEN)
+#define HVSOCK_MIN_PKT_LEN HVSOCK_PKT_LEN(1)
+
 #endif /* _HYPERV_H */
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 73bf6c6..88b1ccd 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -201,8 +201,8 @@ struct ucred {
 #define AF_NFC 39  /* NFC sockets  */
 #define AF_VSOCK   40  /* vSockets */
 #define AF_KCM 41  /* Kernel Connection Multiplexor*/
-
-#define AF_MAX 42  /* For now.. */
+#define AF_HYPERV  42  /* Hyper-V Sockets  */
+#define AF_MAX 43  /* For now.. */
 
 /* Protocol families, same as address families. */
 #define PF_UNSPEC  AF_UNSPEC
@@ -249,6 +249,7 @@ struct ucred {
 #define PF_NFC AF_NFC
 #define PF_VSOCK   AF_VSOCK
 #define PF_KCM AF_KCM
+#define PF_HYPERV  AF_HYPERV
 #define PF_MAX AF_MAX
 
 /* Maximum queue length specifiable by listen.  */
diff --git a/include/net/af_hvsock.h b/include/net/af_hvsock.h
new file mode 100644
index 000..a5aa28d
--- /dev/null
+++ b/include/net/af_hvsock.h
@@ -0,0 +1,51 @@
+#ifndef __AF_HVSOCK_H__
+#define __AF_HVSOCK_H__
+
+#include 
+#include 
+#include 
+
+#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (5 * PAGE_SIZE)
+#define VMBUS_RINGBUFFER_SIZE_HVSOCK_SEND (5 * PAGE_SIZE)
+
+#define HVSOCK_RCV_BUF_SZ  VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV
+#define HVSOCK_SND_BUF_SZ  PAGE_SIZE
+
+#define sk_to_hvsock(__sk)((struct hvsock_sock *)(__sk))
+#define hvsock_to_sk(__hvsk)   ((struct sock *)(__hvsk))
+
+struct 

[PATCH net-next 1/3] net: add the AF_KCM entries to family name tables

[Dexuan Cui]

This is for the recent kcm driver, which introduces AF_KCM(41) in
b7ac4eb(kcm: Kernel Connection Multiplexor module).

Signed-off-by: Dexuan Cui 
Cc: Signed-off-by: Tom Herbert 
---
 net/core/sock.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index b67b9ae..7e73c26 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -221,7 +221,8 @@ static const char *const af_family_key_strings[AF_MAX+1] = {
   "sk_lock-AF_TIPC"  , "sk_lock-AF_BLUETOOTH", "sk_lock-IUCV",
   "sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN" , "sk_lock-AF_PHONET"   ,
   "sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG"  ,
-  "sk_lock-AF_NFC"   , "sk_lock-AF_VSOCK", "sk_lock-AF_MAX"
+  "sk_lock-AF_NFC"   , "sk_lock-AF_VSOCK", "sk_lock-AF_KCM"  ,
+  "sk_lock-AF_MAX"
 };
 static const char *const af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_UNSPEC", "slock-AF_UNIX" , "slock-AF_INET" ,
@@ -237,7 +238,8 @@ static const char *const 
af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_TIPC"  , "slock-AF_BLUETOOTH", "slock-AF_IUCV" ,
   "slock-AF_RXRPC" , "slock-AF_ISDN" , "slock-AF_PHONET"   ,
   "slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG"  ,
-  "slock-AF_NFC"   , "slock-AF_VSOCK","slock-AF_MAX"
+  "slock-AF_NFC"   , "slock-AF_VSOCK","slock-AF_KCM"   ,
+  "slock-AF_MAX"
 };
 static const char *const af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_UNSPEC", "clock-AF_UNIX" , "clock-AF_INET" ,
@@ -253,7 +255,8 @@ static const char *const 
af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_TIPC"  , "clock-AF_BLUETOOTH", "clock-AF_IUCV" ,
   "clock-AF_RXRPC" , "clock-AF_ISDN" , "clock-AF_PHONET"   ,
   "clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG"  ,
-  "clock-AF_NFC"   , "clock-AF_VSOCK", "clock-AF_MAX"
+  "clock-AF_NFC"   , "clock-AF_VSOCK", "clock-AF_KCM"  ,
+  "clock-AF_MAX"
 };
 
 /*
-- 
2.1.0

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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

On Mon, Mar 21, 2016 at 8:40 AM, Hans Verkuil  wrote:
>> +For correctness and optimal performance, it is always required to use
>> +SYNC_START and SYNC_END before and after, respectively, when accessing 
>> the
>> +mapped address. Userspace cannot on coherent access, even when there are
>
> "Userspace cannot on coherent access"? Do you mean "cannot do"? Sorry, the
> meaning isn't clear to me.

"cannot rely on". I'll send out v2 asap (and let's hope the coffee
works this time around).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[Hans Verkuil]

On 03/21/2016 08:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
> 
> Requested by Sumit.
> 
> v2: Fix them typos (Hans).
> 
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-...@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Cc: Hans Verkuil 
> Acked-by: Sumit Semwal 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>  
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EAGAIN or -EINTR, in which case it must be restarted.
>  
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>  
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot rely on coherent access, even when there
> +are systems where it just works without calling these ioctls.
>  
>  2. Supporting existing mmap interfaces in importers
>  
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:  [in]buffer to complete cpu access for.
>   * @direction:   [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>  enum dma_data_direction direction)
> 

Much better :-)

Acked-by: Hans Verkuil 

Regards,

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

Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

[Vitaly Kuznetsov]

KY Srinivasan  writes:

>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Friday, March 18, 2016 5:33 AM
>> To: de...@linuxdriverproject.org
>> Cc: linux-ker...@vger.kernel.org; KY Srinivasan ;
>> Haiyang Zhang ; Alex Ng (LIS)
>> ; Radim Krcmar ; Cathy
>> Avery 
>> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>> 
>> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
>> delivered to CPU0 regardless of what CPU we're sending
>> CHANNELMSG_UNLOAD
>> from. vmbus_wait_for_unload() doesn't account for the fact that in case
>> we're crashing on some other CPU and CPU0 is still alive and operational
>> CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
>> vmbus_connection.unload_event, our wait on the current CPU will never
>> end.
>
> What was the host you were testing on?
>

I was testing on both 2012R2 and 2016TP4. The bug is easily reproducible
by forcing crash on a secondary CPU, e.g.:

# cat crash.sh
#! /bin/sh
echo c > /proc/sysrq-trigger

# taskset -c 1 ./crash.sh

>> 
>> Do the following:
>> 1) Check for completion_done() in the loop. In case interrupt handler is
>>still alive we'll get the confirmation we need.
>> 
>> 2) Always read CPU0's message page as CHANNELMSG_UNLOAD_RESPONSE
>> will be
>>delivered there. We can race with still-alive interrupt handler doing
>>the same but we don't care as we're checking completion_done() now.
>> 
>> 3) Cleanup message pages on all CPUs. This is required (at least for the
>>current CPU as we're clearing CPU0 messages now but we may want to
>> bring
>>up additional CPUs on crash) as new messages won't be delivered till we
>>consume what's pending. On boot we'll place message pages somewhere
>> else
>>and we won't be able to read stale messages.
>> 
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>>  drivers/hv/channel_mgmt.c | 30 +-
>>  1 file changed, 25 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
>> index b10e8f74..5f37057 100644
>> --- a/drivers/hv/channel_mgmt.c
>> +++ b/drivers/hv/channel_mgmt.c
>> @@ -512,14 +512,26 @@ static void init_vp_index(struct vmbus_channel
>> *channel, const uuid_le *type_gui
>> 
>>  static void vmbus_wait_for_unload(void)
>>  {
>> -int cpu = smp_processor_id();
>> -void *page_addr = hv_context.synic_message_page[cpu];
>> +int cpu;
>> +void *page_addr = hv_context.synic_message_page[0];
>>  struct hv_message *msg = (struct hv_message *)page_addr +
>>VMBUS_MESSAGE_SINT;
>>  struct vmbus_channel_message_header *hdr;
>>  bool unloaded = false;
>> 
>> -while (1) {
>> +/*
>> + * CHANNELMSG_UNLOAD_RESPONSE is always delivered to CPU0.
>> When we're
>> + * crashing on a different CPU let's hope that IRQ handler on CPU0 is
>> + * still functional and vmbus_unload_response() will complete
>> + * vmbus_connection.unload_event. If not, the last thing we can do
>> is
>> + * read message page for CPU0 regardless of what CPU we're on.
>> + */
>> +while (!unloaded) {
>> +if (completion_done(_connection.unload_event)) {
>> +unloaded = true;
>> +break;
>> +}
>> +
>>  if (READ_ONCE(msg->header.message_type) ==
>> HVMSG_NONE) {
>>  mdelay(10);
>>  continue;
>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
>>  unloaded = true;
>> 
>>  vmbus_signal_eom(msg);
>> +}
>> 
>> -if (unloaded)
>> -break;
>> +/*
>> + * We're crashing and already got the UNLOAD_RESPONSE, cleanup
>> all
>> + * maybe-pending messages on all CPUs to be able to receive new
>> + * messages after we reconnect.
>> + */
>> +for_each_online_cpu(cpu) {
>> +page_addr = hv_context.synic_message_page[cpu];
>> +msg = (struct hv_message *)page_addr +
>> VMBUS_MESSAGE_SINT;
>> +msg->header.message_type = HVMSG_NONE;
>>  }
>>  }
>> 
>> --
>> 2.5.0

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

[PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

Just a bit of wording polish plus mentioning that it can fail and must
be restarted.

Requested by Sumit.

v2: Fix them typos (Hans).

Cc: Chris Wilson 
Cc: Tiago Vignatti 
Cc: Stéphane Marchesin 
Cc: David Herrmann 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org
Cc: Hans Verkuil 
Acked-by: Sumit Semwal 
Signed-off-by: Daniel Vetter 
---
 Documentation/dma-buf-sharing.txt | 11 ++-
 drivers/dma-buf/dma-buf.c |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 32ac32e773e1..ca44c5820585 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
 
No special interfaces, userspace simply calls mmap on the dma-buf fd, making
sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
-   used when the access happens. This is discussed next paragraphs.
+   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
+   -EAGAIN or -EINTR, in which case it must be restarted.
 
Some systems might need some sort of cache coherency management e.g. when
CPU and GPU domains are being accessed through dma-buf at the same time. To
@@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
want (with the new data being consumed by the GPU or say scanout device)
  - munmap once you don't need the buffer any more
 
-Therefore, for correctness and optimal performance, systems with the memory
-cache shared by the GPU and CPU i.e. the "coherent" and also the
-"incoherent" are always required to use SYNC_START and SYNC_END before and
-after, respectively, when accessing the mapped address.
+For correctness and optimal performance, it is always required to use
+SYNC_START and SYNC_END before and after, respectively, when accessing the
+mapped address. Userspace cannot rely on coherent access, even when there
+are systems where it just works without calling these ioctls.
 
 2. Supporting existing mmap interfaces in importers
 
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 774a60f4309a..4a2c07ee6677 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
  * @dmabuf:[in]buffer to complete cpu access for.
  * @direction: [in]length of range for cpu access.
  *
- * This call must always succeed.
+ * Can return negative error values, returns 0 on success.
  */
 int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
   enum dma_data_direction direction)
-- 
2.8.0.rc3

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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[Hans Verkuil]

Hi Daniel,

Two small comments:

On 03/21/2016 08:30 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
> 
> Requested by Sumit.
> 
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-...@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..5c4e3e586ec8 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>  
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EGAIN or -EINTR, in which case it must be restarted.

EGAIN -> EAGAIN

>  
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>  
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot on coherent access, even when there are

"Userspace cannot on coherent access"? Do you mean "cannot do"? Sorry, the
meaning isn't clear to me.

Regards,

Hans

> +systems where it just works without calling these ioctls.
>  
>  2. Supporting existing mmap interfaces in importers
>  
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:  [in]buffer to complete cpu access for.
>   * @direction:   [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>  enum dma_data_direction direction)
> 

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

[PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

Just a bit of wording polish plus mentioning that it can fail and must
be restarted.

Requested by Sumit.

Cc: Chris Wilson 
Cc: Tiago Vignatti 
Cc: Stéphane Marchesin 
Cc: David Herrmann 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Daniel Vetter 
---
 Documentation/dma-buf-sharing.txt | 11 ++-
 drivers/dma-buf/dma-buf.c |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 32ac32e773e1..5c4e3e586ec8 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
 
No special interfaces, userspace simply calls mmap on the dma-buf fd, making
sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
-   used when the access happens. This is discussed next paragraphs.
+   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
+   -EGAIN or -EINTR, in which case it must be restarted.
 
Some systems might need some sort of cache coherency management e.g. when
CPU and GPU domains are being accessed through dma-buf at the same time. To
@@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
want (with the new data being consumed by the GPU or say scanout device)
  - munmap once you don't need the buffer any more
 
-Therefore, for correctness and optimal performance, systems with the memory
-cache shared by the GPU and CPU i.e. the "coherent" and also the
-"incoherent" are always required to use SYNC_START and SYNC_END before and
-after, respectively, when accessing the mapped address.
+For correctness and optimal performance, it is always required to use
+SYNC_START and SYNC_END before and after, respectively, when accessing the
+mapped address. Userspace cannot on coherent access, even when there are
+systems where it just works without calling these ioctls.
 
 2. Supporting existing mmap interfaces in importers
 
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 774a60f4309a..4a2c07ee6677 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
  * @dmabuf:[in]buffer to complete cpu access for.
  * @direction: [in]length of range for cpu access.
  *
- * This call must always succeed.
+ * Can return negative error values, returns 0 on success.
  */
 int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
   enum dma_data_direction direction)
-- 
2.8.0.rc3

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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

[Sumit Semwal]

On 21 March 2016 at 13:00, Daniel Vetter  wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-...@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Daniel Vetter 
Acked-by: Sumit Semwal 

> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..5c4e3e586ec8 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EGAIN or -EINTR, in which case it must be restarted.
>
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot on coherent access, even when there are
> +systems where it just works without calling these ioctls.
>
>  2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:[in]buffer to complete cpu access for.
>   * @direction: [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>enum dma_data_direction direction)
> --
> 2.8.0.rc3
>

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

Re: [PATCH] dma-buf/sync_file: de-stage sync_file

[Sumit Semwal]

Thanks for the patch, Gustavo!

On 18 March 2016 at 19:49, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
I think it is worthwhile to add relevant bits to the Documentation as
well - care to add relevant stuff to either Documentation/dma_buf.txt,
or to a file of its own? (I'd prefer the former, but would leave it
upto you.)

> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/Kconfig|   2 +
>  drivers/dma-buf/Kconfig|  11 +
>  drivers/dma-buf/Makefile   |   1 +
>  drivers/dma-buf/sync_file.c| 382 
> +
>  drivers/staging/android/Kconfig|   1 +
>  drivers/staging/android/sync.c | 362 ---
>  drivers/staging/android/sync.h |  92 +
>  drivers/staging/android/sync_debug.c   |   1 +
>  include/linux/sync_file.h  | 106 ++
>  .../uapi/sync.h => include/uapi/linux/sync_file.h  |   0
>  10 files changed, 506 insertions(+), 452 deletions(-)
>  create mode 100644 drivers/dma-buf/Kconfig
>  create mode 100644 drivers/dma-buf/sync_file.c
>  create mode 100644 include/linux/sync_file.h
>  rename drivers/staging/android/uapi/sync.h => include/uapi/linux/sync_file.h 
> (100%)
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index d2ac339..430f761 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -114,6 +114,8 @@ source "drivers/rtc/Kconfig"
>
>  source "drivers/dma/Kconfig"
>
> +source "drivers/dma-buf/Kconfig"
> +
>  source "drivers/dca/Kconfig"
>
>  source "drivers/auxdisplay/Kconfig"
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> new file mode 100644
> index 000..9824bc4
> --- /dev/null
> +++ b/drivers/dma-buf/Kconfig
> @@ -0,0 +1,11 @@
> +menu "DMABUF options"
> +
> +config SYNC_FILE
> +   bool "sync_file support for fences"
> +   default n
> +   select ANON_INODES
> +   select DMA_SHARED_BUFFER
> +   ---help---
> + This option enables the fence framework synchronization to export
> + sync_files to userspace that can represent one or more fences.
> +endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 57a675f..4a424ec 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1 +1,2 @@
>  obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
> +obj-$(CONFIG_SYNC_FILE)+= sync_file.o
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> new file mode 100644
> index 000..df786a2
> --- /dev/null
> +++ b/drivers/dma-buf/sync_file.c
> @@ -0,0 +1,382 @@
> +/*
> + * drivers/dma-buf/sync_file.c
> + *
> + * Copyright (C) 2012 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct file_operations sync_file_fops;
> +
> +static struct sync_file *sync_file_alloc(int size, const char *name)
> +{
> +   struct sync_file *sync_file;
> +
> +   sync_file = kzalloc(size, GFP_KERNEL);
> +   if (!sync_file)
> +   return NULL;
> +
> +   sync_file->file = anon_inode_getfile("sync_file", _file_fops,
> +sync_file, 0);
> +   if (IS_ERR(sync_file->file))
> +   goto err;
> +
> +   kref_init(_file->kref);
> +   strlcpy(sync_file->name, name, sizeof(sync_file->name));
> +
> +   init_waitqueue_head(_file->wq);
> +
> +   return sync_file;
> +
> +err:
> +   kfree(sync_file);
> +   return NULL;
> +}
> +
> +static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
> +{
> +   struct sync_file_cb *check;
> +   struct sync_file *sync_file;
> +
> +   check = container_of(cb, struct sync_file_cb, cb);
> +   sync_file = check->sync_file;
> +
> +   if (atomic_dec_and_test(_file->status))
> +   wake_up_all(_file->wq);
> +}
> +
> +/* TODO: implement a create which takes more that one fence */
> +struct sync_file *sync_file_create(const char *name, struct fence *fence)
> +{
> +   struct sync_file *sync_file;
> +
> +   sync_file = sync_file_alloc(offsetof(struct sync_file, 

Re: [PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

[Sumit Semwal]

On 19 March 2016 at 15:39, Daniel Vetter  wrote:
> On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
>> Drivers, especially i915.ko, can fail during the initial migration of a
>> dma-buf for CPU access. However, the error code from the driver was not
>> being propagated back to ioctl and so userspace was blissfully ignorant
>> of the failure. Rendering corruption ensues.
>>
>> Whilst fixing the ioctl to return the error code from
>> dma_buf_start_cpu_access(), also do the same for
>> dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
>> cannot fail. i915.ko however, as most drivers would, wants to avoid being
>> uninterruptible (as would be required to guarrantee no failure when
>> flushing the buffer to the device). As userspace already has to handle
>> errors from the SYNC_IOCTL, take advantage of this to be able to restart
>> the syscall across signals.
>>
>> This fixes a coherency issue for i915.ko as well as reducing the
>> uninterruptible hold upon its BKL, the struct_mutex.
>>
>> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
>> Author: Daniel Vetter 
>> Date:   Thu Feb 11 20:04:51 2016 -0200
>>
>> dma-buf: Add ioctls to allow userspace to flush
>>
>> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
>> Testcase: igt/prime_mmap_coherency/ioctl-errors
>> Signed-off-by: Chris Wilson 
>> Cc: Tiago Vignatti 
>> Cc: Stéphane Marchesin 
>> Cc: David Herrmann 
>> Cc: Sumit Semwal 
>> Cc: Daniel Vetter 
>> CC: linux-me...@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: de...@driverdev.osuosl.org
>
> Applied to drm-misc, I'll send a pull to Dave the next few days if no one
> screams.
> -Daniel
Thanks for pulling it via drm-misc, Daniel.
Chris, I feel since this is an API change, it also needs an update to
the Documentation file.
With that, and a minor nit below, please feel free to add
Acked-by: Sumit Semwal 

>
>> ---
>>  drivers/dma-buf/dma-buf.c | 17 +++--
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
>>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  5 +++--
>>  drivers/gpu/drm/udl/udl_fb.c  |  4 ++--
>>  drivers/staging/android/ion/ion.c |  6 --
>>  include/linux/dma-buf.h   |  6 +++---
>>  6 files changed, 28 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 9810d1df0691..774a60f4309a 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
>>   struct dma_buf *dmabuf;
>>   struct dma_buf_sync sync;
>>   enum dma_data_direction direction;
>> + int ret;
>>
>>   dmabuf = file->private_data;
>>
>> @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
>>   }
>>
>>   if (sync.flags & DMA_BUF_SYNC_END)
>> - dma_buf_end_cpu_access(dmabuf, direction);
>> + ret = dma_buf_end_cpu_access(dmabuf, direction);
>>   else
>> - dma_buf_begin_cpu_access(dmabuf, direction);
>> + ret = dma_buf_begin_cpu_access(dmabuf, direction);
>>
>> - return 0;
>> + return ret;
>>   default:
>>   return -ENOTTY;
>>   }
>> @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>>   *
>>   * This call must always succeed.
>>   */
Perhaps update the above comment to reflect the change as well?

>> -void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>> - enum dma_data_direction direction)
>> +int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>> +enum dma_data_direction direction)
>>  {
>> + int ret = 0;
>> +
>>   WARN_ON(!dmabuf);
>>
>>   if (dmabuf->ops->end_cpu_access)
>> - dmabuf->ops->end_cpu_access(dmabuf, direction);
>> + ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
>> +
>> + return ret;
>>  }
<< snip>>

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