Hi Takashi,
Today's linux-next build (x86_64 allmodconfig) failed like this:
sound/soc/codecs/wm8994.c:30:35: error: linux/mfd/wm8994/core.h: No such file or directory
sound/soc/codecs/wm8994.c:31:40: error: linux/mfd/wm8994/registers.h: No such file or directory
sound/soc/codecs/wm8994.c:32:36: error: linux/mfd/wm8994/pdata.h: No such file or directory
sound/soc/codecs/wm8994.c:33:35: error: linux/mfd/wm8994/gpio.h: No such file or directory
And went down hill form there :-(
Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
WM8994 CODEC driver"). I presume that this commit depends on commits
currently only in the mfd tree ...
I have used the sound tree from next-20100201 for today.
To fix this, the relevant commits from the mfd tree could be put into a
"never to be rebased" branch (or separate git tree) and then this branch
merged into both the sound and mfd trees.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
At Tue, 2 Feb 2010 12:47:11 +1100,
Stephen Rothwell wrote:
>
> Hi Takashi,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> sound/soc/codecs/wm8994.c:30:35: error: linux/mfd/wm8994/core.h: No such file or directory
> sound/soc/codecs/wm8994.c:31:40: error: linux/mfd/wm8994/registers.h: No such file or directory
> sound/soc/codecs/wm8994.c:32:36: error: linux/mfd/wm8994/pdata.h: No such file or directory
> sound/soc/codecs/wm8994.c:33:35: error: linux/mfd/wm8994/gpio.h: No such file or directory
>
> And went down hill form there :-(
Ah, sorry, this driver didn't hit in my quick test in the last
evening before pushing.
> Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
> WM8994 CODEC driver"). I presume that this commit depends on commits
> currently only in the mfd tree ...
Yep, looks so.
> I have used the sound tree from next-20100201 for today.
>
> To fix this, the relevant commits from the mfd tree could be put into a
> "never to be rebased" branch (or separate git tree) and then this branch
> merged into both the sound and mfd trees.
Well, I don't think the codec register definitions don't have to be
dependent on mfd tree at all. All other codec drivers have own
definitions.
Mark, can it be self-contained?
thanks,
Takashi
On Tue, Feb 02, 2010 at 12:47:11PM +1100, Stephen Rothwell wrote:
> sound/soc/codecs/wm8994.c:30:35: error: linux/mfd/wm8994/core.h: No such file or directory
> sound/soc/codecs/wm8994.c:31:40: error: linux/mfd/wm8994/registers.h: No such file or directory
> sound/soc/codecs/wm8994.c:32:36: error: linux/mfd/wm8994/pdata.h: No such file or directory
> sound/soc/codecs/wm8994.c:33:35: error: linux/mfd/wm8994/gpio.h: No such file or directory
> And went down hill form there :-(
This looks really odd - all those headers are present in the linux-next
tree (and have been for a few days) as far as I can tell, and I can't
see any way they could not be found without serious breakage elsewhere.
Could you please re-run your build with V=1 to show the kernel command
line used to build the driver? I can't reproduce this here and like I
say I can't see how this could happen given that those files are there
in -next and it's hard to see how this could happen.
> Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
> WM8994 CODEC driver"). I presume that this commit depends on commits
> currently only in the mfd tree ...
Not exactly, there's a Kconfig dependency which should keep track of
things but the wrong one got merged over when things got split out to go
into the several trees. Though for allmodconfig that will not be
relevant since the dependency will be satisfied anyway and the headers
don't need Kconfig to pull them in.
Like I say, everything required is in the MFD tree in -next anyway.
> I have used the sound tree from next-20100201 for today.
> To fix this, the relevant commits from the mfd tree could be put into a
> "never to be rebased" branch (or separate git tree) and then this branch
> merged into both the sound and mfd trees.
This is not needed, Kconfig will handle it.
On Tue, Feb 02, 2010 at 08:27:19AM +0100, Takashi Iwai wrote:
> Well, I don't think the codec register definitions don't have to be
> dependent on mfd tree at all. All other codec drivers have own
> definitions.
> Mark, can it be self-contained?
No, it needs to look at things like the multi-function pin configuration
in order to configure itself correctly.
Hi Mark,
On Tue, 2 Feb 2010 10:26:10 +0000 Mark Brown <[email protected]> wrote:
>
> This looks really odd - all those headers are present in the linux-next
> tree (and have been for a few days) as far as I can tell, and I can't
> see any way they could not be found without serious breakage elsewhere.
> Could you please re-run your build with V=1 to show the kernel command
> line used to build the driver? I can't reproduce this here and like I
> say I can't see how this could happen given that those files are there
> in -next and it's hard to see how this could happen.
The sound tree is merged before the mfd tree, and the commit that adds
those is only in the mfd tree. So the sound tree, on its own, is
broken. This driver will only build if you merge the mfd tree as well.
> > Caused by commit 9e6e96a197a03752d39a63e4f83e0b707ccedad7 ("ASoC: Add
> > WM8994 CODEC driver"). I presume that this commit depends on commits
> > currently only in the mfd tree ...
>
> Not exactly, there's a Kconfig dependency which should keep track of
> things but the wrong one got merged over when things got split out to go
> into the several trees. Though for allmodconfig that will not be
> relevant since the dependency will be satisfied anyway and the headers
> don't need Kconfig to pull them in.
>
> Like I say, everything required is in the MFD tree in -next anyway.
yes, but I do builds between merging trees ...
> > I have used the sound tree from next-20100201 for today.
>
> > To fix this, the relevant commits from the mfd tree could be put into a
> > "never to be rebased" branch (or separate git tree) and then this branch
> > merged into both the sound and mfd trees.
>
> This is not needed, Kconfig will handle it.
Kconfig has nothing to do with it, sorry.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
At Tue, 2 Feb 2010 10:31:12 +0000,
Mark Brown wrote:
>
> On Tue, Feb 02, 2010 at 08:27:19AM +0100, Takashi Iwai wrote:
>
> > Well, I don't think the codec register definitions don't have to be
> > dependent on mfd tree at all. All other codec drivers have own
> > definitions.
>
> > Mark, can it be self-contained?
>
> No, it needs to look at things like the multi-function pin configuration
> in order to configure itself correctly.
Hm, then shouldn't it depend on mfd?
Takashi
On Tue, Feb 02, 2010 at 11:40:03AM +0100, Takashi Iwai wrote:
> Mark Brown wrote:
> > No, it needs to look at things like the multi-function pin configuration
> > in order to configure itself correctly.
> Hm, then shouldn't it depend on mfd?
Yes, I've got a patch for that which I'll send shortly (though that
shouldn't affect the -next build it will affect the sound build).
On Tue, Feb 02, 2010 at 09:37:32PM +1100, Stephen Rothwell wrote:
> The sound tree is merged before the mfd tree, and the commit that adds
> those is only in the mfd tree. So the sound tree, on its own, is
> broken. This driver will only build if you merge the mfd tree as well.
Ah, you're doing builds after each individual merge. It might help to
change the form you're using when reporting problems with partially
constructed -next - at the minute you say "Today's linux-next build
(x86_64 allmodconfig) failed like this:" which makes it look like you're
testing the result of the full -next merge.
> > > To fix this, the relevant commits from the mfd tree could be put into a
> > > "never to be rebased" branch (or separate git tree) and then this branch
> > > merged into both the sound and mfd trees.
> > This is not needed, Kconfig will handle it.
> Kconfig has nothing to do with it, sorry.
No, it does really fix the problem. As I said the driver should build
depend on a Kconfig symbol which is introduced in the MFD tree. This
means that the driver will not be built at all until MFD has been merged
since the dependencies required to select the driver will not be
satisfied unless the commits it depends on are present in the tree.
I'll push a patch for this shortly.
Hi Mark,
On Tue, 2 Feb 2010 10:58:00 +0000 Mark Brown <[email protected]> wrote:
>
> On Tue, Feb 02, 2010 at 09:37:32PM +1100, Stephen Rothwell wrote:
>
> > The sound tree is merged before the mfd tree, and the commit that adds
> > those is only in the mfd tree. So the sound tree, on its own, is
> > broken. This driver will only build if you merge the mfd tree as well.
>
> Ah, you're doing builds after each individual merge. It might help to
Always have ...
> change the form you're using when reporting problems with partially
> constructed -next - at the minute you say "Today's linux-next build
> (x86_64 allmodconfig) failed like this:" which makes it look like you're
> testing the result of the full -next merge.
I was hoping that the subject of the email would help with that
impression.
> > Kconfig has nothing to do with it, sorry.
>
> No, it does really fix the problem. As I said the driver should build
> depend on a Kconfig symbol which is introduced in the MFD tree. This
> means that the driver will not be built at all until MFD has been merged
> since the dependencies required to select the driver will not be
> satisfied unless the commits it depends on are present in the tree.
Yeah, OK, I guess you could do that.
> I'll push a patch for this shortly.
Thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Feb 02, 2010 at 10:17:43PM +1100, Stephen Rothwell wrote:
> On Tue, 2 Feb 2010 10:58:00 +0000 Mark Brown <[email protected]> wrote:
> > change the form you're using when reporting problems with partially
> > constructed -next - at the minute you say "Today's linux-next build
> > (x86_64 allmodconfig) failed like this:" which makes it look like you're
> > testing the result of the full -next merge.
> I was hoping that the subject of the email would help with that
> impression.
The way I've always read that was that you'd found a build failure in
a given bit of the tree while testing -next - you're clearly doing some
work to identify and understand where the failure came from (and simply
looking at the source file leads to the same result normally anyway) so
the fact that you've identified the subsystem doesn't automatically say
that this happened with a partially merged -next. If you looked less
like a human the subject by itself would be clearer :)
> > > Kconfig has nothing to do with it, sorry.
> > No, it does really fix the problem. As I said the driver should build
> > depend on a Kconfig symbol which is introduced in the MFD tree. This
> > means that the driver will not be built at all until MFD has been merged
> > since the dependencies required to select the driver will not be
> > satisfied unless the commits it depends on are present in the tree.
> Yeah, OK, I guess you could do that.
It's needed anyway, the driver will try to link against the MFD core so
even with both bits merged a build that didn't select the core would
fail.
Hi Stephen,
On Tue, 2010-02-02 at 22:17 +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Tue, 2 Feb 2010 10:58:00 +0000 Mark Brown <[email protected]> wrote:
> >
> > On Tue, Feb 02, 2010 at 09:37:32PM +1100, Stephen Rothwell wrote:
> >
> > > The sound tree is merged before the mfd tree, and the commit that adds
> > > those is only in the mfd tree. So the sound tree, on its own, is
> > > broken. This driver will only build if you merge the mfd tree as well.
> >
> > Ah, you're doing builds after each individual merge. It might help to
>
> Always have ...
>
I wonder if it would be possible to re-order the merge sequence so that
similar inter tree dependencies are less likely to cause -next build
failures in the future. I guess atm lots of driver trees can depend on
MFD (e.g. regulator, sound, rtc, backlight, led, watchdog, etc) so it
may be good to move it up the order.
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
Hi Mark,
On Tue, 2 Feb 2010 11:34:24 +0000 Mark Brown <[email protected]> wrote:
>
> The way I've always read that was that you'd found a build failure in
> a given bit of the tree while testing -next - you're clearly doing some
> work to identify and understand where the failure came from (and simply
> looking at the source file leads to the same result normally anyway) so
> the fact that you've identified the subsystem doesn't automatically say
> that this happened with a partially merged -next. If you looked less
> like a human the subject by itself would be clearer :)
How about "linux-next: build failure after merging xxx tree"?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Liam,
On Tue, 02 Feb 2010 11:50:30 +0000 Liam Girdwood <[email protected]> wrote:
>
> I wonder if it would be possible to re-order the merge sequence so that
> similar inter tree dependencies are less likely to cause -next build
Anything is possible with software :-)
> failures in the future. I guess atm lots of driver trees can depend on
> MFD (e.g. regulator, sound, rtc, backlight, led, watchdog, etc) so it
> may be good to move it up the order.
In this case it would just have masked the dependency and we may not have
found it until the sound tree was merged into Linus' tree and builds
started failing. (I now Mark already knew about this one.) We actually
have very few build dependencies between trees and in most cases I would
prefer that they were exposed in linux-next than in Linus' tree (with the
ensuing bisection problems).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Feb 02, 2010 at 10:55:45PM +1100, Stephen Rothwell wrote:
> How about "linux-next: build failure after merging xxx tree"?
Yes that's a lot clearer, thanks.