Remove variable vpfe_dev and replace it with its value (since the
function otherwise uses values directly instead of local variables).
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <[email protected]>
---
drivers/staging/media/davinci_vpfe/vpfe_video.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 510202a3b091..8927b744b13e 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -448,7 +448,6 @@ vpfe_video_get_next_buffer(struct vpfe_video_device *video)
/* schedule the next buffer which is available on dma queue */
void vpfe_video_schedule_next_buffer(struct vpfe_video_device *video)
{
- struct vpfe_device *vpfe_dev = video->vpfe_dev;
unsigned long addr;
if (list_empty(&video->dma_queue))
@@ -463,19 +462,18 @@ void vpfe_video_schedule_next_buffer(struct vpfe_video_device *video)
list_del(&video->next_frm->list);
video->next_frm->vb.vb2_buf.state = VB2_BUF_STATE_ACTIVE;
addr = vb2_dma_contig_plane_dma_addr(&video->next_frm->vb.vb2_buf, 0);
- video->ops->queue(vpfe_dev, addr);
+ video->ops->queue(video->vpfe_dev, addr);
video->state = VPFE_VIDEO_BUFFER_QUEUED;
}
/* schedule the buffer for capturing bottom field */
void vpfe_video_schedule_bottom_field(struct vpfe_video_device *video)
{
- struct vpfe_device *vpfe_dev = video->vpfe_dev;
unsigned long addr;
addr = vb2_dma_contig_plane_dma_addr(&video->cur_frm->vb.vb2_buf, 0);
addr += video->field_off;
- video->ops->queue(vpfe_dev, addr);
+ video->ops->queue(video->vpfe_dev, addr);
}
/* make buffer available for dequeue */
--
2.19.1
On Fri, May 31, 2019 at 02:17:18AM +0530, Nishka Dasgupta wrote:
> Remove variable vpfe_dev and replace it with its value (since the
> function otherwise uses values directly instead of local variables).
This says _what_ you do. But we can see that in the patch itself.
You need to say _why_ you are doing this.
There's no need for this change at all. Again, as I have said before,
we write code for developers to read first, the compiler second. By
making these types of changes you are making it harder to
read/understand by a developer, and providing absolutely no benifit to
the compiler at all.
So it's actually making the code worse!
not good at all.
Please reconsider this type of change, as I keep asking you to.
greg k-h
On 31/05/19 2:25 AM, Greg KH wrote:
> On Fri, May 31, 2019 at 02:17:18AM +0530, Nishka Dasgupta wrote:
>> Remove variable vpfe_dev and replace it with its value (since the
>> function otherwise uses values directly instead of local variables).
>
> This says _what_ you do. But we can see that in the patch itself.
>
> You need to say _why_ you are doing this.
>
> There's no need for this change at all. Again, as I have said before,
> we write code for developers to read first, the compiler second. By
> making these types of changes you are making it harder to
> read/understand by a developer, and providing absolutely no benifit to
> the compiler at all.
>
> So it's actually making the code worse!
>
> not good at all.
>
> Please reconsider this type of change, as I keep asking you to.
Okay. In this case I thought it wouldn't make it worse since the
function is low on local variables anyway? Clearly I was wrong, so I
won't count this case as an exception in future.
Thanking you,
Nishka
> greg k-h
>
On Fri, May 31, 2019 at 02:39:23AM +0530, Nishka Dasgupta wrote:
> On 31/05/19 2:25 AM, Greg KH wrote:
> > On Fri, May 31, 2019 at 02:17:18AM +0530, Nishka Dasgupta wrote:
> > > Remove variable vpfe_dev and replace it with its value (since the
> > > function otherwise uses values directly instead of local variables).
> >
> > This says _what_ you do. But we can see that in the patch itself.
> >
> > You need to say _why_ you are doing this.
> >
> > There's no need for this change at all. Again, as I have said before,
> > we write code for developers to read first, the compiler second. By
> > making these types of changes you are making it harder to
> > read/understand by a developer, and providing absolutely no benifit to
> > the compiler at all.
> >
> > So it's actually making the code worse!
> >
> > not good at all.
> >
> > Please reconsider this type of change, as I keep asking you to.
>
> Okay. In this case I thought it wouldn't make it worse since the function is
> low on local variables anyway? Clearly I was wrong, so I won't count this
> case as an exception in future.
Did you check the object file output to verify this? Try it and see :)