* Re: linux-next: net tree build warning
From: David Miller @ 2009-09-07 9:04 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, shemminger
In-Reply-To: <20090904144232.1f6ccf45.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 4 Sep 2009 14:42:32 +1000
> Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced this warning:
>
> drivers/net/r8169.c: In function 'rtl8169_start_xmit':
> drivers/net/r8169.c:3421: warning: label 'out' defined but not used
>
> Introduced by commit 61357325f377889a1daffa14962d705dc814dd0e ("netdev:
> convert bulk of drivers to netdev_tx_t").
Thanks for the report, I'll commit the fix below.
Also, Stephen Hemminger has fixed the dlci WAN driver warning
you reported too.
r8169: Fix warning in rtl8169_start_xmit().
Reported by Stephen Rothwell:
drivers/net/r8169.c: In function 'rtl8169_start_xmit':
drivers/net/r8169.c:3421: warning: label 'out' defined but not used
Introduced by commit 61357325f377889a1daffa14962d705dc814dd0e ("netdev:
convert bulk of drivers to netdev_tx_t").
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/r8169.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index a91e9b3..50c6a3c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3416,7 +3416,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
netif_wake_queue(dev);
}
-out:
return NETDEV_TX_OK;
err_stop:
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH -next] Fix "W" macro in unified.h
From: Catalin Marinas @ 2009-09-07 9:00 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-next, sfr, Russell King - ARM Linux
In-Reply-To: <20090905210240.GA3525@x200.localdomain>
On Sun, 2009-09-06 at 01:02 +0400, Alexey Dobriyan wrote:
> Please, fold into 0becb088501886f37ade38762c8eaaf4263572cc
> aka "Thumb-2: Add macros for the unified assembler syntax"
>
> otherwise:
>
> crypto/cast6.c:372:39: error: macro "W" passed 2 arguments, but takes just 1
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Thanks for this. I added it as a new patch since Russell already merged
the current thumb-2 branch and I don't want to modify the history.
The unified.h file is automatically included in the .S files only. But
it seems that it gets included in C files via asm/uaccess.h, so this
patch makes sense.
Russell, would you like the patch on top of my thumb-2 git branch
(should only pull one patch as I haven't rebased it) or to the patch
system (but Alexey should send it so that the author information is
preserved)?
Thanks.
--
Catalin
^ permalink raw reply
* Re: linux-next: tip tree build warnings
From: Martin Schwidefsky @ 2009-09-07 8:59 UTC (permalink / raw)
To: Heiko Carstens
Cc: Ingo Molnar, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Xiao Guangrong
In-Reply-To: <20090903121326.GA4724@osiris.boeblingen.de.ibm.com>
On Thu, 3 Sep 2009 14:13:26 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Thu, Sep 03, 2009 at 10:38:44AM +0200, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > cputime_t is variously "u64", "unsigned long long" and "unsigned
> > > long" on different architectures.
> >
> > Should be unsigned long i think. Most architectures use it as
> > unsigned long via include/asm-generic/cputime.h, except these three:
> >
> > arch/ia64/include/asm/cputime.h:typedef u64 cputime_t;
> > arch/powerpc/include/asm/cputime.h:typedef u64 cputime_t;
> > arch/s390/include/asm/cputime.h:typedef unsigned long long cputime_t;
> >
> > Or we could eliminate the type altogether as well and standardize on
> > u64. Thomas?
>
> s390 uses 64 bit cputime_t because we want the high resolution also in
> 32 bit kernels. So standardizing on u64 would be the preferred solution
> for us.
The cputime_t type serves/served two purposes: 1) make it clear that
this is NOT a jiffie value, it is an architecture defined type with
architecture dependent semantic, 2) by redefining cputime_t to a
structure with a single embedded unsigned long I have been able to
identify all places in the kernel that do not use the proper cputime
functions. I'm not sure if we need 2) anymore.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: David Miller @ 2009-09-07 8:57 UTC (permalink / raw)
To: shemminger; +Cc: khc, sfr, linux-next, netdev
In-Reply-To: <20090904083346.43885303@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 4 Sep 2009 08:33:46 -0700
> This is a brute force removal of the wierd slave interface done for DLCI -> SDLA
> transmit. Before it was using non-standard return values and freeing skb in caller.
> This changes it to using normal return values, and freeing in the callee.
> Luckly only one driver pair was doing this. Not tested on real hardware,
> in fact I wonder if this driver pair is even being used by any users.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Irregardless of what we should do with the SDLA driver, this patch
should go in while that code is still in the tree.
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the percpu tree with Linus' tree
From: Tejun Heo @ 2009-09-07 8:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rusty Russell, Christoph Lameter, Ingo Molnar, linux-next,
linux-kernel
In-Reply-To: <20090907182229.734c31d2.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the percpu tree got a conflict in mm/percpu.c
> between commit 04a13c7c632e1fe04a5f6e6c83565d2559e37598 ("percpu: don't
> assume existence of cpu0") from Linus' tree and commit pcpu_chunk_page_occupied ("percpu: drop pcpu_chunk->page[]") from the percpu tree.
>
> I *think* the changes in the percpu tree supercede those in Linus' tree,
> so I have used those.
Yes, the changes in Linus's tree are backported from devel branch but
the devel already has moved on and dropped one of the changes. I'll
merge Linus's tree into percpu devel branch.
Thanks.
--
tejun
^ permalink raw reply
* Re: linux-next: slab tree build failure
From: Catalin Marinas @ 2009-09-07 8:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: Stephen Rothwell, Christoph Lameter, linux-next, linux-kernel,
Luis R. Rodriguez, John W. Linville
In-Reply-To: <84144f020909062310u37ecdddfw31c6cc9a22ccabd9@mail.gmail.com>
On Mon, 2009-09-07 at 09:10 +0300, Pekka Enberg wrote:
> Hi Stephen,
>
> On Mon, Sep 7, 2009 at 8:37 AM, Stephen Rothwell<sfr@canb.auug.org.au> wrote:
> > Hi all,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > net/wireless/scan.c: In function 'cfg80211_inform_bss':
> > net/wireless/scan.c:499: error: implicit declaration of function 'kmemleak_ignore'
> >
> > Caused by commit 74ce35c0d2261896ed4d49799311a894520f7a94 ("cfg80211:
> > clear cfg80211_inform_bss() from kmemleak reports") from the wireless
> > tree (which should have included linux/kmemleak.h into
> > net/wireless/scan.c). Some interaction with the slab tree has exposed
> > this.
> >
> > I have reverted the above commit for today.
>
> AFAICT, you're interested in kmemleak.git, not slab.git. Catalin?
I think that's a commit from Luis. It shouldn't have been merged in the
first instance anyway (we shouldn't randomly ignore kmemleak reports
unless we know for sure why kmemleak thinks it is a leak and we should
write a comment explaining why).
--
Catalin
^ permalink raw reply
* Re: linux-next: slab tree build failure
From: Stephen Rothwell @ 2009-09-07 8:29 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, linux-next, linux-kernel, Luis R. Rodriguez,
John W. Linville, Catalin Marinas, npiggin
In-Reply-To: <1252309426.4964.3.camel@penberg-laptop>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
Hi Pekka,
On Mon, 07 Sep 2009 10:43:46 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> Aah, let me guess, CONFIG_SLQB? I guess I'll just rebase the damn tree
That would be my guess.
> and make it non-default. We need that anyway if we want to merge it to
> 2.6.32. I'll take a stab at it later this evening (my time zone).
OK. This breakage still needs to be fixed in the wireless tree, though.
--
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 percpu tree with Linus' tree
From: Stephen Rothwell @ 2009-09-07 8:22 UTC (permalink / raw)
To: Tejun Heo, Rusty Russell, Christoph Lameter, Ingo Molnar
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Hi all,
Today's linux-next merge of the percpu tree got a conflict in mm/percpu.c
between commit 04a13c7c632e1fe04a5f6e6c83565d2559e37598 ("percpu: don't
assume existence of cpu0") from Linus' tree and commit pcpu_chunk_page_occupied ("percpu: drop pcpu_chunk->page[]") from the percpu tree.
I *think* the changes in the percpu tree supercede those in Linus' tree,
so I have used those.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: slab tree build failure
From: Pekka Enberg @ 2009-09-07 7:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christoph Lameter, linux-next, linux-kernel, Luis R. Rodriguez,
John W. Linville, Catalin Marinas, npiggin
In-Reply-To: <20090907173108.3c0148d7.sfr@canb.auug.org.au>
Hi Stephen,
On Mon, 7 Sep 2009 09:10:18 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> > AFAICT, you're interested in kmemleak.git, not slab.git. Catalin?
On Mon, 2009-09-07 at 17:31 +1000, Stephen Rothwell wrote:
> I first got the error after merging the slab tree ... the kmemleak tree
> is merged much later.
Aah, let me guess, CONFIG_SLQB? I guess I'll just rebase the damn tree
and make it non-default. We need that anyway if we want to merge it to
2.6.32. I'll take a stab at it later this evening (my time zone).
Pekka
^ permalink raw reply
* Re: linux-next: slab tree build failure
From: Stephen Rothwell @ 2009-09-07 7:31 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, linux-next, linux-kernel, Luis R. Rodriguez,
John W. Linville, Catalin Marinas
In-Reply-To: <84144f020909062310u37ecdddfw31c6cc9a22ccabd9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hi Pekka,
On Mon, 7 Sep 2009 09:10:18 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> AFAICT, you're interested in kmemleak.git, not slab.git. Catalin?
I first got the error after merging the slab tree ... the kmemleak tree
is merged much later.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: linux-next: manual merge of the trivial tree with the scsi tree
From: Desai, Kashyap @ 2009-09-07 6:52 UTC (permalink / raw)
To: Stephen Rothwell, Jiri Kosina
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Kashyap@mail2.lsil.com, James Bottomley, Uwe Kleine-Koenig
In-Reply-To: <20090907162349.3b3337e3.sfr@canb.auug.org.au>
Stephen,
If you are waiting for ACK, then please carry the fix with my ACK signature.
Thanks,
Kashyap
-----Original Message-----
From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
Sent: Monday, September 07, 2009 11:54 AM
To: Jiri Kosina
Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Kashyap@mail2.lsil.com; Desai, Kashyap; James Bottomley; Uwe Kleine-Koenig
Subject: linux-next: manual merge of the trivial tree with the scsi tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/scsi/mpt2sas/mpt2sas_scsih.c between commit
155dd4c763694222c125e65438d823f58ea653bc ("[SCSI] mpt2sas: Prevent
sending command to FW while Host Reset") from the scsi tree and commit
8eaa1cbfd596aeb0d2fec7706faccab42eb4bf62 ("trivial: fix typos "man[ae]g?
ment" -> "management"") from the trivial tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
Jiri, maybe the scsi part of that trivial patch could be sent to the scsi
maintainer.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 774b345,e849fc7..0000000
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@@ -2584,11 -2633,14 +2584,11 @@@ _scsih_qcmd(struct scsi_cmnd *scmd, voi
return 0;
}
- /* see if we are busy with task managment stuff */
+ /* see if we are busy with task management stuff */
- spin_lock_irqsave(&ioc->ioc_reset_in_progress_lock, flags);
- if (sas_target_priv_data->tm_busy ||
- ioc->shost_recovery || ioc->ioc_link_reset_in_progress) {
- spin_unlock_irqrestore(&ioc->ioc_reset_in_progress_lock, flags);
+ if (sas_target_priv_data->tm_busy)
+ return SCSI_MLQUEUE_DEVICE_BUSY;
+ else if (ioc->shost_recovery || ioc->ioc_link_reset_in_progress)
return SCSI_MLQUEUE_HOST_BUSY;
- }
- spin_unlock_irqrestore(&ioc->ioc_reset_in_progress_lock, flags);
if (scmd->sc_data_direction == DMA_FROM_DEVICE)
mpi_control = MPI2_SCSIIO_CONTROL_READ;
^ permalink raw reply
* linux-next: manual merge of the trivial tree with the arm tree
From: Stephen Rothwell @ 2009-09-07 6:32 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-next, linux-kernel, Joe Perches, wanzongshun, Russell King
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
arch/arm/mach-w90x900/w90p910.c between commit
35c9221acb133ecc9abd701a1fb6fa909d177a77 ("ARM: 5682/1: Add cpu.c and
dev.c and modify some files of w90p910 platform") from the arm tree and
commit 6f8fadf4a5c43f9f10f1910c71d8d9ff0b0a26ca ("trivial: remove
unnecessary semicolons") from the trivial tree.
The former commit moved the code changed by the latter into a different
file (arch/arm/mach-w90x900/cpu.c - and removed the old file). Its not
important enough to fix it there (so I just removed this file), but maybe
the part of the trivial commit touching this file could be sent to the
arm maintainer.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the trivial tree with the scsi tree
From: Stephen Rothwell @ 2009-09-07 6:23 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-next, linux-kernel, Kashyap, Desai, James Bottomley,
Uwe Kleine-Koenig
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/scsi/mpt2sas/mpt2sas_scsih.c between commit
155dd4c763694222c125e65438d823f58ea653bc ("[SCSI] mpt2sas: Prevent
sending command to FW while Host Reset") from the scsi tree and commit
8eaa1cbfd596aeb0d2fec7706faccab42eb4bf62 ("trivial: fix typos "man[ae]g?
ment" -> "management"") from the trivial tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
Jiri, maybe the scsi part of that trivial patch could be sent to the scsi
maintainer.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 774b345,e849fc7..0000000
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@@ -2584,11 -2633,14 +2584,11 @@@ _scsih_qcmd(struct scsi_cmnd *scmd, voi
return 0;
}
- /* see if we are busy with task managment stuff */
+ /* see if we are busy with task management stuff */
- spin_lock_irqsave(&ioc->ioc_reset_in_progress_lock, flags);
- if (sas_target_priv_data->tm_busy ||
- ioc->shost_recovery || ioc->ioc_link_reset_in_progress) {
- spin_unlock_irqrestore(&ioc->ioc_reset_in_progress_lock, flags);
+ if (sas_target_priv_data->tm_busy)
+ return SCSI_MLQUEUE_DEVICE_BUSY;
+ else if (ioc->shost_recovery || ioc->ioc_link_reset_in_progress)
return SCSI_MLQUEUE_HOST_BUSY;
- }
- spin_unlock_irqrestore(&ioc->ioc_reset_in_progress_lock, flags);
if (scmd->sc_data_direction == DMA_FROM_DEVICE)
mpi_control = MPI2_SCSIIO_CONTROL_READ;
^ permalink raw reply
* Re: linux-next: slab tree build failure
From: Pekka Enberg @ 2009-09-07 6:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christoph Lameter, linux-next, linux-kernel, Luis R. Rodriguez,
John W. Linville, Catalin Marinas
In-Reply-To: <20090907153723.0c984c83.sfr@canb.auug.org.au>
Hi Stephen,
On Mon, Sep 7, 2009 at 8:37 AM, Stephen Rothwell<sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> net/wireless/scan.c: In function 'cfg80211_inform_bss':
> net/wireless/scan.c:499: error: implicit declaration of function 'kmemleak_ignore'
>
> Caused by commit 74ce35c0d2261896ed4d49799311a894520f7a94 ("cfg80211:
> clear cfg80211_inform_bss() from kmemleak reports") from the wireless
> tree (which should have included linux/kmemleak.h into
> net/wireless/scan.c). Some interaction with the slab tree has exposed
> this.
>
> I have reverted the above commit for today.
AFAICT, you're interested in kmemleak.git, not slab.git. Catalin?
Pekka
^ permalink raw reply
* linux-next: slab tree build failure
From: Stephen Rothwell @ 2009-09-07 5:37 UTC (permalink / raw)
To: Pekka Enberg, Christoph Lameter
Cc: linux-next, linux-kernel, Luis R. Rodriguez, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
Hi all,
Today's linux-next build (x86_64 allmodconfig) failed like this:
net/wireless/scan.c: In function 'cfg80211_inform_bss':
net/wireless/scan.c:499: error: implicit declaration of function 'kmemleak_ignore'
Caused by commit 74ce35c0d2261896ed4d49799311a894520f7a94 ("cfg80211:
clear cfg80211_inform_bss() from kmemleak reports") from the wireless
tree (which should have included linux/kmemleak.h into
net/wireless/scan.c). Some interaction with the slab tree has exposed
this.
I have reverted the above commit for today.
--
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 battery tree with Linus' tree
From: Stephen Rothwell @ 2009-09-07 4:52 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linux-next, linux-kernel, Marek Vasut, Alexander Beregalov,
Greg Kroah-Hartman
Hi Anton,
Today's linux-next merge of the battery tree got a conflict in
drivers/power/wm97xx_battery.c between commit
38c7dc373029e4666b17850054dd43c1c96bb264 ("wm97xx_batery: replace
driver_data with dev_get_drvdata()") from Linus' tree and commit
b8bdc1d0cfc488ac0d94724639f9a61b0a5a1d40 ("wm97xx_battery: Use
platform_data") from the battery tree.
Just context changes. I fixed it up (see below) and can carry the fixes
for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/power/wm97xx_battery.c
index b787335,c552082c..0000000
--- a/drivers/power/wm97xx_battery.c
+++ b/drivers/power/wm97xx_battery.c
@@@ -33,14 -33,20 +33,20 @@@ static enum power_supply_property *prop
static unsigned long wm97xx_read_bat(struct power_supply *bat_ps)
{
+ struct wm97xx_pdata *wmdata = bat_ps->dev->parent->platform_data;
+ struct wm97xx_batt_pdata *pdata = wmdata->batt_pdata;
+
- return wm97xx_read_aux_adc(bat_ps->dev->parent->driver_data,
+ return wm97xx_read_aux_adc(dev_get_drvdata(bat_ps->dev->parent),
pdata->batt_aux) * pdata->batt_mult /
pdata->batt_div;
}
static unsigned long wm97xx_read_temp(struct power_supply *bat_ps)
{
+ struct wm97xx_pdata *wmdata = bat_ps->dev->parent->platform_data;
+ struct wm97xx_batt_pdata *pdata = wmdata->batt_pdata;
+
- return wm97xx_read_aux_adc(bat_ps->dev->parent->driver_data,
+ return wm97xx_read_aux_adc(dev_get_drvdata(bat_ps->dev->parent),
pdata->temp_aux) * pdata->temp_mult /
pdata->temp_div;
}
^ permalink raw reply
* linux-next: manual merge of the mtd tree with the i2c tree
From: Stephen Rothwell @ 2009-09-07 3:36 UTC (permalink / raw)
To: David Woodhouse
Cc: linux-next, linux-kernel, David Brownell, Greg Kroah-Hartman,
Jean Delvare, H Hartley Sweeten, Andrew Morton, Artem Bityutskiy
Hi David,
Today's linux-next merge of the mtd tree got a conflict in
drivers/mtd/mtdcore.c between commit
c6ce12828f9146f12d0654241bcb39523c257c90 ("driver model: constify
attribute groups") from the i2c tree and commit
fca910883324d437a24d447b08f524fa19261a94 ("mtd: make few symbols static")
from the mtd tree.
Just overlapping changes. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/mtd/mtdcore.c
index 69007a6,3f559c0..0000000
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@@ -217,7 -217,7 +217,7 @@@ static struct attribute_group mtd_grou
.attrs = mtd_attrs,
};
- const struct attribute_group *mtd_groups[] = {
-static struct attribute_group *mtd_groups[] = {
++static const struct attribute_group *mtd_groups[] = {
&mtd_group,
NULL,
};
^ permalink raw reply
* linux-next: async_tx tree build failure
From: Stephen Rothwell @ 2009-09-07 3:08 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-next, linux-kernel, Maciej Sosnowski
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hi Dan,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/dma/ioat/dma_v2.c: In function 'ioat2_enumerate_channels':
drivers/dma/ioat/dma_v2.c:346: error: too few arguments to function 'i7300_idle_platform_probe'
Caused by commit feed1bce2e6dc7e3307f122ac95be6741840bee8 ("ioat2,3:
convert to a true ring buffer").
I have used the version of the async_tc tree from next-20090904 for today.
--
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: scsi tree build warnings
From: Stephen Rothwell @ 2009-09-07 3:00 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-next, linux-kernel, Robert Love
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
Hi James,
Today's linux-next build (x86_64 allmodconfig) produced these warnings:
usr/include/scsi/fc/fc_els.h:165: found __[us]{8,16,32,64} type without #include <linux/types.h>
usr/include/scsi/fc/fc_fs.h:32: found __[us]{8,16,32,64} type without #include <linux/types.h>
usr/include/scsi/fc/fc_gs.h:29: found __[us]{8,16,32,64} type without #include <linux/types.h>
usr/include/scsi/fc/fc_ns.h:71: found __[us]{8,16,32,64} type without #include <linux/types.h>
Introduced by commit 171bb4f9f6a20d405a3cb5111ce92ad83aae2302 ("[SCSI]
libfc: Export FC headers").
--
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
* [PATCH -next] Fix "W" macro in unified.h
From: Alexey Dobriyan @ 2009-09-05 21:02 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-next, sfr
Please, fold into 0becb088501886f37ade38762c8eaaf4263572cc
aka "Thumb-2: Add macros for the unified assembler syntax"
otherwise:
crypto/cast6.c:372:39: error: macro "W" passed 2 arguments, but takes just 1
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
arch/arm/include/asm/unified.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -35,7 +35,9 @@
#define ARM(x...)
#define THUMB(x...) x
+#ifdef __ASSEMBLY__
#define W(instr) instr.w
+#endif
#define BSYM(sym) sym + 1
#else /* !CONFIG_THUMB2_KERNEL */
@@ -45,7 +47,9 @@
#define ARM(x...) x
#define THUMB(x...)
+#ifdef __ASSEMBLY__
#define W(instr) instr
+#endif
#define BSYM(sym) sym
#endif /* CONFIG_THUMB2_KERNEL */
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: Krzysztof Halasa @ 2009-09-05 11:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, sfr, linux-next, netdev
In-Reply-To: <20090904193810.46543e3c@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> In the Vyatta product we use the Sangoma drivers, so we actually have
> to make and not configure in the existing WAN drivers.
I'd expect all users of their hw are doing precisely the same (not to
imply there are any S5* (ISA) cards still in use).
But I don't know for sure, sometimes people use really old and long
unmaintained drivers with success. OTOH ISA...
--
Krzysztof Halasa
^ permalink raw reply
* Re: linux-next / s390 crypto breakage
From: Herbert Xu @ 2009-09-05 6:28 UTC (permalink / raw)
To: Jan Glauber; +Cc: Martin Schwidefsky, linux-next, Heiko Carstens
In-Reply-To: <1251993142.7382.8.camel@bender>
On Thu, Sep 03, 2009 at 03:52:22PM +0000, Jan Glauber wrote:
>
> Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com>
Patch applied. Thanks!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: Stephen Hemminger @ 2009-09-05 2:38 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: David Miller, sfr, linux-next, netdev
In-Reply-To: <m31vmmk0kt.fsf@intrepid.localdomain>
On Fri, 04 Sep 2009 20:48:50 +0200
Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
> > This is a brute force removal of the wierd slave interface done for
> > DLCI -> SDLA transmit. Before it was using non-standard return values
> > and freeing skb in caller. This changes it to using normal return
> > values, and freeing in the callee. Luckly only one driver pair was
> > doing this. Not tested on real hardware, in fact I wonder if this
> > driver pair is even being used by any users.
>
> The only hardware which seems to be driven by dlci.c is sdla.c =
> old Sangoma ISA cards.
>
> Sangoma seems to maintain their own drivers for their hw (including
> these ISA cards).
>
> Are the in-kernel drivers functional after all those years? I don't
> know.
In the Vyatta product we use the Sangoma drivers, so we actually have
to make and not configure in the existing WAN drivers.
--
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: Krzysztof Halasa @ 2009-09-04 18:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, sfr, linux-next, netdev
In-Reply-To: <20090904083346.43885303@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> This is a brute force removal of the wierd slave interface done for
> DLCI -> SDLA transmit. Before it was using non-standard return values
> and freeing skb in caller. This changes it to using normal return
> values, and freeing in the callee. Luckly only one driver pair was
> doing this. Not tested on real hardware, in fact I wonder if this
> driver pair is even being used by any users.
The only hardware which seems to be driven by dlci.c is sdla.c =
old Sangoma ISA cards.
Sangoma seems to maintain their own drivers for their hw (including
these ISA cards).
Are the in-kernel drivers functional after all those years? I don't
know.
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: Stephen Hemminger @ 2009-09-04 15:33 UTC (permalink / raw)
To: David Miller, Krzysztof Halasa; +Cc: sfr, linux-next, netdev
In-Reply-To: <20090903.213548.46609322.davem@davemloft.net>
This is a brute force removal of the wierd slave interface done for DLCI -> SDLA
transmit. Before it was using non-standard return values and freeing skb in caller.
This changes it to using normal return values, and freeing in the callee.
Luckly only one driver pair was doing this. Not tested on real hardware,
in fact I wonder if this driver pair is even being used by any users.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/wan/dlci.c | 43 +++++--------------------------------------
drivers/net/wan/sdla.c | 8 ++++----
include/linux/if_frad.h | 5 -----
3 files changed, 9 insertions(+), 47 deletions(-)
--- a/drivers/net/wan/dlci.c 2009-09-04 08:14:38.993377174 -0700
+++ b/drivers/net/wan/dlci.c 2009-09-04 08:25:03.024404089 -0700
@@ -186,46 +186,13 @@ static void dlci_receive(struct sk_buff
dev_kfree_skb(skb);
}
-static netdev_tx_t dlci_transmit(struct sk_buff *skb,
- struct net_device *dev)
+static netdev_tx_t dlci_transmit(struct sk_buff *skb, struct net_device *dev)
{
- struct dlci_local *dlp;
- netdev_tx_t ret;
-
- if (!skb || !dev)
- return NETDEV_TX_OK;
-
- dlp = netdev_priv(dev);
-
- netif_stop_queue(dev);
-
- /* This is hackish, overloads driver specific return values
- on top of normal transmit return! */
- ret = dlp->slave->netdev_ops->ndo_start_xmit(skb, dlp->slave);
- switch (ret)
- {
- case DLCI_RET_OK:
- dev->stats.tx_packets++;
- ret = NETDEV_TX_OK;
- break;
- case DLCI_RET_ERR:
- dev->stats.tx_errors++;
- ret = NETDEV_TX_OK;
- break;
- case DLCI_RET_DROP:
- dev->stats.tx_dropped++;
- ret = NETDEV_TX_BUSY;
- break;
- }
- /* Alan Cox recommends always returning 0, and always freeing the packet */
- /* experience suggest a slightly more conservative approach */
+ struct dlci_local *dlp = netdev_priv(dev);
- if (ret == NETDEV_TX_OK)
- {
- dev_kfree_skb(skb);
- netif_wake_queue(dev);
- }
- return(ret);
+ if (skb)
+ dlp->slave->netdev_ops->ndo_start_xmit(skb, dlp->slave);
+ return NETDEV_TX_OK;
}
static int dlci_config(struct net_device *dev, struct dlci_conf __user *conf, int get)
--- a/drivers/net/wan/sdla.c 2009-09-04 08:18:22.917065991 -0700
+++ b/drivers/net/wan/sdla.c 2009-09-04 08:24:53.587189004 -0700
@@ -652,7 +652,7 @@ static int sdla_dlci_conf(struct net_dev
/* NOTE: the DLCI driver deals with freeing the SKB!! */
static netdev_tx_t sdla_transmit(struct sk_buff *skb,
- struct net_device *dev)
+ struct net_device *dev)
{
struct frad_local *flp;
int ret, addr, accept, i;
@@ -712,23 +712,21 @@ static netdev_tx_t sdla_transmit(struct
}
break;
}
+
switch (ret)
{
case SDLA_RET_OK:
dev->stats.tx_packets++;
- ret = DLCI_RET_OK;
break;
case SDLA_RET_CIR_OVERFLOW:
case SDLA_RET_BUF_OVERSIZE:
case SDLA_RET_NO_BUFS:
dev->stats.tx_dropped++;
- ret = DLCI_RET_DROP;
break;
default:
dev->stats.tx_errors++;
- ret = DLCI_RET_ERR;
break;
}
}
@@ -738,6 +736,8 @@ static netdev_tx_t sdla_transmit(struct
if(flp->master[i]!=NULL)
netif_wake_queue(flp->master[i]);
}
+
+ dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
--- a/include/linux/if_frad.h 2009-09-04 08:19:04.459045748 -0700
+++ b/include/linux/if_frad.h 2009-09-04 08:19:47.487006328 -0700
@@ -69,11 +69,6 @@ struct dlci_conf {
#define DLCI_VALID_FLAGS 0x000B
-/* FRAD driver uses these to indicate what it did with packet */
-#define DLCI_RET_OK 0x00
-#define DLCI_RET_ERR 0x01
-#define DLCI_RET_DROP 0x02
-
/* defines for the actual Frame Relay hardware */
#define FRAD_GET_CONF (SIOCDEVPRIVATE)
#define FRAD_SET_CONF (SIOCDEVPRIVATE + 1)
^ 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