* Re: [PATCH -next] mfd: fix mc13783 build error
From: Samuel Ortiz @ 2009-08-18 23:46 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, akpm, linux-next, LKML
In-Reply-To: <20090818152555.793773ad.randy.dunlap@oracle.com>
Hi Randy,
On Tue, Aug 18, 2009 at 03:25:55PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build errors due to missing Kconfig dependency:
Thanks, should be fixed now.
Cheers,
Samuel.
> mc13783-core.c:(.text+0x11bbaf): undefined reference to `spi_sync'
> mc13783-core.c:(.init.text+0xb6b3): undefined reference to `spi_register_driver'
> mc13783-core.c:(.devinit.text+0x1fd8b): undefined reference to `spi_setup'
> drivers/built-in.o:(.data+0x157c0): undefined reference to `spi_bus_type'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> drivers/mfd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20090818.orig/drivers/mfd/Kconfig
> +++ linux-next-20090818/drivers/mfd/Kconfig
> @@ -240,6 +240,7 @@ config MFD_PCF50633
>
> config MFD_MC13783
> tristate "Support Freescale MC13783"
> + depends on SPI_MASTER
> select MFD_CORE
> help
> Support for the Freescale (Atlas) MC13783 PMIC and audio CODEC.
>
>
>
> ---
> ~Randy
> LPC 2009, Sept. 23-25, Portland, Oregon
> http://linuxplumbersconf.org/2009/
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: linux-next: suspend tree build failure
From: Paul Mundt @ 2009-08-18 22:47 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <200908190040.50949.rjw@sisk.pl>
On Wed, Aug 19, 2009 at 12:40:50AM +0200, Rafael J. Wysocki wrote:
> On Wednesday 19 August 2009, Paul Mundt wrote:
> > Argh, and rebased in the process, again. This is now the second time in
> > as many days this has been rebased, meaning I have to throw away my topic
> > branch and re-create. I thought this was going to remain stable? I would
> > like the SH runtime PM code to get some coverage in -next, but I can't
> > merge it in to my tree if the suspend tree keeps rebasing every day.
>
> Well, my linux-next branch is not to guaranteed to be stable, just like the
> entire linux-next tree.
>
> Once the patch stops making trouble, I'll move it into my for-linus branch,
> which _is_ guaranteed not to be rebased (in fact it's never rebased).
>
> I haven't done it yet exactly because of these build problems. Please wait
> for a couple of days more for things to settle down.
>
Ah, ok, I misunderstood the intention of your -next branch. I'll wait for
it to cool off, thanks. ;-)
^ permalink raw reply
* Re: linux-next: suspend tree build failure
From: Rafael J. Wysocki @ 2009-08-18 22:40 UTC (permalink / raw)
To: Paul Mundt; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20090818221301.GA20676@linux-sh.org>
On Wednesday 19 August 2009, Paul Mundt wrote:
> On Tue, Aug 18, 2009 at 11:43:32PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 18 August 2009, Stephen Rothwell wrote:
> > > Hi Rafael,
> >
> > Hi,
> >
> > > Today's linux-next build (i386 defconfig) failed like this:
> > >
> > > drivers/base/power/main.c: In function 'device_pm_init':
> > > drivers/base/power/main.c:59: error: 'struct dev_pm_info' has no member named 'lock'
> >
> > Argh, that line shouldn't even be there.
> >
> > > Caused by commit ea8e84f27325d9ddc7692f728a10e0a22cd59f52 ("PM: Introduce
> > > core framework for run-time PM of I/O devices (rev. 17)") from the
> > > suspend tree. The i386 defconfig does not have CONFIG_PM_RUNTIME set but
> > > does have CONFIG_PM_SLEEP=y ...
> > >
> > > I have reverted that commit for today.
> > >
> > > When you add a new CONFIG variable, it is worth doing test builds both
> > > with it turned on and turned off ...
> >
> > I tested it, but I broke the patch afterwards by mistake. :-(
> >
> > Sorry for the trouble, I've just pushed an updated tree.
> >
> Argh, and rebased in the process, again. This is now the second time in
> as many days this has been rebased, meaning I have to throw away my topic
> branch and re-create. I thought this was going to remain stable? I would
> like the SH runtime PM code to get some coverage in -next, but I can't
> merge it in to my tree if the suspend tree keeps rebasing every day.
Well, my linux-next branch is not to guaranteed to be stable, just like the
entire linux-next tree.
Once the patch stops making trouble, I'll move it into my for-linus branch,
which _is_ guaranteed not to be rebased (in fact it's never rebased).
I haven't done it yet exactly because of these build problems. Please wait
for a couple of days more for things to settle down.
Best,
Rafael
^ permalink raw reply
* [PATCH -next] net: fix ks8851 build errors
From: Randy Dunlap @ 2009-08-18 22:27 UTC (permalink / raw)
To: Stephen Rothwell, netdev, akpm; +Cc: linux-next, LKML, davem
In-Reply-To: <20090818184215.fdf1c7ae.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build errors due to missing Kconfig selects:
ks8851.c:(.text+0x7d2ee): undefined reference to `crc32_le'
ks8851.c:(.text+0x7d2f5): undefined reference to `bitrev32'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20090818.orig/drivers/net/Kconfig
+++ linux-next-20090818/drivers/net/Kconfig
@@ -1733,6 +1733,8 @@ config KS8851
tristate "Micrel KS8851 SPI"
depends on SPI
select MII
+ select CRC32
+ select BITREVERSE
help
SPI driver for Micrel KS8851 SPI attached network chip.
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* [PATCH -next] mfd: fix mc13783 build error
From: Randy Dunlap @ 2009-08-18 22:25 UTC (permalink / raw)
To: Stephen Rothwell, akpm; +Cc: linux-next, LKML, Samuel Ortiz
In-Reply-To: <20090818184215.fdf1c7ae.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build errors due to missing Kconfig dependency:
mc13783-core.c:(.text+0x11bbaf): undefined reference to `spi_sync'
mc13783-core.c:(.init.text+0xb6b3): undefined reference to `spi_register_driver'
mc13783-core.c:(.devinit.text+0x1fd8b): undefined reference to `spi_setup'
drivers/built-in.o:(.data+0x157c0): undefined reference to `spi_bus_type'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/mfd/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20090818.orig/drivers/mfd/Kconfig
+++ linux-next-20090818/drivers/mfd/Kconfig
@@ -240,6 +240,7 @@ config MFD_PCF50633
config MFD_MC13783
tristate "Support Freescale MC13783"
+ depends on SPI_MASTER
select MFD_CORE
help
Support for the Freescale (Atlas) MC13783 PMIC and audio CODEC.
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* Re: linux-next: suspend tree build failure
From: Paul Mundt @ 2009-08-18 22:13 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <200908182343.32375.rjw@sisk.pl>
On Tue, Aug 18, 2009 at 11:43:32PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 18 August 2009, Stephen Rothwell wrote:
> > Hi Rafael,
>
> Hi,
>
> > Today's linux-next build (i386 defconfig) failed like this:
> >
> > drivers/base/power/main.c: In function 'device_pm_init':
> > drivers/base/power/main.c:59: error: 'struct dev_pm_info' has no member named 'lock'
>
> Argh, that line shouldn't even be there.
>
> > Caused by commit ea8e84f27325d9ddc7692f728a10e0a22cd59f52 ("PM: Introduce
> > core framework for run-time PM of I/O devices (rev. 17)") from the
> > suspend tree. The i386 defconfig does not have CONFIG_PM_RUNTIME set but
> > does have CONFIG_PM_SLEEP=y ...
> >
> > I have reverted that commit for today.
> >
> > When you add a new CONFIG variable, it is worth doing test builds both
> > with it turned on and turned off ...
>
> I tested it, but I broke the patch afterwards by mistake. :-(
>
> Sorry for the trouble, I've just pushed an updated tree.
>
Argh, and rebased in the process, again. This is now the second time in
as many days this has been rebased, meaning I have to throw away my topic
branch and re-create. I thought this was going to remain stable? I would
like the SH runtime PM code to get some coverage in -next, but I can't
merge it in to my tree if the suspend tree keeps rebasing every day.
^ permalink raw reply
* Re: linux-next: suspend tree build failure
From: Rafael J. Wysocki @ 2009-08-18 21:43 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20090818183049.8bde1ee6.sfr@canb.auug.org.au>
On Tuesday 18 August 2009, Stephen Rothwell wrote:
> Hi Rafael,
Hi,
> Today's linux-next build (i386 defconfig) failed like this:
>
> drivers/base/power/main.c: In function 'device_pm_init':
> drivers/base/power/main.c:59: error: 'struct dev_pm_info' has no member named 'lock'
Argh, that line shouldn't even be there.
> Caused by commit ea8e84f27325d9ddc7692f728a10e0a22cd59f52 ("PM: Introduce
> core framework for run-time PM of I/O devices (rev. 17)") from the
> suspend tree. The i386 defconfig does not have CONFIG_PM_RUNTIME set but
> does have CONFIG_PM_SLEEP=y ...
>
> I have reverted that commit for today.
>
> When you add a new CONFIG variable, it is worth doing test builds both
> with it turned on and turned off ...
I tested it, but I broke the patch afterwards by mistake. :-(
Sorry for the trouble, I've just pushed an updated tree.
Thanks,
Rafael
^ permalink raw reply
* [PATCH V3 linux-next] treewide: remove unnecessary semicolons
From: Joe Perches @ 2009-08-18 18:18 UTC (permalink / raw)
To: Jiri Kosina; +Cc: LKML, linux-next
In-Reply-To: <alpine.LNX.2.00.0908181359450.25797@wotan.suse.de>
On Tue, 2009-08-18 at 14:00 +0200, Jiri Kosina wrote:
> On Thu, 13 Aug 2009, Joe Perches wrote:
> > > > Previous discussion at: http://lkml.org/lkml/2009/6/28/288
> > > > Signed-off-by: Joe Perches <joe@perches.com>
> > I could do that or you could "git apply --exclude=drivers/staging/"
> > Which do you prefer?
> It doesn't apply any more, could you please refresh, resend, and I will
> apply it right away?
I used git apply --reject --exclude=drivers/staging
Without staging:
Signed-off-by: Joe Perches <joe@perches.com>
arch/arm/mach-at91/at91cap9_devices.c | 2 +-
arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
arch/arm/mach-w90x900/w90p910.c | 2 +-
arch/arm/plat-mxc/irq.c | 2 +-
arch/s390/hypfs/inode.c | 2 +-
arch/s390/kvm/interrupt.c | 2 +-
arch/sparc/kernel/irq_64.c | 2 +-
arch/um/drivers/net_kern.c | 2 +-
drivers/block/DAC960.c | 4 ++--
drivers/block/swim3.c | 2 +-
drivers/char/epca.c | 2 +-
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/radeon/r300.c | 4 ++--
drivers/ide/ide-probe.c | 2 +-
drivers/ide/umc8672.c | 4 ++--
drivers/isdn/capi/capiutil.c | 2 +-
drivers/macintosh/rack-meter.c | 2 +-
drivers/net/arcnet/arc-rawmode.c | 1 -
drivers/net/arcnet/capmode.c | 1 -
drivers/net/gianfar_ethtool.c | 2 +-
drivers/net/ibm_newemac/core.c | 8 ++++----
drivers/net/igb/igb_main.c | 2 +-
drivers/net/ll_temac_main.c | 2 +-
drivers/net/ni52.c | 4 ++--
drivers/net/qlge/qlge_main.c | 4 ++--
drivers/net/skfp/pcmplc.c | 2 +-
drivers/net/skfp/pmf.c | 8 ++++----
drivers/net/skge.c | 2 +-
drivers/net/sky2.c | 2 +-
drivers/net/vxge/vxge-config.h | 2 +-
drivers/net/vxge/vxge-main.c | 2 +-
drivers/pcmcia/pcmcia_resource.c | 2 +-
drivers/rtc/rtc-omap.c | 2 +-
drivers/s390/block/dasd_eckd.c | 2 +-
drivers/s390/net/netiucv.c | 2 +-
drivers/s390/scsi/zfcp_scsi.c | 2 +-
drivers/scsi/bnx2i/bnx2i_hwi.c | 2 +-
drivers/scsi/lpfc/lpfc_ct.c | 2 +-
drivers/spi/omap_uwire.c | 2 +-
drivers/spi/spi_s3c24xx.c | 2 +-
drivers/usb/class/cdc-wdm.c | 2 --
drivers/usb/serial/spcp8x5.c | 2 +-
drivers/uwb/i1480/i1480u-wlp/netdev.c | 2 +-
drivers/video/cfbcopyarea.c | 2 +-
drivers/video/imxfb.c | 2 +-
drivers/video/s3c2410fb.c | 2 +-
drivers/xen/balloon.c | 2 +-
fs/autofs/dirhash.c | 2 +-
fs/btrfs/tree-log.c | 2 +-
fs/cifs/cifs_dfs_ref.c | 2 +-
fs/nfs/callback_xdr.c | 2 +-
fs/ocfs2/quota_global.c | 2 +-
include/scsi/fc/fc_fc2.h | 3 +--
kernel/trace/trace_hw_branches.c | 2 +-
net/wireless/wext-compat.c | 2 +-
sound/oss/sys_timer.c | 3 ---
sound/soc/codecs/wm9081.c | 2 +-
sound/soc/pxa/pxa-ssp.c | 2 +-
sound/soc/s3c24xx/s3c24xx_uda134x.c | 2 +-
59 files changed, 66 insertions(+), 74 deletions(-)
diff --git a/arch/arm/mach-at91/at91cap9_devices.c b/arch/arm/mach-at91/at91cap9_devices.c
index 412aa49..799c11e 100644
--- a/arch/arm/mach-at91/at91cap9_devices.c
+++ b/arch/arm/mach-at91/at91cap9_devices.c
@@ -171,7 +171,7 @@ void __init at91_add_device_usba(struct usba_platform_data *data)
*/
usba_udc_data.pdata.vbus_pin = -EINVAL;
usba_udc_data.pdata.num_ep = ARRAY_SIZE(usba_udc_ep);
- memcpy(usba_udc_data.ep, usba_udc_ep, sizeof(usba_udc_ep));;
+ memcpy(usba_udc_data.ep, usba_udc_ep, sizeof(usba_udc_ep));
if (data && data->vbus_pin > 0) {
at91_set_gpio_input(data->vbus_pin, 0);
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index 7281865..e87237b 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -99,7 +99,7 @@ void __init at91_add_device_usba(struct usba_platform_data *data)
*/
usba_udc_data.pdata.vbus_pin = -EINVAL;
usba_udc_data.pdata.num_ep = ARRAY_SIZE(usba_udc_ep);
- memcpy(usba_udc_data.ep, usba_udc_ep, sizeof(usba_udc_ep));;
+ memcpy(usba_udc_data.ep, usba_udc_ep, sizeof(usba_udc_ep));
if (data && data->vbus_pin > 0) {
at91_set_gpio_input(data->vbus_pin, 0);
diff --git a/arch/arm/mach-w90x900/w90p910.c b/arch/arm/mach-w90x900/w90p910.c
index 8444eab..57bcd1f 100644
--- a/arch/arm/mach-w90x900/w90p910.c
+++ b/arch/arm/mach-w90x900/w90p910.c
@@ -68,7 +68,7 @@ static DEFINE_CLK(emc, 7);
static DEFINE_SUBCLK(rmii, 2);
static DEFINE_CLK(usbd, 8);
static DEFINE_CLK(usbh, 9);
-static DEFINE_CLK(g2d, 10);;
+static DEFINE_CLK(g2d, 10);
static DEFINE_CLK(pwm, 18);
static DEFINE_CLK(ps2, 24);
static DEFINE_CLK(kpi, 25);
diff --git a/arch/arm/plat-mxc/irq.c b/arch/arm/plat-mxc/irq.c
index 8aee763..c2106d5 100644
--- a/arch/arm/plat-mxc/irq.c
+++ b/arch/arm/plat-mxc/irq.c
@@ -53,7 +53,7 @@ int imx_irq_set_priority(unsigned char irq, unsigned char prio)
unsigned int mask = 0x0F << irq % 8 * 4;
if (irq >= MXC_INTERNAL_IRQS)
- return -EINVAL;;
+ return -EINVAL;
temp = __raw_readl(avic_base + AVIC_NIPRIORITY(irq / 8));
temp &= ~mask;
diff --git a/arch/s390/hypfs/inode.c b/arch/s390/hypfs/inode.c
index 5a805df..ad0a1dd 100644
--- a/arch/s390/hypfs/inode.c
+++ b/arch/s390/hypfs/inode.c
@@ -500,7 +500,7 @@ static int __init hypfs_init(void)
}
s390_kobj = kobject_create_and_add("s390", hypervisor_kobj);
if (!s390_kobj) {
- rc = -ENOMEM;;
+ rc = -ENOMEM;
goto fail_sysfs;
}
rc = register_filesystem(&hypfs_type);
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 2c2f983..43486c2 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -478,7 +478,7 @@ int kvm_s390_inject_program_int(struct kvm_vcpu *vcpu, u16 code)
if (!inti)
return -ENOMEM;
- inti->type = KVM_S390_PROGRAM_INT;;
+ inti->type = KVM_S390_PROGRAM_INT;
inti->pgm.code = code;
VCPU_EVENT(vcpu, 3, "inject: program check %d (from kernel)", code);
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index f0ee790..ea183b9 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -229,7 +229,7 @@ static unsigned int sun4u_compute_tid(unsigned long imap, unsigned long cpuid)
tid = ((a << IMAP_AID_SHIFT) |
(n << IMAP_NID_SHIFT));
tid &= (IMAP_AID_SAFARI |
- IMAP_NID_SAFARI);;
+ IMAP_NID_SAFARI);
}
} else {
tid = cpuid << IMAP_TID_SHIFT;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 4c75409..9483c19 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -533,7 +533,7 @@ static int eth_parse(char *str, int *index_out, char **str_out,
char **error_out)
{
char *end;
- int n, err = -EINVAL;;
+ int n, err = -EINVAL;
n = simple_strtoul(str, &end, 0);
if (end == str) {
diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
index b839af1..26caa3f 100644
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -6653,7 +6653,7 @@ static long DAC960_gam_ioctl(struct file *file, unsigned int Request,
else ErrorCode = get_user(ControllerNumber,
&UserSpaceControllerInfo->ControllerNumber);
if (ErrorCode != 0)
- break;;
+ break;
ErrorCode = -ENXIO;
if (ControllerNumber < 0 ||
ControllerNumber > DAC960_ControllerCount - 1) {
@@ -6661,7 +6661,7 @@ static long DAC960_gam_ioctl(struct file *file, unsigned int Request,
}
Controller = DAC960_Controllers[ControllerNumber];
if (Controller == NULL)
- break;;
+ break;
memset(&ControllerInfo, 0, sizeof(DAC960_ControllerInfo_T));
ControllerInfo.ControllerNumber = ControllerNumber;
ControllerInfo.FirmwareType = Controller->FirmwareType;
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index 80df93e..572ec61 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -1062,7 +1062,7 @@ static int swim3_add_device(struct macio_dev *mdev, int index)
goto out_release;
}
fs->swim3_intr = macio_irq(mdev, 0);
- fs->dma_intr = macio_irq(mdev, 1);;
+ fs->dma_intr = macio_irq(mdev, 1);
fs->cur_cyl = -1;
fs->cur_sector = -1;
fs->secpercyl = 36;
diff --git a/drivers/char/epca.c b/drivers/char/epca.c
index ff647ca..9d589e3 100644
--- a/drivers/char/epca.c
+++ b/drivers/char/epca.c
@@ -2239,7 +2239,7 @@ static void do_softint(struct work_struct *work)
struct channel *ch = container_of(work, struct channel, tqueue);
/* Called in response to a modem change event */
if (ch && ch->magic == EPCA_MAGIC) {
- struct tty_struct *tty = tty_port_tty_get(&ch->port);;
+ struct tty_struct *tty = tty_port_tty_get(&ch->port);
if (tty && tty->driver_data) {
if (test_and_clear_bit(EPCA_EVENT_HANGUP, &ch->event)) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6770ae8..68d3f2c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -211,7 +211,7 @@ intel_dp_aux_ch(struct intel_output *intel_output,
for (try = 0; try < 5; try++) {
/* Load the send data into the aux channel data registers */
for (i = 0; i < send_bytes; i += 4) {
- uint32_t d = pack_aux(send + i, send_bytes - i);;
+ uint32_t d = pack_aux(send + i, send_bytes - i);
I915_WRITE(ch_data + i, d);
}
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 9c8d415..cd2f4c2 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1338,11 +1338,11 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
case 0x443C:
/* TX_FILTER0_[0-15] */
i = (reg - 0x4400) >> 2;
- tmp = ib_chunk->kdata[idx] & 0x7;;
+ tmp = ib_chunk->kdata[idx] & 0x7;
if (tmp == 2 || tmp == 4 || tmp == 6) {
track->textures[i].roundup_w = false;
}
- tmp = (ib_chunk->kdata[idx] >> 3) & 0x7;;
+ tmp = (ib_chunk->kdata[idx] >> 3) & 0x7;
if (tmp == 2 || tmp == 4 || tmp == 6) {
track->textures[i].roundup_h = false;
}
diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 1bb106f..20120fd 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -1201,7 +1201,7 @@ static int ide_find_port_slot(const struct ide_port_info *d)
{
int idx = -ENOENT;
u8 bootable = (d && (d->host_flags & IDE_HFLAG_NON_BOOTABLE)) ? 0 : 1;
- u8 i = (d && (d->host_flags & IDE_HFLAG_QD_2ND_PORT)) ? 1 : 0;;
+ u8 i = (d && (d->host_flags & IDE_HFLAG_QD_2ND_PORT)) ? 1 : 0;
/*
* Claim an unassigned slot.
diff --git a/drivers/ide/umc8672.c b/drivers/ide/umc8672.c
index 0608d41..60f936e 100644
--- a/drivers/ide/umc8672.c
+++ b/drivers/ide/umc8672.c
@@ -170,9 +170,9 @@ static int __init umc8672_init(void)
goto out;
if (umc8672_probe() == 0)
- return 0;;
+ return 0;
out:
- return -ENODEV;;
+ return -ENODEV;
}
module_init(umc8672_init);
diff --git a/drivers/isdn/capi/capiutil.c b/drivers/isdn/capi/capiutil.c
index 16f2e46..26626ee 100644
--- a/drivers/isdn/capi/capiutil.c
+++ b/drivers/isdn/capi/capiutil.c
@@ -1019,7 +1019,7 @@ int __init cdebug_init(void)
if (!g_debbuf->buf) {
kfree(g_cmsg);
kfree(g_debbuf);
- return -ENOMEM;;
+ return -ENOMEM;
}
g_debbuf->size = CDEBUG_GSIZE;
g_debbuf->buf[0] = 0;
diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c
index a98ab72..93fb320 100644
--- a/drivers/macintosh/rack-meter.c
+++ b/drivers/macintosh/rack-meter.c
@@ -274,7 +274,7 @@ static void __devinit rackmeter_init_cpu_sniffer(struct rackmeter *rm)
if (cpu > 1)
continue;
- rcpu = &rm->cpu[cpu];;
+ rcpu = &rm->cpu[cpu];
rcpu->prev_idle = get_cpu_idle_time(cpu);
rcpu->prev_wall = jiffies64_to_cputime64(get_jiffies_64());
schedule_delayed_work_on(cpu, &rm->cpu[cpu].sniffer,
diff --git a/drivers/net/arcnet/arc-rawmode.c b/drivers/net/arcnet/arc-rawmode.c
index 646dfc5..8ea9c75 100644
--- a/drivers/net/arcnet/arc-rawmode.c
+++ b/drivers/net/arcnet/arc-rawmode.c
@@ -123,7 +123,6 @@ static void rx(struct net_device *dev, int bufnum,
BUGLVL(D_SKB) arcnet_dump_skb(dev, skb, "rx");
skb->protocol = cpu_to_be16(ETH_P_ARCNET);
-;
netif_rx(skb);
}
diff --git a/drivers/net/arcnet/capmode.c b/drivers/net/arcnet/capmode.c
index 083e210..66bcbbb 100644
--- a/drivers/net/arcnet/capmode.c
+++ b/drivers/net/arcnet/capmode.c
@@ -149,7 +149,6 @@ static void rx(struct net_device *dev, int bufnum,
BUGLVL(D_SKB) arcnet_dump_skb(dev, skb, "rx");
skb->protocol = cpu_to_be16(ETH_P_ARCNET);
-;
netif_rx(skb);
}
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 2234118..6c144b5 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -293,7 +293,7 @@ static int gfar_gcoalesce(struct net_device *dev, struct ethtool_coalesce *cvals
rxtime = get_ictt_value(priv->rxic);
rxcount = get_icft_value(priv->rxic);
txtime = get_ictt_value(priv->txic);
- txcount = get_icft_value(priv->txic);;
+ txcount = get_icft_value(priv->txic);
cvals->rx_coalesce_usecs = gfar_ticks2usecs(priv, rxtime);
cvals->rx_max_coalesced_frames = rxcount;
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 5443558..635f122 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2557,13 +2557,13 @@ static int __devinit emac_init_config(struct emac_instance *dev)
if (emac_read_uint_prop(np, "mdio-device", &dev->mdio_ph, 0))
dev->mdio_ph = 0;
if (emac_read_uint_prop(np, "zmii-device", &dev->zmii_ph, 0))
- dev->zmii_ph = 0;;
+ dev->zmii_ph = 0;
if (emac_read_uint_prop(np, "zmii-channel", &dev->zmii_port, 0))
- dev->zmii_port = 0xffffffff;;
+ dev->zmii_port = 0xffffffff;
if (emac_read_uint_prop(np, "rgmii-device", &dev->rgmii_ph, 0))
- dev->rgmii_ph = 0;;
+ dev->rgmii_ph = 0;
if (emac_read_uint_prop(np, "rgmii-channel", &dev->rgmii_port, 0))
- dev->rgmii_port = 0xffffffff;;
+ dev->rgmii_port = 0xffffffff;
if (emac_read_uint_prop(np, "fifo-entry-size", &dev->fifo_entry_size, 0))
dev->fifo_entry_size = 16;
if (emac_read_uint_prop(np, "mal-burst-size", &dev->mal_burst_size, 0))
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index fb32735..d0bf634 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -3931,7 +3931,7 @@ static int igb_set_vf_multicasts(struct igb_adapter *adapter,
/* VFs are limited to using the MTA hash table for their multicast
* addresses */
for (i = 0; i < n; i++)
- vf_data->vf_mc_hashes[i] = hash_list[i];;
+ vf_data->vf_mc_hashes[i] = hash_list[i];
/* Flush and reset the mta with the new values */
igb_set_multi(adapter->netdev);
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index da8d0a0..f2a197f 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -865,7 +865,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
dcrs = dcr_resource_start(np, 0);
if (dcrs == 0) {
dev_err(&op->dev, "could not get DMA register address\n");
- goto nodev;;
+ goto nodev;
}
lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
diff --git a/drivers/net/ni52.c b/drivers/net/ni52.c
index a0ac5d4..fae0b2a 100644
--- a/drivers/net/ni52.c
+++ b/drivers/net/ni52.c
@@ -615,10 +615,10 @@ static int init586(struct net_device *dev)
/* addr_len |!src_insert |pre-len |loopback */
writeb(0x2e, &cfg_cmd->adr_len);
writeb(0x00, &cfg_cmd->priority);
- writeb(0x60, &cfg_cmd->ifs);;
+ writeb(0x60, &cfg_cmd->ifs);
writeb(0x00, &cfg_cmd->time_low);
writeb(0xf2, &cfg_cmd->time_high);
- writeb(0x00, &cfg_cmd->promisc);;
+ writeb(0x00, &cfg_cmd->promisc);
if (dev->flags & IFF_ALLMULTI) {
int len = ((char __iomem *)p->iscp - (char __iomem *)ptr - 8) / 6;
if (num_addrs > len) {
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 3a271af..511cd25 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -2659,7 +2659,7 @@ static int ql_start_rx_ring(struct ql_adapter *qdev, struct rx_ring *rx_ring)
FLAGS_LI; /* Load irq delay values */
if (rx_ring->lbq_len) {
cqicb->flags |= FLAGS_LL; /* Load lbq values */
- tmp = (u64)rx_ring->lbq_base_dma;;
+ tmp = (u64)rx_ring->lbq_base_dma;
base_indirect_ptr = (__le64 *) rx_ring->lbq_base_indirect;
page_entries = 0;
do {
@@ -2683,7 +2683,7 @@ static int ql_start_rx_ring(struct ql_adapter *qdev, struct rx_ring *rx_ring)
}
if (rx_ring->sbq_len) {
cqicb->flags |= FLAGS_LS; /* Load sbq values */
- tmp = (u64)rx_ring->sbq_base_dma;;
+ tmp = (u64)rx_ring->sbq_base_dma;
base_indirect_ptr = (__le64 *) rx_ring->sbq_base_indirect;
page_entries = 0;
do {
diff --git a/drivers/net/skfp/pcmplc.c b/drivers/net/skfp/pcmplc.c
index f1df2ec..e6b33ee 100644
--- a/drivers/net/skfp/pcmplc.c
+++ b/drivers/net/skfp/pcmplc.c
@@ -960,7 +960,7 @@ static void pcm_fsm(struct s_smc *smc, struct s_phy *phy, int cmd)
/*PC88b*/
if (!phy->cf_join) {
phy->cf_join = TRUE ;
- queue_event(smc,EVENT_CFM,CF_JOIN+np) ; ;
+ queue_event(smc,EVENT_CFM,CF_JOIN+np) ;
}
if (cmd == PC_JOIN)
GO_STATE(PC8_ACTIVE) ;
diff --git a/drivers/net/skfp/pmf.c b/drivers/net/skfp/pmf.c
index 79e665e..a320fdb 100644
--- a/drivers/net/skfp/pmf.c
+++ b/drivers/net/skfp/pmf.c
@@ -807,9 +807,9 @@ void smt_add_para(struct s_smc *smc, struct s_pcon *pcon, u_short para,
mib_p->fddiPORTLerFlag ;
sp->p4050_pad = 0 ;
sp->p4050_cutoff =
- mib_p->fddiPORTLer_Cutoff ; ;
+ mib_p->fddiPORTLer_Cutoff ;
sp->p4050_alarm =
- mib_p->fddiPORTLer_Alarm ; ;
+ mib_p->fddiPORTLer_Alarm ;
sp->p4050_estimate =
mib_p->fddiPORTLer_Estimate ;
sp->p4050_reject_ct =
@@ -829,7 +829,7 @@ void smt_add_para(struct s_smc *smc, struct s_pcon *pcon, u_short para,
sp->p4051_porttype =
mib_p->fddiPORTMy_Type ;
sp->p4051_connectstate =
- mib_p->fddiPORTConnectState ; ;
+ mib_p->fddiPORTConnectState ;
sp->p4051_pc_neighbor =
mib_p->fddiPORTNeighborType ;
sp->p4051_pc_withhold =
@@ -853,7 +853,7 @@ void smt_add_para(struct s_smc *smc, struct s_pcon *pcon, u_short para,
struct smt_p_4053 *sp ;
sp = (struct smt_p_4053 *) to ;
sp->p4053_multiple =
- mib_p->fddiPORTMultiple_P ; ;
+ mib_p->fddiPORTMultiple_P ;
sp->p4053_availablepaths =
mib_p->fddiPORTAvailablePaths ;
sp->p4053_currentpath =
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index 543af20..7b10fbb 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -215,7 +215,7 @@ static void skge_wol_init(struct skge_port *skge)
if (skge->wol & WAKE_MAGIC)
ctrl |= WOL_CTL_ENA_PME_ON_MAGIC_PKT|WOL_CTL_ENA_MAGIC_PKT_UNIT;
else
- ctrl |= WOL_CTL_DIS_PME_ON_MAGIC_PKT|WOL_CTL_DIS_MAGIC_PKT_UNIT;;
+ ctrl |= WOL_CTL_DIS_PME_ON_MAGIC_PKT|WOL_CTL_DIS_MAGIC_PKT_UNIT;
ctrl |= WOL_CTL_DIS_PME_ON_PATTERN|WOL_CTL_DIS_PATTERN_UNIT;
skge_write16(hw, WOL_REGS(port, WOL_CTRL_STAT), ctrl);
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 1415a83..a68d659 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -749,7 +749,7 @@ static void sky2_wol_init(struct sky2_port *sky2)
if (sky2->wol & WAKE_MAGIC)
ctrl |= WOL_CTL_ENA_PME_ON_MAGIC_PKT|WOL_CTL_ENA_MAGIC_PKT_UNIT;
else
- ctrl |= WOL_CTL_DIS_PME_ON_MAGIC_PKT|WOL_CTL_DIS_MAGIC_PKT_UNIT;;
+ ctrl |= WOL_CTL_DIS_PME_ON_MAGIC_PKT|WOL_CTL_DIS_MAGIC_PKT_UNIT;
ctrl |= WOL_CTL_DIS_PME_ON_PATTERN|WOL_CTL_DIS_PATTERN_UNIT;
sky2_write16(hw, WOL_REGS(port, WOL_CTRL_STAT), ctrl);
diff --git a/drivers/net/vxge/vxge-config.h b/drivers/net/vxge/vxge-config.h
index 62779a5..3e94f0c 100644
--- a/drivers/net/vxge/vxge-config.h
+++ b/drivers/net/vxge/vxge-config.h
@@ -1541,7 +1541,7 @@ void vxge_hw_ring_rxd_1b_info_get(
rxd_info->l4_cksum_valid =
(u32)VXGE_HW_RING_RXD_L4_CKSUM_CORRECT_GET(rxdp->control_0);
rxd_info->l4_cksum =
- (u32)VXGE_HW_RING_RXD_L4_CKSUM_GET(rxdp->control_0);;
+ (u32)VXGE_HW_RING_RXD_L4_CKSUM_GET(rxdp->control_0);
rxd_info->frame =
(u32)VXGE_HW_RING_RXD_ETHER_ENCAP_GET(rxdp->control_0);
rxd_info->proto =
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 094d155..f93963a 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -2352,7 +2352,7 @@ static int vxge_enable_msix(struct vxgedev *vdev)
enum vxge_hw_status status;
/* 0 - Tx, 1 - Rx */
int tim_msix_id[4];
- int alarm_msix_id = 0, msix_intr_vect = 0;;
+ int alarm_msix_id = 0, msix_intr_vect = 0;
vdev->intr_cnt = 0;
/* allocate msix vectors */
diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c
index f5d0ba8..8c2db2a 100644
--- a/drivers/pcmcia/pcmcia_resource.c
+++ b/drivers/pcmcia/pcmcia_resource.c
@@ -489,7 +489,7 @@ int pcmcia_request_configuration(struct pcmcia_device *p_dev,
pccard_io_map iomap;
if (!(s->state & SOCKET_PRESENT))
- return -ENODEV;;
+ return -ENODEV;
if (req->IntType & INT_CARDBUS) {
ds_dbg(p_dev->socket, 0, "IntType may not be INT_CARDBUS\n");
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index bd1ce8e..0587d53 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -430,7 +430,7 @@ fail:
static int __exit omap_rtc_remove(struct platform_device *pdev)
{
- struct rtc_device *rtc = platform_get_drvdata(pdev);;
+ struct rtc_device *rtc = platform_get_drvdata(pdev);
device_init_wakeup(&pdev->dev, 0);
diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
index a1ce573..bd9fe2e 100644
--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -706,7 +706,7 @@ static int dasd_eckd_generate_uid(struct dasd_device *device,
sizeof(uid->serial) - 1);
EBCASC(uid->serial, sizeof(uid->serial) - 1);
uid->ssid = private->gneq->subsystemID;
- uid->real_unit_addr = private->ned->unit_addr;;
+ uid->real_unit_addr = private->ned->unit_addr;
if (private->sneq) {
uid->type = private->sneq->sua_flags;
if (uid->type == UA_BASE_PAV_ALIAS)
diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index 890d86a..6572999 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -2114,7 +2114,7 @@ static ssize_t remove_write (struct device_driver *drv,
IUCV_DBF_TEXT(trace, 3, __func__);
if (count >= IFNAMSIZ)
- count = IFNAMSIZ - 1;;
+ count = IFNAMSIZ - 1;
for (i = 0, p = buf; i < count && *p; i++, p++) {
if (*p == '\n' || *p == ' ')
diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c
index 6925a17..9a70907 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -101,7 +101,7 @@ static int zfcp_scsi_queuecommand(struct scsi_cmnd *scpnt,
if (unlikely((status & ZFCP_STATUS_COMMON_ERP_FAILED) ||
!(status & ZFCP_STATUS_COMMON_RUNNING))) {
zfcp_scsi_command_fail(scpnt, DID_ERROR);
- return 0;;
+ return 0;
}
ret = zfcp_fsf_send_fcp_command_task(unit, scpnt);
diff --git a/drivers/scsi/bnx2i/bnx2i_hwi.c b/drivers/scsi/bnx2i/bnx2i_hwi.c
index 906cef5..41e1b0e 100644
--- a/drivers/scsi/bnx2i/bnx2i_hwi.c
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -1340,7 +1340,7 @@ static int bnx2i_process_login_resp(struct iscsi_session *session,
resp_hdr->opcode = login->op_code;
resp_hdr->flags = login->response_flags;
resp_hdr->max_version = login->version_max;
- resp_hdr->active_version = login->version_active;;
+ resp_hdr->active_version = login->version_active;
resp_hdr->hlength = 0;
hton24(resp_hdr->dlength, login->data_length);
diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 9df7ed3..9a1bd95 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -1207,7 +1207,7 @@ lpfc_ns_cmd(struct lpfc_vport *vport, int cmdcode,
vport->ct_flags &= ~FC_CT_RFF_ID;
CtReq->CommandResponse.bits.CmdRsp =
be16_to_cpu(SLI_CTNS_RFF_ID);
- CtReq->un.rff.PortId = cpu_to_be32(vport->fc_myDID);;
+ CtReq->un.rff.PortId = cpu_to_be32(vport->fc_myDID);
CtReq->un.rff.fbits = FC4_FEATURE_INIT;
CtReq->un.rff.type_code = FC_FCP_DATA;
cmpl = lpfc_cmpl_ct_cmd_rff_id;
diff --git a/drivers/spi/omap_uwire.c b/drivers/spi/omap_uwire.c
index 8980a56..e75ba9b 100644
--- a/drivers/spi/omap_uwire.c
+++ b/drivers/spi/omap_uwire.c
@@ -213,7 +213,7 @@ static int uwire_txrx(struct spi_device *spi, struct spi_transfer *t)
unsigned bits = ust->bits_per_word;
unsigned bytes;
u16 val, w;
- int status = 0;;
+ int status = 0;
if (!t->tx_buf && !t->rx_buf)
return 0;
diff --git a/drivers/spi/spi_s3c24xx.c b/drivers/spi/spi_s3c24xx.c
index e0d44af..9253cab 100644
--- a/drivers/spi/spi_s3c24xx.c
+++ b/drivers/spi/spi_s3c24xx.c
@@ -385,7 +385,7 @@ static int __init s3c24xx_spi_probe(struct platform_device *pdev)
err_no_iores:
err_no_pdata:
- spi_master_put(hw->master);;
+ spi_master_put(hw->master);
err_nomem:
return err;
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index ba589d4..8c64c01 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -506,8 +506,6 @@ static int wdm_open(struct inode *inode, struct file *file)
desc = usb_get_intfdata(intf);
if (test_bit(WDM_DISCONNECTING, &desc->flags))
goto out;
-
- ;
file->private_data = desc;
rv = usb_autopm_get_interface(desc->intf);
diff --git a/drivers/usb/serial/spcp8x5.c b/drivers/usb/serial/spcp8x5.c
index 61e7c40..1e58220 100644
--- a/drivers/usb/serial/spcp8x5.c
+++ b/drivers/usb/serial/spcp8x5.c
@@ -544,7 +544,7 @@ static void spcp8x5_set_termios(struct tty_struct *tty,
}
/* Set Baud Rate */
- baud = tty_get_baud_rate(tty);;
+ baud = tty_get_baud_rate(tty);
switch (baud) {
case 300: buf[0] = 0x00; break;
case 600: buf[0] = 0x01; break;
diff --git a/drivers/uwb/i1480/i1480u-wlp/netdev.c b/drivers/uwb/i1480/i1480u-wlp/netdev.c
index 7305553..b236e69 100644
--- a/drivers/uwb/i1480/i1480u-wlp/netdev.c
+++ b/drivers/uwb/i1480/i1480u-wlp/netdev.c
@@ -214,7 +214,7 @@ int i1480u_open(struct net_device *net_dev)
netif_wake_queue(net_dev);
#ifdef i1480u_FLOW_CONTROL
- result = usb_submit_urb(i1480u->notif_urb, GFP_KERNEL);;
+ result = usb_submit_urb(i1480u->notif_urb, GFP_KERNEL);
if (result < 0) {
dev_err(dev, "Can't submit notification URB: %d\n", result);
goto error_notif_urb_submit;
diff --git a/drivers/video/cfbcopyarea.c b/drivers/video/cfbcopyarea.c
index df03f37..79e5f40 100644
--- a/drivers/video/cfbcopyarea.c
+++ b/drivers/video/cfbcopyarea.c
@@ -114,7 +114,7 @@ bitcpy(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
d0 >>= right;
} else if (src_idx+n <= bits) {
// Single source word
- d0 <<= left;;
+ d0 <<= left;
} else {
// 2 source words
d1 = FB_READL(src + 1);
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 15a0ee6..89e6f1e 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -677,7 +677,7 @@ static int __init imxfb_probe(struct platform_device *pdev)
fbi->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(fbi->clk)) {
- ret = PTR_ERR(fbi->clk);;
+ ret = PTR_ERR(fbi->clk);
dev_err(&pdev->dev, "unable to get clock: %d\n", ret);
goto failed_getclock;
}
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 7da0027..5ffca2a 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -1119,7 +1119,7 @@ int __init s3c2410fb_init(void)
int ret = platform_driver_register(&s3c2410fb_driver);
if (ret == 0)
- ret = platform_driver_register(&s3c2412fb_driver);;
+ ret = platform_driver_register(&s3c2412fb_driver);
return ret;
}
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index f5bbd9e..4d1b322 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -214,7 +214,7 @@ static int increase_reservation(unsigned long nr_pages)
page = balloon_first_page();
for (i = 0; i < nr_pages; i++) {
BUG_ON(page == NULL);
- frame_list[i] = page_to_pfn(page);;
+ frame_list[i] = page_to_pfn(page);
page = balloon_next_page(page);
}
diff --git a/fs/autofs/dirhash.c b/fs/autofs/dirhash.c
index 2316e94..e947915 100644
--- a/fs/autofs/dirhash.c
+++ b/fs/autofs/dirhash.c
@@ -90,7 +90,7 @@ struct autofs_dir_ent *autofs_expire(struct super_block *sb,
DPRINTK(("autofs: not expirable (not a mounted directory): %s\n", ent->name));
continue;
}
- while (d_mountpoint(path.dentry) && follow_down(&path));
+ while (d_mountpoint(path.dentry) && follow_down(&path))
;
umount_ok = may_umount(path.mnt);
path_put(&path);
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index d91b0de..30c0d45 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2605,7 +2605,7 @@ static noinline int copy_items(struct btrfs_trans_handle *trans,
extent);
cs = btrfs_file_extent_offset(src, extent);
cl = btrfs_file_extent_num_bytes(src,
- extent);;
+ extent);
if (btrfs_file_extent_compression(src,
extent)) {
cs = 0;
diff --git a/fs/cifs/cifs_dfs_ref.c b/fs/cifs/cifs_dfs_ref.c
index 606912d..5e8bc99 100644
--- a/fs/cifs/cifs_dfs_ref.c
+++ b/fs/cifs/cifs_dfs_ref.c
@@ -142,7 +142,7 @@ char *cifs_compose_mount_options(const char *sb_mountdata,
rc = dns_resolve_server_name_to_ip(*devname, &srvIP);
if (rc != 0) {
cERROR(1, ("%s: Failed to resolve server part of %s to IP: %d",
- __func__, *devname, rc));;
+ __func__, *devname, rc));
goto compose_mount_options_err;
}
/* md_len = strlen(...) + 12 for 'sep+prefixpath='
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index e5a2dac..76b0aa0 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -222,7 +222,7 @@ static unsigned decode_sessionid(struct xdr_stream *xdr,
p = read_buf(xdr, len);
if (unlikely(p == NULL))
- return htonl(NFS4ERR_RESOURCE);;
+ return htonl(NFS4ERR_RESOURCE);
memcpy(sid->data, p, len);
return 0;
diff --git a/fs/ocfs2/quota_global.c b/fs/ocfs2/quota_global.c
index d604a6a..18bc7a2 100644
--- a/fs/ocfs2/quota_global.c
+++ b/fs/ocfs2/quota_global.c
@@ -144,7 +144,7 @@ static int ocfs2_get_quota_block(struct inode *inode, int block,
err = -EIO;
mlog_errno(err);
}
- return err;;
+ return err;
}
/* Read data from global quotafile - avoid pagecache and such because we cannot
diff --git a/include/scsi/fc/fc_fc2.h b/include/scsi/fc/fc_fc2.h
index cff8a8c..f87777d 100644
--- a/include/scsi/fc/fc_fc2.h
+++ b/include/scsi/fc/fc_fc2.h
@@ -92,8 +92,7 @@ struct fc_esb {
__u8 _esb_resvd[4];
__u8 esb_service_params[112]; /* TBD */
__u8 esb_seq_status[8]; /* sequence statuses, 8 bytes each */
-} __attribute__((packed));;
-
+} __attribute__((packed));
/*
* Define expected size for ASSERTs.
diff --git a/kernel/trace/trace_hw_branches.c b/kernel/trace/trace_hw_branches.c
index ca7d7c4..23b6385 100644
--- a/kernel/trace/trace_hw_branches.c
+++ b/kernel/trace/trace_hw_branches.c
@@ -155,7 +155,7 @@ static enum print_line_t bts_trace_print_line(struct trace_iterator *iter)
seq_print_ip_sym(seq, it->from, symflags) &&
trace_seq_printf(seq, "\n"))
return TRACE_TYPE_HANDLED;
- return TRACE_TYPE_PARTIAL_LINE;;
+ return TRACE_TYPE_PARTIAL_LINE;
}
return TRACE_TYPE_UNHANDLED;
}
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index e4e90e2..a3d47f3 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -860,7 +860,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
return 0;
}
- return rdev->ops->set_tx_power(wdev->wiphy, type, dbm);;
+ return rdev->ops->set_tx_power(wdev->wiphy, type, dbm);
}
EXPORT_SYMBOL_GPL(cfg80211_wext_siwtxpower);
diff --git a/sound/oss/sys_timer.c b/sound/oss/sys_timer.c
index 1075344..8db6aef 100644
--- a/sound/oss/sys_timer.c
+++ b/sound/oss/sys_timer.c
@@ -100,9 +100,6 @@ def_tmr_open(int dev, int mode)
curr_tempo = 60;
curr_timebase = 100;
opened = 1;
-
- ;
-
{
def_tmr.expires = (1) + jiffies;
add_timer(&def_tmr);
diff --git a/sound/soc/codecs/wm9081.c b/sound/soc/codecs/wm9081.c
index 156f2a4..97f9231 100644
--- a/sound/soc/codecs/wm9081.c
+++ b/sound/soc/codecs/wm9081.c
@@ -1087,7 +1087,7 @@ static int wm9081_hw_params(struct snd_pcm_substream *substream,
- wm9081->fs);
for (i = 1; i < ARRAY_SIZE(clk_sys_rates); i++) {
cur_val = abs((wm9081->sysclk_rate /
- clk_sys_rates[i].ratio) - wm9081->fs);;
+ clk_sys_rates[i].ratio) - wm9081->fs);
if (cur_val < best_val) {
best = i;
best_val = cur_val;
diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
index e22c5ce..e7ee83e 100644
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@ -351,7 +351,7 @@ static int pxa_ssp_set_dai_pll(struct snd_soc_dai *cpu_dai,
do_div(tmp, freq_out);
val = tmp;
- val = (val << 16) | 64;;
+ val = (val << 16) | 64;
ssp_write_reg(ssp, SSACDD, val);
ssacd |= (0x6 << 4);
diff --git a/sound/soc/s3c24xx/s3c24xx_uda134x.c b/sound/soc/s3c24xx/s3c24xx_uda134x.c
index 8e79a41..c215d32 100644
--- a/sound/soc/s3c24xx/s3c24xx_uda134x.c
+++ b/sound/soc/s3c24xx/s3c24xx_uda134x.c
@@ -67,7 +67,7 @@ static int s3c24xx_uda134x_startup(struct snd_pcm_substream *substream)
{
int ret = 0;
#ifdef ENFORCE_RATES
- struct snd_pcm_runtime *runtime = substream->runtime;;
+ struct snd_pcm_runtime *runtime = substream->runtime;
#endif
mutex_lock(&clk_lock);
^ permalink raw reply related
* Re: linux-next: usb/pxa trees build failure
From: Greg KH @ 2009-08-18 14:58 UTC (permalink / raw)
To: Eric Miao
Cc: Stephen Rothwell, linux-next, linux-kernel, Aric D. Blumer,
Mike Rapoport, Russell King
In-Reply-To: <4A8AB525.7050404@gmail.com>
On Tue, Aug 18, 2009 at 10:05:25PM +0800, Eric Miao wrote:
> Greg KH wrote:
> > On Tue, Aug 18, 2009 at 01:58:52PM +1000, Stephen Rothwell wrote:
> >> Hi Eric, Greg,
> >>
> >> The next-20090817 (and a few before) build (arm trizeps4_defconfig)
> >> failed like this:
> >>
> >> drivers/usb/host/ohci-pxa27x.c:507: error: 'pdev' undeclared (first use in this function)
> >>
> >> Caused by the interaction of commit
> >> 6458baec17e19d38b9d4eb1f96c213f91609c0e3 ("USB: ohci-pxa27x: Reconfigure
> >> power settings on resume") from the usb tree with commit
> >> b8fb7d4317bcea1b48c9560d23dff81121870ece ("[ARM] pxa: update
> >> ohci-pxa27x.c to use 'struct dev_pm_ops'"). from the pxa tree.
> >>
> >> Greg/Aric, maybe that usb tree patch needs to go through the pxa tree?
> >> (and maybe "USB: ohci-pxa27x: Allow NOCP and OCPM to be cleared" as well?)
> >>
> >> [this also broke the following configs: magician_defconfig,
> >> em_x270_defconfig and cm_x2xx_defconfig.]
> >
> > Ick, not good. Aric, should I drop this patch from my tree?
> >
>
> I think so, might be better to go through the pxa tree so that I can give
> another review. (the fiber across the pacific seems to be broken again, so
> I have to look into this tomorrow, still fetching -next, sigh).
Ok, let me know if you want me to drop these patches from my tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [S390] ftrace: update system call tracer support
From: Jason Baron @ 2009-08-18 14:56 UTC (permalink / raw)
To: Ingo Molnar
Cc: Paul Mundt, Stephen Rothwell, Frederic Weisbecker, LKML,
Lai Jiangshan, Steven Rostedt, Peter Zijlstra, Mathieu Desnoyers,
Jiaying Zhang, Martin Bligh, Li Zefan, Masami Hiramatsu,
Martin Schwidefsky, Wu Zhangjin, linux-next, Heiko Carstens
In-Reply-To: <20090818085110.GA2074@elte.hu>
On Tue, Aug 18, 2009 at 10:51:10AM +0200, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > * Paul Mundt <lethal@linux-sh.org> wrote:
> >
> > > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
> > >
> > > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > > > This pull request integrate one cleanup/fix for ftrace and an
> > > > > update for syscall tracing: the migration from old-style tracer to
> > > > > individual tracepoints/trace_events and the support for perf
> > > > > counter.
> > > > >
> > > > > I've tested it with success either with ftrace (every syscall
> > > > > tracepoints enabled at the same time without problems) and with
> > > > > perfcounter.
> > > > >
> > > > > May be one drawback: it creates so much trace events that the
> > > > > ftrace selftests can take some time :-)
> > > >
> > > > Pulled, thanks a lot!
> > >
> > > And this has now subsequently broken every single SH and S390
> > > configuration, [...]
> >
> > I test SH cross-builds regularly. I just checked the SH defconfig
> > and it builds just fine here:
> >
> > $ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
>
> The s390 build indeed broke. (This got masked by the s390 toolchain
> i'm using not having been able to build Linus's tree - i fixed
> that.)
>
> Could you try the fix below? It does the trick here.
>
> Martin, Heiko - does the fix look good to you? regs->gprs[2] seems
> to be the register used for both the syscall number (enter
> callback) and for the return code (exit callback).
>
> Regarding SH, the fixup should be similarly trivial. Since SH's
> FTRACE_SYSCALLS code is not upstream yet it can (and should) be
> carried in the tree that integrates the SH tree and the tracing
> tree - linux-next in this case.
>
> Thanks,
>
> Ingo
>
> ------------------------------>
> From a9008fd42b1c3c89f684d90bdfb9c2d05c7af119 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@elte.hu>
> Date: Tue, 18 Aug 2009 10:41:57 +0200
> Subject: [PATCH] [S390] ftrace: update system call tracer support
>
> Commit fb34a08c3 ("tracing: Add trace events for each syscall
> entry/exit") changed the lowlevel API to ftrace syscall tracing
> but did not update s390 which started making use of it recently.
>
> This broke the s390 build, as reported by Paul Mundt.
>
> Update the callbacks with the syscall number and the syscall
> return code values. This allows per syscall tracepoints,
> syscall argument enumeration /debug/tracing/events/syscalls/
> and perfcounters support and integration on s390 too.
>
> Reported-by: Paul Mundt <lethal@linux-sh.org>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Jason Baron <jbaron@redhat.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> LKML-Reference: <tip-fb34a08c3469b2be9eae626ccb96476b4687b810@git.kernel.org>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> arch/s390/kernel/ptrace.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
> index 43acd73..05f57cd 100644
> --- a/arch/s390/kernel/ptrace.c
> +++ b/arch/s390/kernel/ptrace.c
> @@ -662,7 +662,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
> }
>
> if (unlikely(test_thread_flag(TIF_SYSCALL_FTRACE)))
> - ftrace_syscall_enter(regs);
> + trace_syscall_enter(regs, regs->gprs[2]);
>
> if (unlikely(current->audit_context))
> audit_syscall_entry(is_compat_task() ?
> @@ -680,7 +680,7 @@ asmlinkage void do_syscall_trace_exit(struct pt_regs *regs)
> regs->gprs[2]);
>
> if (unlikely(test_thread_flag(TIF_SYSCALL_FTRACE)))
> - ftrace_syscall_exit(regs);
> + trace_syscall_exit(regs, regs->gprs[2]);
>
> if (test_thread_flag(TIF_SYSCALL_TRACE))
> tracehook_report_syscall_exit(regs, 0);
thanks for fixing this up Ingo! Sorry for all the trouble.
perhaps, we should just reduce the entry/exit routines to just pass
'regs' since we already have the following abstractions for callbacks:
syscall_get_nr(current, regs);
syscall_get_return_value(current, regs);
Thus, we really only need to be passing 'regs'. I was passing more information
here, to make it easier for other users of the tracepoints...
thanks,
-Jason
^ permalink raw reply
* Re: linux-next: usb/pxa trees build failure
From: Eric Miao @ 2009-08-18 14:05 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Eric Miao, linux-next, linux-kernel,
Aric D. Blumer, Mike Rapoport, Russell King
In-Reply-To: <20090818114242.GA28534@kroah.com>
Greg KH wrote:
> On Tue, Aug 18, 2009 at 01:58:52PM +1000, Stephen Rothwell wrote:
>> Hi Eric, Greg,
>>
>> The next-20090817 (and a few before) build (arm trizeps4_defconfig)
>> failed like this:
>>
>> drivers/usb/host/ohci-pxa27x.c:507: error: 'pdev' undeclared (first use in this function)
>>
>> Caused by the interaction of commit
>> 6458baec17e19d38b9d4eb1f96c213f91609c0e3 ("USB: ohci-pxa27x: Reconfigure
>> power settings on resume") from the usb tree with commit
>> b8fb7d4317bcea1b48c9560d23dff81121870ece ("[ARM] pxa: update
>> ohci-pxa27x.c to use 'struct dev_pm_ops'"). from the pxa tree.
>>
>> Greg/Aric, maybe that usb tree patch needs to go through the pxa tree?
>> (and maybe "USB: ohci-pxa27x: Allow NOCP and OCPM to be cleared" as well?)
>>
>> [this also broke the following configs: magician_defconfig,
>> em_x270_defconfig and cm_x2xx_defconfig.]
>
> Ick, not good. Aric, should I drop this patch from my tree?
>
I think so, might be better to go through the pxa tree so that I can give
another review. (the fiber across the pacific seems to be broken again, so
I have to look into this tomorrow, still fetching -next, sigh).
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Ingo Molnar @ 2009-08-18 12:13 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817.170337.139340805.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Tue, 18 Aug 2009 01:06:54 +0200
>
> > ... but these are the wrong patches, they should be removed or
> > reverted and redone properly.
>
> Given the number of users of net-next-2.6, removal via rebasing
> is simply not an option. The other two posibilities, sure...
>
> > It's not just about keeping kernel/trace/* changes in the
> > tracing tree (which we can relax on-demand given agreement),
> > it's that these patches are also _wrong_ and we cannot relax
> > anything about that.
>
> Why don't we give Neil a chance to review the situation and fix
> things up?
>
> If revert is the final decision, that's fine, I'll revert
> everything.
>
> But in the mean time at least give Neil a chance to read all of
> your feedback and coordinate a way to fix things with everyone.
Oh, sure. Conversion to TRACE_EVENT() is equivalent to the revert
of the current patches plus introduction of the TRACE_EVENT()
defines.
Ingo
^ permalink raw reply
* Re: [GIT PULL] tracing: Syscalls trace events + perf support
From: Paul Mundt @ 2009-08-18 11:56 UTC (permalink / raw)
To: Ingo Molnar
Cc: Frederic Weisbecker, Stephen Rothwell, Jason Baron, LKML,
Lai Jiangshan, Steven Rostedt, Peter Zijlstra, Mathieu Desnoyers,
Jiaying Zhang, Martin Bligh, Li Zefan, Masami Hiramatsu,
Martin Schwidefsky, Wu Zhangjin, linux-next
In-Reply-To: <20090818110616.GA20070@elte.hu>
On Tue, Aug 18, 2009 at 01:06:16PM +0200, Ingo Molnar wrote:
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > I've just retrieved the concerned commit in the sh tree:
> >
> > sh: Add ftrace syscall tracing support
> > (c652d780c9cf7f860141de232b37160fe013feca)
> >
> > Was I cc'ed on this one? I can't find it in my inbox. Unless I'm
> > wrong and I missed it, how could I guess I had to cc you and how
> > am I supposed to fix something I'm even not aware of?
> >
> > I can't find the s390 patch in my inbox either (was I cc'ed ?)
> > ([S390] ftrace: add system call tracer support) but we should
> > have fixed this one because it was already upstream and a
> > git-grep ftrace_syscall_enter would have warned us about that.
> >
> > I didn't know another arch was supporting syscall tracing (except
> > mips because I was cc'ed, but it doesn't seem upstream nor in the
> > mips tree).
>
> Yes, and note that Paul Mundt has not even done the minimal
> courtesy of describing/pasting the build failure he was seeing. But
> he had time for a 4-paragraph rant about how others are supposed to
> do their work... And then he complains about us not having
> considered a change he never Cc:-ed to us. How nice.
>
I explained that all -next builds had broken due to that tree being
pulled in, which I assumed was sufficient. None of my initial post was
suggesting that there was a problem with making changes to the interfaces
or that I expected anyone else to fix them up for me, it is more just
general frustration at how often people blindly push things out to -next
without checking what impact that is going to have on the already merged
trees. This is not just -tip specific, and indeed most of my posts to the
-next list are fixing up these sorts of build bugs caused by other
people's trees.
> This reply from Paul Mundt shows an _incredibly_ arrogant attitude
> towards core kernel facilities: he almost never contributes to them
> (i just checked the logs from v2.6.12 to v2.6.31-rc6) but _THEY_
> must do everything to keep SH running smoothly.
>
I don't think that's a fair generalization. Naturally the vast majority
of my work is in my own architecture, and I send patches for core bits
when we run in to trouble, have to extend certain parts of
infrastructure, discover something is broken whilst wiring up support for
a few feature, etc, etc. And this actually happens quite regularly, so
I'm unsure as to where you get your statistics from.
> And he expects that work to benefit SH to happen regardless of how
> many actual Linux users use, develop on and report bugs from SH.
> Where's the many SH crash reports on kerneloops.org? I see _not a
> single SH report_, out of more than 200,000 kernel oopses reported
> and categorized ... Why?
>
I have enough trouble getting people to submit oopses at all, and the
ones that we do get are most often in the architecture code, so there's
little interest to kerneloops.org. Likewise, issues that we hit with
common code during development we try to debug and send patches for long
before it becomes anyone elses problem.
> The thing is, as things stand today SH is basically freeloding on
> the hard work, testing and core kernel work of other architectures
> - which is fine in itself - what is not fine is to is to then
> complain in an unacceptable tone about bugs that affect SH.
>
This is complete and utter nonsense. SH is one of the only embedded
architectures that aggressively implements and tests new kernel features,
and we send out patches for any issues we run in to on a pretty much
constant basis. Beyond that, most of the patches I send to -next are
fixing up issues introduced by other people that have negative
implications for architectures, and I try to subsequently take care of
those as quickly as possible. The core kernel work we do focus on happens
within that particular subsystem itself, so perhaps there is not so much
visibility outside of that context.
Regarding the ftrace syscall stuff, you did not just break one
architecture, you effectively broke all of them that weren't x86, and
this tends to be unfortunately more of a common trend than an odd
exception. Of course that is a natural part of development, and as long
as things are gradually fixed up it's really not that big of a deal. No
one expects instant fixes all around, the issue is more that no one is
paying attention to what impact these changes will have on others. In
this case we could have Cced you on the ftrace changes we made in the
sh tree so you had been aware of it, but this largely ignores the point.
I don't Cc people when we add new features on the architecture side as
for the most part, and I expect this is the case for most architecture
maintainers. How many times are architecture people told to grovel
around some -tip topic branch before making any changes in their own
trees? If architecture people have to poke around -tip to try and keep
things moving along, I don't think its unrealistic to expect -tip people
to pay attention to the things that are already on-going in linux-next
before merging things.
My "hostility" towards core kernel features tends to be inversely
proportional to how embedded architectures are treated by core kernel
people. We effectively have to fight for every minor change, and are
either dismissed out of hand or regarded with contempt when attempting to
push core changes through. One hardly has to look very long to find your
postings that routinely throw this 95% figure around for example. Folks
complain about embedded architectures not contributing, and then when
they do, this is the end result. As an embedded architecture maintainer I
resigned myself years ago to the fact that I would spend most of my time
outside of my own architecture directory fixing up other peoples code,
and it's only the rare times when this results in opposition -- largely
involving the -tip tree as of late. I even asked you directly how we can
fix this workflow issue in my initial mail, which you completely ignored.
In any event, if all of this constitutes freeloading, then there seems to
be very little point in carrying on dialogue. I'll just pull in the
tracing/core bits in to a topic branch and fix my platform up, as usual.
^ permalink raw reply
* Re: linux-next: usb/pxa trees build failure
From: Greg KH @ 2009-08-18 11:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Eric Miao, linux-next, linux-kernel, Aric D. Blumer,
Mike Rapoport, Russell King
In-Reply-To: <20090818135852.0b3b648d.sfr@canb.auug.org.au>
On Tue, Aug 18, 2009 at 01:58:52PM +1000, Stephen Rothwell wrote:
> Hi Eric, Greg,
>
> The next-20090817 (and a few before) build (arm trizeps4_defconfig)
> failed like this:
>
> drivers/usb/host/ohci-pxa27x.c:507: error: 'pdev' undeclared (first use in this function)
>
> Caused by the interaction of commit
> 6458baec17e19d38b9d4eb1f96c213f91609c0e3 ("USB: ohci-pxa27x: Reconfigure
> power settings on resume") from the usb tree with commit
> b8fb7d4317bcea1b48c9560d23dff81121870ece ("[ARM] pxa: update
> ohci-pxa27x.c to use 'struct dev_pm_ops'"). from the pxa tree.
>
> Greg/Aric, maybe that usb tree patch needs to go through the pxa tree?
> (and maybe "USB: ohci-pxa27x: Allow NOCP and OCPM to be cleared" as well?)
>
> [this also broke the following configs: magician_defconfig,
> em_x270_defconfig and cm_x2xx_defconfig.]
Ick, not good. Aric, should I drop this patch from my tree?
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] tracing: Syscalls trace events + perf support
From: Ingo Molnar @ 2009-08-18 11:06 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Paul Mundt, Stephen Rothwell, Jason Baron, LKML, Lai Jiangshan,
Steven Rostedt, Peter Zijlstra, Mathieu Desnoyers, Jiaying Zhang,
Martin Bligh, Li Zefan, Masami Hiramatsu, Martin Schwidefsky,
Wu Zhangjin, linux-next
In-Reply-To: <20090818102507.GA5231@nowhere>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Tue, Aug 18, 2009 at 09:46:55AM +0900, Paul Mundt wrote:
> > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
> >
> > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > > This pull request integrate one cleanup/fix for ftrace and an
> > > > update for syscall tracing: the migration from old-style tracer to
> > > > individual tracepoints/trace_events and the support for perf
> > > > counter.
> > > >
> > > > I've tested it with success either with ftrace (every syscall
> > > > tracepoints enabled at the same time without problems) and with
> > > > perfcounter.
> > > >
> > > > May be one drawback: it creates so much trace events that the
> > > > ftrace selftests can take some time :-)
> > >
> > > Pulled, thanks a lot!
> >
> > And this has now subsequently broken every single SH and S390
> > configuration, and anyone else unfortunate enough to be
> > supporting ftrace syscall tracing that isn't x86, without so
> > much as a Cc, well done!
> >
> > The s390 case can be fixed up in-tree as support has already
> > been merged, but in the SH case we had ftrace syscall tracing
> > queued up for 2.6.32, so it doesn't show up in -tip, but the
> > end result in -next is now completely broken.
> >
> > I'm not sure how we should handle this, if tracing/core in -tip
> > isn't rebased, should I just pull the topic-branch in to my
> > tree, fix up the sh support on top of that, and push the end
> > result out? This seems like the easiest option at least, but I
> > don't know what other dependencies exist for tracing/core.
> > Alternative suggestions welcome.
> >
> > This happens again and again with ftrace and -tip, where people
> > just randomly change existing interfaces, break all of the
> > existing users, and then fail to tell anyone about it until it
> > shows up in -next. Even if we had pushed all of the sh ftrace
> > bits to the -tip tree early on it would not have changed
> > anything, evident by the fact that s390 and all of the non
> > ftrace syscall architectures were broken by this change as well
> > (the latter case was at least caught and corrected, although
> > not by the original authors of this patch series). Is it really
> > that much to task that people who are running around breaking
> > ftrace interfaces actually bother to Cc the architectures that
> > are using it?
>
> I've just retrieved the concerned commit in the sh tree:
>
> sh: Add ftrace syscall tracing support
> (c652d780c9cf7f860141de232b37160fe013feca)
>
> Was I cc'ed on this one? I can't find it in my inbox. Unless I'm
> wrong and I missed it, how could I guess I had to cc you and how
> am I supposed to fix something I'm even not aware of?
>
> I can't find the s390 patch in my inbox either (was I cc'ed ?)
> ([S390] ftrace: add system call tracer support) but we should
> have fixed this one because it was already upstream and a
> git-grep ftrace_syscall_enter would have warned us about that.
>
> I didn't know another arch was supporting syscall tracing (except
> mips because I was cc'ed, but it doesn't seem upstream nor in the
> mips tree).
Yes, and note that Paul Mundt has not even done the minimal
courtesy of describing/pasting the build failure he was seeing. But
he had time for a 4-paragraph rant about how others are supposed to
do their work... And then he complains about us not having
considered a change he never Cc:-ed to us. How nice.
( I have meanwhile fixed the bug in s390 and have posted that fix -
the SH fix should be an analogous twoliner. )
This reply from Paul Mundt shows an _incredibly_ arrogant attitude
towards core kernel facilities: he almost never contributes to them
(i just checked the logs from v2.6.12 to v2.6.31-rc6) but _THEY_
must do everything to keep SH running smoothly.
And he expects that work to benefit SH to happen regardless of how
many actual Linux users use, develop on and report bugs from SH.
Where's the many SH crash reports on kerneloops.org? I see _not a
single SH report_, out of more than 200,000 kernel oopses reported
and categorized ... Why?
The thing is, as things stand today SH is basically freeloding on
the hard work, testing and core kernel work of other architectures
- which is fine in itself - what is not fine is to is to then
complain in an unacceptable tone about bugs that affect SH.
Of course SH never causes core kernel bugs because it essentially
does no core kernel work at all!
Paul seems to think that freeloading upon 10 million lines of code
coupled with loud, self-sure demands for instant fixes is fine, and
dare anyone trying to advance Linux break the build of a single
architecture out of 22!
Other architectures, powerpc, s390, sparc, x86 etc. all do lots of
core kernel work and make sure it's all nicely reciprocal and
friendly. SH needs to stop the whining and needs to start helping
out for real - or it can get unmerged and go out of tree if it does
not want to participate in the development process.
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL] tracing: Syscalls trace events + perf support
From: Frederic Weisbecker @ 2009-08-18 10:25 UTC (permalink / raw)
To: Paul Mundt, Ingo Molnar, Stephen Rothwell, Jason Baron, LKML, Lai
In-Reply-To: <20090818004654.GA4402@linux-sh.org>
On Tue, Aug 18, 2009 at 09:46:55AM +0900, Paul Mundt wrote:
> [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
>
> On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > This pull request integrate one cleanup/fix for ftrace and an
> > > update for syscall tracing: the migration from old-style tracer to
> > > individual tracepoints/trace_events and the support for perf
> > > counter.
> > >
> > > I've tested it with success either with ftrace (every syscall
> > > tracepoints enabled at the same time without problems) and with
> > > perfcounter.
> > >
> > > May be one drawback: it creates so much trace events that the
> > > ftrace selftests can take some time :-)
> >
> > Pulled, thanks a lot!
> >
> And this has now subsequently broken every single SH and S390
> configuration, and anyone else unfortunate enough to be supporting ftrace
> syscall tracing that isn't x86, without so much as a Cc, well done!
>
> The s390 case can be fixed up in-tree as support has already been merged,
> but in the SH case we had ftrace syscall tracing queued up for 2.6.32, so
> it doesn't show up in -tip, but the end result in -next is now completely
> broken.
>
> I'm not sure how we should handle this, if tracing/core in -tip isn't
> rebased, should I just pull the topic-branch in to my tree, fix up the sh
> support on top of that, and push the end result out? This seems like the
> easiest option at least, but I don't know what other dependencies exist
> for tracing/core. Alternative suggestions welcome.
>
> This happens again and again with ftrace and -tip, where people just
> randomly change existing interfaces, break all of the existing users, and
> then fail to tell anyone about it until it shows up in -next. Even if we
> had pushed all of the sh ftrace bits to the -tip tree early on it would
> not have changed anything, evident by the fact that s390 and all of the
> non ftrace syscall architectures were broken by this change as well (the
> latter case was at least caught and corrected, although not by the
> original authors of this patch series). Is it really that much to task
> that people who are running around breaking ftrace interfaces actually
> bother to Cc the architectures that are using it?
I've just retrieved the concerned commit in the sh tree:
sh: Add ftrace syscall tracing support (c652d780c9cf7f860141de232b37160fe013feca)
Was I cc'ed on this one? I can't find it in my inbox. Unless I'm wrong
and I missed it, how could I guess I had to cc you and how am I supposed
to fix something I'm even not aware of?
I can't find the s390 patch in my inbox either (was I cc'ed ?)
([S390] ftrace: add system call tracer support) but we should have fixed
this one because it was already upstream and a git-grep ftrace_syscall_enter
would have warned us about that.
I didn't know another arch was supporting syscall tracing (except mips because
I was cc'ed, but it doesn't seem upstream nor in the mips tree).
>
> If -tip is going to perpetuate this sort of half-assed development
> methodology, it has no place in -next.
^ permalink raw reply
* Re: [S390] ftrace: update system call tracer support
From: Martin Schwidefsky @ 2009-08-18 10:22 UTC (permalink / raw)
To: Ingo Molnar
Cc: Paul Mundt, Stephen Rothwell, Jason Baron, Frederic Weisbecker,
LKML, Lai Jiangshan, Steven Rostedt, Peter Zijlstra,
Mathieu Desnoyers, Jiaying Zhang, Martin Bligh, Li Zefan,
Masami Hiramatsu, Wu Zhangjin, linux-next, Heiko Carstens
In-Reply-To: <20090818100526.GA14374@elte.hu>
On Tue, 18 Aug 2009 12:05:26 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
>
> > On Tue, 18 Aug 2009 10:51:10 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> > >
> > > * Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > > * Paul Mundt <lethal@linux-sh.org> wrote:
> > > >
> > > > > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
> > > > >
> > > > > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > > > > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > > > > > This pull request integrate one cleanup/fix for ftrace and an
> > > > > > > update for syscall tracing: the migration from old-style tracer to
> > > > > > > individual tracepoints/trace_events and the support for perf
> > > > > > > counter.
> > > > > > >
> > > > > > > I've tested it with success either with ftrace (every syscall
> > > > > > > tracepoints enabled at the same time without problems) and with
> > > > > > > perfcounter.
> > > > > > >
> > > > > > > May be one drawback: it creates so much trace events that the
> > > > > > > ftrace selftests can take some time :-)
> > > > > >
> > > > > > Pulled, thanks a lot!
> > > > >
> > > > > And this has now subsequently broken every single SH and S390
> > > > > configuration, [...]
> > > >
> > > > I test SH cross-builds regularly. I just checked the SH defconfig
> > > > and it builds just fine here:
> > > >
> > > > $ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
> > >
> > > The s390 build indeed broke. (This got masked by the s390 toolchain
> > > i'm using not having been able to build Linus's tree - i fixed
> > > that.)
> > >
> > > Could you try the fix below? It does the trick here.
> > >
> > > Martin, Heiko - does the fix look good to you? regs->gprs[2] seems
> > > to be the register used for both the syscall number (enter
> > > callback) and for the return code (exit callback).
> >
> > Correct, for do_syscall_trace_{enter,exit} the code in entry.S
> > stores the system call number in regs->gprs[2]. The fix is fine.
> > Thanks Ingo.
>
> Thanks, i've added your Acked-by to the commit. I suspect you dont
> want to pull tracing infrastructure changes into the S390 tree, so
> keeping this fix in the tracing tree would be the best option?
Indeed, the patch that introduced the api change is in the tracing tree
so it makes sense to put the s390 adaptions there too.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [S390] ftrace: update system call tracer support
From: Ingo Molnar @ 2009-08-18 10:05 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Paul Mundt, Stephen Rothwell, Jason Baron, Frederic Weisbecker,
LKML, Lai Jiangshan, Steven Rostedt, Peter Zijlstra,
Mathieu Desnoyers, Jiaying Zhang, Martin Bligh, Li Zefan,
Masami Hiramatsu, Wu Zhangjin, linux-next, Heiko Carstens
In-Reply-To: <20090818105927.30f6a140@skybase>
* Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> On Tue, 18 Aug 2009 10:51:10 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > * Paul Mundt <lethal@linux-sh.org> wrote:
> > >
> > > > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
> > > >
> > > > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > > > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > > > > This pull request integrate one cleanup/fix for ftrace and an
> > > > > > update for syscall tracing: the migration from old-style tracer to
> > > > > > individual tracepoints/trace_events and the support for perf
> > > > > > counter.
> > > > > >
> > > > > > I've tested it with success either with ftrace (every syscall
> > > > > > tracepoints enabled at the same time without problems) and with
> > > > > > perfcounter.
> > > > > >
> > > > > > May be one drawback: it creates so much trace events that the
> > > > > > ftrace selftests can take some time :-)
> > > > >
> > > > > Pulled, thanks a lot!
> > > >
> > > > And this has now subsequently broken every single SH and S390
> > > > configuration, [...]
> > >
> > > I test SH cross-builds regularly. I just checked the SH defconfig
> > > and it builds just fine here:
> > >
> > > $ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
> >
> > The s390 build indeed broke. (This got masked by the s390 toolchain
> > i'm using not having been able to build Linus's tree - i fixed
> > that.)
> >
> > Could you try the fix below? It does the trick here.
> >
> > Martin, Heiko - does the fix look good to you? regs->gprs[2] seems
> > to be the register used for both the syscall number (enter
> > callback) and for the return code (exit callback).
>
> Correct, for do_syscall_trace_{enter,exit} the code in entry.S
> stores the system call number in regs->gprs[2]. The fix is fine.
> Thanks Ingo.
Thanks, i've added your Acked-by to the commit. I suspect you dont
want to pull tracing infrastructure changes into the S390 tree, so
keeping this fix in the tracing tree would be the best option?
Ingo
^ permalink raw reply
* Re: [S390] ftrace: update system call tracer support
From: Martin Schwidefsky @ 2009-08-18 8:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Paul Mundt, Stephen Rothwell, Jason Baron, Frederic Weisbecker,
LKML, Lai Jiangshan, Steven Rostedt, Peter Zijlstra,
Mathieu Desnoyers, Jiaying Zhang, Martin Bligh, Li Zefan,
Masami Hiramatsu, Wu Zhangjin, linux-next, Heiko Carstens
In-Reply-To: <20090818085110.GA2074@elte.hu>
On Tue, 18 Aug 2009 10:51:10 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > * Paul Mundt <lethal@linux-sh.org> wrote:
> >
> > > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
> > >
> > > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > > > This pull request integrate one cleanup/fix for ftrace and an
> > > > > update for syscall tracing: the migration from old-style tracer to
> > > > > individual tracepoints/trace_events and the support for perf
> > > > > counter.
> > > > >
> > > > > I've tested it with success either with ftrace (every syscall
> > > > > tracepoints enabled at the same time without problems) and with
> > > > > perfcounter.
> > > > >
> > > > > May be one drawback: it creates so much trace events that the
> > > > > ftrace selftests can take some time :-)
> > > >
> > > > Pulled, thanks a lot!
> > >
> > > And this has now subsequently broken every single SH and S390
> > > configuration, [...]
> >
> > I test SH cross-builds regularly. I just checked the SH defconfig
> > and it builds just fine here:
> >
> > $ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
>
> The s390 build indeed broke. (This got masked by the s390 toolchain
> i'm using not having been able to build Linus's tree - i fixed
> that.)
>
> Could you try the fix below? It does the trick here.
>
> Martin, Heiko - does the fix look good to you? regs->gprs[2] seems
> to be the register used for both the syscall number (enter
> callback) and for the return code (exit callback).
Correct, for do_syscall_trace_{enter,exit} the code in entry.S stores
the system call number in regs->gprs[2]. The fix is fine.
Thanks Ingo.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* [S390] ftrace: update system call tracer support
From: Ingo Molnar @ 2009-08-18 8:51 UTC (permalink / raw)
To: Paul Mundt, Stephen Rothwell, Jason Baron, Frederic Weisbecker,
LKML
In-Reply-To: <20090818073211.GA26670@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> * Paul Mundt <lethal@linux-sh.org> wrote:
>
> > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
> >
> > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > > This pull request integrate one cleanup/fix for ftrace and an
> > > > update for syscall tracing: the migration from old-style tracer to
> > > > individual tracepoints/trace_events and the support for perf
> > > > counter.
> > > >
> > > > I've tested it with success either with ftrace (every syscall
> > > > tracepoints enabled at the same time without problems) and with
> > > > perfcounter.
> > > >
> > > > May be one drawback: it creates so much trace events that the
> > > > ftrace selftests can take some time :-)
> > >
> > > Pulled, thanks a lot!
> >
> > And this has now subsequently broken every single SH and S390
> > configuration, [...]
>
> I test SH cross-builds regularly. I just checked the SH defconfig
> and it builds just fine here:
>
> $ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
The s390 build indeed broke. (This got masked by the s390 toolchain
i'm using not having been able to build Linus's tree - i fixed
that.)
Could you try the fix below? It does the trick here.
Martin, Heiko - does the fix look good to you? regs->gprs[2] seems
to be the register used for both the syscall number (enter
callback) and for the return code (exit callback).
Regarding SH, the fixup should be similarly trivial. Since SH's
FTRACE_SYSCALLS code is not upstream yet it can (and should) be
carried in the tree that integrates the SH tree and the tracing
tree - linux-next in this case.
Thanks,
Ingo
------------------------------>
>From a9008fd42b1c3c89f684d90bdfb9c2d05c7af119 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 18 Aug 2009 10:41:57 +0200
Subject: [PATCH] [S390] ftrace: update system call tracer support
Commit fb34a08c3 ("tracing: Add trace events for each syscall
entry/exit") changed the lowlevel API to ftrace syscall tracing
but did not update s390 which started making use of it recently.
This broke the s390 build, as reported by Paul Mundt.
Update the callbacks with the syscall number and the syscall
return code values. This allows per syscall tracepoints,
syscall argument enumeration /debug/tracing/events/syscalls/
and perfcounters support and integration on s390 too.
Reported-by: Paul Mundt <lethal@linux-sh.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <tip-fb34a08c3469b2be9eae626ccb96476b4687b810@git.kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/s390/kernel/ptrace.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index 43acd73..05f57cd 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -662,7 +662,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
}
if (unlikely(test_thread_flag(TIF_SYSCALL_FTRACE)))
- ftrace_syscall_enter(regs);
+ trace_syscall_enter(regs, regs->gprs[2]);
if (unlikely(current->audit_context))
audit_syscall_entry(is_compat_task() ?
@@ -680,7 +680,7 @@ asmlinkage void do_syscall_trace_exit(struct pt_regs *regs)
regs->gprs[2]);
if (unlikely(test_thread_flag(TIF_SYSCALL_FTRACE)))
- ftrace_syscall_exit(regs);
+ trace_syscall_exit(regs, regs->gprs[2]);
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall_exit(regs, 0);
^ permalink raw reply related
* linux-next: Tree for August 18
From: Stephen Rothwell @ 2009-08-18 8:42 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8892 bytes --]
Hi all,
Changes since 20090817:
This tree fails to build for powerpc allyesconfig (due to a TOC overflow
problem in the final link).
The xfs tree gained a conflict against Linus' tree.
The fsnotify tree gained conflicts against Linus' tree.
The suspend tree lost its build failure, but gained another for which I
reverted a commit.
The usb tree lost its conflicts.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 140 trees (counting Linus' and 21 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_sync.h
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/input/misc/Kconfig
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_crtc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sdvo.c
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
CONFLICT (content): Merge conflict in fs/notify/inotify/inotify_fsnotify.c
CONFLICT (content): Merge conflict in fs/notify/inotify/inotify_user.c
CONFLICT (content): Merge conflict in fs/notify/notification.c
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Applying: drbd: fix for removal of blk_queue_stack_limits
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/socket.h
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (content): Merge conflict in kernel/trace/trace.h
Merging oprofile/for-next
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
Merging edac-amd/for-next
CONFLICT (content): Merge conflict in arch/x86/kernel/smpboot.c
CONFLICT (content): Merge conflict in include/linux/topology.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
Merging sfi/sfi-test
CONFLICT (content): Merge conflict in arch/x86/include/asm/io_apic.h
CONFLICT (content): Merge conflict in arch/x86/kernel/acpi/boot.c
CONFLICT (content): Merge conflict in arch/x86/kernel/apic/io_apic.c
CONFLICT (content): Merge conflict in drivers/acpi/internal.h
CONFLICT (content): Merge conflict in drivers/acpi/tables.c
CONFLICT (content): Merge conflict in include/linux/acpi.h
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/base/class.c
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/tty
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging quilt/usb
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master
[master e6cb60d] Revert "PM: Introduce core framework for run-time PM of I/O devices (rev. 17)"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: suspend tree build failure
From: Stephen Rothwell @ 2009-08-18 8:30 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
Hi Rafael,
Today's linux-next build (i386 defconfig) failed like this:
drivers/base/power/main.c: In function 'device_pm_init':
drivers/base/power/main.c:59: error: 'struct dev_pm_info' has no member named 'lock'
Caused by commit ea8e84f27325d9ddc7692f728a10e0a22cd59f52 ("PM: Introduce
core framework for run-time PM of I/O devices (rev. 17)") from the
suspend tree. The i386 defconfig does not have CONFIG_PM_RUNTIME set but
does have CONFIG_PM_SLEEP=y ...
I have reverted that commit for today.
When you add a new CONFIG variable, it is worth doing test builds both
with it turned on and turned off ...
--
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
* linux-next: manual merge of the configfs tree with Linus' tree
From: Stephen Rothwell @ 2009-08-18 8:30 UTC (permalink / raw)
To: Joel Becker; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi Joel,
The linux-next merge of the configfs tree gets a conflict in
fs/configfs/dir.c between commit 420118caa32c8ccdf9fce5a623b9de3f951573c5
("configfs: Rework configfs_depend_item() locking and make lockdep
happy") from Linus' tree and commit
8af7d5ffe1b6468ed0de1c2bb5335ad40b755ba3 ("configfs: Rework
configfs_depend_item() locking and make lockdep happy") from the configfs
tree. I have been getting this for some time.
The former is just a newer version of the latter. Since all the commits
in the configfs tree seem to be in Linus' tree now, could you please
update it to be his tree to fix the above conflict, thanks. (The
configfs tree for linux-next hasn't been updated since April 30.)
--
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
* linux-next: manual merge of the mips tree with Linus' tree
From: Stephen Rothwell @ 2009-08-18 8:23 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
Hi Ralf,
The linux-next merge of the mips tree gets conflicts between several
commits from Linus' tree and (basically) the same commits from the mips
tree. I have been getting these for some time. The mips tree for
linux-next hasn't been updated since June 6 and doing a manula merge with
Linus' tree (or rebasing it on top of Linus' tree) would fix most of these
conflicts:
$ git merge mips
Auto-merging arch/mips/Kconfig
Auto-merging arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
Auto-merging arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
Auto-merging arch/mips/cavium-octeon/octeon-irq.c
Auto-merging arch/mips/include/asm/cpu-features.h
Auto-merging arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h
Auto-merging arch/mips/mm/c-r4k.c
Auto-merging arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
Auto-merging arch/mips/sibyte/Kconfig
Auto-merging arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
Auto-merging arch/mips/txx9/generic/setup.c
Auto-merging arch/mips/txx9/rbtx4939/setup.c
Auto-merging drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
Auto-merging drivers/char/hw_random/Makefile
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
Auto-merging drivers/dma/Kconfig
Auto-merging drivers/dma/Makefile
Auto-merging drivers/dma/txx9dmac.c
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Automatic merge failed; fix conflicts and then commit the result.
--
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: [GIT PULL] tracing: Syscalls trace events + perf support
From: Ingo Molnar @ 2009-08-18 7:32 UTC (permalink / raw)
To: Paul Mundt, Stephen Rothwell, Jason Baron, Frederic Weisbecker,
LKML
In-Reply-To: <20090818004654.GA4402@linux-sh.org>
* Paul Mundt <lethal@linux-sh.org> wrote:
> [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
>
> On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > This pull request integrate one cleanup/fix for ftrace and an
> > > update for syscall tracing: the migration from old-style tracer to
> > > individual tracepoints/trace_events and the support for perf
> > > counter.
> > >
> > > I've tested it with success either with ftrace (every syscall
> > > tracepoints enabled at the same time without problems) and with
> > > perfcounter.
> > >
> > > May be one drawback: it creates so much trace events that the
> > > ftrace selftests can take some time :-)
> >
> > Pulled, thanks a lot!
>
> And this has now subsequently broken every single SH and S390
> configuration, [...]
I test SH cross-builds regularly. I just checked the SH defconfig
and it builds just fine here:
$ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
...
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
phoenix:~/linux/linux> head .config
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.31-rc6
# Tue Aug 18 09:24:28 2009
#
CONFIG_SUPERH=y
CONFIG_SUPERH32=y
# CONFIG_SUPERH64 is not set
CONFIG_ARCH_DEFCONFIG="arch/sh/configs/shx3_defconfig"
AFAICS SH does not even have any syscall tracing added upstream.
Apparently you added them in the SH tree and then they got
integrated in linux-next, and the integrated end result broke?
Mind putting those bits into a separate Git branch and sending them
to the tracing tree too so that we can make sure it's properly
integrated and tested and that any changes to the generic facility
are propagated to SH too?
Thanks,
Ingo
^ 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