headers
Stephen Rothwell | 12 May 2008 09:36
Picon
Picon

linux-next: sparc build failure

Hi Dave,

Today's linux-next build (sparc allmodconfig) fails like this:

In file included from include2/asm/sigcontext.h:6,
                 from include2/asm/signal.h:5,
                 from include/linux/signal.h:4,
                 from fs/ocfs2/dlm/userdlm.c:30:
include2/asm/ptrace.h:42: error: syntax error before "pt_regs_is_syscall"
include2/asm/ptrace.h:43: warning: return type defaults to `int'
include2/asm/ptrace.h:47: error: syntax error before "pt_regs_clear_syscall"
include2/asm/ptrace.h:48: warning: return type defaults to `int'

In file included from include2/asm/sigcontext.h:6,
                 from include2/asm/signal.h:5,
                 from include/linux/signal.h:4,
                 from drivers/net/usb/rtl8150.c:10:
include2/asm/ptrace.h:42: error: syntax error before "pt_regs_is_syscall"
include2/asm/ptrace.h:43: warning: return type defaults to `int'
include2/asm/ptrace.h:47: error: syntax error before "pt_regs_clear_syscall"
include2/asm/ptrace.h:48: warning: return type defaults to `int'

Seems to have been introduced by commit
28e6103665301ce60634e8a77f0b657c6cc099de ("sparc: Fix debugger syscall
restart interactions") which went into Linus' tree recently ("bool" seems
to be missing a definition).

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Miller | 12 May 2008 09:40
Favicon

Re: linux-next: sparc build failure

From: Stephen Rothwell <sfr <at> canb.auug.org.au>
Date: Mon, 12 May 2008 17:36:58 +1000

> Seems to have been introduced by commit
> 28e6103665301ce60634e8a77f0b657c6cc099de ("sparc: Fix debugger syscall
> restart interactions") which went into Linus' tree recently ("bool" seems
> to be missing a definition).

Fixed in current sparc-2.6.git

--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Stephen Rothwell | 12 May 2008 09:43
Picon
Picon

Re: linux-next: sparc build failure

Hi Dave,

On Mon, 12 May 2008 00:40:31 -0700 (PDT) David Miller <davem <at> davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr <at> canb.auug.org.au>
> Date: Mon, 12 May 2008 17:36:58 +1000
> 
> > Seems to have been introduced by commit
> > 28e6103665301ce60634e8a77f0b657c6cc099de ("sparc: Fix debugger syscall
> > restart interactions") which went into Linus' tree recently ("bool" seems
> > to be missing a definition).
> 
> Fixed in current sparc-2.6.git

OK, thanks ... tomorrow.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Permalink | Reply | 0 comments |
headers
David Miller | 12 May 2008 09:54
Favicon

Re: linux-next: build failure

From: Stephen Rothwell <sfr <at> canb.auug.org.au>
Date: Mon, 12 May 2008 15:47:17 +1000

> Today's linux-next build (sparc64 defconfig) fails like this:
> 
> arch/sparc64/kernel/pci.c: In function `of_create_pci_dev':
> arch/sparc64/kernel/pci.c:412: warning: passing arg 1 of `sprintf' discards qualifiers from pointer
target type
> make[2]: *** [arch/sparc64/kernel/pci.o] Error 1
> 
> (I assume sparc64 builds with -Werr)

Yes, it builds everything except the FPU emulator under arch/sparc64
with -Werror

> This started on May 8 with the introduction of "driver-core: prepare for
> removal of 20 char limit from struct device".
> 
> The sparc64 pci code above looks like this:
> 
> 	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> 		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
> 

There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
break the build there becuase powerpc doesn't use -Werror (yet) :-)

I'm getting a little tired of all of these breakages that occur when
the core PCI probing under drivers/pci or related datastructures are
modified but nobody even tests the build of powerpc or sparc's OF
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stephen Rothwell | 12 May 2008 10:03
Picon
Picon

linux-next: s390 build failure

Hi Greg,

Today's linux-next build (s390 defconfig) fails like this:

drivers/s390/cio/device_fsm.c:53: error: syntax error before ';' token
drivers/s390/cio/device_fsm.c:54: error: syntax error before ';' token

Caused by commit 67da378c80848bb778ee8caecadcdf17e1e310e0 ("driver-core:
prepare for removal of 20 char limit from struct device") from the
driver-core tree. Missing close parentheses on added dev_name() calls.

A touch more care, please.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Permalink | Reply | 1 comment |
headers
Stephen Rothwell | 12 May 2008 10:09
Picon
Picon

Re: linux-next: build failure

Hi Dave,

On Mon, 12 May 2008 00:54:54 -0700 (PDT) David Miller <davem <at> davemloft.net> wrote:
>
> There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
> break the build there becuase powerpc doesn't use -Werror (yet) :-)

OK, I will look for your fix and copy it over, thanks.

> I'm getting a little tired of all of these breakages that occur when
> the core PCI probing under drivers/pci or related datastructures are
> modified but nobody even tests the build of powerpc or sparc's OF
> based PCI bus probing code.
> 
> There have also been functional breakages due to core PCI changes
> because of this, an update goes into the drivers/pci/*.c code but
> doesn't get noticed for arch/{sparc64,powerpc}/'s PCI probing code
> until some poor arch maintainer or user tries to bootup on those
> platforms.

One of the reasons that we have linux-next, of course.  However, it would
be nice if Greg could find a couple of cross compilers for the major
architectures :-)

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Permalink | Reply | 3 comments |
headers
Stephen Rothwell | 12 May 2008 10:15
Picon
Picon

Re: linux-next: build failure

Hi Dave,

On Mon, 12 May 2008 18:09:03 +1000 Stephen Rothwell <sfr <at> canb.auug.org.au> wrote:
>
> On Mon, 12 May 2008 00:54:54 -0700 (PDT) David Miller <davem <at> davemloft.net> wrote:
> >
> > There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
> > break the build there becuase powerpc doesn't use -Werror (yet) :-)
> 
> OK, I will look for your fix and copy it over, thanks.

That should have had a smiley :-)

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Permalink | Reply | 2 comments |
headers
David Miller | 12 May 2008 10:53
Favicon

Re: linux-next: build failure

From: Stephen Rothwell <sfr <at> canb.auug.org.au>
Date: Mon, 12 May 2008 18:15:57 +1000

> Hi Dave,
> 
> On Mon, 12 May 2008 18:09:03 +1000 Stephen Rothwell <sfr <at> canb.auug.org.au> wrote:
> >
> > On Mon, 12 May 2008 00:54:54 -0700 (PDT) David Miller <davem <at> davemloft.net> wrote:
> > >
> > > There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
> > > break the build there becuase powerpc doesn't use -Werror (yet) :-)
> > 
> > OK, I will look for your fix and copy it over, thanks.
> 
> That should have had a smiley :-)

:-)  The fix is likely something like this:

diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 5275074..776703e 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
 <at>  <at>  -189,8 +189,8  <at>  <at>  struct pci_dev *of_create_pci_dev(struct device_node *node,

 	dev->cfg_size = pci_cfg_space_size(dev);

-	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
-		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
+	dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
+		     dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Rothwell | 12 May 2008 12:42
Picon
Picon

Re: linux-next: build failure

Hi Dave,

On Mon, 12 May 2008 01:53:49 -0700 (PDT) David Miller <davem <at> davemloft.net> wrote:
>
> :-)  The fix is likely something like this:
> 
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 5275074..776703e 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
>  <at>  <at>  -189,8 +189,8  <at>  <at>  struct pci_dev *of_create_pci_dev(struct device_node *node,
>  
>  	dev->cfg_size = pci_cfg_space_size(dev);
>  
> -	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> -		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +	dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> +		     dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
>  	dev->class = get_int_prop(node, "class-code", 0);
>  	dev->revision = get_int_prop(node, "revision-id", 0);
>  
> diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
> index 112b09f..bfc8c5d 100644
> --- a/arch/sparc64/kernel/pci.c
> +++ b/arch/sparc64/kernel/pci.c
>  <at>  <at>  -408,8 +408,8  <at>  <at>  struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
>  	dev->class = class >> 8;
>  	dev->revision = class & 0xff;
>  
> -	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Dunlap | 12 May 2008 17:22
Picon
Favicon

Re: linux-next: Tree for May 12

On Mon, 12 May 2008 15:04:18 +1000 Stephen Rothwell wrote:

> Hi all,
> 
> News:  I am now providing patches relative to the latest tag in Linus'
> tree.  I propose to stop providing complete tar balls as they are so
> large and people will have recent versions of Linus's tree anyway (I
> assume).  The patches will be named "patch-<upstream tag>-<next tag>".

Oh well.  For the record, I don't mind using patches instead of
complete tarballs, but I would prefer that the patches be relative
to something like a daily -git snapshot so that using git is not
required at all.

---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane