[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Jun 2018 10:34:45 +0900
From: Alexandre Courbot <acourbot@...omium.org>
To: vkoul@...nel.org
Cc: Stanimir Varbanov <stanimir.varbanov@...aro.org>,
vgarodia@...eaurora.org, Hans Verkuil <hverkuil@...all.nl>,
Mauro Carvalho Chehab <mchehab@...nel.org>, robh@...nel.org,
mark.rutland@....com, andy.gross@...aro.org,
bjorn.andersson@...aro.org,
Linux Media Mailing List <linux-media@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/5] media: venus: add a routine to reset ARM9
On Tue, Jun 5, 2018 at 7:57 PM Vinod <vkoul@...nel.org> wrote:
>
> On 02-06-18, 01:15, Stanimir Varbanov wrote:
> > Hi Vikash,
> >
> > On 1.06.2018 23:26, Vikash Garodia wrote:
> > > Add a new routine to reset the ARM9 and brings it
> > > out of reset. This is in preparation to add PIL
> > > functionality in venus driver.
> >
> > please squash this patch with 4/5. I don't see a reason to add a function
> > which is not used. Shouldn't this produce gcc warnings?
>
> Yes this would but in a multi patch series that is okay as subsequent
> patches would use that and end result in no warning.
Except during bisect.
>
> Splitting logically is good and typical practice in kernel to add the
> routine followed by usages..
Is it in this case though? If this code was shared across multiple
users I could understand but this function is only used locally (and
only in one place IIUC). Also the patch is not so big that the code
would become confusing if this was squashed into 4/5. I don't see any
reason to keep this separate.
Powered by blists - more mailing lists