linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Aishwarya R <aishwaryarj100@gmail.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Allison Randal <allison@lohutok.net>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Stephen Boyd <swboyd@chromium.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iio: adc: at91-adc: Use devm_platform_ioremap_resource
Date: Fri, 10 Apr 2020 19:37:25 +0300	[thread overview]
Message-ID: <CAHp75VfJMsVB2rC-Qx6mQw+e8Vw9sVaWTu2Jvxj-nO1LzadHeA@mail.gmail.com> (raw)
In-Reply-To: <20200410112236.GX3628@piout.net>

On Fri, Apr 10, 2020 at 2:22 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 10/04/2020 13:55:26+0300, Andy Shevchenko wrote:
> > On Thu, Apr 9, 2020 at 7:00 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > On 09/04/2020 20:41:23+0530, Aishwarya R wrote:
> > > > Use the helper function that wraps the calls to
> > > > platform_get_resource() and devm_ioremap_resource()
> > > > together.
> >
> > > Please elaborate the actual value of doing that.
> >
> > Please, elaborate actual value of not doing that.
> >
> > Yes, I know that you are p* off of these changes, but why you not
> > going further and forbid all clean ups we are doing in the code?
> >
> > To the point. Above change is reducing code base and showing the new
> > comers modern APIs to use.

> The value of doing it is to reduce the code size by 16 bytes. The same
> people doing that will actively ruin that by adding error string for
> error that will never ever happen.

I don't see it in the patch we are discussing, so, not an argument.

> Also, the commit message is definitively lacking. A good commit message
> would say that the patch has been generated using coccinelle, that no
> testing has been done and that no thought has been given.

That's I agree with.
But somebody need to teach people how to do it better.

> It would definitively make sense to send one patch per subsystem instead
> of having 475 different patches each changing only one location.

Depends on the maintainer and subsystem. This is arguable argument.
In my subsystems (let's forget about PDx86, where one per subsystem in
principle is not working by nature of the subsystem, but consider
others I'm maintaining) I prefer to have a possibility to track
changes independently on driver basis.

> The whole "let's let newcomers fix trivial bugs" thing is definitively
> not working and it is not leading to an increase of the number of useful
> reviewers and contributors

Semi-agree. That people can be self-organized into a reviewer gang and
try to learn together.
In any case, as for maintainers, the task has not only technical
aspects, but mentoring as well.

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2020-04-10 16:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09 15:11 [PATCH] iio: adc: at91-adc: Use devm_platform_ioremap_resource Aishwarya R
2020-04-09 15:59 ` Alexandre Belloni
2020-04-10 10:55   ` Andy Shevchenko
2020-04-10 11:22     ` Alexandre Belloni
2020-04-10 16:37       ` Andy Shevchenko [this message]
2020-04-12 10:23         ` Jonathan Cameron
2020-04-10  9:43 ` Aishwarya R
2020-04-12 10:13 ` Jonathan Cameron
2020-04-12 13:56 ` Aishwarya R
2020-04-13 15:36   ` Jonathan Cameron

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=CAHp75VfJMsVB2rC-Qx6mQw+e8Vw9sVaWTu2Jvxj-nO1LzadHeA@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=aishwaryarj100@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=allison@lohutok.net \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=pmeerw@pmeerw.net \
    --cc=swboyd@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=wangkefeng.wang@huawei.com \
    /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).