[net-next] ieee802154: Use kmemdup instead of duplicating it in ca8210_test_int_driver_write

Message ID 20180809064429.13348-1-yuehaibing@huawei.com
State Awaiting Upstream
Delegated to: David Miller
Headers show
Series
  • [net-next] ieee802154: Use kmemdup instead of duplicating it in ca8210_test_int_driver_write
Related show

Commit Message

Yue Haibing Aug. 9, 2018, 6:44 a.m.
Replace calls to kmalloc followed by a memcpy with a direct call to
kmemdup.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/net/ieee802154/ca8210.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Stefan Schmidt Aug. 9, 2018, 8:13 a.m. | #1
Hello.

On 08/09/2018 08:44 AM, YueHaibing wrote:
> Replace calls to kmalloc followed by a memcpy with a direct call to
> kmemdup.
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Is Yue your forname and Haibing your surname? In that case having it
written as

Yue Haibing <yuehaibing@huawei.com>

in the from line as well as in the SOB would be better.

> ---
>  drivers/net/ieee802154/ca8210.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
> index 58299fb..e21279d 100644
> --- a/drivers/net/ieee802154/ca8210.c
> +++ b/drivers/net/ieee802154/ca8210.c
> @@ -634,10 +634,9 @@ static int ca8210_test_int_driver_write(
>  	for (i = 0; i < len; i++)
>  		dev_dbg(&priv->spi->dev, "%#03x\n", buf[i]);
>  
> -	fifo_buffer = kmalloc(len, GFP_KERNEL);
> +	fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
>  	if (!fifo_buffer)
>  		return -ENOMEM;
> -	memcpy(fifo_buffer, buf, len);
>  	kfifo_in(&test->up_fifo, &fifo_buffer, 4);
>  	wake_up_interruptible(&priv->test.readq);

Is this some kernel tree wide change you are submitting patches for or
only for the ca8210 driver? Is there any specific problem you see with
the kmalloc and memcpy code here? To me it looks fine.

The reason I ask is to understand if this is bug fix or a cleanup.

Harry, if you are ok with this one let me know with an Acked-By

regards
Stefan Schmidt
Yue Haibing Aug. 9, 2018, 8:44 a.m. | #2
On 2018/8/9 16:13, Stefan Schmidt wrote:
> Hello.
> 
> On 08/09/2018 08:44 AM, YueHaibing wrote:
>> Replace calls to kmalloc followed by a memcpy with a direct call to
>> kmemdup.
>>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> 
> Is Yue your forname and Haibing your surname? In that case having it
> written as
> 
> Yue Haibing <yuehaibing@huawei.com>

Well, It should be this, but it's been a long time to use the former

> 
> in the from line as well as in the SOB would be better.
> 
>> ---
>>  drivers/net/ieee802154/ca8210.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
>> index 58299fb..e21279d 100644
>> --- a/drivers/net/ieee802154/ca8210.c
>> +++ b/drivers/net/ieee802154/ca8210.c
>> @@ -634,10 +634,9 @@ static int ca8210_test_int_driver_write(
>>  	for (i = 0; i < len; i++)
>>  		dev_dbg(&priv->spi->dev, "%#03x\n", buf[i]);
>>  
>> -	fifo_buffer = kmalloc(len, GFP_KERNEL);
>> +	fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
>>  	if (!fifo_buffer)
>>  		return -ENOMEM;
>> -	memcpy(fifo_buffer, buf, len);
>>  	kfifo_in(&test->up_fifo, &fifo_buffer, 4);
>>  	wake_up_interruptible(&priv->test.readq);
> 
> Is this some kernel tree wide change you are submitting patches for or
> only for the ca8210 driver? Is there any specific problem you see with
> the kmalloc and memcpy code here? To me it looks fine.
> 
> The reason I ask is to understand if this is bug fix or a cleanup.

It just a code cleanup only for ca8210.

> 
> Harry, if you are ok with this one let me know with an Acked-By
> 
> regards
> Stefan Schmidt
> 
> .
>
Stefan Schmidt Aug. 9, 2018, 8:57 a.m. | #3
Hello Yue.

On 08/09/2018 10:44 AM, YueHaibing wrote:
> On 2018/8/9 16:13, Stefan Schmidt wrote:
>> Hello.
>>
>> On 08/09/2018 08:44 AM, YueHaibing wrote:
>>> Replace calls to kmalloc followed by a memcpy with a direct call to
>>> kmemdup.
>>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>
>> Is Yue your forname and Haibing your surname? In that case having it
>> written as
>>
>> Yue Haibing <yuehaibing@huawei.com>
> 
> Well, It should be this, but it's been a long time to use the former

Never to late to fix something I guess. :-)
Not blocking this patch base on this though.

>> in the from line as well as in the SOB would be better.
>>
>>> ---
>>>  drivers/net/ieee802154/ca8210.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
>>> index 58299fb..e21279d 100644
>>> --- a/drivers/net/ieee802154/ca8210.c
>>> +++ b/drivers/net/ieee802154/ca8210.c
>>> @@ -634,10 +634,9 @@ static int ca8210_test_int_driver_write(
>>>  	for (i = 0; i < len; i++)
>>>  		dev_dbg(&priv->spi->dev, "%#03x\n", buf[i]);
>>>  
>>> -	fifo_buffer = kmalloc(len, GFP_KERNEL);
>>> +	fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
>>>  	if (!fifo_buffer)
>>>  		return -ENOMEM;
>>> -	memcpy(fifo_buffer, buf, len);
>>>  	kfifo_in(&test->up_fifo, &fifo_buffer, 4);
>>>  	wake_up_interruptible(&priv->test.readq);
>>
>> Is this some kernel tree wide change you are submitting patches for or
>> only for the ca8210 driver? Is there any specific problem you see with
>> the kmalloc and memcpy code here? To me it looks fine.
>>
>> The reason I ask is to understand if this is bug fix or a cleanup.
> 
> It just a code cleanup only for ca8210.

Thanks for the info. I will wait for Harry's ack and apply it to
wpan-next afterwards.

regards
Stefan Schmidt

Patch

diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 58299fb..e21279d 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -634,10 +634,9 @@  static int ca8210_test_int_driver_write(
 	for (i = 0; i < len; i++)
 		dev_dbg(&priv->spi->dev, "%#03x\n", buf[i]);
 
-	fifo_buffer = kmalloc(len, GFP_KERNEL);
+	fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
 	if (!fifo_buffer)
 		return -ENOMEM;
-	memcpy(fifo_buffer, buf, len);
 	kfifo_in(&test->up_fifo, &fifo_buffer, 4);
 	wake_up_interruptible(&priv->test.readq);