* [PATCH 4/13] cxgb3 - use immediate data for offload Tx
From: Divy Le Ray @ 2007-08-11 6:29 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Send small TX_DATA work requests as immediate data even when
there are fragments.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/sge.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 9213cda..dca2716 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1182,8 +1182,8 @@ int t3_eth_xmit(struct sk_buff *skb, struct net_device *dev)
*
* Writes a packet as immediate data into a Tx descriptor. The packet
* contains a work request at its beginning. We must write the packet
- * carefully so the SGE doesn't read accidentally before it's written in
- * its entirety.
+ * carefully so the SGE doesn't read it accidentally before it's written
+ * in its entirety.
*/
static inline void write_imm(struct tx_desc *d, struct sk_buff *skb,
unsigned int len, unsigned int gen)
@@ -1191,7 +1191,11 @@ static inline void write_imm(struct tx_desc *d, struct sk_buff *skb,
struct work_request_hdr *from = (struct work_request_hdr *)skb->data;
struct work_request_hdr *to = (struct work_request_hdr *)d;
- memcpy(&to[1], &from[1], len - sizeof(*from));
+ if (likely(!skb->data_len))
+ memcpy(&to[1], &from[1], len - sizeof(*from));
+ else
+ skb_copy_bits(skb, sizeof(*from), &to[1], len - sizeof(*from));
+
to->wr_hi = from->wr_hi | htonl(F_WR_SOP | F_WR_EOP |
V_WR_BCNTLFLT(len & 7));
wmb();
@@ -1261,7 +1265,7 @@ static inline void reclaim_completed_tx_imm(struct sge_txq *q)
static inline int immediate(const struct sk_buff *skb)
{
- return skb->len <= WR_LEN && !skb->data_len;
+ return skb->len <= WR_LEN;
}
/**
@@ -1467,12 +1471,13 @@ static void write_ofld_wr(struct adapter *adap, struct sk_buff *skb,
*/
static inline unsigned int calc_tx_descs_ofld(const struct sk_buff *skb)
{
- unsigned int flits, cnt = skb_shinfo(skb)->nr_frags;
+ unsigned int flits, cnt;
- if (skb->len <= WR_LEN && cnt == 0)
+ if (skb->len <= WR_LEN)
return 1; /* packet fits as immediate data */
flits = skb_transport_offset(skb) / 8; /* headers */
+ cnt = skb_shinfo(skb)->nr_frags;
if (skb->tail != skb->transport_header)
cnt++;
return flits_to_desc(flits + sgl_len(cnt));
^ permalink raw reply related
* [PATCH 3/13] cxgb3 - SGE doorbell overflow warning
From: Divy Le Ray @ 2007-08-11 6:29 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Log doorbell Fifo overflow
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/regs.h | 8 ++++++++
drivers/net/cxgb3/sge.c | 4 ++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index aa80313..2824278 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -172,6 +172,14 @@
#define A_SG_INT_CAUSE 0x5c
+#define S_HIPIODRBDROPERR 11
+#define V_HIPIODRBDROPERR(x) ((x) << S_HIPIODRBDROPERR)
+#define F_HIPIODRBDROPERR V_HIPIODRBDROPERR(1U)
+
+#define S_LOPIODRBDROPERR 10
+#define V_LOPIODRBDROPERR(x) ((x) << S_LOPIODRBDROPERR)
+#define F_LOPIODRBDROPERR V_LOPIODRBDROPERR(1U)
+
#define S_RSPQDISABLED 3
#define V_RSPQDISABLED(x) ((x) << S_RSPQDISABLED)
#define F_RSPQDISABLED V_RSPQDISABLED(1U)
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index a2cfd68..9213cda 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -2476,6 +2476,10 @@ void t3_sge_err_intr_handler(struct adapter *adapter)
"(0x%x)\n", (v >> S_RSPQ0DISABLED) & 0xff);
}
+ if (status & (F_HIPIODRBDROPERR | F_LOPIODRBDROPERR))
+ CH_ALERT(adapter, "SGE dropped %s priority doorbell\n",
+ status & F_HIPIODRBDROPERR ? "high" : "lo");
+
t3_write_reg(adapter, A_SG_INT_CAUSE, status);
if (status & (F_RSPQCREDITOVERFOW | F_RSPQDISABLED))
t3_fatal_err(adapter);
^ permalink raw reply related
* [PATCH 2/13] cxgb3 - Update rx coalescing length
From: Divy Le Ray @ 2007-08-11 6:29 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Set max Rx coalescing length to 12288
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/common.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index c46c249..55922ed 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -104,7 +104,7 @@ enum {
PROTO_SRAM_LINES = 128, /* size of TP sram */
};
-#define MAX_RX_COALESCING_LEN 16224U
+#define MAX_RX_COALESCING_LEN 12288U
enum {
PAUSE_RX = 1 << 0,
^ permalink raw reply related
* [PATCH 1/13] cxgb3 - MAC workaround update
From: Divy Le Ray @ 2007-08-11 6:29 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Update the MAC workaround to deal with switches that do not
honor pause frames.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/common.h | 1 +
drivers/net/cxgb3/xgmac.c | 22 +++++++++++-----------
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 1637800..c46c249 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -507,6 +507,7 @@ struct cmac {
unsigned int tx_xcnt;
u64 tx_mcnt;
unsigned int rx_xcnt;
+ unsigned int rx_ocnt;
u64 rx_mcnt;
unsigned int toggle_cnt;
unsigned int txen;
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net/cxgb3/xgmac.c
index c302b1a..1d1c391 100644
--- a/drivers/net/cxgb3/xgmac.c
+++ b/drivers/net/cxgb3/xgmac.c
@@ -437,12 +437,13 @@ int t3_mac_enable(struct cmac *mac, int which)
struct mac_stats *s = &mac->stats;
if (which & MAC_DIRECTION_TX) {
- t3_write_reg(adap, A_XGM_TX_CTRL + oft, F_TXEN);
t3_write_reg(adap, A_TP_PIO_ADDR, A_TP_TX_DROP_CFG_CH0 + idx);
t3_write_reg(adap, A_TP_PIO_DATA, 0xc0ede401);
t3_write_reg(adap, A_TP_PIO_ADDR, A_TP_TX_DROP_MODE);
t3_set_reg_field(adap, A_TP_PIO_DATA, 1 << idx, 1 << idx);
+ t3_write_reg(adap, A_XGM_TX_CTRL + oft, F_TXEN);
+
t3_write_reg(adap, A_TP_PIO_ADDR, A_TP_TX_DROP_CNT_CH0 + idx);
mac->tx_mcnt = s->tx_frames;
mac->tx_tcnt = (G_TXDROPCNTCH0RCVD(t3_read_reg(adap,
@@ -454,6 +455,7 @@ int t3_mac_enable(struct cmac *mac, int which)
mac->rx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_RX_SPI4_SOP_EOP_CNT +
oft)));
+ mac->rx_ocnt = s->rx_fifo_ovfl;
mac->txen = F_TXEN;
mac->toggle_cnt = 0;
}
@@ -464,24 +466,19 @@ int t3_mac_enable(struct cmac *mac, int which)
int t3_mac_disable(struct cmac *mac, int which)
{
- int idx = macidx(mac);
struct adapter *adap = mac->adapter;
- int val;
if (which & MAC_DIRECTION_TX) {
t3_write_reg(adap, A_XGM_TX_CTRL + mac->offset, 0);
- t3_write_reg(adap, A_TP_PIO_ADDR, A_TP_TX_DROP_CFG_CH0 + idx);
- t3_write_reg(adap, A_TP_PIO_DATA, 0xc000001f);
- t3_write_reg(adap, A_TP_PIO_ADDR, A_TP_TX_DROP_MODE);
- t3_set_reg_field(adap, A_TP_PIO_DATA, 1 << idx, 1 << idx);
mac->txen = 0;
}
if (which & MAC_DIRECTION_RX) {
+ int val = F_MAC_RESET_;
+
t3_set_reg_field(mac->adapter, A_XGM_RESET_CTRL + mac->offset,
F_PCS_RESET_, 0);
msleep(100);
t3_write_reg(adap, A_XGM_RX_CTRL + mac->offset, 0);
- val = F_MAC_RESET_;
if (is_10G(adap))
val |= F_PCS_RESET_;
else if (uses_xaui(adap))
@@ -541,11 +538,14 @@ int t3b2_mac_watchdog_task(struct cmac *mac)
}
rxcheck:
- if (rx_mcnt != mac->rx_mcnt)
+ if (rx_mcnt != mac->rx_mcnt) {
rx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_RX_SPI4_SOP_EOP_CNT +
- mac->offset)));
- else
+ mac->offset))) +
+ (s->rx_fifo_ovfl -
+ mac->rx_ocnt);
+ mac->rx_ocnt = s->rx_fifo_ovfl;
+ } else
goto out;
if (mac->rx_mcnt != s->rx_frames && rx_xcnt == 0 &&
^ permalink raw reply related
* Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
From: Valdis.Kletnieks @ 2007-08-11 4:38 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Herbert Xu, paulmck, heiko.carstens, horms, linux-kernel, csnook,
rpjday, netdev, ak, cfriesen, akpm, torvalds, jesper.juhl,
linux-arch, zlynx, schwidefsky, davem, wensong, wjiang
In-Reply-To: <ef7e94b08a6515d33039d187e04db5db@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
On Sat, 11 Aug 2007 02:38:40 +0200, Segher Boessenkool said:
> >> That means GCC cannot compile Linux; it already optimises
> >> some accesses to scalars to smaller accesses when it knows
> >> it is allowed to. Not often though, since it hardly ever
> >> helps in the cost model it employs.
> >
> > Please give an example code snippet + gcc version + arch
> > to back this up.
>
> unsigned char f(unsigned long *p)
> {
> return *p & 1;
> }
Not really valid, because it's still able to do one atomic access to
compute the result.
Now, if you had found an example where it converts a 32-bit atomic access into
2 separate 16-bit accesses that weren't atomic as a whole....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: Paul E. McKenney @ 2007-08-11 4:29 UTC (permalink / raw)
To: Herbert Xu
Cc: Chris Snook, dhowells, linux-kernel, linux-arch, torvalds, netdev,
akpm, ak, heiko.carstens, davem, schwidefsky, wensong, horms,
wjiang, cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <E1IJfFe-0003Sq-00@gondolin.me.apana.org.au>
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
> Chris Snook <csnook@redhat.com> wrote:
> >
> > cpu_relax() contains a barrier, so it should do the right thing. For
> > non-smp architectures, I'm concerned about interacting with interrupt
> > handlers. Some drivers do use atomic_* operations.
>
> What problems with interrupt handlers? Access to int/long must
> be atomic or we're in big trouble anyway.
Reordering due to compiler optimizations. CPU reordering does not
affect interactions with interrupt handlers on a given CPU, but
reordering due to compiler code-movement optimization does. Since
volatile can in some cases suppress code-movement optimizations,
it can affect interactions with interrupt handlers.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] b44-ssb: Fix the SSB dependency hell
From: Adrian Bunk @ 2007-08-11 1:41 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Buesch, John Linville, Andrew Morton, Linux Netdev List
In-Reply-To: <1186793856.4862.16.camel@johannes.berg>
On Sat, Aug 11, 2007 at 02:57:36AM +0200, Johannes Berg wrote:
> On Sat, 2007-08-11 at 02:43 +0200, Adrian Bunk wrote:
>
> > -ENOMENUCONFIGPATCH
>
> Has anybody decided how it could possibly even look like anyhow? It
> should be fixed, but nobody has a plan.
The simplest idea would be that an option select'ing some other option
inherits the dependencies of the latter. That should fix all problems
select currently has.
There are for sure some problems hidden that will show up during
implementation, but since noone is implementing it we'll never know...
> > That's horrible - you shouldn't force the user to manually enable three
> > options.
>
> Well, akpm says: "select is broken. do not ever use it"
select works fine if you understand the pitfalls.
Kconfig is a _user interface_, and making using it easy for the user
is therefore important.
Whenever there's a mistake in a help text or something confusing
users will run into problems with the kernel they compiled.
> > config SSB_PCIHOST_POSSIBLE
> [...]
>
> > depends on SSB_PCIHOST_POSSIBLE
> > select SSB
> > select SSB_PCIHOST
>
> That would, indeed, be possible. But it's ... ugly ... you've now
> effectively pushed the information on what *SSB* depends on into each
> SSB *user* instead of SSB itself...
No, this information is still in drivers/ssb/Kconfig.
This would replace:
config B44
depends on SSB_PCIHOST
with:
config B44
depends on SSB_PCIHOST_POSSIBLE
select SSB_PCIHOST
That's an easily understandable pattern without redundant information
about the required dependencies of SSB_PCIHOST.
> > Is there any extremely good reason why options like SSB or SSB_PCIHOST
> > have to be user visible?
>
> Yes. Embedded systems like the small Linksys routers come with SSB as
> the system bus. No PCI/PCIHOST.
OK.
> > And according to the kconfig help text, we should remove the B44_PCI
> > option and enable the code unconditionally?
> > (Or what was the person writing this help text smoking^Wthinking when
> > writing it?)
>
> Same reason. They have a b44 core there but no pci.
OK, that's understandable.
But the kconfig user currently only gets:
config B44_PCI
bool "Broadcom 440x PCI device support"
...
help
Support for Broadcom 440x PCI devices.
Say Y, unless you know what you are doing.
If you say N here I will _not_ listen to your
bugreports!
An example how to make it better:
config USB_OHCI_HCD_SSB
bool "OHCI support for the Broadcom SSB OHCI core (embedded systems only)"
...
help
Support for the Sonics Silicon Backplane (SSB) attached
Broadcom USB OHCI core.
This device is only present in some embedded devices with
Broadcom based SSB bus.
If unsure, say N.
That's the difference between a silly sounding help text ("I will _not_
listen to your bugreports!") and a help text that gives the kconfig user
all required information ("only present in some embedded devices").
And I'm not yet convinced B44_PCI is really worth bothering the user
with - what about automatically enabling PCI support in the driver if
PCI support is enabled in the kernel?
> johannes
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] b44-ssb: Fix the SSB dependency hell
From: Johannes Berg @ 2007-08-11 0:57 UTC (permalink / raw)
To: Adrian Bunk
Cc: Michael Buesch, John Linville, Andrew Morton, Linux Netdev List
In-Reply-To: <20070811004341.GA22213@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
On Sat, 2007-08-11 at 02:43 +0200, Adrian Bunk wrote:
> -ENOMENUCONFIGPATCH
Has anybody decided how it could possibly even look like anyhow? It
should be fixed, but nobody has a plan.
> That's horrible - you shouldn't force the user to manually enable three
> options.
Well, akpm says: "select is broken. do not ever use it"
> config SSB_PCIHOST_POSSIBLE
[...]
> depends on SSB_PCIHOST_POSSIBLE
> select SSB
> select SSB_PCIHOST
That would, indeed, be possible. But it's ... ugly ... you've now
effectively pushed the information on what *SSB* depends on into each
SSB *user* instead of SSB itself...
> Is there any extremely good reason why options like SSB or SSB_PCIHOST
> have to be user visible?
Yes. Embedded systems like the small Linksys routers come with SSB as
the system bus. No PCI/PCIHOST.
> And according to the kconfig help text, we should remove the B44_PCI
> option and enable the code unconditionally?
> (Or what was the person writing this help text smoking^Wthinking when
> writing it?)
Same reason. They have a b44 core there but no pci.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: Herbert Xu @ 2007-08-11 0:54 UTC (permalink / raw)
To: Chris Snook
Cc: dhowells, linux-kernel, linux-arch, torvalds, netdev, akpm, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46BCC26B.6080600@redhat.com>
Chris Snook <csnook@redhat.com> wrote:
>
> cpu_relax() contains a barrier, so it should do the right thing. For
> non-smp architectures, I'm concerned about interacting with interrupt
> handlers. Some drivers do use atomic_* operations.
What problems with interrupt handlers? Access to int/long must
be atomic or we're in big trouble anyway.
Cheers,
--
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 1/24] make atomic_read() behave consistently on alpha
From: Segher Boessenkool @ 2007-08-11 0:50 UTC (permalink / raw)
To: Herbert Xu
Cc: paulmck, heiko.carstens, horms, linux-kernel, csnook, rpjday,
netdev, ak, cfriesen, akpm, torvalds, jesper.juhl, linux-arch,
zlynx, schwidefsky, davem, wensong, wjiang
In-Reply-To: <20070811004322.GA13178@gondor.apana.org.au>
>>>> That means GCC cannot compile Linux; it already optimises
>>>> some accesses to scalars to smaller accesses when it knows
>>>> it is allowed to. Not often though, since it hardly ever
>>>> helps in the cost model it employs.
>>>
>>> Please give an example code snippet + gcc version + arch
>>> to back this up.
>>
>> unsigned char f(unsigned long *p)
>> {
>> return *p & 1;
>> }
>
> This doesn't really matter since we only care about the LSB.
It is exactly what I claimed, and what you asked proof of.
> Do you have an example where gcc reads it non-atmoically and
> we care about all parts?
Like I explained in the original mail; no, I suspect such
a testcase will be really hard to construct, esp. as a small
testcase. I have no reason to believe it is impossible to
do so though -- maybe someone else can write trickier code
than I can, in which case, please do so.
Segher
^ permalink raw reply
* Re: [stable] [RFT] sky2: backport patch
From: Greg KH @ 2007-08-11 0:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, stable, Krzysztof Oledzki
In-Reply-To: <20070807171415.6892a070@oldman>
On Tue, Aug 07, 2007 at 05:14:15PM -0400, Stephen Hemminger wrote:
> Any volunteers to test this, it has a backport for the three main stability patches:
> 1. carrier management
> 2. lost irq timer
> 3. rechecking for packets in poll
> 4. overlength packet hang.
>
> I am away from any sky2 hardware for another week, but others maybe
> able to validate this.
Care to break these down into 3 patches and send them to stable@ if you
get the chance?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
From: Herbert Xu @ 2007-08-11 0:43 UTC (permalink / raw)
To: Segher Boessenkool
Cc: paulmck, heiko.carstens, horms, linux-kernel, csnook, rpjday,
netdev, ak, cfriesen, akpm, torvalds, jesper.juhl, linux-arch,
zlynx, schwidefsky, davem, wensong, wjiang
In-Reply-To: <ef7e94b08a6515d33039d187e04db5db@kernel.crashing.org>
On Sat, Aug 11, 2007 at 02:38:40AM +0200, Segher Boessenkool wrote:
> >>That means GCC cannot compile Linux; it already optimises
> >>some accesses to scalars to smaller accesses when it knows
> >>it is allowed to. Not often though, since it hardly ever
> >>helps in the cost model it employs.
> >
> >Please give an example code snippet + gcc version + arch
> >to back this up.
>
> unsigned char f(unsigned long *p)
> {
> return *p & 1;
> }
This doesn't really matter since we only care about the LSB.
Do you have an example where gcc reads it non-atmoically and
we care about all parts?
Cheers,
--
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] b44-ssb: Fix the SSB dependency hell
From: Adrian Bunk @ 2007-08-11 0:43 UTC (permalink / raw)
To: Michael Buesch; +Cc: John Linville, Andrew Morton, Linux Netdev List
In-Reply-To: <200708110208.21624.mb@bu3sch.de>
On Sat, Aug 11, 2007 at 02:08:21AM +0200, Michael Buesch wrote:
> This fixes the SSB dependency hell and introduces some
> fake-options that only give some advice on what to select.
>
> We live with these fake options only until menuconfig is able
> to tell more about needed dependencies and how to resolve them.
>...
-ENOMENUCONFIGPATCH
IOW: $t\rightarrow\infty$
> +config B44_ADVICE_HACK
> + bool "B44 for PCI not available. Read the help text of this option!"
> + depends on !B44_DEP_HACK
> + ---help---
> + The Broadcom 440x/47xx driver for PCI devices can not be enabled,
> + because the required dependencies are not selected.
> +
> + In order to be able to select the Broadcom 440x/47xx PCI driver, you
> + need to enable the following options first:
> +
> + CONFIG_SSB found in menu:
> + Device Drivers/Sonics Silicon Backplane/Sonics Silicon Backplane support
> + CONFIG_SSB_PCIHOST found in menu:
> + Device Drivers/Sonics Silicon Backplane/Support for SSB on PCI-bus host
> + CONFIG_SSB_DRIVER_PCICORE found in menu:
> + Device Drivers/Sonics Silicon Backplane/SSB PCI core driver
> +
>...
That's horrible - you shouldn't force the user to manually enable three
options.
What is the problem you are trying to solve?
The dependencies of SSB?
There are less horrible solutions for this issue, e.g. [1]:
drivers/ssb/Kconfig:
config SSB_POSSIBLE
bool
depends on EXPERIMENTAL && HAS_IOMEM
config SSB
tristate
config SSB_PCIHOST_POSSIBLE
bool
depends on SSB_POSSIBLE && PCI
config SSB_PCIHOST
bool
drivers/net/Kconfig:
config B44
tristate "Broadcom 440x/47xx ethernet support"
depends on SSB_PCIHOST_POSSIBLE
select SSB
select SSB_PCIHOST
I can make a complete patch for the SSB options, but I need some
pieces of information before starting:
Is there any extremely good reason why options like SSB or SSB_PCIHOST
have to be user visible?
And according to the kconfig help text, we should remove the B44_PCI
option and enable the code unconditionally?
(Or what was the person writing this help text smoking^Wthinking when
writing it?)
cu
Adrian
[1] incomplete example for demonstrating an idea
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
From: Segher Boessenkool @ 2007-08-11 0:38 UTC (permalink / raw)
To: Herbert Xu
Cc: paulmck, heiko.carstens, horms, linux-kernel, csnook, rpjday,
netdev, ak, cfriesen, akpm, torvalds, jesper.juhl, linux-arch,
zlynx, schwidefsky, davem, wensong, wjiang
In-Reply-To: <20070811000029.GA12779@gondor.apana.org.au>
>> That means GCC cannot compile Linux; it already optimises
>> some accesses to scalars to smaller accesses when it knows
>> it is allowed to. Not often though, since it hardly ever
>> helps in the cost model it employs.
>
> Please give an example code snippet + gcc version + arch
> to back this up.
unsigned char f(unsigned long *p)
{
return *p & 1;
}
with both
powerpc64-linux-gcc (GCC) 4.3.0 20070731 (experimental)
and
powerpc64-linux-gcc-4.2.0 (GCC) 4.2.0
(sorry, I don't have anything newer or older right now; if you
really care, I can test with those too)
generate (in 64-bit mode):
.L.f:
lbz 3,7(3)
rldicl 3,3,0,63
blr
and in 32-bit mode:
f:
stwu 1,-16(1)
nop
nop
lbz 3,3(3)
addi 1,1,16
rlwinm 3,3,0,31,31
blr
(the nops are because I use --with-cpu=970).
But perhaps you do not care for PowerPC, in which case:
i686-linux-gcc (GCC) 4.2.0 20060410 (experimental)
(sorry for the old version, I don't build x86 compilers
all that often; also I don't have a 64-bit version right
now):
f:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
popl %ebp
movzbl (%eax), %eax
andl $1, %eax
ret
If you want testing with any other versions, and/or for
any other target architecture, I can do that; it takes a
few minutes to build a compiler.
It is quite hard to build a testcase that reads more than
one part of the "long", since for small testcases the
compiler will almost always be smart enough to do one
bigger read instead; but it certainly isn't inconceivable,
and anyway the compiler would be fully in its right to do
reads non-atomically if not instructed otherwise.
Segher
^ permalink raw reply
* Re: [PATCH for 2.6.24] SCTP: Rewrite of sctp buffer management code
From: Neil Horman @ 2007-08-11 0:35 UTC (permalink / raw)
To: David Miller; +Cc: vladislav.yasevich, netdev, lksctp-developers
In-Reply-To: <20070810.163759.48396729.davem@davemloft.net>
On Fri, Aug 10, 2007 at 04:37:59PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Fri, 10 Aug 2007 19:01:26 -0400
>
> > Thanks for applying this Dave, but something seems to have occured during your
> > application. The commitdiff:
> > http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.24.git;a=commitdiff;h=e20e5d698dcccd2e84ee2e1e482b0b203f885c00
> > only shows applications to socket.c, while the patch that vlad sent you changed
> > much more than that.
>
> Vlad's posted patch only had the socket.c changes, that's the
> problem. I just double checked in the archives on marc.info
>
> I'm reverting this, please sort this out.
Vlad, this looks hosed in the same way in your lksctp-dev tree as well (Sorry I
didn't notice that sooner). Can you dig the patch out of the lksctp archives?
Or shall I repost it to you?
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@tuxdriver.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
^ permalink raw reply
* Re: [PATCH 9/24] make atomic_read() behave consistently on ia64
From: Paul Mackerras @ 2007-08-11 0:35 UTC (permalink / raw)
To: Chris Snook
Cc: Linus Torvalds, Luck, Tony, Andreas Schwab, linux-kernel,
linux-arch, netdev, akpm, ak, heiko.carstens, davem, schwidefsky,
wensong, horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46BCF19E.5000702@redhat.com>
Chris Snook writes:
> I'll do this for the whole patchset. Stay tuned for the resubmit.
Could you incorporate Segher's patch to turn atomic_{read,set} into
asm on powerpc? Segher claims that using asm is really the only
reliable way to ensure that gcc does what we want, and he seems to
have a point.
Paul.
^ permalink raw reply
* [PATCH] b44-ssb: Fix the SSB dependency hell
From: Michael Buesch @ 2007-08-11 0:08 UTC (permalink / raw)
To: John Linville; +Cc: Andrew Morton, Linux Netdev List
This fixes the SSB dependency hell and introduces some
fake-options that only give some advice on what to select.
We live with these fake options only until menuconfig is able
to tell more about needed dependencies and how to resolve them.
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
--
I think this should be merged into the ssb branch of
wireless-dev, unless you plan to maintain a seperate branch
for b44-ssb. But I think merging it with the ssb core is
probably OK.
Index: wireless-dev/drivers/net/Kconfig
===================================================================
--- wireless-dev.orig/drivers/net/Kconfig 2007-08-10 13:40:34.000000000 +0200
+++ wireless-dev/drivers/net/Kconfig 2007-08-10 13:42:18.000000000 +0200
@@ -1452,10 +1452,31 @@ config APRICOT
<file:Documentation/networking/net-modules.txt>. The module will be
called apricot.
+config B44_DEP_HACK
+ bool
+ depends on SSB && SSB_PCIHOST && SSB_DRIVER_PCICORE
+ default y
+
+config B44_ADVICE_HACK
+ bool "B44 for PCI not available. Read the help text of this option!"
+ depends on !B44_DEP_HACK
+ ---help---
+ The Broadcom 440x/47xx driver for PCI devices can not be enabled,
+ because the required dependencies are not selected.
+
+ In order to be able to select the Broadcom 440x/47xx PCI driver, you
+ need to enable the following options first:
+
+ CONFIG_SSB found in menu:
+ Device Drivers/Sonics Silicon Backplane/Sonics Silicon Backplane support
+ CONFIG_SSB_PCIHOST found in menu:
+ Device Drivers/Sonics Silicon Backplane/Support for SSB on PCI-bus host
+ CONFIG_SSB_DRIVER_PCICORE found in menu:
+ Device Drivers/Sonics Silicon Backplane/SSB PCI core driver
+
config B44
tristate "Broadcom 440x/47xx ethernet support"
- depends on HAS_IOMEM
- select SSB
+ depends on SSB
select MII
help
If you have a network (Ethernet) controller of this type, say Y
@@ -1473,9 +1494,7 @@ config B44
config B44_PCI
bool "Broadcom 440x PCI device support"
- depends on B44 && NET_PCI
- select SSB_PCIHOST
- select SSB_DRIVER_PCICORE
+ depends on B44 && SSB_PCIHOST && SSB_DRIVER_PCICORE && NET_PCI
default y
help
Support for Broadcom 440x PCI devices.
^ permalink raw reply
* Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
From: Herbert Xu @ 2007-08-11 0:00 UTC (permalink / raw)
To: Segher Boessenkool
Cc: paulmck, heiko.carstens, horms, linux-kernel, csnook, rpjday,
netdev, ak, cfriesen, akpm, torvalds, jesper.juhl, linux-arch,
zlynx, schwidefsky, davem, wensong, wjiang
In-Reply-To: <442f95ba19f8622ce04cf0334f34be11@kernel.crashing.org>
On Fri, Aug 10, 2007 at 10:07:27PM +0200, Segher Boessenkool wrote:
>
> That means GCC cannot compile Linux; it already optimises
> some accesses to scalars to smaller accesses when it knows
> it is allowed to. Not often though, since it hardly ever
> helps in the cost model it employs.
Please give an example code snippet + gcc version + arch
to back this up.
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
* net-2.6.24 being rebased...
From: David Miller @ 2007-08-10 23:55 UTC (permalink / raw)
To: netdev
Because of the SCTP patch messup, I'm rebasing the net-2.6.24 tree in
order to dike that patch out.
Sorry for any inconvenience this might cause :-/
^ permalink raw reply
* Re: [patch 03/18] drivers/net/ns83820.c: add paramter to disable autonegotiation
From: Andrew Morton @ 2007-08-10 23:45 UTC (permalink / raw)
To: Logix -; +Cc: Benjamin LaHaise, jeff, netdev, dan, jgarzik
In-Reply-To: <506359130708101552n5023c81dvdb314bec26e70925@mail.gmail.com>
On Sat, 11 Aug 2007 00:52:38 +0200
"Logix -" <thelogix@gmail.com> wrote:
> On 8/11/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > > [akpm: this is a previously-nacked patch, but the problem is real]
> >
> > I think I'll drop the whole patch. I've been nursing the thing along for
> > 1.5 years and I don't recall seeing any reports of any bugs which it would
> > have fixed anyway.
> >
>
> Except, using this card for sniffing using a passive fiber-tap cant be done,
> since with autoneg enabled, the card is set on half-duplex. Might not be a
> bug, but definitely a problem for me. But if im the only one in the world
> who needs this, so be it.
>
Feel free to send a new patch. It could be based on this one, but please
review the comments which people have had when this patch was sent on
earlier occasions.
http://marc.info/?l=linux-netdev&w=2&r=1&s=add+paramter+to+disable+autonegotiation&q=b is a decent start.
Thanks.
^ permalink raw reply
* Re: [patch 27/28] Introduce U16_MAX and U32_MAX
From: Andrew Morton @ 2007-08-10 23:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, satyam
In-Reply-To: <20070810.153819.76325424.davem@davemloft.net>
On Fri, 10 Aug 2007 15:38:19 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: akpm@linux-foundation.org
> Date: Fri, 10 Aug 2007 14:12:10 -0700
>
> > From: Satyam Sharma <satyam@infradead.org>
> >
> > ... in kernel.h and clean up home-grown macros elsewhere in the tree.
> >
> > Leave out the one in reiserfs_fs.h as it is in the userspace-visible part
> > of that header. Still, #undef the (equivalent) kernel version there to
> > avoid seeing "redefined, previous definition was here" gcc warnings.
> >
> > [akpm@linux-foundation.org: fix U16_MAX, U32_MAX defns]
> > Signed-off-by: Satyam Sharma <satyam@infradead.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> I won't apply this one, for two reasons:
>
> 1) The reiserfs definition is better, it is _type_ based.
> Please use (~(__u16)0) and (~(__u32)0), respectively.
>
> 2) The reiserfs definition is going to define an equivalent
> value, so just adding an #undef and still letting reiserfs
> override is wrong. Why put a common define in kernel.h
> if other headers still keep their own crufty copy too?
OK, I made those changes. Will add to the next batch->davem.
I note that reiserfs has open-coded (~(__u64) 0) in there too...
From: Satyam Sharma <satyam@infradead.org>
... in kernel.h and clean up home-grown macros elsewhere in the tree.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/netconsole.c | 7 +++----
include/linux/kernel.h | 3 +++
include/linux/reiserfs_fs.h | 2 --
net/ipv4/tcp_illinois.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff -puN drivers/net/netconsole.c~introduce-u16_max-and-u32_max drivers/net/netconsole.c
--- a/drivers/net/netconsole.c~introduce-u16_max-and-u32_max
+++ a/drivers/net/netconsole.c
@@ -34,6 +34,7 @@
*
****************************************************************/
+#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/init.h>
#include <linux/module.h>
@@ -389,7 +390,6 @@ static ssize_t store_local_port(struct n
size_t count)
{
long local_port;
-#define __U16_MAX ((__u16) ~0U)
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
@@ -398,7 +398,7 @@ static ssize_t store_local_port(struct n
return -EINVAL;
}
- local_port = strtol10_check_range(buf, 0, __U16_MAX);
+ local_port = strtol10_check_range(buf, 0, U16_MAX);
if (local_port < 0)
return local_port;
@@ -412,7 +412,6 @@ static ssize_t store_remote_port(struct
size_t count)
{
long remote_port;
-#define __U16_MAX ((__u16) ~0U)
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
@@ -421,7 +420,7 @@ static ssize_t store_remote_port(struct
return -EINVAL;
}
- remote_port = strtol10_check_range(buf, 0, __U16_MAX);
+ remote_port = strtol10_check_range(buf, 0, U16_MAX);
if (remote_port < 0)
return remote_port;
diff -puN include/linux/kernel.h~introduce-u16_max-and-u32_max include/linux/kernel.h
--- a/include/linux/kernel.h~introduce-u16_max-and-u32_max
+++ a/include/linux/kernel.h
@@ -30,6 +30,9 @@ extern const char linux_proc_banner[];
#define LLONG_MIN (-LLONG_MAX - 1)
#define ULLONG_MAX (~0ULL)
+#define U16_MAX (~(__u16)0)
+#define U32_MAX (~(__u32)0)
+
#define STACK_MAGIC 0xdeadbeef
#define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1)
diff -puN include/linux/reiserfs_fs.h~introduce-u16_max-and-u32_max include/linux/reiserfs_fs.h
--- a/include/linux/reiserfs_fs.h~introduce-u16_max-and-u32_max
+++ a/include/linux/reiserfs_fs.h
@@ -1225,8 +1225,6 @@ struct treepath var = {.path_length = IL
#define MAX_US_INT 0xffff
// reiserfs version 2 has max offset 60 bits. Version 1 - 32 bit offset
-#define U32_MAX (~(__u32)0)
-
static inline loff_t max_reiserfs_offset(struct inode *inode)
{
if (get_inode_item_key_version(inode) == KEY_FORMAT_3_5)
diff -puN net/ipv4/tcp_illinois.c~introduce-u16_max-and-u32_max net/ipv4/tcp_illinois.c
--- a/net/ipv4/tcp_illinois.c~introduce-u16_max-and-u32_max
+++ a/net/ipv4/tcp_illinois.c
@@ -12,6 +12,7 @@
* Copyright (C) 2007 Stephen Hemminger <shemminger@linux-foundation.org>
*/
+#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/skbuff.h>
#include <linux/inet_diag.h>
@@ -23,7 +24,6 @@
#define ALPHA_MIN ((3*ALPHA_SCALE)/10) /* ~0.3 */
#define ALPHA_MAX (10*ALPHA_SCALE) /* 10.0 */
#define ALPHA_BASE ALPHA_SCALE /* 1.0 */
-#define U32_MAX ((u32)~0U)
#define RTT_MAX (U32_MAX / ALPHA_MAX) /* 3.3 secs */
#define BETA_SHIFT 6
_
^ permalink raw reply
* Re: [PATCH for 2.6.24] SCTP: Rewrite of sctp buffer management code
From: David Miller @ 2007-08-10 23:37 UTC (permalink / raw)
To: nhorman; +Cc: vladislav.yasevich, netdev, lksctp-developers
In-Reply-To: <20070810230126.GB3983@hmsreliant.homelinux.net>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 10 Aug 2007 19:01:26 -0400
> Thanks for applying this Dave, but something seems to have occured during your
> application. The commitdiff:
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.24.git;a=commitdiff;h=e20e5d698dcccd2e84ee2e1e482b0b203f885c00
> only shows applications to socket.c, while the patch that vlad sent you changed
> much more than that.
Vlad's posted patch only had the socket.c changes, that's the
problem. I just double checked in the archives on marc.info
I'm reverting this, please sort this out.
^ permalink raw reply
* RE: [PATCH 9/24] make atomic_read() behave consistently on ia64
From: Luck, Tony @ 2007-08-10 23:32 UTC (permalink / raw)
To: Luck, Tony, Chris Snook
Cc: Andreas Schwab, linux-kernel, linux-arch, torvalds, netdev, akpm,
ak, heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46BCE9F8.4060009@redhat.com>
> Here are the functions in which they occur in the object file. You
> may have to chase down some inlining to find the function that
> actually uses atomic_*().
Ignore this ... Andreas' patch was only two lines so I
thought I'd "save time" by just hand-editing the source over
on my build machine. I managed to goof that by editing the
wrong function for one of the cases. :-(
New result. With Andreas's patch correctly applied, the generated
vmlinux is identical with/without your patch.
-Tony
^ permalink raw reply
* Re: [PATCH 9/24] make atomic_read() behave consistently on ia64
From: Chris Snook @ 2007-08-10 23:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Luck, Tony, Andreas Schwab, linux-kernel, linux-arch, netdev,
akpm, ak, heiko.carstens, davem, schwidefsky, wensong, horms,
wjiang, cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <alpine.LFD.0.999.0708101607130.30176@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Fri, 10 Aug 2007, Luck, Tony wrote:
>> Here are the functions in which they occur in the object file. You
>> may have to chase down some inlining to find the function that
>> actually uses atomic_*().
>
> Could you just make the "atomic_read()" and "atomic_set()" functions be
> inline functions instead?
>
> That way you get nice compiler warnings when you pass the wrong kind of
> object around. So
>
> static void atomic_set(atomic_t *p, int value)
> {
> *(volatile int *)&p->value = value;
> }
>
> static int atomic_read(atomic_t *p)
> {
> return *(volatile int *)&p->value;
> }
>
> etc...
I'll do this for the whole patchset. Stay tuned for the resubmit.
-- Chris
^ permalink raw reply
* Re: [PATCH 1/4] Add ETHTOOL_[GS]FLAGS sub-ioctls
From: Rick Jones @ 2007-08-10 23:15 UTC (permalink / raw)
To: David Miller; +Cc: greearb, jeff, auke-jan.h.kok, netdev, linux-kernel
In-Reply-To: <20070810.154601.98709831.davem@davemloft.net>
David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Fri, 10 Aug 2007 15:40:02 -0700
>
>
>>For GSO on output, is there a generic fallback for any driver that
>>does not specifically implement GSO?
>
>
> Absolutely, in fact that's mainly what it's there for.
>
> I don't think there is any issue. The knob is there via
> ethtool for people who really want to disable it.
Just to be paranoid (who me?) we are then at a point where what happened
a couple months ago with forwarding between 10G and IPoIB won't happen
again - where things failed because a 10G NIC had LRO enabled by default?
rick jones
^ 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