* Re: [PATCH 33/37] sound/soc: use .dev.of_node instead of .node in struct of_device
From: Grant Likely @ 2010-03-11 21:22 UTC (permalink / raw)
To: Mark Brown
Cc: monstr, gregkh, benh, akpm, davem, sfr, jgarzik, ben-linux, dwmw2,
jeremy.kerr, James.Bottomley, microblaze-uclinux, linux-kernel,
linuxppc-dev, sparclinux, linux-ide, netdev, linux-i2c,
devicetree-discuss, linux-scsi, alsa-devel, timur, lrg
In-Reply-To: <20100311193458.GA13289@opensource.wolfsonmicro.com>
On Thu, Mar 11, 2010 at 12:34 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Mar 11, 2010 at 11:06:50AM -0700, Grant Likely wrote:
>> .node is being removed
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> but please ensure that Liam and especially Timur also check this (both
> CCed).
>
> For enormous patch serieses like this it's really nice if you can ensure
> that each person is only CCed on the patches that they need to review.
> Much less stuff in the inbox.
Yeah, sorry about that (and to everyone receiving this thread, I'm
really sorry. I won't do it again). I've already been yelled at for
that. What happened is that on a previous series I was yelled at for
not sending all patches to everyone (so that the patches could be
reviewed in context). So, naturally, I made sure to include everyone
on the whole series this time.... doh.
Next time I post I'll constrain it to small chunks.
Thanks for the review.
g.
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: David Miller @ 2010-03-11 21:30 UTC (permalink / raw)
To: jengelh; +Cc: shemminger, netdev
In-Reply-To: <alpine.LSU.2.01.1003112205360.24500@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Thu, 11 Mar 2010 22:07:07 +0100 (CET)
> On a side note, is it perhaps possible to use jiffies-like magic to
> also have 64-bit counters on 32-bit, or is that still too expensive?
I think there might still be atomicity issues.
We've been telling people to poll periodically in userspace to avoid
these problems, but that has limitations as network speeds increase.
^ permalink raw reply
* Re: BNX2: Kernel crashes with 2.6.31 and 2.6.31.9
From: Brian Haley @ 2010-03-11 21:57 UTC (permalink / raw)
To: Michael Chan
Cc: David Miller, bonbons@linux-vserver.org, Benjamin Li,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1268336848.9775.154.camel@nseg_linux_HP1.broadcom.com>
Michael Chan wrote:
> On Thu, 2010-03-11 at 11:40 -0800, Brian Haley wrote:
>> I can only reproduce this on one system out of many, so it's either a
>> race condition or bad hardware. The only thing I can confirm at the
>> moment is that it's the code at the bottom of bnx2_set_coalesce()
>> that's causing it, I'm trying to go through all those codepaths now.
>
> The NETDEV WATCHDOG is caused by stopping the TX queues with
> ->trans_start older than dev->watchdog_timeo which is set to 5 seconds
> in bnx2. Please try this patch below to update the ->trans_start first
> before stopping the TX queues:
Well I'm an idiot. Someone had cherry-picked commit 4529819c4 (that caused
the reset_task bnx2 crash), so it was bad code in bnx2_netif_stop()/start()
that's already been fixed upstream. I'll merge our bnx2 code up to the
firmware commit and start testing again to see if we still see the watchdog
timeouts we've seen in the past.
Thanks for your help.
-Brian
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: Stephen Hemminger @ 2010-03-11 22:04 UTC (permalink / raw)
To: David Miller; +Cc: jengelh, netdev
In-Reply-To: <20100311.122639.258785986.davem@davemloft.net>
On Thu, 11 Mar 2010 12:26:39 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 11 Mar 2010 12:12:39 -0800
>
> > On Thu, 11 Mar 2010 20:57:29 +0100
> > Jan Engelhardt <jengelh@medozas.de> wrote:
> >
> >> `ip -s link` shows interface counters truncated to 32 bit. This is
> >> because interface statistics are transported only in 32-bit quantity
> >> to userspace. This commit adds a new IFLA_STATS64 attribute that
> >> exports them in full 64 bit.
> >>
> >> References: http://lkml.indiana.edu/hypermail/linux/kernel/0307.3/0215.html
> >> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
> >>
> >
> > What is the point since net_device_stats has only 32 bit counters.
> > The last time this came up the issue was is that is not possible
> > to atomically increment a 64 bit counter on most 32 bit platforms.
>
> On 64-bit it has 64-bit counters, yet we only report 32-bit
> counters to userspace via netlink even in that case.
That make sense, but maybe we shouldn't send IFLA_STATS64 on
32bit platforms.
^ permalink raw reply
* [patch 1/3] isdn: misplaced parenthesis in pof_handle_data()
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: isdn; +Cc: netdev, akpm, roel.kluin
From: Roel Kluin <roel.kluin@gmail.com>
The parenthesis was misplaced.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/hysdn/hysdn_boot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/isdn/hysdn/hysdn_boot.c~isdn-misplaced-parenthesis-in-pof_handle_data drivers/isdn/hysdn/hysdn_boot.c
--- a/drivers/isdn/hysdn/hysdn_boot.c~isdn-misplaced-parenthesis-in-pof_handle_data
+++ a/drivers/isdn/hysdn/hysdn_boot.c
@@ -143,7 +143,7 @@ pof_handle_data(hysdn_card * card, int d
(boot->pof_recid == TAG_CABSDATA) ? "CABSDATA" : "ABSDATA",
datlen, boot->pof_recoffset);
- if ((boot->last_error = card->writebootseq(card, boot->buf.BootBuf, datlen) < 0))
+ if ((boot->last_error = card->writebootseq(card, boot->buf.BootBuf, datlen)) < 0)
return (boot->last_error); /* error writing data */
if (boot->pof_recoffset + datlen >= boot->pof_reclen)
_
^ permalink raw reply
* [patch 2/3] i4l: silence compiler warnings for array access in Eicon DIVA ISDN driver
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: isdn; +Cc: netdev, akpm, imunsie, mac, sgayda2
From: Ian Munsie <imunsie@au.ibm.com>
When compiling this driver, the compiler throws the following warnings:
drivers/isdn/hardware/eicon/message.c:8426: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8427: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8434: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8435: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8436: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8447: warning: array subscript is above array bounds
This arises from the particular semantics the driver is using to write to
the nlc array (static byte[256]). The array has a length in byte 0
followed by a T30_INFO struct starting at byte 1.
The T30_INFO struct has a number of variable length strings after the
station_id entry, which cannot be explicitly defined in the struct and the
driver accesses them with an array index to station_id beyond the length
of station_id.
This patch merely changes the semantics that the driver uses to access the
entries after the station_id entry to use the original 256 byte nlc array
taking the offset and length of the station_id entry to calculate where to
write in the array, thereby silencing the warning.
Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
Cc: Armin Schindler <mac@melware.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Stoyan Gaydarov <sgayda2@uiuc.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/hardware/eicon/message.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff -puN drivers/isdn/hardware/eicon/message.c~i4l-silence-compiler-warnings-for-array-access-in-eicon-diva-isdn-driver drivers/isdn/hardware/eicon/message.c
--- a/drivers/isdn/hardware/eicon/message.c~i4l-silence-compiler-warnings-for-array-access-in-eicon-diva-isdn-driver
+++ a/drivers/isdn/hardware/eicon/message.c
@@ -8423,17 +8423,17 @@ static word add_b23(PLCI *plci, API_PARS
pos = 0;
else
{
- ((T30_INFO *)&nlc[1])->station_id[20 + pos++] = ' ';
- ((T30_INFO *)&nlc[1])->station_id[20 + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
len = (byte)b3_config_parms[2].length;
if (len > 20)
len = 20;
if (CAPI_MAX_DATE_TIME_LENGTH + 2 + len + 2 + b3_config_parms[3].length <= CAPI_MAX_HEAD_LINE_SPACE)
{
for (i = 0; i < len; i++)
- ((T30_INFO *)&nlc[1])->station_id[20 + pos++] = ((byte *)b3_config_parms[2].info)[1+i];
- ((T30_INFO *)&nlc[1])->station_id[20 + pos++] = ' ';
- ((T30_INFO *)&nlc[1])->station_id[20 + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ((byte *)b3_config_parms[2].info)[1+i];
+ nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
}
}
}
@@ -8444,9 +8444,8 @@ static word add_b23(PLCI *plci, API_PARS
((T30_INFO *)&nlc[1])->head_line_len = (byte)(pos + len);
nlc[0] += (byte)(pos + len);
for (i = 0; i < len; i++)
- ((T30_INFO *)&nlc[1])->station_id[20 + pos++] = ((byte *)b3_config_parms[3].info)[1+i];
- }
- else
+ nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ((byte *)b3_config_parms[3].info)[1+i];
+ } else
((T30_INFO *)&nlc[1])->head_line_len = 0;
plci->nsf_control_bits = 0;
_
^ permalink raw reply
* [patch 3/3] i4l: change magic numbers in Eicon DIVA ISDN driver to symbolic names
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: isdn; +Cc: netdev, akpm, imunsie, mac, sgayda2
From: Ian Munsie <imunsie@au.ibm.com>
Replace references to the '20' magic number found throughout the Eicon
ISDN driver for the length of the station_id field in the T30_INFO struct
with the T30_MAX_STATION_ID_LENGTH symbolic constant.
Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
Cc: Armin Schindler <mac@melware.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Stoyan Gaydarov <sgayda2@uiuc.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/hardware/eicon/message.c | 32 ++++++++++++------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff -puN drivers/isdn/hardware/eicon/message.c~i4l-change-magic-numbers-in-eicon-diva-isdn-driver-to-symbolic-names drivers/isdn/hardware/eicon/message.c
--- a/drivers/isdn/hardware/eicon/message.c~i4l-change-magic-numbers-in-eicon-diva-isdn-driver-to-symbolic-names
+++ a/drivers/isdn/hardware/eicon/message.c
@@ -2754,7 +2754,7 @@ static byte connect_b3_req(dword Id, wor
for (i = 0; i < w; i++)
((T30_INFO *)(plci->fax_connect_info_buffer))->station_id[i] = fax_parms[4].info[1+i];
((T30_INFO *)(plci->fax_connect_info_buffer))->head_line_len = 0;
- len = offsetof(T30_INFO, station_id) + 20;
+ len = offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH;
w = fax_parms[5].length;
if (w > 20)
w = 20;
@@ -2892,7 +2892,7 @@ static byte connect_b3_res(dword Id, wor
&& (plci->nsf_control_bits & T30_NSF_CONTROL_BIT_ENABLE_NSF)
&& (plci->nsf_control_bits & T30_NSF_CONTROL_BIT_NEGOTIATE_RESP))
{
- len = offsetof(T30_INFO, station_id) + 20;
+ len = offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH;
if (plci->fax_connect_info_length < len)
{
((T30_INFO *)(plci->fax_connect_info_buffer))->station_id_len = 0;
@@ -3802,7 +3802,7 @@ static byte manufacturer_res(dword Id, w
break;
}
ncpi = &m_parms[1];
- len = offsetof(T30_INFO, station_id) + 20;
+ len = offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH;
if (plci->fax_connect_info_length < len)
{
((T30_INFO *)(plci->fax_connect_info_buffer))->station_id_len = 0;
@@ -6830,7 +6830,7 @@ static void nl_ind(PLCI *plci)
if(((T30_INFO *)plci->NL.RBuffer->P)->station_id_len)
{
plci->ncpi_buffer[len] = 20;
- for (i = 0; i < 20; i++)
+ for (i = 0; i < T30_MAX_STATION_ID_LENGTH; i++)
plci->ncpi_buffer[++len] = ((T30_INFO *)plci->NL.RBuffer->P)->station_id[i];
}
if (((plci->NL.Ind & 0x0f) == N_DISC) || ((plci->NL.Ind & 0x0f) == N_DISC_ACK))
@@ -6844,7 +6844,7 @@ static void nl_ind(PLCI *plci)
if ((plci->requested_options_conn | plci->requested_options | a->requested_options_table[plci->appl->Id-1])
& ((1L << PRIVATE_FAX_SUB_SEP_PWD) | (1L << PRIVATE_FAX_NONSTANDARD)))
{
- i = offsetof(T30_INFO, station_id) + 20 + ((T30_INFO *)plci->NL.RBuffer->P)->head_line_len;
+ i = offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + ((T30_INFO *)plci->NL.RBuffer->P)->head_line_len;
while (i < plci->NL.RBuffer->length)
plci->ncpi_buffer[++len] = plci->NL.RBuffer->P[i++];
}
@@ -8400,7 +8400,7 @@ static word add_b23(PLCI *plci, API_PARS
}
}
/* copy station id to NLC */
- for(i=0; i<20; i++)
+ for(i=0; i < T30_MAX_STATION_ID_LENGTH; i++)
{
if(i<b3_config_parms[2].length)
{
@@ -8411,29 +8411,29 @@ static word add_b23(PLCI *plci, API_PARS
((T30_INFO *)&nlc[1])->station_id[i] = ' ';
}
}
- ((T30_INFO *)&nlc[1])->station_id_len = 20;
+ ((T30_INFO *)&nlc[1])->station_id_len = T30_MAX_STATION_ID_LENGTH;
/* copy head line to NLC */
if(b3_config_parms[3].length)
{
- pos = (byte)(fax_head_line_time (&(((T30_INFO *)&nlc[1])->station_id[20])));
+ pos = (byte)(fax_head_line_time (&(((T30_INFO *)&nlc[1])->station_id[T30_MAX_STATION_ID_LENGTH])));
if (pos != 0)
{
if (CAPI_MAX_DATE_TIME_LENGTH + 2 + b3_config_parms[3].length > CAPI_MAX_HEAD_LINE_SPACE)
pos = 0;
else
{
- nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
- nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + pos++] = ' ';
len = (byte)b3_config_parms[2].length;
if (len > 20)
len = 20;
if (CAPI_MAX_DATE_TIME_LENGTH + 2 + len + 2 + b3_config_parms[3].length <= CAPI_MAX_HEAD_LINE_SPACE)
{
for (i = 0; i < len; i++)
- nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ((byte *)b3_config_parms[2].info)[1+i];
- nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
- nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + pos++] = ((byte *)b3_config_parms[2].info)[1+i];
+ nlc[1 + offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + pos++] = ' ';
+ nlc[1 + offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + pos++] = ' ';
}
}
}
@@ -8444,7 +8444,7 @@ static word add_b23(PLCI *plci, API_PARS
((T30_INFO *)&nlc[1])->head_line_len = (byte)(pos + len);
nlc[0] += (byte)(pos + len);
for (i = 0; i < len; i++)
- nlc[1 + offsetof(T30_INFO, station_id) + 20 + pos++] = ((byte *)b3_config_parms[3].info)[1+i];
+ nlc[1 + offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH + pos++] = ((byte *)b3_config_parms[3].info)[1+i];
} else
((T30_INFO *)&nlc[1])->head_line_len = 0;
@@ -8472,7 +8472,7 @@ static word add_b23(PLCI *plci, API_PARS
fax_control_bits |= T30_CONTROL_BIT_ACCEPT_SEL_POLLING;
}
len = nlc[0];
- pos = offsetof(T30_INFO, station_id) + 20;
+ pos = offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH;
if (pos < plci->fax_connect_info_length)
{
for (i = 1 + plci->fax_connect_info_buffer[pos]; i != 0; i--)
@@ -8524,7 +8524,7 @@ static word add_b23(PLCI *plci, API_PARS
}
PUT_WORD(&(((T30_INFO *)&nlc[1])->control_bits_low), fax_control_bits);
- len = offsetof(T30_INFO, station_id) + 20;
+ len = offsetof(T30_INFO, station_id) + T30_MAX_STATION_ID_LENGTH;
for (i = 0; i < len; i++)
plci->fax_connect_info_buffer[i] = nlc[1+i];
((T30_INFO *) plci->fax_connect_info_buffer)->head_line_len = 0;
_
^ permalink raw reply
* [patch 1/5] phonet: use for_each_set_bit()
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, akinobu.mita
From: Akinobu Mita <akinobu.mita@gmail.com>
Replace open-coded loop with for_each_set_bit().
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/phonet/pn_dev.c | 3 +--
net/phonet/pn_netlink.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff -puN net/phonet/pn_dev.c~phonet-use-for_each_set_bit net/phonet/pn_dev.c
--- a/net/phonet/pn_dev.c~phonet-use-for_each_set_bit
+++ a/net/phonet/pn_dev.c
@@ -107,8 +107,7 @@ static void phonet_device_destroy(struct
if (pnd) {
u8 addr;
- for (addr = find_first_bit(pnd->addrs, 64); addr < 64;
- addr = find_next_bit(pnd->addrs, 64, 1+addr))
+ for_each_set_bit(addr, pnd->addrs, 64)
phonet_address_notify(RTM_DELADDR, dev, addr);
kfree(pnd);
}
diff -puN net/phonet/pn_netlink.c~phonet-use-for_each_set_bit net/phonet/pn_netlink.c
--- a/net/phonet/pn_netlink.c~phonet-use-for_each_set_bit
+++ a/net/phonet/pn_netlink.c
@@ -141,8 +141,7 @@ static int getaddr_dumpit(struct sk_buff
continue;
addr_idx = 0;
- for (addr = find_first_bit(pnd->addrs, 64); addr < 64;
- addr = find_next_bit(pnd->addrs, 64, 1+addr)) {
+ for_each_set_bit(addr, pnd->addrs, 64) {
if (addr_idx++ < addr_start_idx)
continue;
_
^ permalink raw reply
* [patch 3/5] LL TEMAC driver: add non-Virtex 5 support
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, jtyner, afleming, grant.likely
From: John Tyner <jtyner@cs.ucr.edu>
Add support for using the LL TEMAC Ethernet driver on non-Virtex 5
platforms by adding support for accessing the Soft DMA registers as if
they were memory mapped instead of solely through the DCR's (available on
the Virtex 5).
Signed-off-by: John Tyner <jtyner@cs.ucr.edu>
Cc: Andy Fleming <afleming@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/ll_temac.h | 1 +
drivers/net/ll_temac_main.c | 31 ++++++++++++++++++++-----------
2 files changed, 21 insertions(+), 11 deletions(-)
diff -puN drivers/net/ll_temac.h~ll-temac-driver-add-non-virtex-5-support drivers/net/ll_temac.h
--- a/drivers/net/ll_temac.h~ll-temac-driver-add-non-virtex-5-support
+++ a/drivers/net/ll_temac.h
@@ -338,6 +338,7 @@ struct temac_local {
/* IO registers and IRQs */
void __iomem *regs;
dcr_host_t sdma_dcrs;
+ u32 __iomem *sdma_regs;
int tx_irq;
int rx_irq;
int emac_num;
diff -puN drivers/net/ll_temac_main.c~ll-temac-driver-add-non-virtex-5-support drivers/net/ll_temac_main.c
--- a/drivers/net/ll_temac_main.c~ll-temac-driver-add-non-virtex-5-support
+++ a/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -117,12 +114,20 @@ void temac_indirect_out32(struct temac_l
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp->sdma_dcrs, reg);
+ if (lp->sdma_regs) {
+ return __raw_readl(lp->sdma_regs + reg);
+ } else {
+ return dcr_read(lp->sdma_dcrs, reg);
+ }
}
static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
{
- dcr_write(lp->sdma_dcrs, reg, value);
+ if (lp->sdma_regs) {
+ __raw_writel(value, lp->sdma_regs + reg);
+ } else {
+ dcr_write(lp->sdma_dcrs, reg, value);
+ }
}
/**
@@ -870,13 +875,17 @@ temac_of_probe(struct of_device *op, con
goto nodev;
}
- dcrs = dcr_resource_start(np, 0);
- if (dcrs == 0) {
- dev_err(&op->dev, "could not get DMA register address\n");
+ lp->sdma_regs = NULL;
+
+ if ((dcrs = dcr_resource_start(np, 0)) != 0) {
+ lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
+ dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
+ } else if ((lp->sdma_regs = of_iomap(np, 0))) {
+ dev_dbg(&op->dev, "MEM base: %p\n", lp->sdma_regs);
+ } else {
+ dev_err(&op->dev, "unable to map DMA registers\n");
goto nodev;
}
- lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
- dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
lp->rx_irq = irq_of_parse_and_map(np, 0);
lp->tx_irq = irq_of_parse_and_map(np, 1);
@@ -903,7 +912,7 @@ temac_of_probe(struct of_device *op, con
lp->phy_node = of_parse_phandle(op->node, "phy-handle", 0);
if (lp->phy_node)
- dev_dbg(lp->dev, "using PHY node %s (%p)\n", np->full_name, np);
+ dev_dbg(lp->dev, "using PHY node %s (%p)\n", lp->phy_node->full_name, lp->phy_node);
/* Add the device attributes */
rc = sysfs_create_group(&lp->dev->kobj, &temac_attr_group);
_
^ permalink raw reply
* [patch 4/5] obsolete config in kernel source: USE_INTERNAL_TIMER
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, siccegge, roel.kluin
From: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
CONFIG_USE_INTERNAL_TIMER seems to be the remainings of some experiment.
It is explicitely #undef-ed as not working, only referenced from one
source file and rather aged.
Hereby cleaning it from the kernel tree.
Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Acked-by: Roel Kluin <roel.kluin@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/irda/w83977af_ir.c | 36 -------------------------------
1 file changed, 36 deletions(-)
diff -puN drivers/net/irda/w83977af_ir.c~obsolete-config-in-kernel-source-use_internal_timer drivers/net/irda/w83977af_ir.c
--- a/drivers/net/irda/w83977af_ir.c~obsolete-config-in-kernel-source-use_internal_timer
+++ a/drivers/net/irda/w83977af_ir.c
@@ -65,7 +65,6 @@
#undef CONFIG_NETWINDER_TX_DMA_PROBLEMS /* Not needed */
#define CONFIG_NETWINDER_RX_DMA_PROBLEMS /* Must have this one! */
#endif
-#undef CONFIG_USE_INTERNAL_TIMER /* Just cannot make that timer work */
#define CONFIG_USE_W977_PNP /* Currently needed */
#define PIO_MAX_SPEED 115200
@@ -533,25 +532,6 @@ static netdev_tx_t w83977af_hard_xmit(st
self->tx_buff.len = skb->len;
mtt = irda_get_mtt(skb);
-#ifdef CONFIG_USE_INTERNAL_TIMER
- if (mtt > 50) {
- /* Adjust for timer resolution */
- mtt /= 1000+1;
-
- /* Setup timer */
- switch_bank(iobase, SET4);
- outb(mtt & 0xff, iobase+TMRL);
- outb((mtt >> 8) & 0x0f, iobase+TMRH);
-
- /* Start timer */
- outb(IR_MSL_EN_TMR, iobase+IR_MSL);
- self->io.direction = IO_XMIT;
-
- /* Enable timer interrupt */
- switch_bank(iobase, SET0);
- outb(ICR_ETMRI, iobase+ICR);
- } else {
-#endif
IRDA_DEBUG(4, "%s(%ld), mtt=%d\n", __func__ , jiffies, mtt);
if (mtt)
udelay(mtt);
@@ -560,9 +540,6 @@ static netdev_tx_t w83977af_hard_xmit(st
switch_bank(iobase, SET0);
outb(ICR_EDMAI, iobase+ICR);
w83977af_dma_write(self, iobase);
-#ifdef CONFIG_USE_INTERNAL_TIMER
- }
-#endif
} else {
self->tx_buff.data = self->tx_buff.head;
self->tx_buff.len = async_wrap_skb(skb, self->tx_buff.data,
@@ -876,20 +853,7 @@ static int w83977af_dma_receive_complete
/* Check if we have transferred all data to memory */
switch_bank(iobase, SET0);
if (inb(iobase+USR) & USR_RDR) {
-#ifdef CONFIG_USE_INTERNAL_TIMER
- /* Put this entry back in fifo */
- st_fifo->head--;
- st_fifo->len++;
- st_fifo->entries[st_fifo->head].status = status;
- st_fifo->entries[st_fifo->head].len = len;
-
- /* Restore set register */
- outb(set, iobase+SSR);
-
- return FALSE; /* I'll be back! */
-#else
udelay(80); /* Should be enough!? */
-#endif
}
skb = dev_alloc_skb(len+1);
_
^ permalink raw reply
* [patch 5/5] obsolete config in kernel source: HSO_AUTOPM
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, siccegge
From: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
CONFIG_HSO_AUTOPM is set by KConfig / set in the Kernel source, makefiles
and won't be ever set this way, therefor simply removing the protected
code.
Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/usb/hso.c | 3 ---
1 file changed, 3 deletions(-)
diff -puN drivers/net/usb/hso.c~obsolete-config-in-kernel-source-hso_autopm drivers/net/usb/hso.c
--- a/drivers/net/usb/hso.c~obsolete-config-in-kernel-source-hso_autopm
+++ a/drivers/net/usb/hso.c
@@ -1155,9 +1155,6 @@ static void _hso_serial_set_termios(stru
static void hso_resubmit_rx_bulk_urb(struct hso_serial *serial, struct urb *urb)
{
int result;
-#ifdef CONFIG_HSO_AUTOPM
- usb_mark_last_busy(urb->dev);
-#endif
/* We are done with this URB, resubmit it. Prep the USB to wait for
* another frame */
usb_fill_bulk_urb(urb, serial->parent->usb,
_
^ permalink raw reply
* [patch 2/5] atm: use for_each_set_bit()
From: akpm @ 2010-03-11 22:07 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, akinobu.mita, chas
From: Akinobu Mita <akinobu.mita@gmail.com>
Replace open-coded loop with for_each_set_bit().
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/atm/lanai.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff -puN drivers/atm/lanai.c~atm-use-for_each_set_bit drivers/atm/lanai.c
--- a/drivers/atm/lanai.c~atm-use-for_each_set_bit
+++ a/drivers/atm/lanai.c
@@ -306,11 +306,10 @@ static void vci_bitfield_iterate(struct
const unsigned long *lp,
void (*func)(struct lanai_dev *,vci_t vci))
{
- vci_t vci = find_first_bit(lp, NUM_VCI);
- while (vci < NUM_VCI) {
+ vci_t vci;
+
+ for_each_set_bit(vci, lp, NUM_VCI)
func(lanai, vci);
- vci = find_next_bit(lp, NUM_VCI, vci + 1);
- }
}
/* -------------------- BUFFER UTILITIES: */
_
^ permalink raw reply
* Re: [patch 3/5] LL TEMAC driver: add non-Virtex 5 support
From: Grant Likely @ 2010-03-11 22:10 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev, jtyner, afleming, John Linn
In-Reply-To: <201003112207.o2BM7qhv013492@imap1.linux-foundation.org>
On Thu, Mar 11, 2010 at 3:07 PM, <akpm@linux-foundation.org> wrote:
> From: John Tyner <jtyner@cs.ucr.edu>
>
> Add support for using the LL TEMAC Ethernet driver on non-Virtex 5
> platforms by adding support for accessing the Soft DMA registers as if
> they were memory mapped instead of solely through the DCR's (available on
> the Virtex 5).
Thanks Andrew. Changes were requested on this one, but IIRC John
Tyner doesn't have any bandwidth to work on it. John Linn from Xilinx
has adopted the patch and is fixing it up.
g.
>
> Signed-off-by: John Tyner <jtyner@cs.ucr.edu>
> Cc: Andy Fleming <afleming@freescale.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/ll_temac.h | 1 +
> drivers/net/ll_temac_main.c | 31 ++++++++++++++++++++-----------
> 2 files changed, 21 insertions(+), 11 deletions(-)
>
> diff -puN drivers/net/ll_temac.h~ll-temac-driver-add-non-virtex-5-support drivers/net/ll_temac.h
> --- a/drivers/net/ll_temac.h~ll-temac-driver-add-non-virtex-5-support
> +++ a/drivers/net/ll_temac.h
> @@ -338,6 +338,7 @@ struct temac_local {
> /* IO registers and IRQs */
> void __iomem *regs;
> dcr_host_t sdma_dcrs;
> + u32 __iomem *sdma_regs;
> int tx_irq;
> int rx_irq;
> int emac_num;
> diff -puN drivers/net/ll_temac_main.c~ll-temac-driver-add-non-virtex-5-support drivers/net/ll_temac_main.c
> --- a/drivers/net/ll_temac_main.c~ll-temac-driver-add-non-virtex-5-support
> +++ a/drivers/net/ll_temac_main.c
> @@ -20,9 +20,6 @@
> * or rx, so this should be okay.
> *
> * TODO:
> - * - Fix driver to work on more than just Virtex5. Right now the driver
> - * assumes that the locallink DMA registers are accessed via DCR
> - * instructions.
> * - Factor out locallink DMA code into separate driver
> * - Fix multicast assignment.
> * - Fix support for hardware checksumming.
> @@ -117,12 +114,20 @@ void temac_indirect_out32(struct temac_l
>
> static u32 temac_dma_in32(struct temac_local *lp, int reg)
> {
> - return dcr_read(lp->sdma_dcrs, reg);
> + if (lp->sdma_regs) {
> + return __raw_readl(lp->sdma_regs + reg);
> + } else {
> + return dcr_read(lp->sdma_dcrs, reg);
> + }
> }
>
> static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
> {
> - dcr_write(lp->sdma_dcrs, reg, value);
> + if (lp->sdma_regs) {
> + __raw_writel(value, lp->sdma_regs + reg);
> + } else {
> + dcr_write(lp->sdma_dcrs, reg, value);
> + }
> }
>
> /**
> @@ -870,13 +875,17 @@ temac_of_probe(struct of_device *op, con
> goto nodev;
> }
>
> - dcrs = dcr_resource_start(np, 0);
> - if (dcrs == 0) {
> - dev_err(&op->dev, "could not get DMA register address\n");
> + lp->sdma_regs = NULL;
> +
> + if ((dcrs = dcr_resource_start(np, 0)) != 0) {
> + lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
> + dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
> + } else if ((lp->sdma_regs = of_iomap(np, 0))) {
> + dev_dbg(&op->dev, "MEM base: %p\n", lp->sdma_regs);
> + } else {
> + dev_err(&op->dev, "unable to map DMA registers\n");
> goto nodev;
> }
> - lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
> - dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
>
> lp->rx_irq = irq_of_parse_and_map(np, 0);
> lp->tx_irq = irq_of_parse_and_map(np, 1);
> @@ -903,7 +912,7 @@ temac_of_probe(struct of_device *op, con
>
> lp->phy_node = of_parse_phandle(op->node, "phy-handle", 0);
> if (lp->phy_node)
> - dev_dbg(lp->dev, "using PHY node %s (%p)\n", np->full_name, np);
> + dev_dbg(lp->dev, "using PHY node %s (%p)\n", lp->phy_node->full_name, lp->phy_node);
>
> /* Add the device attributes */
> rc = sysfs_create_group(&lp->dev->kobj, &temac_attr_group);
> _
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: David Miller @ 2010-03-11 22:13 UTC (permalink / raw)
To: shemminger; +Cc: jengelh, netdev
In-Reply-To: <20100311140406.37ee0b83@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 11 Mar 2010 14:04:06 -0800
> That make sense, but maybe we shouldn't send IFLA_STATS64 on
> 32bit platforms.
Let's at least be optimistic that we'll be able to support 64-bit
stats on 32-bit at some point :-)
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: Jan Engelhardt @ 2010-03-11 22:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20100311140406.37ee0b83@nehalam>
On Thursday 2010-03-11 23:04, Stephen Hemminger wrote:
>> >> `ip -s link` shows interface counters truncated to 32 bit. This is
>> >> because interface statistics are transported only in 32-bit quantity
>> >> to userspace. This commit adds a new IFLA_STATS64 attribute that
>> >> exports them in full 64 bit.
>>
>> On 64-bit it has 64-bit counters, yet we only report 32-bit
>> counters to userspace via netlink even in that case.
>
>That make sense, but maybe we shouldn't send IFLA_STATS64 on
>32bit platforms.
Somehow I'd prefer to have consistency. Platform-specific
actions and/or payload I think we already were plagued enough by
syscalls and iptables. (Just to name two.)
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: Jan Engelhardt @ 2010-03-11 22:15 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20100311.141325.205780761.davem@davemloft.net>
On Thursday 2010-03-11 23:13, David Miller wrote:
>
>> That make sense, but maybe we shouldn't send IFLA_STATS64 on
>> 32bit platforms.
>
>Let's at least be optimistic that we'll be able to support 64-bit
>stats on 32-bit at some point :-)
I was about to say. There is hope: whenever you least expect it,
academia comes up with a perfectly foundated theory and plan to solve
the problem. (N.B.: But the initial implementation generally sucks ;-)
^ permalink raw reply
* Re: Fw: [Bug 15517] New: big file transfers stall and break network
From: Matt Carlson @ 2010-03-11 22:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100311084630.64b85696@nehalam>
On Thu, Mar 11, 2010 at 08:46:30AM -0800, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Thu, 11 Mar 2010 14:40:12 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 15517] New: big file transfers stall and break network
>
>
> http://bugzilla.kernel.org/show_bug.cgi?id=15517
>
> Summary: big file transfers stall and break network
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.32.9
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: conrad_s@rocketmail.com
> Regression: Yes
>
>
> Created an attachment (id=25475)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=25475)
> lspci output, from working 2.6.31
>
> Upgrading to kernel 2.6.32.9 on a 64-bit machine (Fedora 12,
> 2.6.32.9-67.fc12.x86_64) caused breakage in transfer of large files over SSH
> and SMB, followed by breaking network access.
>
> To reproduce, copy a large file (> 900 MB) using SSH or SMB (mounted either
> directly via "mount" or indirectly via "gfvs / nautilus"). Copy stalls and
> network becomes unusable (e.g. can't ssh to any other host).
>
> Previous kernel 2.6.31.12 (Fedora 12, 2.6.31.12-174.2.22.fc12.x86_64) works
> fine.
This is a 5906 chip bug that was exposed. Commit
92c6b8d16a36df3f28b2537bed2a56491fb08f11 fixes the problem. Mike Pagano
has already submitted this fix to stable.
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: Stephen Hemminger @ 2010-03-11 22:50 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: David Miller, netdev
In-Reply-To: <alpine.LSU.2.01.1003112305060.11569@obet.zrqbmnf.qr>
On Thu, 11 Mar 2010 23:13:18 +0100 (CET)
Jan Engelhardt <jengelh@medozas.de> wrote:
> On Thursday 2010-03-11 23:04, Stephen Hemminger wrote:
> >> >> `ip -s link` shows interface counters truncated to 32 bit. This is
> >> >> because interface statistics are transported only in 32-bit quantity
> >> >> to userspace. This commit adds a new IFLA_STATS64 attribute that
> >> >> exports them in full 64 bit.
> >>
> >> On 64-bit it has 64-bit counters, yet we only report 32-bit
> >> counters to userspace via netlink even in that case.
> >
> >That make sense, but maybe we shouldn't send IFLA_STATS64 on
> >32bit platforms.
>
> Somehow I'd prefer to have consistency. Platform-specific
> actions and/or payload I think we already were plagued enough by
> syscalls and iptables. (Just to name two.)
But if you send 32bit truncated values when 64 bit is expected
then users are going to complain
--
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: David Miller @ 2010-03-11 22:54 UTC (permalink / raw)
To: shemminger; +Cc: jengelh, netdev
In-Reply-To: <20100311145059.1a020e1c@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 11 Mar 2010 14:50:59 -0800
> But if you send 32bit truncated values when 64 bit is expected
> then users are going to complain
They already complain, a lot.
This isn't going to change the situation at all, and
I agree with Jan that consistency is the trumping factor
here.
^ permalink raw reply
* Re: [PATCH] net: davinci emac: use dma_{map, unmap}_single API for cache coherency
From: Kevin Hilman @ 2010-03-11 22:56 UTC (permalink / raw)
To: Sekhar Nori
Cc: srk-l0cyMroinI0, netdev-u79uwXL29TY76Z2rM5mHXA,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/
In-Reply-To: <1268133637-23399-1-git-send-email-nsekhar-l0cyMroinI0@public.gmane.org>
Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org> writes:
> The davinci emac driver uses some ARM specific DMA APIs
> for cache coherency which have been removed from kernel
> with the 2.6.34 merge.
>
> Modify the driver to use the dma_{map, unmap}_single() APIs
> defined in dma-mapping.h
>
> Without this fix, the driver fails to compile on Linus's
> tree.
>
> Tested on DM365 and OMAP-L138 EVMs.
>
> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
Verified that this is compiling/running again with v2.6.34-rc1.
Kevin
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: Stephen Hemminger @ 2010-03-11 23:10 UTC (permalink / raw)
To: David Miller; +Cc: jengelh, netdev
In-Reply-To: <20100311.145412.118613343.davem@davemloft.net>
On Thu, 11 Mar 2010 14:54:12 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 11 Mar 2010 14:50:59 -0800
>
> > But if you send 32bit truncated values when 64 bit is expected
> > then users are going to complain
>
> They already complain, a lot.
>
> This isn't going to change the situation at all, and
> I agree with Jan that consistency is the trumping factor
> here.
But if non utilities will already adapt to new/old kernel, so
just don't put out 64 bit values if the platform is 32 bit.
When/if 32 bit platforms support it, great add the extra stats.
--
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: David Miller @ 2010-03-11 23:15 UTC (permalink / raw)
To: shemminger; +Cc: jengelh, netdev
In-Reply-To: <20100311151050.31f8ad5d@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 11 Mar 2010 15:10:50 -0800
> But if non utilities will already adapt to new/old kernel, so
> just don't put out 64 bit values if the platform is 32 bit.
> When/if 32 bit platforms support it, great add the extra stats.
How about we just make userland ready for it and:
1) Emitting it now will get it tested even on 32-bit
2) They'll be ready when the drivers can keep track of
64-bit stats too.
Stephen I've heard your side of the story, I just don't
agree with it :-)
^ permalink raw reply
* Re: [PATCH 3/3] net: core: add IFLA_STATS64 support
From: Stephen Hemminger @ 2010-03-11 23:44 UTC (permalink / raw)
To: David Miller; +Cc: jengelh, netdev
In-Reply-To: <20100311.151529.16498686.davem@davemloft.net>
On Thu, 11 Mar 2010 15:15:29 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 11 Mar 2010 15:10:50 -0800
>
> > But if non utilities will already adapt to new/old kernel, so
> > just don't put out 64 bit values if the platform is 32 bit.
> > When/if 32 bit platforms support it, great add the extra stats.
>
> How about we just make userland ready for it and:
>
> 1) Emitting it now will get it tested even on 32-bit
>
> 2) They'll be ready when the drivers can keep track of
> 64-bit stats too.
>
> Stephen I've heard your side of the story, I just don't
> agree with it :-)
I'm okay with it. just raising the issue.
--
^ permalink raw reply
* [PATCH 10/13] RDS: only put sockets that have seen congestion on the poll_waitq
From: Andy Grover @ 2010-03-11 23:50 UTC (permalink / raw)
To: netdev; +Cc: rds-devel
In-Reply-To: <1268351407-7394-1-git-send-email-andy.grover@oracle.com>
rds_poll_waitq's listeners will be awoken if we receive a congestion
notification. Bad performance may result because *all* polled sockets
contend for this single lock. However, it should not be necessary to
wake pollers when a congestion update arrives if they have never
experienced congestion, and not putting these on the waitq will
hopefully greatly reduce contention.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
---
net/rds/af_rds.c | 7 ++++++-
net/rds/rds.h | 2 ++
net/rds/send.c | 4 +++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
index 853c52b..937ecda 100644
--- a/net/rds/af_rds.c
+++ b/net/rds/af_rds.c
@@ -159,7 +159,8 @@ static unsigned int rds_poll(struct file *file, struct socket *sock,
poll_wait(file, sk->sk_sleep, wait);
- poll_wait(file, &rds_poll_waitq, wait);
+ if (rs->rs_seen_congestion)
+ poll_wait(file, &rds_poll_waitq, wait);
read_lock_irqsave(&rs->rs_recv_lock, flags);
if (!rs->rs_cong_monitor) {
@@ -181,6 +182,10 @@ static unsigned int rds_poll(struct file *file, struct socket *sock,
mask |= (POLLOUT | POLLWRNORM);
read_unlock_irqrestore(&rs->rs_recv_lock, flags);
+ /* clear state any time we wake a seen-congested socket */
+ if (mask)
+ rs->rs_seen_congestion = 0;
+
return mask;
}
diff --git a/net/rds/rds.h b/net/rds/rds.h
index 85d6f89..4bec6e2 100644
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -388,6 +388,8 @@ struct rds_sock {
/* flag indicating we were congested or not */
int rs_congested;
+ /* seen congestion (ENOBUFS) when sending? */
+ int rs_seen_congestion;
/* rs_lock protects all these adjacent members before the newline */
spinlock_t rs_lock;
diff --git a/net/rds/send.c b/net/rds/send.c
index 192a480..51e2def 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -894,8 +894,10 @@ int rds_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
queue_delayed_work(rds_wq, &conn->c_conn_w, 0);
ret = rds_cong_wait(conn->c_fcong, dport, nonblock, rs);
- if (ret)
+ if (ret) {
+ rs->rs_seen_congestion = 1;
goto out;
+ }
while (!rds_send_queue_rm(rs, conn, rm, rs->rs_bound_port,
dport, &queued)) {
--
1.6.3.3
^ permalink raw reply related
* [PATCH 06/13] RDS: Fix send locking issue
From: Andy Grover @ 2010-03-11 23:50 UTC (permalink / raw)
To: netdev; +Cc: rds-devel, Tina Yang
In-Reply-To: <1268351407-7394-1-git-send-email-andy.grover@oracle.com>
From: Tina Yang <Tina.Yang@oracle.com>
Fix a deadlock between rds_rdma_send_complete() and
rds_send_remove_from_sock() when rds socket lock and
rds message lock are acquired out-of-order.
Signed-off-by: Tina Yang <Tina.Yang@oracle.com>
Signed-off-by: Andy Grover <andy.grover@oracle.com>
---
net/rds/send.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index ad2e469..1a2ef24 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -533,14 +533,13 @@ void rds_send_remove_from_sock(struct list_head *messages, int status)
if (rs != rm->m_rs) {
if (rs) {
- spin_unlock(&rs->rs_lock);
rds_wake_sk_sleep(rs);
sock_put(rds_rs_to_sk(rs));
}
rs = rm->m_rs;
- spin_lock(&rs->rs_lock);
sock_hold(rds_rs_to_sk(rs));
}
+ spin_lock(&rs->rs_lock);
if (test_and_clear_bit(RDS_MSG_ON_SOCK, &rm->m_flags)) {
struct rds_rdma_op *ro = rm->m_rdma_op;
@@ -560,6 +559,7 @@ void rds_send_remove_from_sock(struct list_head *messages, int status)
rds_message_put(rm);
rm->m_rs = NULL;
}
+ spin_unlock(&rs->rs_lock);
unlock_and_drop:
spin_unlock(&rm->m_rs_lock);
@@ -567,7 +567,6 @@ unlock_and_drop:
}
if (rs) {
- spin_unlock(&rs->rs_lock);
rds_wake_sk_sleep(rs);
sock_put(rds_rs_to_sk(rs));
}
--
1.6.3.3
^ permalink raw reply related
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