[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a3VcPhPDskzrGL2UZJz1YK+7nGLC3S0soY0c78j3=LVwg@mail.gmail.com>
Date: Mon, 27 Jan 2020 15:12:21 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Peng Fan <peng.fan@....com>
Cc: "catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"festevam@...il.com" <festevam@...il.com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
dl-linux-imx <linux-imx@....com>,
"olof@...om.net" <olof@...om.net>,
Aisheng Dong <aisheng.dong@....com>,
Leonard Crestez <leonard.crestez@....com>,
Abel Vesa <abel.vesa@....com>,
"krzk@...nel.org" <krzk@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 0/5] soc: imx: increase build coverage for imx8 soc driver
On Mon, Jan 27, 2020 at 2:22 PM Peng Fan <peng.fan@....com> wrote:
>
> > Subject: Re: [PATCH V2 0/5] soc: imx: increase build coverage for imx8 soc
> > driver
> >
> > On Mon, Jan 27, 2020 at 1:33 PM Peng Fan <peng.fan@....com> wrote:
> > >
> > > > Subject: Re: [PATCH V2 0/5] soc: imx: increase build coverage for
> > > > imx8 soc driver
> > > >
> > > > On Mon, Jan 27, 2020 at 10:44 AM Peng Fan <peng.fan@....com> wrote:
> > > > >
> > > > > From: Peng Fan <peng.fan@....com>
> > > > >
> > > > >
> > > > > V2:
> > > > > Include Leonard's patch to fix build break after enable compile
> > > > > test Add Leonard's R-b tag
> > > > >
> > > > > Rename soc-imx8.c to soc-imx8m.c which is for i.MX8M family Add
> > > > > SOC_IMX8M for build gate soc-imx8m.c Increase build coverage for
> > > > > i.MX SoC driver
> > > >
> > > > The changes all look good to me, but I'd just do it all in one
> > > > combined patch, as the changes are all logically part of the same
> > > > thing. You can leave Leonard's fix as a [PATCH 1/2] if you want, but the
> > rest should clearly be a single change.
> > >
> > > There is a arm64 defconfig change, should it be also included in the single
> > change?
> >
> > Good point, that one is probably better left separate indeed.
>
> Since the defconfig change needs stay alone in a patch,
> merge other patches into one might not be good. The patchset
> I did is to make sure the soc-imx8m.c could always be built. If
> I merge the others into one, without the defconfig patch set CONFIG
> option to y, soc-imx8m.c will not be built. This might break git bisect
> to check the soc-imx8m.c
>
> So I prefer not to merge the others into one patch. Do you agree?
I'm generally not too worried about intermittent defconfig breaks during
bisection, as the defconfig is not use all that much in practice. Splitting
the other changes into separate patches wouldn't help here either
unless you want to spread it out over multiple merge windows.
I'd probably just put it all in one patch (including the defconfig change)
in this case, alternatively you could add a 'default ARCH_MXC && ARM64'
to the Kconfig symbol.
Arnd
Powered by blists - more mailing lists