On Mon, 2016-01-25 at 20:22 +, Hugo Camboulive wrote:
> alloc_etherdev() calls alloc_netdev_mqs(), which
> already uses kzalloc/vzalloc.
>
> This clears a sparse warning :
> drivers/staging/unisys/visornic/visornic_main.c:1366:15: warning:
> memset with byte count of 1460112
>
>
On Mon, 2016-01-25 at 20:22 +, Hugo Camboulive wrote:
> alloc_etherdev() calls alloc_netdev_mqs(), which
> already uses kzalloc/vzalloc.
>
> This clears a sparse warning :
> drivers/staging/unisys/visornic/visornic_main.c:1366:15: warning:
> memset with byte count of 1460112
>
>
On 12/01/2015 10:57 AM, Dan Carpenter wrote:
What I meant was that I'm generally opposed to "common exit paths".
Mixing all the exit paths together often makes the code more complicated
and leads to errors. That makes sense from a common sense perspective
that doing many things is more
On 12/01/2015 03:00 AM, Dan Carpenter wrote:
Doing One Err style error handling is often a mistake but it's ok here.
Why is it okay here? I don't understand why this function would be any
different than the other places where the code used a goto.
If we *have* to change it I would prefer
On 12/01/2015 03:00 AM, Dan Carpenter wrote:
Doing One Err style error handling is often a mistake but it's ok here.
Why is it okay here? I don't understand why this function would be any
different than the other places where the code used a goto.
If we *have* to change it I would prefer
On 12/01/2015 10:57 AM, Dan Carpenter wrote:
What I meant was that I'm generally opposed to "common exit paths".
Mixing all the exit paths together often makes the code more complicated
and leads to errors. That makes sense from a common sense perspective
that doing many things is more
As the actually intended timeout is not documented and msecs_to_jiffies
timeouts can be a factor 10 different from the current effective timeout
this needs to be checked by someone who knows the details of this driver
in any case it should be passed in a HZ independent manner.
I need an ack
As the actually intended timeout is not documented and msecs_to_jiffies
timeouts can be a factor 10 different from the current effective timeout
this needs to be checked by someone who knows the details of this driver
in any case it should be passed in a HZ independent manner.
I need an ack
On 03/26/2015 09:47 AM, Ben Romer wrote:
On 03/26/2015 08:01 AM, Greg Kroah-Hartman wrote:
I need an ack from Benjamin and/or David before I can take these, as
they are the maintainers of the driver, and have the ability to test
these patches.
I'll just wait to apply them until that happens
On 03/26/2015 08:01 AM, Greg Kroah-Hartman wrote:
I need an ack from Benjamin and/or David before I can take these, as
they are the maintainers of the driver, and have the ability to test
these patches.
I'll just wait to apply them until that happens.
Ben/David?
I'll test them today. :)
--
On 03/26/2015 09:47 AM, Ben Romer wrote:
On 03/26/2015 08:01 AM, Greg Kroah-Hartman wrote:
I need an ack from Benjamin and/or David before I can take these, as
they are the maintainers of the driver, and have the ability to test
these patches.
I'll just wait to apply them until that happens
On 03/26/2015 08:01 AM, Greg Kroah-Hartman wrote:
I need an ack from Benjamin and/or David before I can take these, as
they are the maintainers of the driver, and have the ability to test
these patches.
I'll just wait to apply them until that happens.
Ben/David?
I'll test them today. :)
--
Sudip Mukherjee wrote:
> fixed sparse warning : context imbalance in 'destroy_device'
> unexpected unlock
> this patch will generate warning from checkpatch for
> lines over 80 character , but since those are user-visible strings
> so it was not modified.
>
>
Sudip Mukherjee sudipm.mukher...@gmail.com wrote:
fixed sparse warning : context imbalance in 'destroy_device'
unexpected unlock
this patch will generate warning from checkpatch for
lines over 80 character , but since those are user-visible strings
so it was not
14 matches
Mail list logo
