Caro usuário

[ADMIN]

Caro usuário,

Esta é para informá-lo que alguém estava tentando entrar sua conta email de um 
local diferente {IP:37. 187.138.129
{França: 22/01/2015 02:36 GTM}

Se você não estiver por favor siga as instruções abaixo para atualizar e 
Verifique apenas 12 horas de sua conta para fazer isso fim de manter seu 
endereço de e-mail está ativo.

Email:
SENHA:
RE-CONTRASENA:
Data de nascimento:


Este e-mail é sujeito à fiscalização obrigatória, Não-conformidade resultaria 
na suspensão da sua conta de e-mail eletrônico.

Atenciosamente
Equipe de suporte técnico.
Esta mensagem, incluindo seus anexos, pode conter informacoes privilegiadas 
e/ou de carater confidencial, nao podendo ser retransmitida sem autorizacao do 
remetente. Se voce nao e o destinatario ou pessoa autorizada a recebe-la, 
informamos que o seu uso, divulgacao, copia ou arquivamento sao proibidos. 
Portanto, se você recebeu esta mensagem por engano, por favor, nos informe 
respondendo imediatamente a este e-mail e 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC 00/10] Freescale DPAA B/QMan drivers

[Dan Carpenter]

Normally, for staging drivers we just require the TODO and a maintainer
and we merge things as-is.  There isn't really much review of the code.

regards,
dan carpenter

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

Re: [PATCH 0/4] Drivers: hv: Further protection for the rescind path

[Vitaly Kuznetsov]

KY Srinivasan  writes:

>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Tuesday, February 3, 2015 9:01 AM
>> To: KY Srinivasan; de...@linuxdriverproject.org
>> Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang
>> Subject: [PATCH 0/4] Drivers: hv: Further protection for the rescind path
>> 
>> This series is a continuation of the "Drivers: hv: vmbus: serialize Offer and
>> Rescind offer". I'm trying to address a number of theoretically possible 
>> issues
>> with rescind offer handling. All these complications come from the fact that 
>> a
>> rescind offer results in vmbus channel being freed and we must ensure
>> nobody still uses it. Instead of introducing new locks I suggest we switch
>> channels usage to the get/put workflow.
>> 
>> The main part of the series is [PATCH 1/4] which introduces the workflow for
>> vmbus channels, all other patches fix different corner cases using this
>> workflow. I'm not sure all such cases are covered with this series (probably
>> not), but in case protection is required in some other places it should 
>> become
>> relatively easy to add one.
>> 
>> I did some sanity testing with CONFIG_DEBUG_LOCKDEP=y and nothing
>> popped out, however, additional testing would be much appreciated.
>> 
>> K.Y., Haiyang, I'm not sending this series to netdev@ and linux-scsi@ as it 
>> is
>> supposed to be applied as a whole, please resend these patches with your
>> sign-offs when (and if) we're done with reviews. Thanks!
>
> Vitaly,
>
> Thanks for looking into this issue. While today, rescind offer results in the 
> freeing of the channel, I don't think
> that is required. By not freeing up the channel in the rescind path, we can 
> have a safe way to access the channel and
> that does not have to involve taking a reference on the channel every time 
> you access it - the get/put workflow in your
> patch set. As part of the network performance improvement work, I had 
> eliminated all locks in the receive path by setting
> up per-cpu data structures for mapping the relid to channel etc. These set of 
> patches introduces locking/atomic operations
> in performance critical code paths to deal with an event that is truly
> rare - the channel getting rescinded.

It is possible to eliminate all locks/atomic operations from performance
critical pyth in my patch series by following Dexuan's suggestion -
we'll get the channel in vmbus_open and put it in vmbus_close (and on
processing offer/rescind offer) this won't affect performance. I'm in
the middle of testing this approach.

>
> All channel messages are handled in a single work context:
>
> vmbus_on_msg_dpc() -> vmbus_onmessage_work()-> Various channel messages 
> [offer, rescind etc.]
>
> So, the rescind message cannot be processed while we are processing the offer 
> message and since an offer
> cannot be rescinded before it is offered, offer and rescind are naturally 
> serialized (I think I have patchset in my queue
> from you that is trying to solve the concurrent execution of offer and 
> rescind and looking at the code I cannot see how
> this can occur).
>
> As part of handling the rescind message, we will just set the channel state 
> to indicate that the offer is rescinded (we can add
> the rescind state to the channel states already defined and this will be done 
> under the protection of the channel lock).
> The cleanup of the channel and sending of the RELID release message  will 
> only be done in the context of the driver as part of 
> driver remove function. I think this should be doable in a way that does not 
> penalize the normal path. If it is ok with you, I will
> try to put together a patch along the lines I have described here.
>

Yes, if we consider rescind event as a very rare event we can avoid
freeing channels, but if (in some conditions) it happens frequently
we'll have significant memory leakage.

We can also free them with something like schedule_deyalyed_work with
e.g. 10 second delay after removing it from all lists so probability of
hitting a crash will me very low, I seriously doubt we will ever hit it.

Please let me know what you think is better. In case we follow 'never
free' or 'delayed free' approach I'll extract and send separately PATCH
2/4 from my series to address 'loosing rescind offer' issue pointed out
by Dexuan. 

Thanks,

> Regards,
>
> K. Y
>
>> 
>> Vitaly Kuznetsov (4):
>>   Drivers: hv: vmbus: implement get/put usage workflow for vmbus
>> channels
>>   Drivers: hv: vmbus: do not lose rescind offer on failure in
>> vmbus_process_offer()
>>   Drivers: hv: vmbus: protect vmbus_get_outgoing_channel() against
>> channel removal
>>   hyperv: netvsc: improve protection against rescind offer
>> 
>>  drivers/hv/channel_mgmt.c   | 75
>> +
>>  drivers/hv/connection.c |  7 +++--
>>  drivers/hv/hyperv_vmbus.h   |  4 +++
>>  drivers/net/hyperv/netvsc.c | 10 --  drivers/scsi/st

Re: [Xen-devel] [Patch v4 01/23] ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

[David Vrabel]

On 05/02/15 05:44, Jiang Liu wrote:
> 
> --- a/drivers/xen/xen-acpi-memhotplug.c
> +++ b/drivers/xen/xen-acpi-memhotplug.c
> @@ -117,8 +117,8 @@ acpi_memory_get_resource(struct acpi_resource *resource, 
> void *context)
>   list_for_each_entry(info, &mem_device->res_list, list) {
>   if ((info->caching == address64.info.mem.caching) &&
>   (info->write_protect == address64.info.mem.write_protect) &&
> - (info->start_addr + info->length == address64.minimum)) {
> - info->length += address64.address_length;
> + (info->start_addr + info->length == 
> address64.address.minimum)) {
> + info->length += address64.address.address_length;
>   return AE_OK;
>   }
>   }
> @@ -130,8 +130,8 @@ acpi_memory_get_resource(struct acpi_resource *resource, 
> void *context)
>   INIT_LIST_HEAD(&new->list);
>   new->caching = address64.info.mem.caching;
>   new->write_protect = address64.info.mem.write_protect;
> - new->start_addr = address64.minimum;
> - new->length = address64.address_length;
> + new->start_addr = address64.address.minimum;
> + new->length = address64.address.address_length;
>   list_add_tail(&new->list, &mem_device->res_list);
>  
>   return AE_OK;

Xen parts:

Acked-by: David Vrabel 

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

Re: [PATCH net-next v2] hyper-v: allow access to vmbus from userspace driver

[Vitaly Kuznetsov]

Stephen Hemminger  writes:

> This is enables the hyper-v driver for DPDK .
> The hv_uio driver needs to access the shared vmbus monitor
> pages.

Why can't we just make vmbus_connection struct public?

>
> I would also like to put hv_uio in upstream kernel like other
> uio drivers, but need to get API accepted with DPDK first.
>
> Signed-off-by: Stas Egorov 
> Signed-off-by: Stephen Hemminger 
>
> ---
> v2 - simplify and rename to vmbus_get_monitor_pages
>
>  drivers/hv/connection.c |   20 +---
>  include/linux/hyperv.h  |3 +++
>  2 files changed, 20 insertions(+), 3 deletions(-)
>
> --- a/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
> +++ b/drivers/hv/connection.c 2015-02-04 14:59:51.636194383 -0800
> @@ -64,6 +64,15 @@ static __u32 vmbus_get_next_version(__u3
>   }
>  }
>
> +void vmbus_get_monitor_pages(unsigned long *int_page,
> +  unsigned long monitor_pages[2])
> +{

Too weird to be a public interface in my opinion.

> + *int_page = (unsigned long)vmbus_connection.int_page;
> + monitor_pages[0] = (unsigned long)vmbus_connection.monitor_pages[0];
> + monitor_pages[1] = (unsigned long)vmbus_connection.monitor_pages[1];
> +}
> +EXPORT_SYMBOL_GPL(vmbus_get_monitor_pages);
> +
>  static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
>   __u32 version)
>  {
> @@ -347,10 +356,7 @@ static void process_chn_event(u32 relid)
>   else
>   bytes_to_read = 0;
>   } while (read_state && (bytes_to_read != 0));
> - } else {
> - pr_err("no channel callback for relid - %u\n", relid);
>   }
> -
>  }

This change wasn't mentioned in your commit msg.

>
>  /*
> --- a/include/linux/hyperv.h  2015-02-03 10:58:51.751752450 -0800
> +++ b/include/linux/hyperv.h  2015-02-04 15:00:26.388355012 -0800
> @@ -868,6 +868,9 @@ extern int vmbus_recvpacket_raw(struct v
>
>  extern void vmbus_ontimer(unsigned long data);
>
> +extern void vmbus_get_monitor_pages(unsigned long *int_page,
> + unsigned long monitor_pages[2]);
> +
>  /* Base driver object */
>  struct hv_driver {
>   const char *name;
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

Re: [PATCH] staging: gdm724x: gdm_tty: Fix for possible null pointer dereference

[Dan Carpenter]

On Wed, Feb 04, 2015 at 06:46:34PM +0100, Rickard Strandqvist wrote:
> 2015-02-02 17:36 GMT+01:00 Sudip Mukherjee :
> > On Thu, Jan 29, 2015 at 07:46:10PM +0100, Rickard Strandqvist wrote:
> >> diff --git a/drivers/staging/gdm724x/gdm_tty.c 
> >> b/drivers/staging/gdm724x/gdm_tty.c
> >> index 001348c..66b356e 100644
> >> --- a/drivers/staging/gdm724x/gdm_tty.c
> >> +++ b/drivers/staging/gdm724x/gdm_tty.c
> >> @@ -145,7 +145,7 @@ static int gdm_tty_recv_complete(void *data,
> >>   struct gdm *gdm = tty_dev->gdm[index];
> >>
> >>   if (!GDM_TTY_READY(gdm)) {
> >> - if (complete == RECV_PACKET_PROCESS_COMPLETE)
> >> + if (gdm && complete == RECV_PACKET_PROCESS_COMPLETE)
> > GDM_TTY_READY() is already checking for gdm, there is no chance that gdm 
> > can be null at this point. so this additional check is not required.
> >
> > regards
> > sudip
> >>   gdm_tty_recv(gdm, gdm_tty_recv_complete);
> >>   return TO_HOST_PORT_CLOSE;
> >>   }
> 
> Hi Sudip
> 
> Yes, GDM_TTY_READY checks gdm, but this is a if(! )
> 

You're right.  But, by that same logic, we should also test
gdm->tty_dev.  So it looks like this:

if (!GDM_TTY_READY(gdm))  {
if (gdm && gdm->tty_dev && complete == 
RECV_PACKET_PROCESS_COMPLETE)
gdm_tty_recv(gdm, gdm_tty_recv_complete);
return TO_HOST_PORT_CLOSE;
}

That is really sucky...  Garbage code like this is why kernel style
doesn't favour macros.  We should just open code GDM_TTY_READY() and
gdm_tty_recv() so that people can read the code.

I wonder if "gdm->tty_dev" is the same as the "tty_dev" parameter?

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

Re: [PATCH v2] staging: rtl8192u: r8192U_core: Fix for possible null pointer dereference

[Dan Carpenter]

I don't know if this patch was merged before Greg cleaned out his inbox.

It's a good patch if you could just clean it up a bit.

On Thu, Jan 29, 2015 at 07:59:12PM +0100, Rickard Strandqvist wrote:
> Fix a possible null pointer dereference, there is
> otherwise a risk of a possible null pointer dereference.

The change log should say that "driver_info" is the NULL pointer.  It
should say that by default stats->RxIs40MHzPacket is zero (as opposed to
uninitialized memory).

> 
> This was found using a static code analysis program called cppcheck
> 
> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index e031a25..4a29237 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -4476,11 +4476,11 @@ static void query_rxdesc_status(struct sk_buff *skb,
>  
>   /* for debug 2008.5.29 */
>  
> - //added by vivi, for MP, 20080108
> - stats->RxIs40MHzPacket = driver_info->BW;
> - if (stats->RxDrvInfoSize != 0)
> + if (driver_info && stats->RxDrvInfoSize != 0) {
> + //added by vivi, for MP, 20080108

Delete these kinds of comments, please.


> + stats->RxIs40MHzPacket = driver_info->BW;
>   TranslateRxSignalStuff819xUsb(skb, stats, driver_info);
> -
> + }

regards,
dan carpenter

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

Re: [PATCH v2] staging: rtl8192u: r8192U_core: Fix for possible null pointer dereference

[Sudip Mukherjee]

On Thu, Feb 05, 2015 at 03:27:45PM +0300, Dan Carpenter wrote:
> I don't know if this patch was merged before Greg cleaned out his inbox.
> 
> It's a good patch if you could just clean it up a bit.
> 
> On Thu, Jan 29, 2015 at 07:59:12PM +0100, Rickard Strandqvist wrote:
> > Fix a possible null pointer dereference, there is
> > otherwise a risk of a possible null pointer dereference.
> 
> The change log should say that "driver_info" is the NULL pointer.  It
> should say that by default stats->RxIs40MHzPacket is zero (as opposed to
> uninitialized memory).
> 
> > 

> > +++ b/drivers/staging/rtl8192u/r8192U_core.c
> > @@ -4476,11 +4476,11 @@ static void query_rxdesc_status(struct sk_buff *skb,
> >  
> > /* for debug 2008.5.29 */
> >  
> > -   //added by vivi, for MP, 20080108
> > -   stats->RxIs40MHzPacket = driver_info->BW;
> > -   if (stats->RxDrvInfoSize != 0)
> > +   if (driver_info && stats->RxDrvInfoSize != 0) {
> > +   //added by vivi, for MP, 20080108
> 
> Delete these kinds of comments, please.
> 
> 
> > +   stats->RxIs40MHzPacket = driver_info->BW;
> > TranslateRxSignalStuff819xUsb(skb, stats, driver_info);
> > -
> > +   }

but in the present form the logic is changing. can you please check the 
following idea - 

if (driver_info) {
stats->RxIs40MHzPacket = driver_info->BW;
if (stats->RxDrvInfoSize != 0)
TranslateRxSignalStuff819xUsb(skb, stats, driver_info);
}


regards
sudip


> 
> regards,
> dan carpenter
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 0/4] Drivers: hv: Further protection for the rescind path

[Dexuan Cui]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Thursday, February 5, 2015 18:10 PM
> To: KY Srinivasan
> Cc: de...@linuxdriverproject.org; Haiyang Zhang; linux-ker...@vger.kernel.org;
> Dexuan Cui; Jason Wang
> Subject: Re: [PATCH 0/4] Drivers: hv: Further protection for the rescind path
>
> KY Srinivasan  writes:
>
> >> -Original Message-
> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >> Sent: Tuesday, February 3, 2015 9:01 AM
> >> To: KY Srinivasan; de...@linuxdriverproject.org
> >> Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang
> >> Subject: [PATCH 0/4] Drivers: hv: Further protection for the rescind path
> >>
> >> This series is a continuation of the "Drivers: hv: vmbus: serialize Offer 
> >> and
> >> Rescind offer". I'm trying to address a number of theoretically possible 
> >> issues
> >> with rescind offer handling. All these complications come from the fact 
> >> that a
> >> rescind offer results in vmbus channel being freed and we must ensure
> >> nobody still uses it. Instead of introducing new locks I suggest we switch
> >> channels usage to the get/put workflow.
> >>
> >> The main part of the series is [PATCH 1/4] which introduces the workflow 
> >> for
> >> vmbus channels, all other patches fix different corner cases using this
> >> workflow. I'm not sure all such cases are covered with this series 
> >> (probably
> >> not), but in case protection is required in some other places it should 
> >> become
> >> relatively easy to add one.
> >>
> >> I did some sanity testing with CONFIG_DEBUG_LOCKDEP=y and nothing
> >> popped out, however, additional testing would be much appreciated.
> >>
> >> K.Y., Haiyang, I'm not sending this series to netdev@ and linux-scsi@ as 
> >> it is
> >> supposed to be applied as a whole, please resend these patches with your
> >> sign-offs when (and if) we're done with reviews. Thanks!
> >
> > Vitaly,
> >
> > Thanks for looking into this issue. While today, rescind offer results in 
> > the
> freeing of the channel, I don't think
> > that is required. By not freeing up the channel in the rescind path, we can 
> > have
> a safe way to access the channel and
> > that does not have to involve taking a reference on the channel every time 
> > you
> access it - the get/put workflow in your
> > patch set. As part of the network performance improvement work, I had
> eliminated all locks in the receive path by setting
> > up per-cpu data structures for mapping the relid to channel etc. These set 
> > of
> patches introduces locking/atomic operations
> > in performance critical code paths to deal with an event that is truly
> > rare - the channel getting rescinded.
>
> It is possible to eliminate all locks/atomic operations from performance
> critical pyth in my patch series by following Dexuan's suggestion -
> we'll get the channel in vmbus_open and put it in vmbus_close (and on
> processing offer/rescind offer) this won't affect performance. I'm in
> the middle of testing this approach.
>
> >
> > All channel messages are handled in a single work context:
> > vmbus_on_msg_dpc() -> vmbus_onmessage_work()-> Various channel
> messages [offer, rescind etc.]
This is true.

> >
> > So, the rescind message cannot be processed while we are processing the
> offer message and since an offer
> > cannot be rescinded before it is offered, offer and rescind are naturally
> > serialized (I think I have patchset in my queue
IMO this may not be true.
The cause is:
(I'm using the latest linux-next repo, which includes Vitaly's patch
"Drivers: hv: vmbus: serialize Offer and Rescind offer".)

vmbus_onoffer_rescind() runs in vmbus_connection.work_queue, but
vmbus_process_offer() runs in the per-channel newchannel->controlwq, so the
two functions are not serialized, at least in theory.

As a result, in vmbus_process_offer(): after the new channel is added into
vmbus_connection.chn_list, but before the channel is completely initialized by
us (we need to create a vmbus device and associate the device with the
channel -- this procedure could fail and we goto err_free_chan and free the
channel directly!),  vmbus_onoffer_rescind() can see the new channel, but
doesn't know the channel could be freed in another place at the same time.

BTW, when vmbus_process_offer() -> vmbus_device_create() fails, we
goto err_free_chan without removing the new channel from
vmbus_connection.chn_list?

As another result : in vmbus_process_offer(), in the case
vmbus_device_register() fails, we'll run "list_del(&newchannel->listentry) and
unlock  vmbus_connection.channel_lock" -- just after these 2 lines, at this 
time,
vmbus_onoffer_rescind() -> relid2channel() can return NULL, and we'll miss the
rescind message, i.e., we fail to send the CHANNELMSG_RELID_RELEASED
message to the host.

Of course, these corner cases should be rare since the rescind message is really
rare today, but it may not be true in future: we can have a VMsock-like

Re: [PATCH v2] staging: rtl8192u: r8192U_core: Fix for possible null pointer dereference

[Dan Carpenter]

On Thu, Feb 05, 2015 at 06:13:22PM +0530, Sudip Mukherjee wrote:
> if (driver_info) {
>   stats->RxIs40MHzPacket = driver_info->BW;
>   if (stats->RxDrvInfoSize != 0)
>   TranslateRxSignalStuff819xUsb(skb, stats, driver_info);
> }

If driver_info is non-NULL then stats->RxDrvInfoSize is not zero and
also the reverse.  So really you only need to test one.

regards,
dan carpenter

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

[PATCH] staging: lustre: lustre: libcfs: define symbols as static

[Chen Weixiang]

-- 
Best regards,
Chen Weixiang (Alex)

>From 8de8c7f65f4529e3febb384402344d062f64230b Mon Sep 17 00:00:00 2001
From: Chen Weixiang 
Date: Thu, 5 Feb 2015 20:07:02 +0800
Subject: [PATCH] staging: lustre: lustre: libcfs: define symbols as static

This patch fixes the following warning using sparse
- warning: symbol 'libcfs_debug_mb' was not declared. Should it be
  static?
- warning: symbol 'portal_enter_debugger' was not declared. Should
  it be static?

Signed-off-by: Chen Weixiang 
---
 drivers/staging/lustre/lustre/libcfs/debug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
b/drivers/staging/lustre/lustre/libcfs/debug.c
index 7170088..76c62e8 100644
--- a/drivers/staging/lustre/lustre/libcfs/debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/debug.c
@@ -57,7 +57,7 @@ module_param(libcfs_debug, int, 0644);
 MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
 EXPORT_SYMBOL(libcfs_debug);
 
-unsigned int libcfs_debug_mb = 0;
+static unsigned int libcfs_debug_mb;
 module_param(libcfs_debug_mb, uint, 0644);
 MODULE_PARM_DESC(libcfs_debug_mb, "Total debug buffer size.");
 EXPORT_SYMBOL(libcfs_debug_mb);
@@ -93,7 +93,7 @@ EXPORT_SYMBOL(libcfs_debug_binary);
 unsigned int libcfs_stack = 3 * THREAD_SIZE / 4;
 EXPORT_SYMBOL(libcfs_stack);
 
-unsigned int portal_enter_debugger;
+static unsigned int portal_enter_debugger;
 EXPORT_SYMBOL(portal_enter_debugger);
 
 unsigned int libcfs_catastrophe;
-- 
2.2.2

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

[PATCH] staging: lustre: lustre: libcfs: define symbols as static

[Chen Weixiang]

This patch fixes the following warning using sparse
- warning: symbol 'libcfs_debug_mb' was not declared. Should it be
  static?
- warning: symbol 'portal_enter_debugger' was not declared. Should
  it be static?

Signed-off-by: Chen Weixiang 
---
 drivers/staging/lustre/lustre/libcfs/debug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/debug.c 
b/drivers/staging/lustre/lustre/libcfs/debug.c
index 7170088..76c62e8 100644
--- a/drivers/staging/lustre/lustre/libcfs/debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/debug.c
@@ -57,7 +57,7 @@ module_param(libcfs_debug, int, 0644);
 MODULE_PARM_DESC(libcfs_debug, "Lustre kernel debug mask");
 EXPORT_SYMBOL(libcfs_debug);
 
-unsigned int libcfs_debug_mb = 0;
+static unsigned int libcfs_debug_mb;
 module_param(libcfs_debug_mb, uint, 0644);
 MODULE_PARM_DESC(libcfs_debug_mb, "Total debug buffer size.");
 EXPORT_SYMBOL(libcfs_debug_mb);
@@ -93,7 +93,7 @@ EXPORT_SYMBOL(libcfs_debug_binary);
 unsigned int libcfs_stack = 3 * THREAD_SIZE / 4;
 EXPORT_SYMBOL(libcfs_stack);
 
-unsigned int portal_enter_debugger;
+static unsigned int portal_enter_debugger;
 EXPORT_SYMBOL(portal_enter_debugger);
 
 unsigned int libcfs_catastrophe;
-- 
2.2.2

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

[PATCH] staging: unisys: Fix typo in comment

[Bastien Nocera]

Signed-off-by: Bastien Nocera 
---
 drivers/staging/unisys/virthba/virthba.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/virthba/virthba.c 
b/drivers/staging/unisys/virthba/virthba.c
index d7a629b..03672d8 100644
--- a/drivers/staging/unisys/virthba/virthba.c
+++ b/drivers/staging/unisys/virthba/virthba.c
@@ -476,7 +476,7 @@ virthba_probe(struct virtpci_dev *virtpcidev, const struct 
pci_device_id *id)
 * instance - this virthba that has just been created is an
 * instance of a scsi host adapter. This scsi_host_alloc
 * function allocates a new Scsi_Host struct & performs basic
-* initializatoin.  The host is not published to the scsi
+* initialization.  The host is not published to the scsi
 * midlayer until scsi_add_host is called.
 */
DBGINF("calling scsi_host_alloc.\n");
-- 
2.1.0


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

[PATCH v2] staging: rtl8188eu: core: switch with redundant cases

[Nicholas Mc Guire]

A few redundant switch cases as well as a redundant if/else
within one of the cases was consolidated to a single call.

case WIFI_REASSOCREQ,WIFI_PROBEREQ,WIFI_BEACON,WIFI_ACTION all have the 
same effect - notably also both the if and else in the WIFI_PROBEREQ case. 

These redundant cases could all be dropped and consolidated into the 
default but for documentation they are combined into a fall through case.

Signed-off-by: Nicholas Mc Guire 
---

v2: verified that check_fwstate() has no side-effects requested by
Rasmus Villemoes , and fixed up the log
message based on feedback from Dan Carpenter 
 (hope this is better now)

Patch was only compile-tested for x86_64_defconfig + CONFIG_STAGING=y
CONFIG_R8188EU=m

Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)

 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c |9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 28918201..cd12dd7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -484,17 +484,8 @@ void mgt_dispatcher(struct adapter *padapter, struct 
recv_frame *precv_frame)
/* fall through */
case WIFI_ASSOCREQ:
case WIFI_REASSOCREQ:
-   _mgt_dispatcher(padapter, ptable, precv_frame);
-   break;
case WIFI_PROBEREQ:
-   if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
-   _mgt_dispatcher(padapter, ptable, precv_frame);
-   else
-   _mgt_dispatcher(padapter, ptable, precv_frame);
-   break;
case WIFI_BEACON:
-   _mgt_dispatcher(padapter, ptable, precv_frame);
-   break;
case WIFI_ACTION:
_mgt_dispatcher(padapter, ptable, precv_frame);
break;
-- 
1.7.10.4

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

Re: [RFC 00/10] Freescale DPAA B/QMan drivers

[Emil Medve]

Hello Dan,


Thanks for the reply

On 02/05/2015 02:41 AM, Dan Carpenter wrote:
> Normally, for staging drivers we just require the TODO and a maintainer
> and we merge things as-is.  There isn't really much review of the code.

I think I'll go for drivers/soc as we have quite a handful of other
drivers using this code that already decided not to be located into staging


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

[PATCH] hyperv: fix sparse warnings

[Lad Prabhakar]

From: "Lad, Prabhakar" 

this patch fixes following sparse warnings:

netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared. 
Should it be static?
rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was not 
declared. Should it be static?
rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not 
declared. Should it be static?

Signed-off-by: Lad, Prabhakar 
---
 Found this issue on linux-next (gcc  version 4.9.2,
 sparse version  0.4.5-rc1) and applies on top linux-next.

 drivers/net/hyperv/netvsc.c   | 6 +++---
 drivers/net/hyperv/rndis_filter.c | 5 +++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 58bb410..208eb05 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -685,9 +685,9 @@ static u32 netvsc_get_next_send_section(struct 
netvsc_device *net_device)
return ret_val;
 }
 
-u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device,
-   unsigned int section_index,
-   struct hv_netvsc_packet *packet)
+static u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device,
+  unsigned int section_index,
+  struct hv_netvsc_packet *packet)
 {
char *start = net_device->send_buf;
char *dest = (start + (section_index * net_device->send_section_size));
diff --git a/drivers/net/hyperv/rndis_filter.c 
b/drivers/net/hyperv/rndis_filter.c
index 7bd8387..7816d98 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -624,7 +624,8 @@ cleanup:
return ret;
 }
 
-int rndis_filter_set_offload_params(struct hv_device *hdev,
+static int
+rndis_filter_set_offload_params(struct hv_device *hdev,
struct ndis_offload_params *req_offloads)
 {
struct netvsc_device *nvdev = hv_get_drvdata(hdev);
@@ -699,7 +700,7 @@ u8 netvsc_hash_key[HASH_KEYLEN] = {
0x6a, 0x42, 0xb7, 0x3b, 0xbe, 0xac, 0x01, 0xfa
 };
 
-int rndis_filter_set_rss_param(struct rndis_device *rdev, int num_queue)
+static int rndis_filter_set_rss_param(struct rndis_device *rdev, int num_queue)
 {
struct net_device *ndev = rdev->net_dev->ndev;
struct rndis_request *request;
-- 
1.9.1

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

RE: [Patch v4 01/23] ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

[KY Srinivasan]

> -Original Message-
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Wednesday, February 4, 2015 9:44 PM
> To: Rafael J. Wysocki; Thomas Gleixner; Bjorn Helgaas; Yinghai Lu; Borislav
> Petkov; Lv Zheng; Tony Luck; Fenghua Yu; Ingo Molnar; H. Peter Anvin;
> x...@kernel.org; Len Brown; Robert Moore; Clemens Ladisch; Arnd
> Bergmann; Greg Kroah-Hartman; KY Srinivasan; Haiyang Zhang; Konrad
> Rzeszutek Wilk; Boris Ostrovsky; David Vrabel
> Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> a...@vger.kernel.org; Jiang Liu; linux-i...@vger.kernel.org;
> de...@acpica.org; de...@linuxdriverproject.org; xen-
> de...@lists.xenproject.org
> Subject: [Patch v4 01/23] ACPICA: Resources: Provide common part for struct
> acpi_resource_address structures.
> 
> From: Lv Zheng 
> 
> struct acpi_resource_address and struct
> acpi_resource_extended_address64 share substracts just at different
> offsets. To unify the parsing functions, OSPMs like Linux need a new
> ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can extract the
> shared data.
> 
> This patch also synchronizes the structure changes to the Linux kernel.
> The usages are searched by matching the following keywords:
> 1. acpi_resource_address
> 2. acpi_resource_extended_address
> 3. ACPI_RESOURCE_TYPE_ADDRESS
> 4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
> And we found and fixed the usages in the following files:
>  arch/ia64/kernel/acpi-ext.c
>  arch/ia64/pci/pci.c
>  arch/x86/pci/acpi.c
>  arch/x86/pci/mmconfig-shared.c
>  drivers/xen/xen-acpi-memhotplug.c
>  drivers/acpi/acpi_memhotplug.c
>  drivers/acpi/pci_root.c
>  drivers/acpi/resource.c
>  drivers/char/hpet.c
>  drivers/pnp/pnpacpi/rsparser.c
>  drivers/hv/vmbus_drv.c
> 
> Build tests are passed with defconfig/allnoconfig/allyesconfig and
> defconfig+CONFIG_ACPI=n.
> 
> Original-by: Thomas Gleixner 
> Original-by: Jiang Liu 
> Signed-off-by: Lv Zheng 
> Signed-off-by: Jiang Liu 

Hyper-V parts:
Acked-by: K. Y. Srinivasan 

> ---
>  arch/ia64/kernel/acpi-ext.c   |6 ++--
>  arch/ia64/pci/pci.c   |   14 -
>  arch/x86/pci/acpi.c   |   26 
>  arch/x86/pci/mmconfig-shared.c|6 ++--
>  drivers/acpi/acpi_memhotplug.c|8 ++---
>  drivers/acpi/acpica/rsaddr.c  |9 +++---
>  drivers/acpi/acpica/rsdumpinfo.c  |   59 +++--
> 
>  drivers/acpi/acpica/rsxface.c |   10 +++
>  drivers/acpi/pci_root.c   |6 ++--
>  drivers/acpi/resource.c   |   24 +++
>  drivers/char/hpet.c   |4 +--
>  drivers/hv/vmbus_drv.c|4 +--
>  drivers/pnp/pnpacpi/rsparser.c|   16 +-
>  drivers/xen/xen-acpi-memhotplug.c |8 ++---
>  include/acpi/acrestyp.h   |   40 +++--
>  15 files changed, 125 insertions(+), 115 deletions(-)
> 
> diff --git a/arch/ia64/kernel/acpi-ext.c b/arch/ia64/kernel/acpi-ext.c index
> 8b9318d311a0..bd09bf74f187 100644
> --- a/arch/ia64/kernel/acpi-ext.c
> +++ b/arch/ia64/kernel/acpi-ext.c
> @@ -69,10 +69,10 @@ static acpi_status find_csr_space(struct acpi_resource
> *resource, void *data)
>   status = acpi_resource_to_address64(resource, &addr);
>   if (ACPI_SUCCESS(status) &&
>   addr.resource_type == ACPI_MEMORY_RANGE &&
> - addr.address_length &&
> + addr.address.address_length &&
>   addr.producer_consumer == ACPI_CONSUMER) {
> - space->base = addr.minimum;
> - space->length = addr.address_length;
> + space->base = addr.address.minimum;
> + space->length = addr.address.address_length;
>   return AE_CTRL_TERMINATE;
>   }
>   return AE_OK;   /* keep looking */
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c index
> 900cc93e5409..48cc65705db4 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -188,12 +188,12 @@ static u64 add_io_space(struct pci_root_info *info,
> 
>   name = (char *)(iospace + 1);
> 
> - min = addr->minimum;
> - max = min + addr->address_length - 1;
> + min = addr->address.minimum;
> + max = min + addr->address.address_length - 1;
>   if (addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
>   sparse = 1;
> 
> - space_nr = new_space(addr->translation_offset, sparse);
> + space_nr = new_space(addr->address.translation_offset, sparse);
>   if (space_nr == ~0)
>   goto free_resource;
> 
> @@ -247,7 +247,7 @@ static acpi_status resource_to_window(struct
> acpi_resource *resource,
>   if (ACPI_SUCCESS(status) &&
>   (addr->resource_type == ACPI_MEMORY_RANGE ||
>addr->resource_type == ACPI_IO_RANGE) &&
> - addr->address_length &&
> + addr->address.address_length &&
>   addr->producer_consumer == ACPI_PRODUCER)
>   return AE_OK;
> 
> @@ -284,7 +284,7 @@ static acpi_status add_window(struct a

RE: [PATCH 0/4] Drivers: hv: Further protection for the rescind path

[KY Srinivasan]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Thursday, February 5, 2015 2:10 AM
> To: KY Srinivasan
> Cc: de...@linuxdriverproject.org; Haiyang Zhang; linux-
> ker...@vger.kernel.org; Dexuan Cui; Jason Wang
> Subject: Re: [PATCH 0/4] Drivers: hv: Further protection for the rescind path
> 
> KY Srinivasan  writes:
> 
> >> -Original Message-
> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >> Sent: Tuesday, February 3, 2015 9:01 AM
> >> To: KY Srinivasan; de...@linuxdriverproject.org
> >> Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason
> >> Wang
> >> Subject: [PATCH 0/4] Drivers: hv: Further protection for the rescind
> >> path
> >>
> >> This series is a continuation of the "Drivers: hv: vmbus: serialize
> >> Offer and Rescind offer". I'm trying to address a number of
> >> theoretically possible issues with rescind offer handling. All these
> >> complications come from the fact that a rescind offer results in
> >> vmbus channel being freed and we must ensure nobody still uses it.
> >> Instead of introducing new locks I suggest we switch channels usage to
> the get/put workflow.
> >>
> >> The main part of the series is [PATCH 1/4] which introduces the
> >> workflow for vmbus channels, all other patches fix different corner
> >> cases using this workflow. I'm not sure all such cases are covered
> >> with this series (probably not), but in case protection is required
> >> in some other places it should become relatively easy to add one.
> >>
> >> I did some sanity testing with CONFIG_DEBUG_LOCKDEP=y and nothing
> >> popped out, however, additional testing would be much appreciated.
> >>
> >> K.Y., Haiyang, I'm not sending this series to netdev@ and linux-scsi@
> >> as it is supposed to be applied as a whole, please resend these
> >> patches with your sign-offs when (and if) we're done with reviews.
> Thanks!
> >
> > Vitaly,
> >
> > Thanks for looking into this issue. While today, rescind offer results
> > in the freeing of the channel, I don't think that is required. By not
> > freeing up the channel in the rescind path, we can have a safe way to
> > access the channel and that does not have to involve taking a
> > reference on the channel every time you access it - the get/put
> > workflow in your patch set. As part of the network performance
> > improvement work, I had eliminated all locks in the receive path by setting
> up per-cpu data structures for mapping the relid to channel etc. These set of
> patches introduces locking/atomic operations in performance critical code
> paths to deal with an event that is truly rare - the channel getting 
> rescinded.
> 
> It is possible to eliminate all locks/atomic operations from performance
> critical pyth in my patch series by following Dexuan's suggestion - we'll get
> the channel in vmbus_open and put it in vmbus_close (and on processing
> offer/rescind offer) this won't affect performance. I'm in the middle of
> testing this approach.
> 
> >
> > All channel messages are handled in a single work context:
> >
> > vmbus_on_msg_dpc() -> vmbus_onmessage_work()-> Various channel
> > messages [offer, rescind etc.]
> >
> > So, the rescind message cannot be processed while we are processing
> > the offer message and since an offer cannot be rescinded before it is
> > offered, offer and rescind are naturally serialized (I think I have
> > patchset in my queue from you that is trying to solve the concurrent
> execution of offer and rescind and looking at the code I cannot see how this
> can occur).
> >
> > As part of handling the rescind message, we will just set the channel
> > state to indicate that the offer is rescinded (we can add the rescind state 
> > to
> the channel states already defined and this will be done under the protection
> of the channel lock).
> > The cleanup of the channel and sending of the RELID release message
> > will only be done in the context of the driver as part of driver
> > remove function. I think this should be doable in a way that does not
> penalize the normal path. If it is ok with you, I will try to put together a 
> patch
> along the lines I have described here.
> >
> 
> Yes, if we consider rescind event as a very rare event we can avoid freeing
> channels, but if (in some conditions) it happens frequently we'll have
> significant memory leakage.
> 
Rescind offer is rare; but I am not suggesting that we would leak memory in 
this case.
What I am suggesting is that we can place the burden where it should be - do all
the cleanup in vmbus_close() driven by the remove function.

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

Re: [RFC 00/10] Freescale DPAA B/QMan drivers

[Emil Medve]

Hello Bob,


On 02/05/2015 09:48 AM, Bob Cochran wrote:
> On 02/04/2015 09:48 AM, Emil Medve wrote:
>>
>> Hello,
>>
>>
>> This is the first attempt to publish the Freescale DPAA B/QMan
>> drivers. They are
>> not to be applied yet.  At this stage, this is more or less the
>> drivers from the
>> Freescale PowerPC SDK roughly squashed and split in a sequence of
>> component
>> patches. They still needs some work and cleanup before we expect to
>> have them
>> applied, but we appreciate early feedback
> 
> 
> Hi Emil,
> 
> I had thought to try to apply these patches and build it, but I won't
> get very far using it without FMAN (on my t1040).   I searched through
> the mail archives and didn't find FMAN patches other than for the device
> tree.   I also don't see it in the mainline tree.
> 
> If FMAN patches have already been submitted, please point me to it.
> 
> If not, then please let me know when we will see code to support FMAN.

Let me inquire with the FMan guy here. I'll get back to you on this,
however, don't hold your breath. There might be some weeks before the
FMan driver will hit the e-mail lists

> Also, is it your intention for the same QMAN/BMAN drivers to be used
> with both FMAN and the LS AIOP?

These drivers (with some upcoming updates) are expected to be use on all
QorIQ and LS1 devices. The programming model for LS2 (which includes the
AIOP and friends) seems to have a different programming model and these
drivers will not be usable there


Cheers,


> Thank you,
> 
> Bob
> 
> 
> 
> 
> 
>>
>>
>> Cheers,
>>
>>
>> Geoff Thorpe (8):
>>fsl_bman: Add drivers for the Freescale DPAA BMan
>>fsl_qman: Add drivers for the Freescale DPAA QMan
>>powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan
>>powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan
>>fsl_bman: Add self-tester
>>fsl_qman: Add self-tester
>>fsl_bman: Add debugfs support
>>fsl_qman: Add debugfs support
>>
>> Hai-Ying Wang (2):
>>fsl_bman: Add HOTPLUG_CPU support
>>fsl_qman: Add HOTPLUG_CPU support
>>
>>   arch/powerpc/Kconfig|   33 +-
>>   arch/powerpc/platforms/85xx/Kconfig |   11 +-
>>   arch/powerpc/platforms/85xx/corenet_generic.c   |   26 +-
>>   arch/powerpc/platforms/85xx/p1023_rdb.c |   26 +-
>>   drivers/staging/Kconfig |4 +-
>>   drivers/staging/Makefile|1 +
>>   drivers/staging/fsl_qbman/Kconfig   |  188 ++
>>   drivers/staging/fsl_qbman/Makefile  |   23 +
>>   drivers/staging/fsl_qbman/bman_config.c |  611 ++
>>   drivers/staging/fsl_qbman/bman_debugfs.c|  119 +
>>   drivers/staging/fsl_qbman/bman_driver.c |  373 
>>   drivers/staging/fsl_qbman/bman_high.c   | 1055 +
>>   drivers/staging/fsl_qbman/bman_low.h|  524 +
>>   drivers/staging/fsl_qbman/bman_private.h|  149 ++
>>   drivers/staging/fsl_qbman/bman_test.c   |   56 +
>>   drivers/staging/fsl_qbman/bman_test.h   |   44 +
>>   drivers/staging/fsl_qbman/bman_test_high.c  |  181 ++
>>   drivers/staging/fsl_qbman/bman_test_thresh.c|  196 ++
>>   drivers/staging/fsl_qbman/dpa_alloc.c   |  573 +
>>   drivers/staging/fsl_qbman/dpa_sys.h |  294 +++
>>   drivers/staging/fsl_qbman/qbman_driver.c|   85 +
>>   drivers/staging/fsl_qbman/qman_config.c |  991 +
>>   drivers/staging/fsl_qbman/qman_debugfs.c| 1326 
>>   drivers/staging/fsl_qbman/qman_driver.c |  548 +
>>   drivers/staging/fsl_qbman/qman_high.c   | 2624
>> +++
>>   drivers/staging/fsl_qbman/qman_low.h| 1302 +++
>>   drivers/staging/fsl_qbman/qman_private.h|  283 +++
>>   drivers/staging/fsl_qbman/qman_test.c   |   57 +
>>   drivers/staging/fsl_qbman/qman_test.h   |   43 +
>>   drivers/staging/fsl_qbman/qman_test_high.c  |  213 ++
>>   drivers/staging/fsl_qbman/qman_test_hotpotato.c |  497 +
>>   drivers/staging/fsl_qbman/qman_utility.c|  129 ++
>>   include/linux/fsl_bman.h|  517 +
>>   include/linux/fsl_qman.h| 1955
>> +
>>   34 files changed, 15032 insertions(+), 25 deletions(-)
>>   create mode 100644 drivers/staging/fsl_qbman/Kconfig
>>   create mode 100644 drivers/staging/fsl_qbman/Makefile
>>   create mode 100644 drivers/staging/fsl_qbman/bman_config.c
>>   create mode 100644 drivers/staging/fsl_qbman/bman_debugfs.c
>>   create mode 100644 drivers/staging/fsl_qbman/bman_driver.c
>>   create mode 100644 drivers/staging/fsl_qbman/bman_high.c
>>   create mode 100644 drivers/staging/fsl_qbman/bman_low.h
>>   create mode 100644 drivers/staging/fsl_qbman/bman_private.h
>>   create mode 100644 drivers/staging/fsl_qbman/bman_test.c
>>   create mode 100644 drivers/staging/fsl_qbman/bman_test.h
>>   create

Re: [RFC 00/10] Freescale DPAA B/QMan drivers

[Bob Cochran]

On 02/04/2015 09:48 AM, Emil Medve wrote:


Hello,


This is the first attempt to publish the Freescale DPAA B/QMan drivers. They are
not to be applied yet.  At this stage, this is more or less the drivers from the
Freescale PowerPC SDK roughly squashed and split in a sequence of component
patches. They still needs some work and cleanup before we expect to have them
applied, but we appreciate early feedback



Hi Emil,

I had thought to try to apply these patches and build it, but I won't 
get very far using it without FMAN (on my t1040).   I searched through 
the mail archives and didn't find FMAN patches other than for the device 
tree.   I also don't see it in the mainline tree.


If FMAN patches have already been submitted, please point me to it.

If not, then please let me know when we will see code to support FMAN.

Also, is it your intention for the same QMAN/BMAN drivers to be used 
with both FMAN and the LS AIOP?


Thank you,

Bob








Cheers,


Geoff Thorpe (8):
   fsl_bman: Add drivers for the Freescale DPAA BMan
   fsl_qman: Add drivers for the Freescale DPAA QMan
   powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan
   powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan
   fsl_bman: Add self-tester
   fsl_qman: Add self-tester
   fsl_bman: Add debugfs support
   fsl_qman: Add debugfs support

Hai-Ying Wang (2):
   fsl_bman: Add HOTPLUG_CPU support
   fsl_qman: Add HOTPLUG_CPU support

  arch/powerpc/Kconfig|   33 +-
  arch/powerpc/platforms/85xx/Kconfig |   11 +-
  arch/powerpc/platforms/85xx/corenet_generic.c   |   26 +-
  arch/powerpc/platforms/85xx/p1023_rdb.c |   26 +-
  drivers/staging/Kconfig |4 +-
  drivers/staging/Makefile|1 +
  drivers/staging/fsl_qbman/Kconfig   |  188 ++
  drivers/staging/fsl_qbman/Makefile  |   23 +
  drivers/staging/fsl_qbman/bman_config.c |  611 ++
  drivers/staging/fsl_qbman/bman_debugfs.c|  119 +
  drivers/staging/fsl_qbman/bman_driver.c |  373 
  drivers/staging/fsl_qbman/bman_high.c   | 1055 +
  drivers/staging/fsl_qbman/bman_low.h|  524 +
  drivers/staging/fsl_qbman/bman_private.h|  149 ++
  drivers/staging/fsl_qbman/bman_test.c   |   56 +
  drivers/staging/fsl_qbman/bman_test.h   |   44 +
  drivers/staging/fsl_qbman/bman_test_high.c  |  181 ++
  drivers/staging/fsl_qbman/bman_test_thresh.c|  196 ++
  drivers/staging/fsl_qbman/dpa_alloc.c   |  573 +
  drivers/staging/fsl_qbman/dpa_sys.h |  294 +++
  drivers/staging/fsl_qbman/qbman_driver.c|   85 +
  drivers/staging/fsl_qbman/qman_config.c |  991 +
  drivers/staging/fsl_qbman/qman_debugfs.c| 1326 
  drivers/staging/fsl_qbman/qman_driver.c |  548 +
  drivers/staging/fsl_qbman/qman_high.c   | 2624 +++
  drivers/staging/fsl_qbman/qman_low.h| 1302 +++
  drivers/staging/fsl_qbman/qman_private.h|  283 +++
  drivers/staging/fsl_qbman/qman_test.c   |   57 +
  drivers/staging/fsl_qbman/qman_test.h   |   43 +
  drivers/staging/fsl_qbman/qman_test_high.c  |  213 ++
  drivers/staging/fsl_qbman/qman_test_hotpotato.c |  497 +
  drivers/staging/fsl_qbman/qman_utility.c|  129 ++
  include/linux/fsl_bman.h|  517 +
  include/linux/fsl_qman.h| 1955 +
  34 files changed, 15032 insertions(+), 25 deletions(-)
  create mode 100644 drivers/staging/fsl_qbman/Kconfig
  create mode 100644 drivers/staging/fsl_qbman/Makefile
  create mode 100644 drivers/staging/fsl_qbman/bman_config.c
  create mode 100644 drivers/staging/fsl_qbman/bman_debugfs.c
  create mode 100644 drivers/staging/fsl_qbman/bman_driver.c
  create mode 100644 drivers/staging/fsl_qbman/bman_high.c
  create mode 100644 drivers/staging/fsl_qbman/bman_low.h
  create mode 100644 drivers/staging/fsl_qbman/bman_private.h
  create mode 100644 drivers/staging/fsl_qbman/bman_test.c
  create mode 100644 drivers/staging/fsl_qbman/bman_test.h
  create mode 100644 drivers/staging/fsl_qbman/bman_test_high.c
  create mode 100644 drivers/staging/fsl_qbman/bman_test_thresh.c
  create mode 100644 drivers/staging/fsl_qbman/dpa_alloc.c
  create mode 100644 drivers/staging/fsl_qbman/dpa_sys.h
  create mode 100644 drivers/staging/fsl_qbman/qbman_driver.c
  create mode 100644 drivers/staging/fsl_qbman/qman_config.c
  create mode 100644 drivers/staging/fsl_qbman/qman_debugfs.c
  create mode 100644 drivers/staging/fsl_qbman/qman_driver.c
  create mode 100644 drivers/staging/fsl_qbman/qman_high.c
  create mode 100644 drivers/staging/fsl_qbman/qman_low.h
  create mode 100644 drivers/staging/fsl_qbman/qman_private.h
  create mode 100644 drivers/staging/fsl_qbman/qman_test.c
  create mode 100644 drivers/staging/fsl_q

use of opaque subject lines

[Al Viro]

On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:

> On a serious note: I do understand what you're getting at, I don't take
> that personally (and I will send a v2 addressing the things above), but
> honestly, this kind of answer might just be a real turn-off for other
> people trying to get into kernel development...
> 
> I don't want to start a whole new 'attitude in the kernel community'
> discussion, but I can't just let this go like that, sorry.

Just during the last 12 hours or so, I've seen the following l-k traffic:

Subject: [PATCH] usb: host/sl811-hcd: fix sparse warning
Subject: [PATCH] usb: gadget: function/f_sourcesink: fix sparse warning
Subject: [PATCH] tty: vt/vt: fix sparse warning
Subject: [PATCH] scsi: fix sparse warnings
Subject: [PATCH] bfa: bfa_core: fix sparse warning
Subject: [PATCH] scsi: fix sparse warning
Subject: [PATCH] xen/acpi-processor: fix sparse warning
Subject: [PATCH] scsi: initio: fix sparse warnings
Subject: [PATCH] scsi: dc395x: fix sparse warning
Subject: [PATCH] scsi: eata: fix sparse warning
Subject: [PATCH] scsi: qla1280: fix sparse warnings
Subject: [PATCH] scsi: ips: fix sparse warnings
Subject: [PATCH] fbdev: via/via_clock: fix sparse warning
Subject: [PATCH] usb: gadget: fix sparse warnings
Subject: [PATCH] usb: gadget: fix sparse warnings
Subject: [PATCH] usb: gadget: function/uvc_v4l2.c: fix sparse warnings
Subject: [PATCH] xen-netback: fix sparse warning
Subject: [PATCH] thermal: int340x: fix sparse warning
Subject: [PATCH] vxge: fix sparse warning
Subject: Re: [PATCH] xen-netback: fix sparse warning
Subject: [PATCH] ixgbe: fix sparse warnings
Subject: [PATCH] samsung-laptop: fix sparse warning
Subject: [PATCH] x86: thinkpad_acpi.c: fix sparse warning
Subject: [PATCH] Sony-laptop: fix sparse warning

one of those is an ACK from maintainer, the rest are (AFAICS) all "make
something static", all with rather poor commit messages and subjects.  Not
threaded, either (that would've somewhat mitigated one of the problems).

Bad attitude?  I'd say that _this_ is one.  l-k is high-traffic list;
postings like that mean extra strain on those who are trying at least to
skim through it and they are not easy on those who are trying to read the
commit logs.  And it's trivial to mitigate - choose less opaque subjects,
for starters.  Because these are about as opaque as it gets: essentially,
it's "sparse had drawn my attention to $FILE; I've fixed that problem by
making it STFU".  Readers would like more information to filter upon?
Tough luck, open the damn mail and look into it.  One after another, after
another, to the tune of dozens per night.  All with the commit messages
pretty much of the form "$TOOL has produced $MESSAGE; with diff below it
doesn't".

It's physically impossible to read through all l-k traffic; the rate is too
high for that.  Is making it possible to do minimal triage too much to ask for?
I'm not blaming anyone for going after the low-hanging fruit like that to
get some experience on simple stuff, but as it is, it reinforces seriously
bad habits while creating considerable PITA for list readers.  And yes,
we'd all done our share of lousy commit messages, but this pretty much
teaches newbies to do that all the time.

Sigh...  Folks, please
* Use descriptive subject lines at least somewhere in a thread.
* Describe what the thing does, besides "makes $TOOL to STFU".
* Remember, you don't fix warnings - you deal with the problem
(if any) in the code those warnings had pointed to.  And if there isn't
a problem (i.e. the warning was a false positive) you might be annotating
the code to tell the dumb tool what's going on there.  Which is a different
genre, and needs different mindset when reviewing (it's easy to obfuscate
a _real_ problem away - away from the $TOOL's ability to spot it, that
is).
* Remember that said tools are nowhere near strong AI; the
same warning can come from very different underlying problems.  These
warnigns are heuristics - such-and-such looking code has high chances of
needing attention.  Give at least some indication what the problem _is_ - e.g.
the sparse warnings that has spawned this flood might come from
1) function really is used only in the file it's defined in,
never intended to be used elsewhere, ought to be static to avoid namespace
pollution
2) function is used elsewhere, and its uses elsewhere have explicit
externs right at the point of use.  Dangerous, since there's no practical
way for compiler (gcc, sparse, lint, whatever) to verify that there's no
type mismatch.  Ought to have extern placed in some header included both by
the file where it's defined and by all files where it's used, with externs
at the point of use removed.  Need to be careful about the choice of header
and location in it.
3) function _is_ declared in a common header, but it's either not
included by the file where it actually lives, *or* is included only on
some architectures an

Re: [PATCH net-next v2] hyper-v: allow access to vmbus from userspace driver

[Stephen Hemminger]

On Thu, 05 Feb 2015 12:01:03 +0100
Vitaly Kuznetsov  wrote:

> Stephen Hemminger  writes:
> 
> > This is enables the hyper-v driver for DPDK .
> > The hv_uio driver needs to access the shared vmbus monitor
> > pages.
> 
> Why can't we just make vmbus_connection struct public?
> 
> >
> > I would also like to put hv_uio in upstream kernel like other
> > uio drivers, but need to get API accepted with DPDK first.
> >
> > Signed-off-by: Stas Egorov 
> > Signed-off-by: Stephen Hemminger 
> >
> > ---
> > v2 - simplify and rename to vmbus_get_monitor_pages
> >
> >  drivers/hv/connection.c |   20 +---
> >  include/linux/hyperv.h  |3 +++
> >  2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > --- a/drivers/hv/connection.c   2015-02-03 10:58:51.751752450 -0800
> > +++ b/drivers/hv/connection.c   2015-02-04 14:59:51.636194383 -0800
> > @@ -64,6 +64,15 @@ static __u32 vmbus_get_next_version(__u3
> > }
> >  }
> >
> > +void vmbus_get_monitor_pages(unsigned long *int_page,
> > +unsigned long monitor_pages[2])
> > +{
> 
> Too weird to be a public interface in my opinion.
> 
> > +   *int_page = (unsigned long)vmbus_connection.int_page;
> > +   monitor_pages[0] = (unsigned long)vmbus_connection.monitor_pages[0];
> > +   monitor_pages[1] = (unsigned long)vmbus_connection.monitor_pages[1];
> > +}
> > +EXPORT_SYMBOL_GPL(vmbus_get_monitor_pages);
> > +
> >  static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
> > __u32 version)
> >  {
> > @@ -347,10 +356,7 @@ static void process_chn_event(u32 relid)
> > else
> > bytes_to_read = 0;
> > } while (read_state && (bytes_to_read != 0));
> > -   } else {
> > -   pr_err("no channel callback for relid - %u\n", relid);
> > }
> > -
> >  }
> 
> This change wasn't mentioned in your commit msg.

Was in earlier commit. Need to prevent driver from logging error
when device is not claimed directly by existing kernel devices.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: use of opaque subject lines

[Lad, Prabhakar]

On Thu, Feb 5, 2015 at 4:30 PM, Al Viro  wrote:
> On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:
>
>> On a serious note: I do understand what you're getting at, I don't take
>> that personally (and I will send a v2 addressing the things above), but
>> honestly, this kind of answer might just be a real turn-off for other
>> people trying to get into kernel development...
>>
>> I don't want to start a whole new 'attitude in the kernel community'
>> discussion, but I can't just let this go like that, sorry.
>
> Just during the last 12 hours or so, I've seen the following l-k traffic:
>
> Subject: [PATCH] usb: host/sl811-hcd: fix sparse warning
> Subject: [PATCH] usb: gadget: function/f_sourcesink: fix sparse warning
> Subject: [PATCH] tty: vt/vt: fix sparse warning
> Subject: [PATCH] scsi: fix sparse warnings
> Subject: [PATCH] bfa: bfa_core: fix sparse warning
> Subject: [PATCH] scsi: fix sparse warning
> Subject: [PATCH] xen/acpi-processor: fix sparse warning
> Subject: [PATCH] scsi: initio: fix sparse warnings
> Subject: [PATCH] scsi: dc395x: fix sparse warning
> Subject: [PATCH] scsi: eata: fix sparse warning
> Subject: [PATCH] scsi: qla1280: fix sparse warnings
> Subject: [PATCH] scsi: ips: fix sparse warnings
> Subject: [PATCH] fbdev: via/via_clock: fix sparse warning
> Subject: [PATCH] usb: gadget: fix sparse warnings
> Subject: [PATCH] usb: gadget: fix sparse warnings
> Subject: [PATCH] usb: gadget: function/uvc_v4l2.c: fix sparse warnings
> Subject: [PATCH] xen-netback: fix sparse warning
> Subject: [PATCH] thermal: int340x: fix sparse warning
> Subject: [PATCH] vxge: fix sparse warning
> Subject: Re: [PATCH] xen-netback: fix sparse warning
> Subject: [PATCH] ixgbe: fix sparse warnings
> Subject: [PATCH] samsung-laptop: fix sparse warning
> Subject: [PATCH] x86: thinkpad_acpi.c: fix sparse warning
> Subject: [PATCH] Sony-laptop: fix sparse warning
>
all right I have stopped the script to send any more patches fixing
sparse warnings !

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

RE: [PATCH] hyperv: fix sparse warnings

[Haiyang Zhang]

> -Original Message-
> From: Lad Prabhakar [mailto:prabhakar.cse...@gmail.com]
> Sent: Thursday, February 5, 2015 10:07 AM
> To: KY Srinivasan; Haiyang Zhang; de...@linuxdriverproject.org
> Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; Lad, Prabhakar
> Subject: [PATCH] hyperv: fix sparse warnings
> 
> From: "Lad, Prabhakar" 
> 
> this patch fixes following sparse warnings:
> 
> netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not
> declared. Should it be static?
> rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params'
> was not declared. Should it be static?
> rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was
> not declared. Should it be static?
> 
> Signed-off-by: Lad, Prabhakar 

Signed-off-by: Haiyang Zhang 

Thanks.


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

Re: use of opaque subject lines

[Joe Perches]

On Thu, 2015-02-05 at 16:30 +, Al Viro wrote:
> On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:
> 
> > On a serious note: I do understand what you're getting at, I don't take
> > that personally (and I will send a v2 addressing the things above), but
> > honestly, this kind of answer might just be a real turn-off for other
> > people trying to get into kernel development...
> > 
> > I don't want to start a whole new 'attitude in the kernel community'
> > discussion, but I can't just let this go like that, sorry.

Maybe YA checkpatch warning when patch subjects
include either "checkpatch" or "sparse" would help?

Something like:
---
 scripts/checkpatch.pl | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3642b0d..b6bed59 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2170,6 +2170,13 @@ sub process {
}
}
 
+# Check email subject for poor style
+   if ($in_header_lines &&
+   $line =~ /^Subject:.*\b(?:checkpatch|sparse)\b[^:]/i) {
+   WARN("EMAIL_SUBJECT",
+"A patch subject line should describe the change 
not the tool that found it\n" . $herecurr);
+   }
+
 # Check for old stable address
if ($line =~ /^\s*cc:\s*.*?.*$/i) {
ERROR("STABLE_ADDRESS",


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

Re: use of opaque subject lines

[Dan Carpenter]

Acked-by: Dan Carpenter 

regards,
dan carpenter

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

Re: use of opaque subject lines

[Dan Carpenter]

On Thu, Feb 05, 2015 at 09:32:55AM -0800, Joe Perches wrote:
> On Thu, 2015-02-05 at 09:31 -0800, Joe Perches wrote:
> > On Thu, 2015-02-05 at 20:25 +0300, Dan Carpenter wrote:
> > > Acked-by: Dan Carpenter 
> > 
> > Maybe I should add sparse too... ;)
> 
> drat, of course I meant smatch...
>

No need.  Smatch users are awesome at writing changelogs.

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

Re: [PATCH v2] staging: rtl8192u: r8192U_core: Fix for possible null pointer dereference

[Rickard Strandqvist]

2015-02-05 13:51 GMT+01:00 Dan Carpenter :
> On Thu, Feb 05, 2015 at 06:13:22PM +0530, Sudip Mukherjee wrote:
>> if (driver_info) {
>>   stats->RxIs40MHzPacket = driver_info->BW;
>>   if (stats->RxDrvInfoSize != 0)
>>   TranslateRxSignalStuff819xUsb(skb, stats, driver_info);
>> }
>
> If driver_info is non-NULL then stats->RxDrvInfoSize is not zero and
> also the reverse.  So really you only need to test one.
>
> regards,
> dan carpenter
>

True Dan

Okay, I'll make one last patch then, or if you want to do it Sudip?
Have you not done before Saturday I do it.

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

Re: use of opaque subject lines

[Joe Perches]

On Thu, 2015-02-05 at 09:31 -0800, Joe Perches wrote:
> On Thu, 2015-02-05 at 20:25 +0300, Dan Carpenter wrote:
> > Acked-by: Dan Carpenter 
> 
> Maybe I should add sparse too... ;)

drat, of course I meant smatch...


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

Re: use of opaque subject lines

[Greg Kroah-Hartman]

On Thu, Feb 05, 2015 at 04:57:09PM +, Lad, Prabhakar wrote:
> On Thu, Feb 5, 2015 at 4:30 PM, Al Viro  wrote:
> > On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:
> >
> >> On a serious note: I do understand what you're getting at, I don't take
> >> that personally (and I will send a v2 addressing the things above), but
> >> honestly, this kind of answer might just be a real turn-off for other
> >> people trying to get into kernel development...
> >>
> >> I don't want to start a whole new 'attitude in the kernel community'
> >> discussion, but I can't just let this go like that, sorry.
> >
> > Just during the last 12 hours or so, I've seen the following l-k traffic:
> >
> > Subject: [PATCH] usb: host/sl811-hcd: fix sparse warning
> > Subject: [PATCH] usb: gadget: function/f_sourcesink: fix sparse warning
> > Subject: [PATCH] tty: vt/vt: fix sparse warning
> > Subject: [PATCH] scsi: fix sparse warnings
> > Subject: [PATCH] bfa: bfa_core: fix sparse warning
> > Subject: [PATCH] scsi: fix sparse warning
> > Subject: [PATCH] xen/acpi-processor: fix sparse warning
> > Subject: [PATCH] scsi: initio: fix sparse warnings
> > Subject: [PATCH] scsi: dc395x: fix sparse warning
> > Subject: [PATCH] scsi: eata: fix sparse warning
> > Subject: [PATCH] scsi: qla1280: fix sparse warnings
> > Subject: [PATCH] scsi: ips: fix sparse warnings
> > Subject: [PATCH] fbdev: via/via_clock: fix sparse warning
> > Subject: [PATCH] usb: gadget: fix sparse warnings
> > Subject: [PATCH] usb: gadget: fix sparse warnings
> > Subject: [PATCH] usb: gadget: function/uvc_v4l2.c: fix sparse warnings
> > Subject: [PATCH] xen-netback: fix sparse warning
> > Subject: [PATCH] thermal: int340x: fix sparse warning
> > Subject: [PATCH] vxge: fix sparse warning
> > Subject: Re: [PATCH] xen-netback: fix sparse warning
> > Subject: [PATCH] ixgbe: fix sparse warnings
> > Subject: [PATCH] samsung-laptop: fix sparse warning
> > Subject: [PATCH] x86: thinkpad_acpi.c: fix sparse warning
> > Subject: [PATCH] Sony-laptop: fix sparse warning
> >
> all right I have stopped the script to send any more patches fixing
> sparse warnings !

That's not the point at all {sigh}

The point is, if you are going to do fixes, also provide a valid subject
line too.  Think of the people on the receiving end of your patch, they
are the most valuable and limited resource our community has right now.
You want to make it as _easy_ as possible for them to accept your
contribution.  If you don't provide enough information, or drown them in
redundancy, or crappy patches, they will just get frustrated and drop
them all on the floor.

And _NEVER_ have automated scripts create patches and send them out.  I
only know of ONE person/bot that gets away with this, and you are not
that person, sorry.  It it not a script on the receiving end of your
output, so don't use a script to create a mess for them to dig through.

I want these types of fixes, but make it easy for us to accept them, not
hard, like Al is pointing out in very vivid detail.  To respond to his
heartfelt plea and detailed instructions with a "fine, I'll just go
away!" is disrespectful.

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

Re: use of opaque subject lines

[Greg Kroah-Hartman]

On Thu, Feb 05, 2015 at 09:08:59AM -0800, Joe Perches wrote:
> On Thu, 2015-02-05 at 16:30 +, Al Viro wrote:
> > On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:
> > 
> > > On a serious note: I do understand what you're getting at, I don't take
> > > that personally (and I will send a v2 addressing the things above), but
> > > honestly, this kind of answer might just be a real turn-off for other
> > > people trying to get into kernel development...
> > > 
> > > I don't want to start a whole new 'attitude in the kernel community'
> > > discussion, but I can't just let this go like that, sorry.
> 
> Maybe YA checkpatch warning when patch subjects
> include either "checkpatch" or "sparse" would help?
> 
> Something like:
> ---
>  scripts/checkpatch.pl | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3642b0d..b6bed59 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2170,6 +2170,13 @@ sub process {
>   }
>   }
>  
> +# Check email subject for poor style
> + if ($in_header_lines &&
> + $line =~ /^Subject:.*\b(?:checkpatch|sparse)\b[^:]/i) {
> + WARN("EMAIL_SUBJECT",
> +  "A patch subject line should describe the change 
> not the tool that found it\n" . $herecurr);
> + }
> +
>  # Check for old stable address
>   if ($line =~ /^\s*cc:\s*.*?.*$/i) {
>   ERROR("STABLE_ADDRESS",
> 


Acked-by: Greg Kroah-Hartman 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: use of opaque subject lines

[Joe Perches]

On Thu, 2015-02-05 at 20:35 +0300, Dan Carpenter wrote:
> On Thu, Feb 05, 2015 at 09:32:55AM -0800, Joe Perches wrote:
> > On Thu, 2015-02-05 at 09:31 -0800, Joe Perches wrote:
> > > On Thu, 2015-02-05 at 20:25 +0300, Dan Carpenter wrote:
> > > > Acked-by: Dan Carpenter 
> > > Maybe I should add sparse too... ;)
> > drat, of course I meant smatch...
> No need.  Smatch users are awesome at writing changelogs.

:) good point, kinda...

$ git log --format=oneline | grep -wi smatch | wc -l
141
$ git log --pretty=oneline | grep -wi sparse | wc -l
2383
$ git log --pretty=oneline | grep -Pi "\bcheckpatch\b[^:]" | wc -l
1637


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

Re: use of opaque subject lines

[Lad, Prabhakar]

On Thu, Feb 5, 2015 at 5:57 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Feb 05, 2015 at 04:57:09PM +, Lad, Prabhakar wrote:
>> On Thu, Feb 5, 2015 at 4:30 PM, Al Viro  wrote:
>> > On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:
>> >
>> >> On a serious note: I do understand what you're getting at, I don't take
>> >> that personally (and I will send a v2 addressing the things above), but
>> >> honestly, this kind of answer might just be a real turn-off for other
>> >> people trying to get into kernel development...
>> >>
>> >> I don't want to start a whole new 'attitude in the kernel community'
>> >> discussion, but I can't just let this go like that, sorry.
>> >
>> > Just during the last 12 hours or so, I've seen the following l-k traffic:
>> >
>> > Subject: [PATCH] usb: host/sl811-hcd: fix sparse warning
>> > Subject: [PATCH] usb: gadget: function/f_sourcesink: fix sparse warning
>> > Subject: [PATCH] tty: vt/vt: fix sparse warning
>> > Subject: [PATCH] scsi: fix sparse warnings
>> > Subject: [PATCH] bfa: bfa_core: fix sparse warning
>> > Subject: [PATCH] scsi: fix sparse warning
>> > Subject: [PATCH] xen/acpi-processor: fix sparse warning
>> > Subject: [PATCH] scsi: initio: fix sparse warnings
>> > Subject: [PATCH] scsi: dc395x: fix sparse warning
>> > Subject: [PATCH] scsi: eata: fix sparse warning
>> > Subject: [PATCH] scsi: qla1280: fix sparse warnings
>> > Subject: [PATCH] scsi: ips: fix sparse warnings
>> > Subject: [PATCH] fbdev: via/via_clock: fix sparse warning
>> > Subject: [PATCH] usb: gadget: fix sparse warnings
>> > Subject: [PATCH] usb: gadget: fix sparse warnings
>> > Subject: [PATCH] usb: gadget: function/uvc_v4l2.c: fix sparse warnings
>> > Subject: [PATCH] xen-netback: fix sparse warning
>> > Subject: [PATCH] thermal: int340x: fix sparse warning
>> > Subject: [PATCH] vxge: fix sparse warning
>> > Subject: Re: [PATCH] xen-netback: fix sparse warning
>> > Subject: [PATCH] ixgbe: fix sparse warnings
>> > Subject: [PATCH] samsung-laptop: fix sparse warning
>> > Subject: [PATCH] x86: thinkpad_acpi.c: fix sparse warning
>> > Subject: [PATCH] Sony-laptop: fix sparse warning
>> >
>> all right I have stopped the script to send any more patches fixing
>> sparse warnings !
>
> That's not the point at all {sigh}
>
> The point is, if you are going to do fixes, also provide a valid subject
> line too.  Think of the people on the receiving end of your patch, they
> are the most valuable and limited resource our community has right now.
> You want to make it as _easy_ as possible for them to accept your
> contribution.  If you don't provide enough information, or drown them in
> redundancy, or crappy patches, they will just get frustrated and drop
> them all on the floor.
>
> And _NEVER_ have automated scripts create patches and send them out.  I
> only know of ONE person/bot that gets away with this, and you are not
> that person, sorry.  It it not a script on the receiving end of your
> output, so don't use a script to create a mess for them to dig through.
>
> I want these types of fixes, but make it easy for us to accept them, not
> hard, like Al is pointing out in very vivid detail.  To respond to his
> heartfelt plea and detailed instructions with a "fine, I'll just go
> away!" is disrespectful.
>
Sorry for that.

I agree a proper a description is needed ideally, but all these days prior to my
patches, the subject  line was 'fix sparse warnings' for such patches,
that’s the
reason I picked it for my script. I understand people get annoyed seeing so many
continuous patches with same subject line, ill make my script a bit smarter
to have detailed explanation now on.

Just a side note I verify the patch created by the script and if its
OK then only I post it to ML.

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

Re: use of opaque subject lines

[Dan Carpenter]

On Thu, Feb 05, 2015 at 10:01:39AM -0800, Joe Perches wrote:
> On Thu, 2015-02-05 at 20:35 +0300, Dan Carpenter wrote:
> > On Thu, Feb 05, 2015 at 09:32:55AM -0800, Joe Perches wrote:
> > > On Thu, 2015-02-05 at 09:31 -0800, Joe Perches wrote:
> > > > On Thu, 2015-02-05 at 20:25 +0300, Dan Carpenter wrote:
> > > > > Acked-by: Dan Carpenter 
> > > > Maybe I should add sparse too... ;)
> > > drat, of course I meant smatch...
> > No need.  Smatch users are awesome at writing changelogs.
> 
> :) good point, kinda...
> 
> $ git log --format=oneline | grep -wi smatch | wc -l
> 141

Please add smatch to the list of tools.

regards,
dan carpenter

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

Re: use of opaque subject lines

[Joe Perches]

On Thu, 2015-02-05 at 20:25 +0300, Dan Carpenter wrote:
> Acked-by: Dan Carpenter 

Maybe I should add sparse too... ;)


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

Re: use of opaque subject lines

[Paul Bolle]

On Thu, 2015-02-05 at 09:57 -0800, Greg Kroah-Hartman wrote:
> And _NEVER_ have automated scripts create patches and send them out.  I
> only know of ONE person/bot that gets away with this, and you are not
> that person, sorry.  It it not a script on the receiving end of your
> output, so don't use a script to create a mess for them to dig through.

Mind if I ask which person/bot you have in mind? People are trying to
bot away the kconfig related messages I send out - which I think is a
very good idea - and I'd like to know what level that bot should reach
before people can get out of its way.

(I happen to think that the stuff I currently do is best done with a
human filter applied.)

Thanks,


Paul Bolle

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

Re: use of opaque subject lines

[Greg Kroah-Hartman]

On Thu, Feb 05, 2015 at 08:32:13PM +0100, Paul Bolle wrote:
> On Thu, 2015-02-05 at 09:57 -0800, Greg Kroah-Hartman wrote:
> > And _NEVER_ have automated scripts create patches and send them out.  I
> > only know of ONE person/bot that gets away with this, and you are not
> > that person, sorry.  It it not a script on the receiving end of your
> > output, so don't use a script to create a mess for them to dig through.
> 
> Mind if I ask which person/bot you have in mind?

If you don't know that there is a bot doing patches, then that proves it
is so good that people do not realize it :)

> People are trying to
> bot away the kconfig related messages I send out - which I think is a
> very good idea - and I'd like to know what level that bot should reach
> before people can get out of its way.
> 
> (I happen to think that the stuff I currently do is best done with a
> human filter applied.)

Please stick with a human filter, that's the best thing possible.

thanks,

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

Re: use of opaque subject lines

[Joe Perches]

On Thu, 2015-02-05 at 12:06 -0800, Greg Kroah-Hartman wrote:
> On Thu, Feb 05, 2015 at 08:32:13PM +0100, Paul Bolle wrote:
> > On Thu, 2015-02-05 at 09:57 -0800, Greg Kroah-Hartman wrote:
> > > And _NEVER_ have automated scripts create patches and send them out.  I
> > > only know of ONE person/bot that gets away with this, and you are not
> > > that person, sorry.  It it not a script on the receiving end of your
> > > output, so don't use a script to create a mess for them to dig through.
> > 
> > Mind if I ask which person/bot you have in mind?
> 
> If you don't know that there is a bot doing patches, then that proves it
> is so good that people do not realize it :)

Hmm.  That proves bots should be used to create patches.


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

[PATCH] staging: lustre: fix coding style errors in drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c

[Tal Shorer]

Signed-off-by: Tal Shorer 
---
 drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c 
b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
index c539e37..acc2e10 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
@@ -65,7 +65,7 @@
 #include 
 #include "../tracefile.h"
 
-static struct ctl_table_header *lnet_table_header = NULL;
+static struct ctl_table_header *lnet_table_header;
 extern char lnet_upcall[1024];
 /**
  * The path of debug log dump upcall script.
@@ -165,7 +165,7 @@ static int proc_dobitmasks(struct ctl_table *table, int 
write,
 __proc_dobitmasks);
 }
 
-static int min_watchdog_ratelimit = 0;   /* disable ratelimiting */
+static int min_watchdog_ratelimit;   /* disable ratelimiting */
 static int max_watchdog_ratelimit = (24*60*60); /* limit to once per day */
 
 static int __proc_dump_kernel(void *data, int write,
@@ -308,7 +308,7 @@ static int proc_console_backoff(struct ctl_table *table, 
int write,
dummy.proc_handler = &proc_dointvec;
 
if (!write) { /* read */
-   backoff= libcfs_console_backoff;
+   backoff = libcfs_console_backoff;
rc = proc_dointvec(&dummy, write, buffer, lenp, ppos);
return rc;
}
-- 
2.2.2

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

Re: [PATCH] staging: lustre: fix coding style errors in drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c

[Drokin, Oleg]

On Feb 5, 2015, at 5:07 PM, Tal Shorer wrote:

> Signed-off-by: Tal Shorer 
> ---
> drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c 
> b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
> index c539e37..acc2e10 100644
> --- a/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
> +++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
> @@ -65,7 +65,7 @@
> #include 
> #include "../tracefile.h"
> 
> -static struct ctl_table_header *lnet_table_header = NULL;
> +static struct ctl_table_header *lnet_table_header;
> extern char lnet_upcall[1024];
> /**
>  * The path of debug log dump upcall script.
> @@ -165,7 +165,7 @@ static int proc_dobitmasks(struct ctl_table *table, int 
> write,
>__proc_dobitmasks);
> }
> 
> -static int min_watchdog_ratelimit = 0; /* disable ratelimiting */
> +static int min_watchdog_ratelimit; /* disable ratelimiting */

I think you just made this comment nonsensical by this change.
= 0 is explained as that disables the rate limiting. With no assignment (I know 
it's a noop)
it's now unclear what does the comment says and possibly needs to be expanded to
say something like "0 to disable ratelimiting" or the like, but it's less 
readable.

> static int max_watchdog_ratelimit = (24*60*60); /* limit to once per day */

In reality these two "variables" are nothing more than constants, they are 
never changed too.
Their only purpose is to be fed into procfs code (proc_dointvec_minmax) to know 
the range
of values to accepted.
As such spelling them out makes the most sense in my view.

The rest of the patch I think is good.
Thanks.

> static int __proc_dump_kernel(void *data, int write,
> @@ -308,7 +308,7 @@ static int proc_console_backoff(struct ctl_table *table, 
> int write,
>   dummy.proc_handler = &proc_dointvec;
> 
>   if (!write) { /* read */
> - backoff= libcfs_console_backoff;
> + backoff = libcfs_console_backoff;
>   rc = proc_dointvec(&dummy, write, buffer, lenp, ppos);
>   return rc;
>   }
> -- 
> 2.2.2
> 

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

RE: [PATCH 0/4] Drivers: hv: Further protection for the rescind path

[KY Srinivasan]

> -Original Message-
> From: Dexuan Cui
> Sent: Thursday, February 5, 2015 4:45 AM
> To: Vitaly Kuznetsov; KY Srinivasan
> Cc: de...@linuxdriverproject.org; Haiyang Zhang; linux-
> ker...@vger.kernel.org; Jason Wang
> Subject: RE: [PATCH 0/4] Drivers: hv: Further protection for the rescind path
> 
> > -Original Message-
> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > Sent: Thursday, February 5, 2015 18:10 PM
> > To: KY Srinivasan
> > Cc: de...@linuxdriverproject.org; Haiyang Zhang;
> > linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang
> > Subject: Re: [PATCH 0/4] Drivers: hv: Further protection for the
> > rescind path
> >
> > KY Srinivasan  writes:
> >
> > >> -Original Message-
> > >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > >> Sent: Tuesday, February 3, 2015 9:01 AM
> > >> To: KY Srinivasan; de...@linuxdriverproject.org
> > >> Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason
> > >> Wang
> > >> Subject: [PATCH 0/4] Drivers: hv: Further protection for the
> > >> rescind path
> > >>
> > >> This series is a continuation of the "Drivers: hv: vmbus: serialize
> > >> Offer and Rescind offer". I'm trying to address a number of
> > >> theoretically possible issues with rescind offer handling. All
> > >> these complications come from the fact that a rescind offer results
> > >> in vmbus channel being freed and we must ensure nobody still uses
> > >> it. Instead of introducing new locks I suggest we switch channels usage
> to the get/put workflow.
> > >>
> > >> The main part of the series is [PATCH 1/4] which introduces the
> > >> workflow for vmbus channels, all other patches fix different corner
> > >> cases using this workflow. I'm not sure all such cases are covered
> > >> with this series (probably not), but in case protection is required
> > >> in some other places it should become relatively easy to add one.
> > >>
> > >> I did some sanity testing with CONFIG_DEBUG_LOCKDEP=y and nothing
> > >> popped out, however, additional testing would be much appreciated.
> > >>
> > >> K.Y., Haiyang, I'm not sending this series to netdev@ and
> > >> linux-scsi@ as it is supposed to be applied as a whole, please
> > >> resend these patches with your sign-offs when (and if) we're done with
> reviews. Thanks!
> > >
> > > Vitaly,
> > >
> > > Thanks for looking into this issue. While today, rescind offer
> > > results in the
> > freeing of the channel, I don't think
> > > that is required. By not freeing up the channel in the rescind path,
> > > we can have
> > a safe way to access the channel and
> > > that does not have to involve taking a reference on the channel
> > > every time you
> > access it - the get/put workflow in your
> > > patch set. As part of the network performance improvement work, I
> > > had
> > eliminated all locks in the receive path by setting
> > > up per-cpu data structures for mapping the relid to channel etc.
> > > These set of
> > patches introduces locking/atomic operations
> > > in performance critical code paths to deal with an event that is
> > > truly rare - the channel getting rescinded.
> >
> > It is possible to eliminate all locks/atomic operations from
> > performance critical pyth in my patch series by following Dexuan's
> > suggestion - we'll get the channel in vmbus_open and put it in
> > vmbus_close (and on processing offer/rescind offer) this won't affect
> > performance. I'm in the middle of testing this approach.
> >
> > >
> > > All channel messages are handled in a single work context:
> > > vmbus_on_msg_dpc() -> vmbus_onmessage_work()-> Various channel
> > messages [offer, rescind etc.]
> This is true.
> 
> > >
> > > So, the rescind message cannot be processed while we are processing
> > > the
> > offer message and since an offer
> > > cannot be rescinded before it is offered, offer and rescind are
> > > naturally serialized (I think I have patchset in my queue
> IMO this may not be true.
> The cause is:
> (I'm using the latest linux-next repo, which includes Vitaly's patch
> "Drivers: hv: vmbus: serialize Offer and Rescind offer".)
> 
> vmbus_onoffer_rescind() runs in vmbus_connection.work_queue, but
> vmbus_process_offer() runs in the per-channel newchannel->controlwq, so
> the two functions are not serialized, at least in theory.
> 
> As a result, in vmbus_process_offer(): after the new channel is added into
> vmbus_connection.chn_list, but before the channel is completely initialized
> by us (we need to create a vmbus device and associate the device with the
> channel -- this procedure could fail and we goto err_free_chan and free the
> channel directly!),  vmbus_onoffer_rescind() can see the new channel, but
> doesn't know the channel could be freed in another place at the same time.
> 
> BTW, when vmbus_process_offer() -> vmbus_device_create() fails, we goto
> err_free_chan without removing the new channel from
> vmbus_connection.chn_list?
> 
> As another result : in vmbus_process_offer(), in the case

Re: [PATCH] hyperv: fix sparse warnings

[David Miller]

From: Lad Prabhakar 
Date: Thu,  5 Feb 2015 15:06:33 +

> From: "Lad, Prabhakar" 
> 
> this patch fixes following sparse warnings:
> 
> netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared. 
> Should it be static?
> rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was 
> not declared. Should it be static?
> rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not 
> declared. Should it be static?
> 
> Signed-off-by: Lad, Prabhakar 

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