From: Stephen Boyd <swboyd@chromium.org>
To: Doug Anderson <dianders@chromium.org>
Cc: alokc@codeaurora.org, Mark Brown <broonie@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
Matthias Kaehlcke <mka@chromium.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Girish Mahadevan <girishm@codeaurora.org>,
Dilip Kota <dkota@codeaurora.org>
Subject: Re: [PATCH V5 3/3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP
Date: Tue, 09 Oct 2018 18:22:01 -0700 [thread overview]
Message-ID: <153913452169.119890.11450124419228013575@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAD=FV=UAfF2rcqdJv30Vd6WXz1qciNVKj2aGq6YTO3+NLVE7yA@mail.gmail.com>
Quoting Doug Anderson (2018-10-09 14:18:26)
> Hi,
> On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Doug Anderson (2018-10-09 10:48:55)
> > >
> > > Ah, you're suggesting separating the platform_get_irq() and the
> > > request_irq() so that we call platform_get_irq() as the first thing in
> > > the function but don't do the request_irq() until later. Yeah, that
> > > could be done and I guess if you feel strongly about it I wouldn't
> > > object to the change, but I don't feel it buys us a lot and I kind of
> > > like keeping the two next to each other. Specifically why I don't
> > > think it buys us a lot:
> > >
> > > 1. You still need the "dev_err" print, right? platform_get_irq()
> > > doesn't automatically print errors for you I think.
> >
> > I usually leave it out. Who cares? Maybe we should throw a dev_err()
> > into platform_get_irq() on failure so we can keep drivers cleaner and
> > reduce a bunch of "can't find my IRQ" messages throughout the kernel.
>
> Yeah, all the boilerplate code is annoying. ...of course by hoisting
> it up then you get a whole bunch of people that have "optional" IRQs
> suddenly getting error messages spewed which is also no good. IMO the
> convention of Linux drivers I've always reviewed is to print errors
> like this, so unless that changes my vote is to follow convention.
>
>
> > > 2. You now need a local variable "irq". By putting the
> > > platform_get_irq() before the memory allocation you now can't store it
> > > directly in mas->irq. We could try using "ret" as a temporary
> > > variable but that seems worse in this case since it'd be a bit
> > > fragile.
> > >
> > > 3. You don't get rid of any error labels / error handling so we don't
> > > really save any code
> > >
> > > When I tried this my diffstat says 8 lines added and 7 removed, so a
> > > net increase in LOC FWIW. I'm relying in gmail so my patch will be
> > > whitespace-damaged (sigh), but you can find a clean one at:
> > >
> > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e0325d618e209c22379e3a4269c14627b19243a8%5E%21/#F0
> > >
> > > ...the basic idea is this though:
> > >
> >
> > Thanks! Here's an updated patch that I haven't compile tested in any way
> > that hoists up the IO mapping part too, which shows that the 'se' local
> > variable is almost entirely useless.
>
> Yeah, I'd be all for getting rid of "se". I'm still not really seeing
> the benefit of hoisting all the rest of the stuff up. Do you feel
> strongly about it?
>
> In any case I think we've both said that all of our comments so far
> are just nits and could be addressed in a followup patch. Unless Mark
> Brown wants these nits fixed ahead of time or has other changes he'd
> like, I don't think we're expecting another spin of this patch from
> Alok or Dilip, right? We'd just expect them to post some follow-up
> patches after Mark lands it?
>
>
Yes this is all nits territory. I don't really care too much, but the
patch is already written, so might as well roll it all in and make
things shiny.
Time to get back to real work :P
next prev parent reply other threads:[~2018-10-10 1:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 13:44 [PATCH V5 0/3] spi-geni-qcom: QUP SPI GENI driver and SPI device tree bindings Alok Chauhan
2018-10-03 13:44 ` [PATCH V5 1/3] dt-bindings: soc: qcom: Remove SPI controller maximum frequency binding Alok Chauhan
2018-10-03 13:44 ` [PATCH V5 2/3] dt-bindings: soc: qcom: GENI SE SPI controller device tree binding Alok Chauhan
2018-10-03 13:44 ` [PATCH V5 3/3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP Alok Chauhan
2018-10-03 17:46 ` Doug Anderson
2018-10-08 23:43 ` Stephen Boyd
2018-10-08 23:52 ` Doug Anderson
2018-10-09 16:12 ` Stephen Boyd
2018-10-09 17:48 ` Doug Anderson
2018-10-09 19:45 ` Stephen Boyd
2018-10-09 21:18 ` Doug Anderson
2018-10-10 1:22 ` Stephen Boyd [this message]
2018-10-11 7:13 ` alokc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=153913452169.119890.11450124419228013575@swboyd.mtv.corp.google.com \
--to=swboyd@chromium.org \
--cc=alokc@codeaurora.org \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=dkota@codeaurora.org \
--cc=girishm@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mka@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).