* Re: linux-next: manual merge of the kvm tree
From: Benjamin Herrenschmidt @ 2008-12-22 21:41 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Stephen Rothwell, Avi Kivity, linux-next, Kumar Gala
In-Reply-To: <1229981967.7181.5.camel@localhost.localdomain>
On Mon, 2008-12-22 at 15:39 -0600, Hollis Blanchard wrote:
> On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> > >
> > > The former patch changes the _tlbia() to _tlbil_all() in
> > > kvm_arch_vcpu_put(). The latter restructures this code.
> > >
> > > I don't know enough to fix this up, so for today I have merely used the
> > > kvm tree version. Please come up with something better (if needed) and I
> > > can use that as a merge resolution.
> >
> > Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> > ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> > which don't exist anymore for nohash...
>
> I've stopped calling _tlbia() in KVM, so I think the easiest solution
> would be to drop the KVM part of your patch, Ben.
Patch is in Paulus -next already so we'll have to do a manual resolve.
Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
sorry about that.
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Hollis Blanchard @ 2008-12-22 22:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Avi Kivity, linux-next, Kumar Gala
In-Reply-To: <1229982095.4360.19.camel@pasglop>
On Tue, 2008-12-23 at 08:41 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2008-12-22 at 15:39 -0600, Hollis Blanchard wrote:
> > On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> > > On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> > > >
> > > > The former patch changes the _tlbia() to _tlbil_all() in
> > > > kvm_arch_vcpu_put(). The latter restructures this code.
> > > >
> > > > I don't know enough to fix this up, so for today I have merely used the
> > > > kvm tree version. Please come up with something better (if needed) and I
> > > > can use that as a merge resolution.
> > >
> > > Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> > > ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> > > which don't exist anymore for nohash...
> >
> > I've stopped calling _tlbia() in KVM, so I think the easiest solution
> > would be to drop the KVM part of your patch, Ben.
>
> Patch is in Paulus -next already so we'll have to do a manual resolve.
Who has to do it? My code should "win".
> Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
> sorry about that.
I don't want _tlb anything; I was only using _tlbia(), and I'm not any
more.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Benjamin Herrenschmidt @ 2008-12-22 22:11 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Stephen Rothwell, Avi Kivity, linux-next, Kumar Gala,
Paul Mackerras
In-Reply-To: <1229983422.7181.7.camel@localhost.localdomain>
On Mon, 2008-12-22 at 16:03 -0600, Hollis Blanchard wrote:
> > Patch is in Paulus -next already so we'll have to do a manual
> resolve.
>
> Who has to do it? My code should "win".
I don't understand. There is no "win" or "lose" here, just somebody who
has to fixup the merge conflict :-) In any case I don't see why any code
should "win" here.
Shouldn't be hard, we just need to sync with paulus who pulls what tree
in what tree to solve it. Maybe we can pull kvm into powerpc and solve
it there or something like that ?
The other solution is to rebase powerpc and change the patch but that's
evil, we always avoid rebasing, it hurts too many people.
> > Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
> > sorry about that.
>
> I don't want _tlb anything; I was only using _tlbia(), and I'm not any
> more.
Ok. I got confused by another mail about undefined _tlbil_all() which
was probably another fix for that same stuff.
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Paul Mackerras @ 2008-12-22 22:29 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Avi Kivity, linux-next,
Kumar Gala
In-Reply-To: <1229983422.7181.7.camel@localhost.localdomain>
Hollis Blanchard writes:
> > Patch is in Paulus -next already so we'll have to do a manual resolve.
>
> Who has to do it? My code should "win".
Do you have your own tree or is all your stuff in the main kvm tree?
If there is a powerpc KVM tree, I could pull that and resolve the
conflict, but I don't want to pull all the queued up KVM stuff.
Worst case is Linus gets to resolve the conflict in the merge window.
If that's just a matter of him taking your version of the file, it
should be within his powers to manage. :)
Paul.
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: Andrew Morton @ 2008-12-22 22:43 UTC (permalink / raw)
To: Ingo Molnar; +Cc: sfr, linux-kernel, kenchen, paulus, tglx, hpa, linux-next
In-Reply-To: <20081222080341.GA18897@elte.hu>
On Mon, 22 Dec 2008 09:03:41 +0100
Ingo Molnar <mingo@elte.hu> wrote:
> Subject: powerpc: change u64/s64 to a long long integer type
<applause>
There are lots of other architctures that need doing though.
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Hollis Blanchard @ 2008-12-22 22:44 UTC (permalink / raw)
To: Paul Mackerras
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Avi Kivity, linux-next,
Kumar Gala
In-Reply-To: <18768.5298.173232.227168@cargo.ozlabs.ibm.com>
On Tue, 2008-12-23 at 09:29 +1100, Paul Mackerras wrote:
> Hollis Blanchard writes:
>
> > > Patch is in Paulus -next already so we'll have to do a manual resolve.
> >
> > Who has to do it? My code should "win".
>
> Do you have your own tree or is all your stuff in the main kvm tree?
>
> If there is a powerpc KVM tree, I could pull that and resolve the
> conflict, but I don't want to pull all the queued up KVM stuff.
It's just the main KVM tree.
> Worst case is Linus gets to resolve the conflict in the merge window.
> If that's just a matter of him taking your version of the file, it
> should be within his powers to manage. :)
Yeah, that's what I meant by "win"... whatever changes Ben made are to
now-dead code, so the code in kvm.git should be used. Does Linus need
special instruction to do this, or how does that work?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: linux-next: Tree for December 18 (patch: kernel-doc notation)
From: Andrew Morton @ 2008-12-22 22:49 UTC (permalink / raw)
To: Randy Dunlap; +Cc: sfr, david, linux-next, linux-kernel
In-Reply-To: <20081218161437.fe2d2675.randy.dunlap@oracle.com>
On Thu, 18 Dec 2008 16:14:37 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> fs/inode.c and mm/filemap.c need kernel-doc fixes.
>
> What tree were these merged into for linux-next?
I use git-blame.
> How do I get these doc fixes merged? (2 patches below)
>
> ---
>
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix fs/inode.c kernel-doc function parameters:
>
> Warning(linux-next-20081218//fs/inode.c:120): No description found for parameter 'sb'
> Warning(linux-next-20081218//fs/inode.c:120): No description found for parameter 'inode'
> Warning(linux-next-20081218//fs/inode.c:588): No description found for parameter 'sb'
> Warning(linux-next-20081218//fs/inode.c:588): No description found for parameter 'inode'
>
>From the XFS tree:
commit 2cb1599f9b2ecdd7a9e59feeee647eb258966839
Author: David Chinner <david@fromorbit.com>
AuthorDate: Thu Oct 30 17:32:23 2008 +1100
Commit: Lachlan McIlroy <lachlan@redback.melbourne.sgi.com>
CommitDate: Thu Oct 30 17:32:23 2008 +1100
Inode: Allow external initialisers
> ---
>
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix mm/filemap.c functions' kernel-doc:
>
> Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:575): No description found for parameter 'page'
> Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:575): No description found for parameter 'waiter'
> Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:2348): No description found for parameter 'mapping'
> Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:2348): No description found for parameter 'index'
> Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:2348): No description found for parameter 'source'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> cc: Dave Chinner <david@fromorbit.com>
That's no longer in linux-next. I'd guess it was from the fs-cache
patches.
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: Sam Ravnborg @ 2008-12-22 23:00 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, sfr, linux-kernel, kenchen, paulus, tglx, hpa,
linux-next, David Miller
In-Reply-To: <20081222144319.1bfc0061.akpm@linux-foundation.org>
On Mon, Dec 22, 2008 at 02:43:19PM -0800, Andrew Morton wrote:
> On Mon, 22 Dec 2008 09:03:41 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > Subject: powerpc: change u64/s64 to a long long integer type
>
> <applause>
>
> There are lots of other architctures that need doing though.
I have missed the introduction.
Can you explain why?
I have done a bit of sparc hacking lately and was wondering if
sparc needs something similar.
cd arch/sparc
git grep u64 | grep -v __u64 | wc -l
448
[On the unified tree]
Sam
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: H. Peter Anvin @ 2008-12-22 23:03 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Andrew Morton, Ingo Molnar, sfr, linux-kernel, kenchen, paulus,
tglx, linux-next, David Miller
In-Reply-To: <20081222230035.GB4074@uranus.ravnborg.org>
Sam Ravnborg wrote:
> On Mon, Dec 22, 2008 at 02:43:19PM -0800, Andrew Morton wrote:
>> On Mon, 22 Dec 2008 09:03:41 +0100
>> Ingo Molnar <mingo@elte.hu> wrote:
>>
>>> Subject: powerpc: change u64/s64 to a long long integer type
>> <applause>
>>
>> There are lots of other architctures that need doing though.
>
> I have missed the introduction.
> Can you explain why?
>
> I have done a bit of sparc hacking lately and was wondering if
> sparc needs something similar.
>
> cd arch/sparc
> git grep u64 | grep -v __u64 | wc -l
> 448
>
This should only affect 64-bit architectures.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* testing (Was: Re: linux-next: scsi-post-merge tree build failure)
From: Stephen Rothwell @ 2008-12-22 23:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, linuxppc-dev, linux-next, Kumar Gala,
Hollis Blanchard
In-Reply-To: <1229979392.4360.15.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]
Hi Ben,
On Tue, 23 Dec 2008 07:56:32 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Tue, 2008-12-23 at 01:25 +1100, Stephen Rothwell wrote:
> > Hi Paul, Ben,
> >
> > Today's linux-next build (powerpc ppc44x_config) failed like this:
> >
> > arch/powerpc/kvm/powerpc.c: In function 'kvm_arch_vcpu_put':
> > arch/powerpc/kvm/powerpc.c:333: error: implicit declaration of function '_tlbil_all'
> >
> > Probably caused by commit 2a4aca1144394653269720ffbb5a325a77abd5fa
> > ("powerpc/mm: Split low level tlb invalidate for nohash processors").
> > Reverting just that commit was too difficult, so I have reverted the
> > powerpc tree for today.
>
> You can't revert that without reverting my whole series.
I know that ... I tried.
> Adding a #include ../mm/mmu_decl.h to the kvm code should fix it for
> now.
>
> I need to talk to hollis about the right way to do that stuff in
> the long run but it might be it... those _tlbil things are low level
> stuff that aren't supposed to be used by the outside world which is
> why I moved the declarations there, but KVM is also low level :-)
So, why is this series in powerpc/next at all if some of the modified
files haven't even been compiled? A simple ppc44x_defconfig build of the
powerpc/next tree fails - which I would have thought would be part of the
testing since KVM is only implemented for 44x on powerpc.
(Sorry, I am annoyed - it was late when I finally found this build
failure on top of everything else.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: Sam Ravnborg @ 2008-12-22 23:13 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andrew Morton, Ingo Molnar, sfr, linux-kernel, kenchen, paulus,
tglx, linux-next, David Miller
In-Reply-To: <49501CC9.5040507@zytor.com>
On Mon, Dec 22, 2008 at 03:03:37PM -0800, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> > On Mon, Dec 22, 2008 at 02:43:19PM -0800, Andrew Morton wrote:
> >> On Mon, 22 Dec 2008 09:03:41 +0100
> >> Ingo Molnar <mingo@elte.hu> wrote:
> >>
> >>> Subject: powerpc: change u64/s64 to a long long integer type
> >> <applause>
> >>
> >> There are lots of other architctures that need doing though.
> >
> > I have missed the introduction.
> > Can you explain why?
> >
> > I have done a bit of sparc hacking lately and was wondering if
> > sparc needs something similar.
> >
> > cd arch/sparc
> > git grep u64 | grep -v __u64 | wc -l
> > 448
> >
>
> This should only affect 64-bit architectures.
In the sparc-next tree:
ls arch/sparc64
ls: arch/sparc64: No such file or directory
We have unified sparc and sparc64 so they are in the same arch directory now.
This will hit mainline in the upcoming merge window.
This has happended over at the sparclinux mailing list as this was
sparc/sparc64 specific stuff so no wonder you have not heard about it.
Sam
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: Andrew Morton @ 2008-12-22 23:13 UTC (permalink / raw)
To: Sam Ravnborg
Cc: mingo, sfr, linux-kernel, kenchen, paulus, tglx, hpa, linux-next,
davem
In-Reply-To: <20081222230035.GB4074@uranus.ravnborg.org>
On Tue, 23 Dec 2008 00:00:35 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:
> On Mon, Dec 22, 2008 at 02:43:19PM -0800, Andrew Morton wrote:
> > On Mon, 22 Dec 2008 09:03:41 +0100
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > Subject: powerpc: change u64/s64 to a long long integer type
> >
> > <applause>
> >
> > There are lots of other architctures that need doing though.
>
> I have missed the introduction.
> Can you explain why?
People keep on doing
printk("%llu", some_u64);
testing it only on x86_64 and this generates a warning storm on
powerpc, sparc64, etc. Because they use `long', not `long long'.
And not just a little bit - this bug gets repeated maybe ten times per
week - it's insane.
If we make all architectures use `long long' then the above code
becomes correct and warning-free on all architectures.
And we then get to remove all the open-coded (unsigned long long) casts
which we added all over the tree (hundreds of them).
> I have done a bit of sparc hacking lately and was wondering if
> sparc needs something similar.
>
> cd arch/sparc
> git grep u64 | grep -v __u64 | wc -l
> 448
>
> [On the unified tree]
Yes, quite a few 64-bit architectures are using `long' for their
s64/u64 types. We should convert them all to `long long'.
That's quite trivial to do, but it causes a lot of warnings due to code
in arch-speciic files which does
printk("%lu", some_u64);
which will then generate a warning. Or an error if the archtiecture
uses -Werror, which several do. So we need to simultaneously convert
all those to %llu. (Or %Lu, which saves a byte :))
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Inaky Perez-Gonzalez @ 2008-12-22 23:37 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, Greg KH, linux-next
In-Reply-To: <20081222175336.GA22701@uranus.ravnborg.org>
On Monday 22 December 2008, Sam Ravnborg wrote:
> On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> > On Sunday 21 December 2008, Sam Ravnborg wrote:
> > > On Mon, Dec 22, 2008 at 01:42:21PM +1100, Stephen Rothwell wrote:
> > > > (Just cc'ing Sam)
> > > >
> > > > On Sun, 21 Dec 2008 17:31:10 -0800 Greg KH <greg@kroah.com> wrote:
> > > > > On Mon, Dec 22, 2008 at 11:33:35AM +1100, Stephen Rothwell wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > > > >
> > > > > > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No
> > > > > > such file or directory
> > > > > >
....
> > > diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> > > new file mode 100644
> > > index 0000000..bda9430
> > > --- /dev/null
> > > +++ b/drivers/net/wimax/Makefile
> > > @@ -0,0 +1,2 @@
> > > +
> > > +obj-$(CONFIG_WIMAX_I2400M) += i2400m/
> > >
> > >
> > >
> > > But the problem here is that because we do not even pretend to
> > > build some files in this dir thus kbuild does not create build-in.o
> > >
> > > The fix is a bit ugly but simple. Add a dummy statement to
> > > the drivers/net/wimax/Makefile like this:
> > >
> > > # force kbuild to create built-in.o
> > > obj- := dummy.o
> >
> > ops -- ok, I will. I guess I have to add this in all the similar ones,
> > right?
>
> You need this in all cases where you have a Makefile that
> only specify sub directories. I assume thilinux-wimax.git/s is the only
Makefile
> where you have this.
It is -- I've been trying to reproduce it in the current tree I had and I
can't get to do it. In any case, I'll leave the workaround in.
Thanks,
--
Inaky
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Paul Mackerras @ 2008-12-23 0:07 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Avi Kivity, linux-next,
Kumar Gala, Josh Boyer
In-Reply-To: <1229985853.7181.10.camel@localhost.localdomain>
Hollis Blanchard writes:
> On Tue, 2008-12-23 at 09:29 +1100, Paul Mackerras wrote:
> > Hollis Blanchard writes:
> >
> > > > Patch is in Paulus -next already so we'll have to do a manual resolve.
> > >
> > > Who has to do it? My code should "win".
> >
> > Do you have your own tree or is all your stuff in the main kvm tree?
> >
> > If there is a powerpc KVM tree, I could pull that and resolve the
> > conflict, but I don't want to pull all the queued up KVM stuff.
>
> It's just the main KVM tree.
>
> > Worst case is Linus gets to resolve the conflict in the merge window.
> > If that's just a matter of him taking your version of the file, it
> > should be within his powers to manage. :)
>
> Yeah, that's what I meant by "win"... whatever changes Ben made are to
> now-dead code, so the code in kvm.git should be used. Does Linus need
> special instruction to do this, or how does that work?
ppc44x_defconfig now fails to build in my tree because of _tlbil_all
being undefined (it has CONFIG_KVM=y), so I need some sort of fix.
What would happen if I made arch/powerpc/kvm/powerpc.c look like the
version from the KVM tree?
Paul.
^ permalink raw reply
* Re: testing (Was: Re: linux-next: scsi-post-merge tree build failure)
From: Benjamin Herrenschmidt @ 2008-12-23 0:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Mackerras, linuxppc-dev, linux-next, Kumar Gala,
Hollis Blanchard
In-Reply-To: <20081223100456.bb556b19.sfr@canb.auug.org.au>
On Tue, 2008-12-23 at 10:04 +1100, Stephen Rothwell wrote:
> So, why is this series in powerpc/next at all if some of the modified
> files haven't even been compiled?
Because nobody spotted the problem while the series was out for review ?
> A simple ppc44x_defconfig build of the
> powerpc/next tree fails - which I would have thought would be part of the
> testing since KVM is only implemented for 44x on powerpc.
>
> (Sorry, I am annoyed - it was late when I finally found this build
> failure on top of everything else.)
I have about 3 44x configs in my build tests. KVM happens not to be
enabled in any of them :-( I'll add this ppc4xx_defconfig to the lot, I
didn't know it existed in fact.
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Hollis Blanchard @ 2008-12-23 1:02 UTC (permalink / raw)
To: Paul Mackerras
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Avi Kivity, linux-next,
Kumar Gala, Josh Boyer
In-Reply-To: <18768.11194.175787.360371@cargo.ozlabs.ibm.com>
On Tue, 2008-12-23 at 11:07 +1100, Paul Mackerras wrote:
> Hollis Blanchard writes:
>
> > On Tue, 2008-12-23 at 09:29 +1100, Paul Mackerras wrote:
> > > Hollis Blanchard writes:
> > >
> > > > > Patch is in Paulus -next already so we'll have to do a manual resolve.
> > > >
> > > > Who has to do it? My code should "win".
> > >
> > > Do you have your own tree or is all your stuff in the main kvm tree?
> > >
> > > If there is a powerpc KVM tree, I could pull that and resolve the
> > > conflict, but I don't want to pull all the queued up KVM stuff.
> >
> > It's just the main KVM tree.
> >
> > > Worst case is Linus gets to resolve the conflict in the merge window.
> > > If that's just a matter of him taking your version of the file, it
> > > should be within his powers to manage. :)
> >
> > Yeah, that's what I meant by "win"... whatever changes Ben made are to
> > now-dead code, so the code in kvm.git should be used. Does Linus need
> > special instruction to do this, or how does that work?
>
> ppc44x_defconfig now fails to build in my tree because of _tlbil_all
> being undefined (it has CONFIG_KVM=y), so I need some sort of fix.
> What would happen if I made arch/powerpc/kvm/powerpc.c look like the
> version from the KVM tree?
It still wouldn't build, because it would require new functions (e.g.
kvmppc_core_vcpu_put) to be defined in other files.
I don't really know what to say, because from my point of view the
offending code was removed a long time ago, so it shouldn't be causing
these problems. In hindsight, what is the best solution in these
situations? Maybe if Ben had talked to me we could have applied the
exact same patch to powerpc.git and kvm.git at the same time, which
would keep both trees building and still be automatically merged later.
If you commit a new change to your tree that reverses only the
arch/powerpc/kvm/powerpc.c part of Ben's patch, would that solve the
merge problem? ppc44x_defconfig would still fail in the meantime though.
If you fix the ppc44x_defconfig build, the merge problem is compounded.
Either way I guess it is something that needs to be sorted out in
powerpc.git, so you can pick which style of breakage you'd prefer?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Benjamin Herrenschmidt @ 2008-12-23 1:38 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Paul Mackerras, Stephen Rothwell, Avi Kivity, linux-next,
Kumar Gala, Josh Boyer
In-Reply-To: <1229994151.7181.24.camel@localhost.localdomain>
On Mon, 2008-12-22 at 19:02 -0600, Hollis Blanchard wrote:
> If you commit a new change to your tree that reverses only the
> arch/powerpc/kvm/powerpc.c part of Ben's patch, would that solve the
> merge problem? ppc44x_defconfig would still fail in the meantime though.
> If you fix the ppc44x_defconfig build, the merge problem is compounded.
> Either way I guess it is something that needs to be sorted out in
> powerpc.git, so you can pick which style of breakage you'd prefer?
Or add #include "../mm/mmu_decl.h" to powerpc to fix the local build
breakage now and fix the merge conflict later at merge time.
Cheers,
Ben.
^ permalink raw reply
* Re: testing (Was: Re: linux-next: scsi-post-merge tree build failure)
From: Josh Boyer @ 2008-12-23 1:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Benjamin Herrenschmidt, Blanchard, Hollis, linuxppc-dev,
linux-next, Paul Mackerras
In-Reply-To: <20081223100456.bb556b19.sfr@canb.auug.org.au>
On Tue, Dec 23, 2008 at 10:04:56AM +1100, Stephen Rothwell wrote:
>Hi Ben,
>
>On Tue, 23 Dec 2008 07:56:32 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>
>> On Tue, 2008-12-23 at 01:25 +1100, Stephen Rothwell wrote:
>> > Hi Paul, Ben,
>> >
>> > Today's linux-next build (powerpc ppc44x_config) failed like this:
>> >
>> > arch/powerpc/kvm/powerpc.c: In function 'kvm_arch_vcpu_put':
>> > arch/powerpc/kvm/powerpc.c:333: error: implicit declaration of function '_tlbil_all'
>> >
>> > Probably caused by commit 2a4aca1144394653269720ffbb5a325a77abd5fa
>> > ("powerpc/mm: Split low level tlb invalidate for nohash processors").
>> > Reverting just that commit was too difficult, so I have reverted the
>> > powerpc tree for today.
>>
>> You can't revert that without reverting my whole series.
>
>I know that ... I tried.
>
>> Adding a #include ../mm/mmu_decl.h to the kvm code should fix it for
>> now.
>>
>> I need to talk to hollis about the right way to do that stuff in
>> the long run but it might be it... those _tlbil things are low level
>> stuff that aren't supposed to be used by the outside world which is
>> why I moved the declarations there, but KVM is also low level :-)
>
>So, why is this series in powerpc/next at all if some of the modified
>files haven't even been compiled? A simple ppc44x_defconfig build of the
>powerpc/next tree fails - which I would have thought would be part of the
>testing since KVM is only implemented for 44x on powerpc.
Well, they were, and then they weren't. I tested this series starting
with the ppc44x_defconfig. However, I was incrementally compiling them
and I also had the 16/64K pages patch applied and 64K enabled. That
resulted in a kernel that was too big for the wrapper, so I went in
and turned some stuff off to make the kernel smaller. That included
the KVM stuff. By the time I was done building and testing the whole
series, it had remained disabled.
That might sound like a cop-out, but it's what happend. I should have
done a simple build after I was done. Sorry Stephen.
josh
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Greg KH @ 2008-12-23 4:29 UTC (permalink / raw)
To: Mark McLoughlin; +Cc: Stephen Rothwell, linux-next
In-Reply-To: <1229957446.19474.19.camel@localhost.localdomain>
On Mon, Dec 22, 2008 at 02:50:46PM +0000, Mark McLoughlin wrote:
> On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next build (powerpc allnoconfig) failed like this:
> >
> > drivers/base/core.c: In function '__root_device_register':
> > drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> >
> > Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> > root_device_register()"). This needs to cope with !CONFIG_MODULES (where
> > struct module is not defined).
>
> Ouch, my bad.
>
> > I applied the following patch but only for today because it is too hard
> > to revert the above patch ...
> >
> > --
> > Cheers,
> > Stephen Rothwell sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 22 Dec 2008 23:50:56 +1100
> > Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/base/core.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index 6fbdd8b..aa93980 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> > return ERR_PTR(err);
> > }
> >
> > +#ifdef CONFIG_MODULE
> > if (owner) {
> > struct module_kobject *mk = &owner->mkobj;
> >
> > @@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> > }
> > root->owner = owner;
> > }
> > +#endif
>
> Yep, looks correct to me ...
Ick, I hate ifdefs... I'll go fix this up.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the mtd tree
From: Greg KH @ 2008-12-23 4:28 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Woodhouse, linux-next, Artem Bityutskiy, Kay Sievers
In-Reply-To: <20081222171201.4a3680ae.sfr@canb.auug.org.au>
On Mon, Dec 22, 2008 at 05:12:01PM +1100, Stephen Rothwell wrote:
> Hi David,
>
> Today's linux-next merge of the mtd tree got a conflict in
> drivers/mtd/devices/m25p80.c drivers/mtd/devices/mtd_dataflash.c between
> commit 0e02ed3e44ef541e4d684348d9e684ab3bdd9399 ("mtd: struct device -
> replace bus_id with dev_name(), dev_set_name()") from the driver-core
> tree and commits 5b7f3a500cd097d673a6283fbb748c1e4f87bac6 ("[MTD] fix
> dataflash 64-bit divisions") and d85316ac459f1cdd14ea1828eebeac1f1028e167
> ("[MTD] fix m25p80 64-bit divisions") from the mtd tree.
>
> I fixed it up (see below) and can carry the fix as necessary. However, I
> suggest that you apply the patch from the driver-core tree as its
> prerequisites are upstream and you were cc'd on it.
Yes, David, please apply the following patch to prevent this from
happening...
thanks,
greg k-h
--------------
From: Kay Sievers <kay.sievers@vrfy.org>
Subject: mtd: struct device - replace bus_id with dev_name(), dev_set_name()
CC: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/mtd/devices/m25p80.c | 16 ++++++++--------
drivers/mtd/devices/mtd_dataflash.c | 30 +++++++++++++++---------------
drivers/mtd/maps/integrator-flash.c | 2 +-
drivers/mtd/maps/ixp2000.c | 4 ++--
drivers/mtd/maps/ixp4xx.c | 2 +-
drivers/mtd/maps/omap_nor.c | 2 +-
drivers/mtd/maps/physmap.c | 6 +++---
drivers/mtd/maps/physmap_of.c | 4 ++--
drivers/mtd/mtdconcat.c | 2 +-
drivers/mtd/nand/fsl_upm.c | 2 +-
drivers/mtd/nand/plat_nand.c | 2 +-
drivers/mtd/nand/tmio_nand.c | 2 +-
drivers/mtd/onenand/generic.c | 2 +-
drivers/mtd/onenand/omap2.c | 2 +-
drivers/mtd/ubi/build.c | 2 +-
drivers/mtd/ubi/vmt.c | 4 ++--
include/linux/mtd/concat.h | 2 +-
17 files changed, 43 insertions(+), 43 deletions(-)
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -170,7 +170,7 @@ static int wait_till_ready(struct m25p *
static int erase_chip(struct m25p *flash)
{
DEBUG(MTD_DEBUG_LEVEL3, "%s: %s %dKiB\n",
- flash->spi->dev.bus_id, __func__,
+ dev_name(&flash->spi->dev), __func__,
flash->mtd.size / 1024);
/* Wait until finished previous write command. */
@@ -197,7 +197,7 @@ static int erase_chip(struct m25p *flash
static int erase_sector(struct m25p *flash, u32 offset)
{
DEBUG(MTD_DEBUG_LEVEL3, "%s: %s %dKiB at 0x%08x\n",
- flash->spi->dev.bus_id, __func__,
+ dev_name(&flash->spi->dev), __func__,
flash->mtd.erasesize / 1024, offset);
/* Wait until finished previous write command. */
@@ -234,7 +234,7 @@ static int m25p80_erase(struct mtd_info
u32 addr,len;
DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %d\n",
- flash->spi->dev.bus_id, __func__, "at",
+ dev_name(&flash->spi->dev), __func__, "at",
(u32)instr->addr, instr->len);
/* sanity checks */
@@ -295,7 +295,7 @@ static int m25p80_read(struct mtd_info *
struct spi_message m;
DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
- flash->spi->dev.bus_id, __func__, "from",
+ dev_name(&flash->spi->dev), __func__, "from",
(u32)from, len);
/* sanity checks */
@@ -367,7 +367,7 @@ static int m25p80_write(struct mtd_info
struct spi_message m;
DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
- flash->spi->dev.bus_id, __func__, "to",
+ dev_name(&flash->spi->dev), __func__, "to",
(u32)to, len);
if (retlen)
@@ -563,7 +563,7 @@ static struct flash_info *__devinit jede
tmp = spi_write_then_read(spi, &code, 1, id, 5);
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
- spi->dev.bus_id, tmp);
+ dev_name(&spi->dev), tmp);
return NULL;
}
jedec = id[0];
@@ -617,7 +617,7 @@ static int __devinit m25p_probe(struct s
/* unrecognized chip? */
if (i == ARRAY_SIZE(m25p_data)) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
- spi->dev.bus_id, data->type);
+ dev_name(&spi->dev), data->type);
info = NULL;
/* recognized; is that chip really what's there? */
@@ -658,7 +658,7 @@ static int __devinit m25p_probe(struct s
if (data && data->name)
flash->mtd.name = data->name;
else
- flash->mtd.name = spi->dev.bus_id;
+ flash->mtd.name = dev_name(&spi->dev);
flash->mtd.type = MTD_NORFLASH;
flash->mtd.writesize = 1;
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -128,7 +128,7 @@ static int dataflash_waitready(struct sp
status = dataflash_status(spi);
if (status < 0) {
DEBUG(MTD_DEBUG_LEVEL1, "%s: status %d?\n",
- spi->dev.bus_id, status);
+ dev_name(&spi->dev), status);
status = 0;
}
@@ -154,7 +154,7 @@ static int dataflash_erase(struct mtd_in
uint8_t *command;
DEBUG(MTD_DEBUG_LEVEL2, "%s: erase addr=0x%x len 0x%x\n",
- spi->dev.bus_id,
+ dev_name(&spi->dev),
instr->addr, instr->len);
/* Sanity checks */
@@ -197,7 +197,7 @@ static int dataflash_erase(struct mtd_in
if (status < 0) {
printk(KERN_ERR "%s: erase %x, err %d\n",
- spi->dev.bus_id, pageaddr, status);
+ dev_name(&spi->dev), pageaddr, status);
/* REVISIT: can retry instr->retries times; or
* giveup and instr->fail_addr = instr->addr;
*/
@@ -239,7 +239,7 @@ static int dataflash_read(struct mtd_inf
int status;
DEBUG(MTD_DEBUG_LEVEL2, "%s: read 0x%x..0x%x\n",
- priv->spi->dev.bus_id, (unsigned)from, (unsigned)(from + len));
+ dev_name(&priv->spi->dev), (unsigned)from, (unsigned)(from + len));
*retlen = 0;
@@ -288,7 +288,7 @@ static int dataflash_read(struct mtd_inf
status = 0;
} else
DEBUG(MTD_DEBUG_LEVEL1, "%s: read %x..%x --> %d\n",
- priv->spi->dev.bus_id,
+ dev_name(&priv->spi->dev),
(unsigned)from, (unsigned)(from + len),
status);
return status;
@@ -315,7 +315,7 @@ static int dataflash_write(struct mtd_in
uint8_t *command;
DEBUG(MTD_DEBUG_LEVEL2, "%s: write 0x%x..0x%x\n",
- spi->dev.bus_id, (unsigned)to, (unsigned)(to + len));
+ dev_name(&spi->dev), (unsigned)to, (unsigned)(to + len));
*retlen = 0;
@@ -374,7 +374,7 @@ static int dataflash_write(struct mtd_in
status = spi_sync(spi, &msg);
if (status < 0)
DEBUG(MTD_DEBUG_LEVEL1, "%s: xfer %u -> %d \n",
- spi->dev.bus_id, addr, status);
+ dev_name(&spi->dev), addr, status);
(void) dataflash_waitready(priv->spi);
}
@@ -396,7 +396,7 @@ static int dataflash_write(struct mtd_in
spi_transfer_del(x + 1);
if (status < 0)
DEBUG(MTD_DEBUG_LEVEL1, "%s: pgm %u/%u -> %d \n",
- spi->dev.bus_id, addr, writelen, status);
+ dev_name(&spi->dev), addr, writelen, status);
(void) dataflash_waitready(priv->spi);
@@ -416,14 +416,14 @@ static int dataflash_write(struct mtd_in
status = spi_sync(spi, &msg);
if (status < 0)
DEBUG(MTD_DEBUG_LEVEL1, "%s: compare %u -> %d \n",
- spi->dev.bus_id, addr, status);
+ dev_name(&spi->dev), addr, status);
status = dataflash_waitready(priv->spi);
/* Check result of the compare operation */
if (status & (1 << 6)) {
printk(KERN_ERR "%s: compare page %u, err %d\n",
- spi->dev.bus_id, pageaddr, status);
+ dev_name(&spi->dev), pageaddr, status);
remaining = 0;
status = -EIO;
break;
@@ -779,7 +779,7 @@ static struct flash_info *__devinit jede
tmp = spi_write_then_read(spi, &code, 1, id, 3);
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
- spi->dev.bus_id, tmp);
+ dev_name(&spi->dev), tmp);
return ERR_PTR(tmp);
}
if (id[0] != 0x1f)
@@ -869,7 +869,7 @@ static int __devinit dataflash_probe(str
status = dataflash_status(spi);
if (status <= 0 || status == 0xff) {
DEBUG(MTD_DEBUG_LEVEL1, "%s: status error %d\n",
- spi->dev.bus_id, status);
+ dev_name(&spi->dev), status);
if (status == 0 || status == 0xff)
status = -ENODEV;
return status;
@@ -905,13 +905,13 @@ static int __devinit dataflash_probe(str
/* obsolete AT45DB1282 not (yet?) supported */
default:
DEBUG(MTD_DEBUG_LEVEL1, "%s: unsupported device (%x)\n",
- spi->dev.bus_id, status & 0x3c);
+ dev_name(&spi->dev), status & 0x3c);
status = -ENODEV;
}
if (status < 0)
DEBUG(MTD_DEBUG_LEVEL1, "%s: add_dataflash --> %d\n",
- spi->dev.bus_id, status);
+ dev_name(&spi->dev), status);
return status;
}
@@ -921,7 +921,7 @@ static int __devexit dataflash_remove(st
struct dataflash *flash = dev_get_drvdata(&spi->dev);
int status;
- DEBUG(MTD_DEBUG_LEVEL1, "%s: remove\n", spi->dev.bus_id);
+ DEBUG(MTD_DEBUG_LEVEL1, "%s: remove\n", dev_name(&spi->dev));
if (mtd_has_partitions() && flash->partitioned)
status = del_mtd_partitions(&flash->mtd);
--- a/drivers/mtd/maps/integrator-flash.c
+++ b/drivers/mtd/maps/integrator-flash.c
@@ -105,7 +105,7 @@ static int armflash_probe(struct platfor
info->map.bankwidth = plat->width;
info->map.phys = res->start;
info->map.virt = base;
- info->map.name = dev->dev.bus_id;
+ info->map.name = dev_name(&dev->dev);
info->map.set_vpp = armflash_set_vpp;
simple_map_init(&info->map);
--- a/drivers/mtd/maps/ixp2000.c
+++ b/drivers/mtd/maps/ixp2000.c
@@ -188,7 +188,7 @@ static int ixp2000_flash_probe(struct pl
*/
info->map.map_priv_2 = (unsigned long) ixp_data->bank_setup;
- info->map.name = dev->dev.bus_id;
+ info->map.name = dev_name(&dev->dev);
info->map.read = ixp2000_flash_read8;
info->map.write = ixp2000_flash_write8;
info->map.copy_from = ixp2000_flash_copy_from;
@@ -196,7 +196,7 @@ static int ixp2000_flash_probe(struct pl
info->res = request_mem_region(dev->resource->start,
dev->resource->end - dev->resource->start + 1,
- dev->dev.bus_id);
+ dev_name(&dev->dev));
if (!info->res) {
dev_err(&dev->dev, "Could not reserve memory region\n");
err = -ENOMEM;
--- a/drivers/mtd/maps/ixp4xx.c
+++ b/drivers/mtd/maps/ixp4xx.c
@@ -218,7 +218,7 @@ static int ixp4xx_flash_probe(struct pla
* handle that.
*/
info->map.bankwidth = 2;
- info->map.name = dev->dev.bus_id;
+ info->map.name = dev_name(&dev->dev);
info->map.read = ixp4xx_read16,
info->map.write = ixp4xx_probe_write16,
info->map.copy_from = ixp4xx_copy_from,
--- a/drivers/mtd/maps/omap_nor.c
+++ b/drivers/mtd/maps/omap_nor.c
@@ -101,7 +101,7 @@ static int __init omapflash_probe(struct
err = -ENOMEM;
goto out_release_mem_region;
}
- info->map.name = pdev->dev.bus_id;
+ info->map.name = dev_name(&pdev->dev);
info->map.phys = res->start;
info->map.size = size;
info->map.bankwidth = pdata->width;
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -108,13 +108,13 @@ static int physmap_flash_probe(struct pl
if (!devm_request_mem_region(&dev->dev,
dev->resource[i].start,
dev->resource[i].end - dev->resource[i].start + 1,
- dev->dev.bus_id)) {
+ dev_name(&dev->dev))) {
dev_err(&dev->dev, "Could not reserve memory region\n");
err = -ENOMEM;
goto err_out;
}
- info->map[i].name = dev->dev.bus_id;
+ info->map[i].name = dev_name(&dev->dev);
info->map[i].phys = dev->resource[i].start;
info->map[i].size = dev->resource[i].end - dev->resource[i].start + 1;
info->map[i].bankwidth = physmap_data->width;
@@ -150,7 +150,7 @@ static int physmap_flash_probe(struct pl
* We detected multiple devices. Concatenate them together.
*/
#ifdef CONFIG_MTD_CONCAT
- info->cmtd = mtd_concat_create(info->mtd, devices_found, dev->dev.bus_id);
+ info->cmtd = mtd_concat_create(info->mtd, devices_found, dev_name(&dev->dev));
if (info->cmtd == NULL)
err = -ENXIO;
#else
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -183,7 +183,7 @@ static int __devinit of_flash_probe(stru
err = -EBUSY;
info->res = request_mem_region(res.start, res.end - res.start + 1,
- dev->dev.bus_id);
+ dev_name(&dev->dev));
if (!info->res)
goto err_out;
@@ -194,7 +194,7 @@ static int __devinit of_flash_probe(stru
goto err_out;
}
- info->map.name = dev->dev.bus_id;
+ info->map.name = dev_name(&dev->dev);
info->map.phys = res.start;
info->map.size = res.end - res.start + 1;
info->map.bankwidth = *width;
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -691,7 +691,7 @@ static int concat_block_markbad(struct m
*/
struct mtd_info *mtd_concat_create(struct mtd_info *subdev[], /* subdevices to concatenate */
int num_devs, /* number of subdevices */
- char *name)
+ const char *name)
{ /* name for the new device */
int i;
size_t size;
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -222,7 +222,7 @@ static int __devinit fun_probe(struct of
fun->rnb_gpio = of_get_gpio(ofdev->node, 0);
if (fun->rnb_gpio >= 0) {
- ret = gpio_request(fun->rnb_gpio, ofdev->dev.bus_id);
+ ret = gpio_request(fun->rnb_gpio, dev_name(&ofdev->dev));
if (ret) {
dev_err(&ofdev->dev, "can't request RNB gpio\n");
goto err2;
--- a/drivers/mtd/nand/plat_nand.c
+++ b/drivers/mtd/nand/plat_nand.c
@@ -54,7 +54,7 @@ static int __init plat_nand_probe(struct
data->chip.priv = &data;
data->mtd.priv = &data->chip;
data->mtd.owner = THIS_MODULE;
- data->mtd.name = pdev->dev.bus_id;
+ data->mtd.name = dev_name(&pdev->dev);
data->chip.IO_ADDR_R = data->io_base;
data->chip.IO_ADDR_W = data->io_base;
--- a/drivers/mtd/nand/tmio_nand.c
+++ b/drivers/mtd/nand/tmio_nand.c
@@ -433,7 +433,7 @@ static int tmio_probe(struct platform_de
nand_chip->chip_delay = 15;
retval = request_irq(irq, &tmio_irq,
- IRQF_DISABLED, dev->dev.bus_id, tmio);
+ IRQF_DISABLED, dev_name(&dev->dev), tmio);
if (retval) {
dev_err(&dev->dev, "request_irq error %d\n", retval);
goto err_irq;
--- a/drivers/mtd/onenand/generic.c
+++ b/drivers/mtd/onenand/generic.c
@@ -63,7 +63,7 @@ static int __devinit generic_onenand_pro
info->onenand.mmcontrol = pdata->mmcontrol;
info->onenand.irq = platform_get_irq(pdev, 0);
- info->mtd.name = pdev->dev.bus_id;
+ info->mtd.name = dev_name(&pdev->dev);
info->mtd.priv = &info->onenand;
info->mtd.owner = THIS_MODULE;
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -668,7 +668,7 @@ static int __devinit omap2_onenand_probe
c->onenand.base);
c->pdev = pdev;
- c->mtd.name = pdev->dev.bus_id;
+ c->mtd.name = dev_name(&pdev->dev);
c->mtd.priv = &c->onenand;
c->mtd.owner = THIS_MODULE;
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -280,7 +280,7 @@ static int ubi_sysfs_init(struct ubi_dev
ubi->dev.release = dev_release;
ubi->dev.devt = ubi->cdev.dev;
ubi->dev.class = ubi_class;
- sprintf(&ubi->dev.bus_id[0], UBI_NAME_STR"%d", ubi->ubi_num);
+ dev_set_name(&ubi->dev, UBI_NAME_STR"%d", ubi->ubi_num);
err = device_register(&ubi->dev);
if (err)
return err;
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -329,7 +329,7 @@ int ubi_create_volume(struct ubi_device
vol->dev.devt = dev;
vol->dev.class = ubi_class;
- sprintf(&vol->dev.bus_id[0], "%s_%d", ubi->ubi_name, vol->vol_id);
+ dev_set_name(&vol->dev, "%s_%d", ubi->ubi_name, vol->vol_id);
err = device_register(&vol->dev);
if (err) {
ubi_err("cannot register device");
@@ -678,7 +678,7 @@ int ubi_add_volume(struct ubi_device *ub
vol->dev.parent = &ubi->dev;
vol->dev.devt = dev;
vol->dev.class = ubi_class;
- sprintf(&vol->dev.bus_id[0], "%s_%d", ubi->ubi_name, vol->vol_id);
+ dev_set_name(&vol->dev, "%s_%d", ubi->ubi_name, vol->vol_id);
err = device_register(&vol->dev);
if (err)
goto out_gluebi;
--- a/include/linux/mtd/concat.h
+++ b/include/linux/mtd/concat.h
@@ -13,7 +13,7 @@
struct mtd_info *mtd_concat_create(
struct mtd_info *subdev[], /* subdevices to concatenate */
int num_devs, /* number of subdevices */
- char *name); /* name for the new device */
+ const char *name); /* name for the new device */
void mtd_concat_destroy(struct mtd_info *mtd);
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Greg KH @ 2008-12-23 4:30 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Inaky Perez-Gonzalez, Stephen Rothwell, linux-next
In-Reply-To: <20081222175336.GA22701@uranus.ravnborg.org>
On Mon, Dec 22, 2008 at 06:53:36PM +0100, Sam Ravnborg wrote:
> On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> > On Sunday 21 December 2008, Sam Ravnborg wrote:
> > > On Mon, Dec 22, 2008 at 01:42:21PM +1100, Stephen Rothwell wrote:
> > > > (Just cc'ing Sam)
> > > >
> > > > On Sun, 21 Dec 2008 17:31:10 -0800 Greg KH <greg@kroah.com> wrote:
> > > > > On Mon, Dec 22, 2008 at 11:33:35AM +1100, Stephen Rothwell wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > > > >
> > > > > > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No such
> > > > > > file or directory
> > > > > >
> > > > > > I reverted commit 66aa675719ab82a03a66b75210fd40be6541f8fb ("wimax:
> > > > > > Makefile, Kconfig and docbook linkage for the stack") just to make
> > > > > > the build work.
> > > > >
> > > > > Inaky, any ideas? This really looks like a build system error that I
> > > > > ran into with the staging tree in the past. I had to add a "dummy"
> > > > > file to the empty directory to get it to build properly.
> > > > >
> > > > > I tried to duplicate the problem with a sample patch, but never could
> > > > > :(
> > >
> > > Incidentally I sent some review comments to said patch yesterday
> > > but missed this one.
> > >
> > > We have:
> > > diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> > > new file mode 100644
> > > index 0000000..bda9430
> > > --- /dev/null
> > > +++ b/drivers/net/wimax/Makefile
> > > @@ -0,0 +1,2 @@
> > > +
> > > +obj-$(CONFIG_WIMAX_I2400M) += i2400m/
> > >
> > >
> > >
> > > But the problem here is that because we do not even pretend to
> > > build some files in this dir thus kbuild does not create build-in.o
> > >
> > > The fix is a bit ugly but simple. Add a dummy statement to
> > > the drivers/net/wimax/Makefile like this:
> > >
> > > # force kbuild to create built-in.o
> > > obj- := dummy.o
> >
> > ops -- ok, I will. I guess I have to add this in all the similar ones, right?
> You need this in all cases where you have a Makefile that
> only specify sub directories. I assume this is the only Makefile
> where you have this.
Ah great, I'll do this for the drivers/staging/ directory as well, I had
the same error there and couldn't figure it out.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Greg KH @ 2008-12-23 4:31 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Sam Ravnborg, Stephen Rothwell, linux-next
In-Reply-To: <200812221537.17363.inaky@linux.intel.com>
On Mon, Dec 22, 2008 at 03:37:16PM -0800, Inaky Perez-Gonzalez wrote:
> On Monday 22 December 2008, Sam Ravnborg wrote:
> > On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> > > On Sunday 21 December 2008, Sam Ravnborg wrote:
> > > > On Mon, Dec 22, 2008 at 01:42:21PM +1100, Stephen Rothwell wrote:
> > > > > (Just cc'ing Sam)
> > > > >
> > > > > On Sun, 21 Dec 2008 17:31:10 -0800 Greg KH <greg@kroah.com> wrote:
> > > > > > On Mon, Dec 22, 2008 at 11:33:35AM +1100, Stephen Rothwell wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > > > > >
> > > > > > > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No
> > > > > > > such file or directory
> > > > > > >
> ....
> > > > diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> > > > new file mode 100644
> > > > index 0000000..bda9430
> > > > --- /dev/null
> > > > +++ b/drivers/net/wimax/Makefile
> > > > @@ -0,0 +1,2 @@
> > > > +
> > > > +obj-$(CONFIG_WIMAX_I2400M) += i2400m/
> > > >
> > > >
> > > >
> > > > But the problem here is that because we do not even pretend to
> > > > build some files in this dir thus kbuild does not create build-in.o
> > > >
> > > > The fix is a bit ugly but simple. Add a dummy statement to
> > > > the drivers/net/wimax/Makefile like this:
> > > >
> > > > # force kbuild to create built-in.o
> > > > obj- := dummy.o
> > >
> > > ops -- ok, I will. I guess I have to add this in all the similar ones,
> > > right?
> >
> > You need this in all cases where you have a Makefile that
> > only specify sub directories. I assume thilinux-wimax.git/s is the only
> Makefile
> > where you have this.
>
> It is -- I've been trying to reproduce it in the current tree I had and I
> can't get to do it. In any case, I'll leave the workaround in.
Delete all .o files you have in that directory, and any .* files as
well. Odds are you had files left over from previous development. I
ran into this problem in the staging tree as well.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Greg KH @ 2008-12-23 4:31 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Sam Ravnborg, Stephen Rothwell, linux-next
In-Reply-To: <200812220926.43784.inaky@linux.intel.com>
On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> On Sunday 21 December 2008, Sam Ravnborg wrote:
> > On Mon, Dec 22, 2008 at 01:42:21PM +1100, Stephen Rothwell wrote:
> > > (Just cc'ing Sam)
> > >
> > > On Sun, 21 Dec 2008 17:31:10 -0800 Greg KH <greg@kroah.com> wrote:
> > > > On Mon, Dec 22, 2008 at 11:33:35AM +1100, Stephen Rothwell wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > > >
> > > > > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No such
> > > > > file or directory
> > > > >
> > > > > I reverted commit 66aa675719ab82a03a66b75210fd40be6541f8fb ("wimax:
> > > > > Makefile, Kconfig and docbook linkage for the stack") just to make
> > > > > the build work.
> > > >
> > > > Inaky, any ideas? This really looks like a build system error that I
> > > > ran into with the staging tree in the past. I had to add a "dummy"
> > > > file to the empty directory to get it to build properly.
> > > >
> > > > I tried to duplicate the problem with a sample patch, but never could
> > > > :(
> >
> > Incidentally I sent some review comments to said patch yesterday
> > but missed this one.
> >
> > We have:
> > diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> > new file mode 100644
> > index 0000000..bda9430
> > --- /dev/null
> > +++ b/drivers/net/wimax/Makefile
> > @@ -0,0 +1,2 @@
> > +
> > +obj-$(CONFIG_WIMAX_I2400M) += i2400m/
> >
> >
> >
> > But the problem here is that because we do not even pretend to
> > build some files in this dir thus kbuild does not create build-in.o
> >
> > The fix is a bit ugly but simple. Add a dummy statement to
> > the drivers/net/wimax/Makefile like this:
> >
> > # force kbuild to create built-in.o
> > obj- := dummy.o
>
> ops -- ok, I will. I guess I have to add this in all the similar ones, right?
>
> Greg, do you want a new patch series or just another patch on top?
Just a single replacement patch for when we add this makefile is fine
with me.
thanks,
greg k-h
^ permalink raw reply
* linux-next: no linux-next release for Dec 23
From: Stephen Rothwell @ 2008-12-23 7:14 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
Hi all,
There will be no more releases until (hopefully) Dec 29. Hope you all
have a nice rest.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Inaky Perez-Gonzalez @ 2008-12-23 10:26 UTC (permalink / raw)
To: Greg KH; +Cc: Sam Ravnborg, Stephen Rothwell, linux-next
In-Reply-To: <20081223043139.GG1928@kroah.com>
On Monday 22 December 2008, Greg KH wrote:
> On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> > On Sunday 21 December 2008, Sam Ravnborg wrote:
> >
> > ops -- ok, I will. I guess I have to add this in all the similar ones,
> > right?
> >
> > Greg, do you want a new patch series or just another patch on top?
>
> Just a single replacement patch for when we add this makefile is fine
> with me.
Hmmm, there was more feedback Sam gave me on Kconfig and Makefiles I added,
so at the end the patch touches more files than just this one. Maybe a whole
new series will be the way to go.
--
Inaky
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox