All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Joe Perches <joe@perches.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Akinobu Mita <akinobu.mita@gmail.com>,
	linux-rtc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed
Date: Tue, 14 Jan 2020 11:13:42 +0100	[thread overview]
Message-ID: <CAMuHMdUpRmccLvm7S3e5x0xXJ9XVm8WGbgpbhxSQvwXXT4YzeQ@mail.gmail.com> (raw)
In-Reply-To: <b72846874d5ee367bf86e787ca2152f90d814a34.camel@perches.com>

Hi Joe,

On Mon, Jan 13, 2020 at 9:13 AM Joe Perches <joe@perches.com> wrote:
> On Mon, 2020-01-13 at 08:57 +0100, Geert Uytterhoeven wrote:
> > On Mon, Jan 13, 2020 at 8:41 AM Joe Perches <joe@perches.com> wrote:
> > > On Mon, 2020-01-13 at 08:25 +0100, Geert Uytterhoeven wrote:
> > > > On Mon, Jan 13, 2020 at 7:36 AM Joe Perches <joe@perches.com> wrote:
> > > > > On Sun, 2020-01-12 at 18:13 +0100, Geert Uytterhoeven wrote:
> > > > > > Merely enabling I2C and RTC selects REGMAP_I2C and REGMAP_SPI, even when
> > > > > > no driver needs it.  While the former can be moduler, the latter cannot,
> > > > > > and thus becomes built-in.
> > > > > >
> > > > > > Fix this by moving the select statements for REGMAP_I2C and REGMAP_SPI
> > > > > > from the RTC_I2C_AND_SPI helper to the individual drivers that depend on
> > > > > > it.
> > > > > >
> > > > > > Note that the comment for RTC_I2C_AND_SPI refers to SND_SOC_I2C_AND_SPI
> > > > > > for more information, but the latter does not select REGMAP_{I2C,SPI}
> > > > > > itself, and defers that to the individual drivers, too.
> > > > > >
> > > > > > Fixes: 080481f54ef62121 ("rtc: merge ds3232 and ds3234")
> > > > > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > ---
> > > > > > Joe: When merging addresses, scripts/get_maintainer.pl replaces
> > > > > >      Alexandre's authoritative email address from MAINTAINERS by the
> > > > > >      obsolete address in the SoB-line of the commit referred to by the
> > > > > >      Fixes-line.
> > > > > What are you doing to get this changed output?
> > > >
> > > > scripts/get_maintainer.pl
> > > > 0001-rtc-i2c-spi-Avoid-inclusion-of-REGMAP-support-when-n.patch
> > > >
> > > > > I get the same get_maintainer address output either way
> > > > > with only with the 'blamed_fixes:' content added.
> > > >
> > > > Thanks, I can confirm it's fixed in next-20200110.
> > > > With v5.5-rc6, it still gives the old addresss.
> > >
> > > Well, OK, get_maintainer is the same but there is a
> > > different .mailmap in -next
> >
> > Indeed.
> >
> > However, I think the precedence should be
> >
> >     MAINTAINERS > .mailmap > SoB in referenced commit
> >
> > instead of
> >
> >     .mailmap > SoB in referenced commit > MAINTAINERS
> >
> > Do you agree?
>
> Well, not really.  Priority is:
>
>         1 .mailmap address
>         2 SoB address in commit message
>         2 SoB
> address in referenced Fixes: commits
>         3 MAINTAINERS address
>
> MAINTAINER entries are sometimes stale and .mailmap
> is generally more current so perhaps it should be
>
>         1 .mailmap address
>         2 SoB address in commit message
>         3 MAINTAINERS address
>         4 SoB address in referenced Fixes: commits
>
> But it seems a restructuring of get_maintainer
> would be required to do that as the Fixes: line is
> parsed before any filenames in a patch and I'm not
> too bothered by the precedence and output right
> now to muck around in get_maintainer's internals.

Exactly. There's a reason I just reported the issue, instead of sending a
patch ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2020-01-14 10:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-12 17:13 [PATCH] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed Geert Uytterhoeven
2020-01-12 21:45 ` kbuild test robot
2020-01-12 21:45   ` kbuild test robot
2020-01-13  1:29 ` kbuild test robot
2020-01-13  1:29   ` kbuild test robot
2020-01-13  6:36 ` Joe Perches
2020-01-13  7:25   ` Geert Uytterhoeven
2020-01-13  7:40     ` Joe Perches
2020-01-13  7:57       ` Geert Uytterhoeven
2020-01-13  8:12         ` Joe Perches
2020-01-14 10:13           ` Geert Uytterhoeven [this message]
2020-01-27 22:45 ` Alexandre Belloni
2020-01-28  8:33   ` Geert Uytterhoeven
2020-01-28  8:50     ` Alexandre Belloni
2020-01-28  8:59       ` Geert Uytterhoeven

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=CAMuHMdUpRmccLvm7S3e5x0xXJ9XVm8WGbgpbhxSQvwXXT4YzeQ@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=a.zummo@towertech.it \
    --cc=akinobu.mita@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.