* Re: [PATCH] make atomic_t volatile on all architectures
From: Linus Torvalds @ 2007-08-12 9:54 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Segher Boessenkool, wjiang, wensong, heiko.carstens, linux-kernel,
ak, cfriesen, netdev, horms, akpm, Chuck Ebbert, davem, zlynx,
Chris Snook
In-Reply-To: <1186912098.3852.11.camel@localhost>
On Sun, 12 Aug 2007, Martin Schwidefsky wrote:
>
> The duplication "=m" and "m" with the same constraint is rather
> annoying.
It's not only annoying, it causes gcc to generate bad code too. At least
certain versions of gcc will generate the address *twice*, even if there
is obviously only one address used.
If you have problems with "+m", you are often actually better off using
just "m" and then adding a memory clobber. But that has other code
generation downsides.
Linus
^ permalink raw reply
* Re: [PATCH] make atomic_t volatile on all architectures
From: Martin Schwidefsky @ 2007-08-12 9:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: Segher Boessenkool, wjiang, wensong, heiko.carstens, linux-kernel,
ak, cfriesen, netdev, horms, akpm, Chuck Ebbert, davem, zlynx,
Chris Snook
In-Reply-To: <alpine.LFD.0.999.0708112305170.30176@woody.linux-foundation.org>
On Sat, 2007-08-11 at 23:09 -0700, Linus Torvalds wrote:
> Segher, how about you just accept that Linux uses gcc as per reality, and
> that sometimes the reality is different from your expectations?
>
> "+m" works. We use it. It's better than the alternatives. Pointing to
> stale documentation doesn't change anything.
Well, perhaps on i386. I've seen some older versions of the s390 gcc die
with an ICE because I have used "+m" in some kernel inline assembly. I'm
happy to hear that this issue is fixed in recent gcc. Now I'll have to
find out if this is already true with gcc 3.x. The duplication "=m" and
"m" with the same constraint is rather annoying.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH] make atomic_t volatile on all architectures
From: Martin Schwidefsky @ 2007-08-12 9:47 UTC (permalink / raw)
To: Segher Boessenkool
Cc: wjiang, Linus Torvalds, wensong, heiko.carstens, linux-kernel, ak,
cfriesen, netdev, horms, akpm, Chuck Ebbert, davem, zlynx,
Chris Snook
In-Reply-To: <a599bc5062d557db46496f0d7c7886b0@kernel.crashing.org>
On Sun, 2007-08-12 at 07:53 +0200, Segher Boessenkool wrote:
> > Yes, though I would use "=m" on the output list and "m" on the input
> > list. The reason is that I've seen gcc fall on its face with an ICE on
> > s390 due to "+m". The explanation I've got from our compiler people was
> > quite esoteric, as far as I remember gcc splits "+m" to an input
> > operand
> > and an output operand. Now it can happen that the compiler chooses two
> > different registers to access the same memory location. "+m" requires
> > that the two memory references are identical which causes the ICE if
> > they are not.
>
> The problem is very nicely described here, last paragraph:
> <http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01816.html>
>
> It's not a problem anymore in (very) recent GCC, although
> that of course won't help you in the kernel (yet).
So you are saying that gcc 3.x still has this problem ?
> > I do not know if the current compilers still do this. Has
> > anyone else seen this happen ?
>
> In recent GCC, it's actually documented:
>
> The ordinary output operands must be write-only; GCC will assume that
> the values in these operands before the instruction are dead and need
> not be generated. Extended asm supports input-output or read-write
> operands. Use the constraint character `+' to indicate such an operand
> and list it with the output operands. You should only use read-write
> operands when the constraints for the operand (or the operand in which
> only some of the bits are to be changed) allow a register.
>
> Note that last line.
I see, thanks for the info.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH] make atomic_t volatile on all architectures
From: Linus Torvalds @ 2007-08-12 6:09 UTC (permalink / raw)
To: Segher Boessenkool
Cc: schwidefsky, wjiang, wensong, heiko.carstens, linux-kernel, ak,
cfriesen, netdev, horms, akpm, Chuck Ebbert, davem, zlynx,
Chris Snook
In-Reply-To: <a599bc5062d557db46496f0d7c7886b0@kernel.crashing.org>
On Sun, 12 Aug 2007, Segher Boessenkool wrote:
>
> Note that last line.
Segher, how about you just accept that Linux uses gcc as per reality, and
that sometimes the reality is different from your expectations?
"+m" works. We use it. It's better than the alternatives. Pointing to
stale documentation doesn't change anything.
The same is true of accesses through a volatile pointer. The kernel has
done that for a *loong* time (all MMIO IO is done that way), and it's
totally pointless to say that "volatile" isn't guaranteed to do what it
does. It works, and quite frankly, if it didn't work, it would be a gcc
BUG.
And again, this is not a "C standard" issue. It's a "sane implementation"
issue. Linux expects the compiler to be sane. If it isn't, that's not our
problem. gcc *is* sane, and I don't see why you constantly act as if it
wasn't.
Linus
^ permalink raw reply
* Re: [PATCH] make atomic_t volatile on all architectures
From: Segher Boessenkool @ 2007-08-12 5:53 UTC (permalink / raw)
To: schwidefsky
Cc: wjiang, Linus Torvalds, wensong, heiko.carstens, linux-kernel, ak,
cfriesen, netdev, horms, akpm, Chuck Ebbert, davem, zlynx,
Chris Snook
In-Reply-To: <1186683646.9669.20.camel@localhost>
>> You'd have to use "+m".
>
> Yes, though I would use "=m" on the output list and "m" on the input
> list. The reason is that I've seen gcc fall on its face with an ICE on
> s390 due to "+m". The explanation I've got from our compiler people was
> quite esoteric, as far as I remember gcc splits "+m" to an input
> operand
> and an output operand. Now it can happen that the compiler chooses two
> different registers to access the same memory location. "+m" requires
> that the two memory references are identical which causes the ICE if
> they are not.
The problem is very nicely described here, last paragraph:
<http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01816.html>
It's not a problem anymore in (very) recent GCC, although
that of course won't help you in the kernel (yet).
> I do not know if the current compilers still do this. Has
> anyone else seen this happen ?
In recent GCC, it's actually documented:
The ordinary output operands must be write-only; GCC will assume that
the values in these operands before the instruction are dead and need
not be generated. Extended asm supports input-output or read-write
operands. Use the constraint character `+' to indicate such an operand
and list it with the output operands. You should only use read-write
operands when the constraints for the operand (or the operand in which
only some of the bits are to be changed) allow a register.
Note that last line.
Segher
^ permalink raw reply
* [RFC: -mm patch] improve the SSB dependencies
From: Adrian Bunk @ 2007-08-11 23:08 UTC (permalink / raw)
To: Michael Buesch
Cc: Adrian Bunk, Johannes Berg, John Linville, Andrew Morton,
Linux Netdev List
In-Reply-To: <200708111642.39348.mb@bu3sch.de>
On Sat, Aug 11, 2007 at 04:42:39PM +0200, Michael Buesch wrote:
> On Saturday 11 August 2007 16:30:02 Adrian Bunk wrote:
> > And offering more options than required or manually sending users into
> > other menus are bad thing for your users.
>
> Breaking compilations are as bad.
> So, does your example actually work in practice and not only
> in theory, too? My select stuff should have worked in theory, too.
> But it broke, for whatever reasons on whatever weird setups.
>
> We somehow are in an endless loop here:
>
> loop:
> implement it with select
> people complain select it bad and suggest to implement it with depends on
> implement it with depends on
> either
> users don't find it anymore
> users complain
> or
> it needs way to tell the user what to select first
> developers complain
> goto loop
>
> ;)
It's your fault that you base your work on an algorithm lacking the
essential steps
fix it properly
goto out
;-)
More seriously, below is a patch doing what I have in mind.
> Greetings Michael.
cu
Adrian
<-- snip -->
This patch adds *_POSSIBLE helper variables for all SSB* variables that
get select'ed. They indicate whether this variable can be select'ed,
IOW: whether it's dependencies are fulfilled.
Usage in drivers:
If you need SSB support:
config FOO
tristate "foo"
depends on SSB_POSSIBLE
select SSB
If you need SSB_BAZ support:
config BAR
tristate "bar"
depends on SSB_BAZ_POSSIBLE
select SSB
select SSB_BAZ
If your driver needs SSB and has optional functionality requiring SSB_BAZ:
config FOOBAR
tristate "foobar
depends on SSB_POSSIBLE
select SSB
# due to being "bool" this suboption shouldn't directly select SSB
# SSB is already select'ed by FOOBAR
config FOOBAR_BAZ
bool "baz support in foobar"
depends on FOOBAR && SSB_BAZ_POSSIBLE
select SSB_BAZ
After this patch, SSB_BAZ can be one of:
- SSB_PCIHOST
- SSB_DRIVER_PCICORE
- SSB_PCMCIAHOST
- SSB_DEBUG
Additional changes in this patch:
- small help text changes
- B44_PCI is no longer usr visible (automatically enabled when possible)
- let SSB_SILENT depend on EMBEDDED (unless you are in a very
space restricted environment you don't need to enable it)
- make the following options no longer user visible
(they are select'ed when required):
- SSB_PCIHOST
- SSB_DRIVER_PCICORE
- SSB_PCMCIAHOST
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
drivers/net/Kconfig | 12 ---
drivers/net/wireless/bcm43xx-mac80211/Kconfig | 10 +-
drivers/ssb/Kconfig | 72 ++++++++++--------
drivers/usb/host/Kconfig | 4 -
4 files changed, 51 insertions(+), 47 deletions(-)
6ed573214282b96e7714b33b89a7221c01efbb86
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index cea1979..a4f0c2f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1435,6 +1435,7 @@ config APRICOT
config B44
tristate "Broadcom 440x/47xx ethernet support"
depends on HAS_IOMEM
+ depends on SSB_POSSIBLE
select SSB
select MII
help
@@ -1452,17 +1453,10 @@ config B44
called b44.
config B44_PCI
- bool "Broadcom 440x PCI device support"
- depends on B44 && NET_PCI
- select SSB_PCIHOST
+ bool
+ depends on B44 && SSB_DRIVER_PCICORE_POSSIBLE
select SSB_DRIVER_PCICORE
default y
- 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!
config FORCEDETH
tristate "nForce Ethernet support"
diff --git a/drivers/net/wireless/bcm43xx-mac80211/Kconfig b/drivers/net/wireless/bcm43xx-mac80211/Kconfig
index 8f9df0e..8af8535 100644
--- a/drivers/net/wireless/bcm43xx-mac80211/Kconfig
+++ b/drivers/net/wireless/bcm43xx-mac80211/Kconfig
@@ -1,6 +1,6 @@
config BCM43XX_MAC80211
tristate "Broadcom BCM43xx wireless support (mac80211 stack)"
- depends on MAC80211 && WLAN_80211 && EXPERIMENTAL
+ depends on MAC80211 && WLAN_80211 && SSB_POSSIBLE && EXPERIMENTAL
select FW_LOADER
select SSB
select HW_RANDOM
@@ -10,8 +10,8 @@ config BCM43XX_MAC80211
config BCM43XX_MAC80211_PCI
bool "BCM43xx PCI device support"
- depends on BCM43XX_MAC80211 && PCI
- select SSB_PCIHOST
+ depends on BCM43XX_MAC80211
+ depends on SSB_DRIVER_PCICORE_POSSIBLE
select SSB_DRIVER_PCICORE
default y
---help---
@@ -24,7 +24,7 @@ config BCM43XX_MAC80211_PCI
config BCM43XX_MAC80211_PCMCIA
bool "BCM43xx PCMCIA device support"
- depends on BCM43XX_MAC80211 && PCMCIA
+ depends on BCM43XX_MAC80211 && SSB_PCMCIAHOST_POSSIBLE
select SSB_PCMCIAHOST
---help---
Broadcom 43xx PCMCIA device support.
@@ -45,7 +45,7 @@ config BCM43XX_MAC80211_PCMCIA
config BCM43XX_MAC80211_DEBUG
bool "Broadcom BCM43xx debugging (RECOMMENDED)"
depends on BCM43XX_MAC80211
- select SSB_DEBUG if !SSB_SILENT
+ select SSB_DEBUG if SSB_DEBUG_POSSIBLE
default y
---help---
Broadcom 43xx debugging messages.
diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 094703c..366c888 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -1,37 +1,42 @@
menu "Sonics Silicon Backplane"
+config SSB_POSSIBLE
+ bool
+ depends on EXPERIMENTAL && HAS_IOMEM
+ default y
+
config SSB
tristate "Sonics Silicon Backplane support"
- depends on EXPERIMENTAL && HAS_IOMEM
+ depends on SSB_POSSIBLE
help
- Support for the Sonics Silicon Backplane bus
+ Support for the Sonics Silicon Backplane bus.
+ You only need to enable this option if you are
+ configuring a kernel for an embedded system with
+ this bus.
- The module will be called ssb
+ The module will be called ssb.
- If unsure, say M
+ If unsure, say N.
-config SSB_PCIHOST
- bool "Support for SSB on PCI-bus host"
- depends on SSB && PCI
+config SSB_PCIHOST_POSSIBLE
+ bool
+ depends on SSB_POSSIBLE && PCI
default y
- help
- Support for a Sonics Silicon Backplane on top
- of a PCI device.
- If unsure, say Y
+config SSB_PCIHOST
+ bool
-config SSB_PCMCIAHOST
- bool "Support for SSB on PCMCIA-bus host"
- depends on SSB && PCMCIA
- help
- Support for a Sonics Silicon Backplane on top
- of a PCMCIA device.
+config SSB_PCMCIAHOST_POSSIBLE
+ bool
+ depends on SSB_POSSIBLE && PCMCIA
+ default y
- If unsure, say N
+config SSB_PCMCIAHOST
+ bool
config SSB_SILENT
bool "No SSB kernel messages"
- depends on SSB
+ depends on SSB && EMBEDDED
help
This option turns off all Sonics Silicon Backplane printks.
Note that you won't be able to identify problems, once
@@ -39,30 +44,35 @@ config SSB_SILENT
This might only be desired for production kernels on
embedded devices to reduce the kernel size.
- Say N
+ If unsure, say N.
+
+config SSB_DEBUG_POSSIBLE
+ bool
+ depends on SSB && !SSB_SILENT
+ default y
config SSB_DEBUG
bool "SSB debugging"
- depends on SSB && !SSB_SILENT
+ depends on SSB_DEBUG_POSSIBLE
help
This turns on additional runtime checks and debugging
messages. Turn this on for SSB troubleshooting.
- If unsure, say N
+ If unsure, say N.
config SSB_SERIAL
bool
depends on SSB
# ChipCommon and ExtIf serial support routines.
-config SSB_DRIVER_PCICORE
- bool "SSB PCI core driver"
- depends on SSB && SSB_PCIHOST
- help
- Driver for the Sonics Silicon Backplane attached
- Broadcom PCI core.
+config SSB_DRIVER_PCICORE_POSSIBLE
+ bool
+ depends on SSB_PCIHOST_POSSIBLE
+ default y
- If unsure, say Y
+config SSB_DRIVER_PCICORE
+ bool
+ select SSB_PCIHOST
config SSB_PCICORE_HOSTMODE
bool "Hostmode support for SSB PCI core"
@@ -78,7 +88,7 @@ config SSB_DRIVER_MIPS
Driver for the Sonics Silicon Backplane attached
Broadcom MIPS core.
- If unsure, say N
+ If unsure, say N.
config SSB_DRIVER_EXTIF
bool "SSB Broadcom EXTIF core driver"
@@ -87,6 +97,6 @@ config SSB_DRIVER_EXTIF
Driver for the Sonics Silicon Backplane attached
Broadcom EXTIF core.
- If unsure, say N
+ If unsure, say N.
endmenu
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index dc3b7fe..d7f5328 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -101,6 +101,7 @@ config USB_OHCI_HCD
depends on USB && USB_ARCH_HAS_OHCI
select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
select I2C if ARCH_PNX4008
+ select SSB if USB_OHCI_HCD_SSB
---help---
The Open Host Controller Interface (OHCI) is a standard for accessing
USB 1.1 host controller hardware. It does more in hardware than Intel's
@@ -156,8 +157,7 @@ config USB_OHCI_HCD_PCI
config USB_OHCI_HCD_SSB
bool "OHCI support for the Broadcom SSB OHCI core (embedded systems only)"
- depends on USB_OHCI_HCD && ((USB_OHCI_HCD=m && SSB) || (USB_OHCI_HCD=y && SSB=y)) && EXPERIMENTAL
- default n
+ depends on USB_OHCI_HCD && SSB_POSSIBLE && EXPERIMENTAL
---help---
Support for the Sonics Silicon Backplane (SSB) attached
Broadcom USB OHCI core.
^ permalink raw reply related
* Re: Weird network problems with 2.6.23-rc2
From: Jiri Kosina @ 2007-08-11 21:55 UTC (permalink / raw)
To: Shish; +Cc: linux-kernel, netdev
In-Reply-To: <20070811083959.305b0421.shish@shishnet.org>
On Sat, 11 Aug 2007, Shish wrote:
> Something seems to have broken in 2.6.23-rc2, and I'm not sure what, or
> where I should look for further debugging. The info I have:
>
> On my 2.6.23-rc2 desktop, things run fine.
>
> On my test server, built from the same source tree, networking goes
> strange every few minutes, with the following symptoms:
>
> o) running ping against the server, the first ping goes through;
> further pings go AWOL until about icmp_seq=30, when I get 4-5 icmp
> replies (marked as DUP!), then no pings for a while, then dups, and so
> on.
>
> o) the server doesn't see ARP replies. According to tcpdump, the server
> will send eg "who has 192.168.0.2? tell 192.168.0.1"; the client in
> question will recieve the packet and send a response, but nothing shows
> up in the server-side tcpdump.
>
> o) after a few minutes of random network troubles, everything will work
> fine again, (ping is normal, arp replies are seen, tcp sessions work)
> for a few minutes.
>
> o) The server's dmesg shows lots of "short udp packet" messages
>
> o) ifdown then ifup'ing the interfaces fixes things, temporarily.
>
> Reverting to 2.6.22, everything seems to be running fine (but no lguest,
> which is what I came for :( )
>
> I've also tried with the latest code from git, the behaviour is the same
> as 2.6.23-rc2.
This needs to go to netdev, CC added.
Also, git-bisect will help a lot here to find the commit which caused the
regression you are seeing.
--
Jiri Kosina
^ permalink raw reply
* Re: [RFC] IP_RECVERRC
From: jamal @ 2007-08-11 19:27 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, David Miller
In-Reply-To: <20070810162643.GA11892@one.firstfloor.org>
On Fri, 2007-10-08 at 18:26 +0200, Andi Kleen wrote:
> Are we talking about TCP or UDP/RAW?
Both. initially datagram.
I think you gave me something to think about - let me go back to the
drawing table. I like the per socket timer idea; however, if i can solve
from the app (or write my own app which is fine) then i will rather go
that path.
Thanks for taking the time Andi.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] b44-ssb: Fix the SSB dependency hell
From: Michael Buesch @ 2007-08-11 14:42 UTC (permalink / raw)
To: Adrian Bunk
Cc: Johannes Berg, John Linville, Andrew Morton, Linux Netdev List
In-Reply-To: <20070811143002.GE22213@stusta.de>
On Saturday 11 August 2007 16:30:02 Adrian Bunk wrote:
> And offering more options than required or manually sending users into
> other menus are bad thing for your users.
Breaking compilations are as bad.
So, does your example actually work in practice and not only
in theory, too? My select stuff should have worked in theory, too.
But it broke, for whatever reasons on whatever weird setups.
We somehow are in an endless loop here:
loop:
implement it with select
people complain select it bad and suggest to implement it with depends on
implement it with depends on
either
users don't find it anymore
users complain
or
it needs way to tell the user what to select first
developers complain
goto loop
;)
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] b44-ssb: Fix the SSB dependency hell
From: Adrian Bunk @ 2007-08-11 14:30 UTC (permalink / raw)
To: Michael Buesch
Cc: Johannes Berg, John Linville, Andrew Morton, Linux Netdev List
In-Reply-To: <200708111136.46781.mb@bu3sch.de>
On Sat, Aug 11, 2007 at 11:36:46AM +0200, Michael Buesch wrote:
>
> That's all a silly discussion, guys.
> I personally do _not_ care which way we do this.
> BUT: My users do care. There is currently no way telling them to first enable
> SSB, when they want to select b44 (for example).
The current status quo is that select handles it.
You want to send the users into menus to manually enable options.
That's worse for your users.
> Select _does_ introduce breakage. I did use select and I am pretty sure
> I got the dependencies right. And it _still_ broken on weird architectures.
Have you looked at how I proposed to handle the SSB dependencies?
If yes, why is this broken?
> So, I do not care how this is implemented. I do care however, that users
> do get an advice (at least) on what to do. And that's what my patch does.
> If someone has a better idea, please provide a patch.
I do care about your users.
And offering more options than required or manually sending users into
other menus are bad thing for your users.
> Greetings Michael.
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: Michael Buesch @ 2007-08-11 9:36 UTC (permalink / raw)
To: Adrian Bunk
Cc: Johannes Berg, John Linville, Andrew Morton, Linux Netdev List
In-Reply-To: <20070811014111.GB22213@stusta.de>
On Saturday 11 August 2007 03:41:11 Adrian Bunk wrote:
> 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?
That's all a silly discussion, guys.
I personally do _not_ care which way we do this.
BUT: My users do care. There is currently no way telling them to first enable
SSB, when they want to select b44 (for example).
Select _does_ introduce breakage. I did use select and I am pretty sure
I got the dependencies right. And it _still_ broken on weird architectures.
So, I do not care how this is implemented. I do care however, that users
do get an advice (at least) on what to do. And that's what my patch does.
If someone has a better idea, please provide a patch.
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: David Howells @ 2007-08-11 8:47 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.
I'm not sure that actually answers my question. Why not smp_rmb()?
David
^ permalink raw reply
* Re: RealTek 8169 support question
From: Francois Romieu @ 2007-08-11 8:24 UTC (permalink / raw)
To: Chuck Lever; +Cc: netdev ML
In-Reply-To: <46BCE95B.7020408@oracle.com>
Chuck Lever <chuck.lever@oracle.com> :
[...]
> Not yet. I wanted to check with "the Maintainer" to see if it was worth
> trying. :-) The last time I tried a kernel build on one of these
It is worth trying.
> little Via processors, it took forever. Will give it a shot.
Why can you not compile on a different computer ?
--
Ueimor
^ permalink raw reply
* [PATCH 0/13] cxgb3 - driver updates
From: divy @ 2007-08-11 6:52 UTC (permalink / raw)
To: jeff, netdev; +Cc: linux-kernel, swise
Hi Jeff,
I'm submitting a patch series for inclusion in netdev#upstream.
Here is a brief description:
- MAC hang workaround update
- Modify max HW Rx coalescing size
- Log SGE doorbell Fifo overflow
- Use Tx immediate data for offload packets whenever possible
- RDMA can get internal mem info to workaround HW issues
- More validity checks on connection ids
- Stop MAC when a fatal error is detected
- Log HW serial number
- Update internal mem operating mode
- Update engine microcode management, version is now 1.1.0
- Update FW management, version is now 4.6.0
- Ignore some HW errors until the HW is initialized
- Check MSI/MSI-X after it got enabled
Cheers,
Divy
^ permalink raw reply
* [PATCH 0/13] cxgb3 - driver updates
From: divy @ 2007-08-11 6:51 UTC (permalink / raw)
To: jeff, netdev; +Cc: linux-kernel, swise
Hi Jeff,
I'm submitting a patch series for inclusion in netdev#upstream.
Here is a brief description:
- MAC hang workaround update
- Modify max HW Rx coalescing size
- Log SGE doorbell Fifo overflow
- Use Tx immediate data for offload packets whenever possible
- RDMA can get internal mem info to workaround HW issues
- More validity checks on connection ids
- Stop MAC when a fatal error is detected
- Log HW serial number
- Update internal mem operating mode
- Update engine microcode management, version is now 1.1.0
- Update FW management, version is now 4.6.0
- Ignore some HW errors until the HW is initialized
- Check MSI/MSI-X after it got enabled
Cheers,
Divy
^ permalink raw reply
* [PATCH 13/13] cxgb3 - test MSI capabilities
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Check that the HW in really in MSI/MSI-X mode
when it was succesfully enabled.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/cxgb3_main.c | 42 ++++++++++++++++++++++++++++++++++++++++
drivers/net/cxgb3/regs.h | 4 ++++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index eaebd7f..1449692 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2318,6 +2318,46 @@ void t3_fatal_err(struct adapter *adapter)
}
+/*
+ * Interrupt handler used to check if MSI/MSI-X works on this platform.
+ */
+static irqreturn_t check_intr_handler(int irq, void *cookie)
+{
+ struct adapter *adap = cookie;
+
+ t3_set_reg_field(adap, A_PL_INT_ENABLE0, F_MI1, 0);
+ return IRQ_HANDLED;
+}
+
+static void __devinit check_msi(struct adapter *adap)
+{
+ int vec, mi1;
+
+ if (!(t3_read_reg(adap, A_PL_INT_CAUSE0) & F_MI1))
+ return;
+
+ vec = (adap->flags & USING_MSI) ? adap->pdev->irq :
+ adap->msix_info[0].vec;
+
+ if (request_irq(vec, check_intr_handler, 0, adap->name, adap))
+ return;
+
+ t3_set_reg_field(adap, A_PL_INT_ENABLE0, 0, F_MI1);
+ msleep(10);
+ mi1 = t3_read_reg(adap, A_PL_INT_ENABLE0) & F_MI1;
+ if (mi1)
+ t3_set_reg_field(adap, A_PL_INT_ENABLE0, F_MI1, 0);
+ free_irq(vec, adap);
+
+ if (mi1) {
+ cxgb_disable_msi(adap);
+ dev_info(&adap->pdev->dev,
+ "the kernel believes that MSI is available on this "
+ "platform\nbut the driver's MSI test has failed. "
+ "Proceeding with INTx interrupts.\n");
+ }
+}
+
static int __devinit cxgb_enable_msix(struct adapter *adap)
{
struct msix_entry entries[SGE_QSETS + 1];
@@ -2554,6 +2594,8 @@ static int __devinit init_one(struct pci_dev *pdev,
adapter->flags |= USING_MSIX;
else if (msi > 0 && pci_enable_msi(pdev) == 0)
adapter->flags |= USING_MSI;
+ if (adapter->flags & (USING_MSIX | USING_MSI))
+ check_msi(adapter);
err = sysfs_create_group(&adapter->port[0]->dev.kobj,
&cxgb3_attr_group);
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index 5e1bc0d..f97f8ab 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1639,6 +1639,10 @@
#define V_MC5A(x) ((x) << S_MC5A)
#define F_MC5A V_MC5A(1U)
+#define S_MI1 13
+#define V_MI1(x) ((x) << S_MI1)
+#define F_MI1 V_MI1(1U)
+
#define S_CPL_SWITCH 12
#define V_CPL_SWITCH(x) ((x) << S_CPL_SWITCH)
#define F_CPL_SWITCH V_CPL_SWITCH(1U)
^ permalink raw reply related
* [PATCH 12/13] cxgb3 - log and clear PEX errors
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Clear pciE PEX errors late at module load time.
Log details when PEX errors occur.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/t3_hw.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 3d47627..538b254 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -1355,6 +1355,10 @@ static void pcie_intr_handler(struct adapter *adapter)
{0}
};
+ if (t3_read_reg(adapter, A_PCIE_INT_CAUSE) & F_PEXERR)
+ CH_ALERT(adapter, "PEX error code 0x%x\n",
+ t3_read_reg(adapter, A_PCIE_PEX_ERR));
+
if (t3_handle_intr_status(adapter, A_PCIE_INT_CAUSE, PCIE_INTR_MASK,
pcie_intr_info, adapter->irq_stats))
t3_fatal_err(adapter);
@@ -1806,6 +1810,8 @@ void t3_intr_clear(struct adapter *adapter)
for (i = 0; i < ARRAY_SIZE(cause_reg_addr); ++i)
t3_write_reg(adapter, cause_reg_addr[i], 0xffffffff);
+ if (is_pcie(adapter))
+ t3_write_reg(adapter, A_PCIE_PEX_ERR, 0xffffffff);
t3_write_reg(adapter, A_PL_INT_CAUSE0, 0xffffffff);
t3_read_reg(adapter, A_PL_INT_CAUSE0); /* flush */
}
^ permalink raw reply related
* [PATCH 11/13] cxgb3 - Firmware update
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Update firmware version
Allow the driver to be up and running with older FW image
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/common.h | 2 +-
drivers/net/cxgb3/cxgb3_main.c | 9 +++++----
drivers/net/cxgb3/t3_hw.c | 20 +++++++++++++++-----
drivers/net/cxgb3/version.h | 2 +-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index b665b20..ff867c2 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -691,7 +691,7 @@ int t3_read_flash(struct adapter *adapter, unsigned int addr,
unsigned int nwords, u32 *data, int byte_oriented);
int t3_load_fw(struct adapter *adapter, const u8 * fw_data, unsigned int size);
int t3_get_fw_version(struct adapter *adapter, u32 *vers);
-int t3_check_fw_version(struct adapter *adapter);
+int t3_check_fw_version(struct adapter *adapter, int *must_load);
int t3_init_hw(struct adapter *adapter, u32 fw_params);
void mac_prep(struct cmac *mac, struct adapter *adapter, int index);
void early_hw_init(struct adapter *adapter, const struct adapter_info *ai);
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 65ded16..eaebd7f 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -814,11 +814,12 @@ static int cxgb_up(struct adapter *adap)
int must_load;
if (!(adap->flags & FULL_INIT_DONE)) {
- err = t3_check_fw_version(adap);
- if (err == -EINVAL)
+ err = t3_check_fw_version(adap, &must_load);
+ if (err == -EINVAL) {
err = upgrade_fw(adap);
- if (err)
- goto out;
+ if (err && must_load)
+ goto out;
+ }
err = t3_check_tpsram_version(adap, &must_load);
if (err == -EINVAL) {
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 63032e8..3d47627 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -957,16 +957,18 @@ int t3_get_fw_version(struct adapter *adapter, u32 *vers)
/**
* t3_check_fw_version - check if the FW is compatible with this driver
* @adapter: the adapter
- *
+ * @must_load: set to 1 if loading a new FW image is required
+
* Checks if an adapter's FW is compatible with the driver. Returns 0
* if the versions are compatible, a negative error otherwise.
*/
-int t3_check_fw_version(struct adapter *adapter)
+int t3_check_fw_version(struct adapter *adapter, int *must_load)
{
int ret;
u32 vers;
unsigned int type, major, minor;
+ *must_load = 1;
ret = t3_get_fw_version(adapter, &vers);
if (ret)
return ret;
@@ -979,9 +981,17 @@ int t3_check_fw_version(struct adapter *adapter)
minor == FW_VERSION_MINOR)
return 0;
- CH_ERR(adapter, "found wrong FW version(%u.%u), "
- "driver needs version %u.%u\n", major, minor,
- FW_VERSION_MAJOR, FW_VERSION_MINOR);
+ if (major != FW_VERSION_MAJOR)
+ CH_ERR(adapter, "found wrong FW version(%u.%u), "
+ "driver needs version %u.%u\n", major, minor,
+ FW_VERSION_MAJOR, FW_VERSION_MINOR);
+ else {
+ *must_load = 0;
+ CH_WARN(adapter, "found wrong FW minor version(%u.%u), "
+ "driver compiled for version %u.%u\n", major, minor,
+ FW_VERSION_MAJOR, FW_VERSION_MINOR);
+ }
+
return -EINVAL;
}
diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h
index eb508bf..ef1c633 100644
--- a/drivers/net/cxgb3/version.h
+++ b/drivers/net/cxgb3/version.h
@@ -39,6 +39,6 @@
/* Firmware version */
#define FW_VERSION_MAJOR 4
-#define FW_VERSION_MINOR 3
+#define FW_VERSION_MINOR 6
#define FW_VERSION_MICRO 0
#endif /* __CHELSIO_VERSION_H */
^ permalink raw reply related
* [PATCH 10/13] cxgb3 - engine microcode update
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Load microcode engine when the interface
is configured up.
Bump up version to 1.1.0.
Allow the driver to be and running with
older microcode images.
Allow ethtool to log the microcode version.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/common.h | 8 ++-
drivers/net/cxgb3/cxgb3_main.c | 116 ++++++++++++++++++++++++----------------
drivers/net/cxgb3/t3_hw.c | 43 +++++++++++++--
3 files changed, 113 insertions(+), 54 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index d54446f..b665b20 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -127,8 +127,8 @@ enum { /* adapter interrupt-maintained statistics */
enum {
TP_VERSION_MAJOR = 1,
- TP_VERSION_MINOR = 0,
- TP_VERSION_MICRO = 44
+ TP_VERSION_MINOR = 1,
+ TP_VERSION_MICRO = 0
};
#define S_TP_VERSION_MAJOR 16
@@ -438,6 +438,7 @@ enum { /* chip revisions */
T3_REV_A = 0,
T3_REV_B = 2,
T3_REV_B2 = 3,
+ T3_REV_C = 4,
};
struct trace_params {
@@ -682,7 +683,8 @@ const struct adapter_info *t3_get_adapter_info(unsigned int board_id);
int t3_seeprom_read(struct adapter *adapter, u32 addr, u32 *data);
int t3_seeprom_write(struct adapter *adapter, u32 addr, u32 data);
int t3_seeprom_wp(struct adapter *adapter, int enable);
-int t3_check_tpsram_version(struct adapter *adapter);
+int t3_get_tp_version(struct adapter *adapter, u32 *vers);
+int t3_check_tpsram_version(struct adapter *adapter, int *must_load);
int t3_check_tpsram(struct adapter *adapter, u8 *tp_ram, unsigned int size);
int t3_set_proto_sram(struct adapter *adap, u8 *data);
int t3_read_flash(struct adapter *adapter, unsigned int addr,
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index e5744e7..65ded16 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -721,6 +721,7 @@ static void bind_qsets(struct adapter *adap)
}
#define FW_FNAME "t3fw-%d.%d.%d.bin"
+#define TPSRAM_NAME "t3%c_protocol_sram-%d.%d.%d.bin"
static int upgrade_fw(struct adapter *adap)
{
@@ -742,6 +743,61 @@ static int upgrade_fw(struct adapter *adap)
return ret;
}
+static inline char t3rev2char(struct adapter *adapter)
+{
+ char rev = 0;
+
+ switch(adapter->params.rev) {
+ case T3_REV_A:
+ rev = 'a';
+ break;
+ case T3_REV_B:
+ case T3_REV_B2:
+ rev = 'b';
+ break;
+ case T3_REV_C:
+ rev = 'c';
+ break;
+ }
+ return rev;
+}
+
+int update_tpsram(struct adapter *adap)
+{
+ const struct firmware *tpsram;
+ char buf[64];
+ struct device *dev = &adap->pdev->dev;
+ int ret;
+ char rev;
+
+ rev = t3rev2char(adap);
+ if (!rev)
+ return 0;
+
+ snprintf(buf, sizeof(buf), TPSRAM_NAME, rev,
+ TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
+
+ ret = request_firmware(&tpsram, buf, dev);
+ if (ret < 0) {
+ dev_err(dev, "could not load TP SRAM: unable to load %s\n",
+ buf);
+ return ret;
+ }
+
+ ret = t3_check_tpsram(adap, tpsram->data, tpsram->size);
+ if (ret)
+ goto release_tpsram;
+
+ ret = t3_set_proto_sram(adap, tpsram->data);
+ if (ret)
+ dev_err(dev, "loading protocol SRAM failed\n");
+
+release_tpsram:
+ release_firmware(tpsram);
+
+ return ret;
+}
+
/**
* cxgb_up - enable the adapter
* @adapter: adapter being enabled
@@ -755,6 +811,7 @@ static int upgrade_fw(struct adapter *adap)
static int cxgb_up(struct adapter *adap)
{
int err = 0;
+ int must_load;
if (!(adap->flags & FULL_INIT_DONE)) {
err = t3_check_fw_version(adap);
@@ -763,6 +820,13 @@ static int cxgb_up(struct adapter *adap)
if (err)
goto out;
+ err = t3_check_tpsram_version(adap, &must_load);
+ if (err == -EINVAL) {
+ err = update_tpsram(adap);
+ if (err && must_load)
+ goto out;
+ }
+
err = init_dummy_netdevs(adap);
if (err)
goto out;
@@ -1097,9 +1161,11 @@ static int get_eeprom_len(struct net_device *dev)
static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
{
u32 fw_vers = 0;
+ u32 tp_vers = 0;
struct adapter *adapter = dev->priv;
t3_get_fw_version(adapter, &fw_vers);
+ t3_get_tp_version(adapter, &tp_vers);
strcpy(info->driver, DRV_NAME);
strcpy(info->version, DRV_VERSION);
@@ -1108,11 +1174,14 @@ static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
strcpy(info->fw_version, "N/A");
else {
snprintf(info->fw_version, sizeof(info->fw_version),
- "%s %u.%u.%u",
+ "%s %u.%u.%u TP %u.%u.%u",
G_FW_VERSION_TYPE(fw_vers) ? "T" : "N",
G_FW_VERSION_MAJOR(fw_vers),
G_FW_VERSION_MINOR(fw_vers),
- G_FW_VERSION_MICRO(fw_vers));
+ G_FW_VERSION_MICRO(fw_vers),
+ G_TP_VERSION_MAJOR(tp_vers),
+ G_TP_VERSION_MINOR(tp_vers),
+ G_TP_VERSION_MICRO(tp_vers));
}
}
@@ -2088,42 +2157,6 @@ static void cxgb_netpoll(struct net_device *dev)
}
#endif
-#define TPSRAM_NAME "t3%c_protocol_sram-%d.%d.%d.bin"
-int update_tpsram(struct adapter *adap)
-{
- const struct firmware *tpsram;
- char buf[64];
- struct device *dev = &adap->pdev->dev;
- int ret;
- char rev;
-
- rev = adap->params.rev == T3_REV_B2 ? 'b' : 'a';
-
- snprintf(buf, sizeof(buf), TPSRAM_NAME, rev,
- TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
-
- ret = request_firmware(&tpsram, buf, dev);
- if (ret < 0) {
- dev_err(dev, "could not load TP SRAM: unable to load %s\n",
- buf);
- return ret;
- }
-
- ret = t3_check_tpsram(adap, tpsram->data, tpsram->size);
- if (ret)
- goto release_tpsram;
-
- ret = t3_set_proto_sram(adap, tpsram->data);
- if (ret)
- dev_err(dev, "loading protocol SRAM failed\n");
-
-release_tpsram:
- release_firmware(tpsram);
-
- return ret;
-}
-
-
/*
* Periodic accumulation of MAC statistics.
*/
@@ -2478,13 +2511,6 @@ static int __devinit init_one(struct pci_dev *pdev,
err = -ENODEV;
goto out_free_dev;
}
-
- err = t3_check_tpsram_version(adapter);
- if (err == -EINVAL)
- err = update_tpsram(adapter);
-
- if (err)
- goto out_free_dev;
/*
* The card is now ready to go. If any errors occur during device
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 13bfbec..63032e8 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -849,16 +849,15 @@ static int t3_write_flash(struct adapter *adapter, unsigned int addr,
}
/**
- * t3_check_tpsram_version - read the tp sram version
+ * t3_get_tp_version - read the tp sram version
* @adapter: the adapter
+ * @vers: where to place the version
*
- * Reads the protocol sram version from serial eeprom.
+ * Reads the protocol sram version from sram.
*/
-int t3_check_tpsram_version(struct adapter *adapter)
+int t3_get_tp_version(struct adapter *adapter, u32 *vers)
{
int ret;
- u32 vers;
- unsigned int major, minor;
/* Get version loaded in SRAM */
t3_write_reg(adapter, A_TP_EMBED_OP_FIELD0, 0);
@@ -867,7 +866,29 @@ int t3_check_tpsram_version(struct adapter *adapter)
if (ret)
return ret;
- vers = t3_read_reg(adapter, A_TP_EMBED_OP_FIELD1);
+ *vers = t3_read_reg(adapter, A_TP_EMBED_OP_FIELD1);
+
+ return 0;
+}
+
+/**
+ * t3_check_tpsram_version - read the tp sram version
+ * @adapter: the adapter
+ * @must_load: set to 1 if loading a new microcode image is required
+ *
+ * Reads the protocol sram version from flash.
+ */
+int t3_check_tpsram_version(struct adapter *adapter, int *must_load)
+{
+ int ret;
+ u32 vers;
+ unsigned int major, minor;
+
+ *must_load = 1;
+
+ ret = t3_get_tp_version(adapter, &vers);
+ if (ret)
+ return ret;
major = G_TP_VERSION_MAJOR(vers);
minor = G_TP_VERSION_MINOR(vers);
@@ -875,6 +896,16 @@ int t3_check_tpsram_version(struct adapter *adapter)
if (major == TP_VERSION_MAJOR && minor == TP_VERSION_MINOR)
return 0;
+ if (major != TP_VERSION_MAJOR)
+ CH_ERR(adapter, "found wrong TP version (%u.%u), "
+ "driver needs version %d.%d\n", major, minor,
+ TP_VERSION_MAJOR, TP_VERSION_MINOR);
+ else {
+ *must_load = 0;
+ CH_ERR(adapter, "found wrong TP version (%u.%u), "
+ "driver compiled for version %d.%d\n", major, minor,
+ TP_VERSION_MAJOR, TP_VERSION_MINOR);
+ }
return -EINVAL;
}
^ permalink raw reply related
* [PATCH 9/13] cxgb3 - Update internal memory management
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Set PM1 internal memory to round robin mode
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/regs.h | 2 ++
drivers/net/cxgb3/t3_hw.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index 2824278..5e1bc0d 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1326,6 +1326,7 @@
#define V_D0_WEIGHT(x) ((x) << S_D0_WEIGHT)
#define A_PM1_RX_CFG 0x5c0
+#define A_PM1_RX_MODE 0x5c4
#define A_PM1_RX_INT_ENABLE 0x5d8
@@ -1394,6 +1395,7 @@
#define A_PM1_RX_INT_CAUSE 0x5dc
#define A_PM1_TX_CFG 0x5e0
+#define A_PM1_TX_MODE 0x5e4
#define A_PM1_TX_INT_ENABLE 0x5f8
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 23b1a16..13bfbec 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -3189,6 +3189,8 @@ int t3_init_hw(struct adapter *adapter, u32 fw_params)
t3_set_reg_field(adapter, A_PCIX_CFG, 0, F_CLIDECEN);
t3_write_reg(adapter, A_PM1_RX_CFG, 0xffffffff);
+ t3_write_reg(adapter, A_PM1_RX_MODE, 0);
+ t3_write_reg(adapter, A_PM1_TX_MODE, 0);
init_hw_for_avail_ports(adapter, adapter->params.nports);
t3_sge_init(adapter, &adapter->params.sge);
^ permalink raw reply related
* [PATCH 8/13] cxgb3 - log adapter derial number
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Log HW serial number when cxgb3 module is loaded.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/common.h | 2 ++
drivers/net/cxgb3/cxgb3_main.c | 6 ++++--
drivers/net/cxgb3/t3_hw.c | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 55922ed..d54446f 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -97,6 +97,7 @@ enum {
MAX_NPORTS = 2, /* max # of ports */
MAX_FRAME_SIZE = 10240, /* max MAC frame size, including header + FCS */
EEPROMSIZE = 8192, /* Serial EEPROM size */
+ SERNUM_LEN = 16, /* Serial # length */
RSS_TABLE_SIZE = 64, /* size of RSS lookup and mapping tables */
TCB_SIZE = 128, /* TCB size */
NMTUS = 16, /* size of MTU table */
@@ -391,6 +392,7 @@ struct vpd_params {
unsigned int uclk;
unsigned int mdc;
unsigned int mem_timing;
+ u8 sn[SERNUM_LEN + 1];
u8 eth_base[6];
u8 port_type[MAX_NPORTS];
unsigned short xauicfg[2];
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index a1f94cf..e5744e7 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2333,10 +2333,12 @@ static void __devinit print_port_info(struct adapter *adap,
(adap->flags & USING_MSIX) ? " MSI-X" :
(adap->flags & USING_MSI) ? " MSI" : "");
if (adap->name == dev->name && adap->params.vpd.mclk)
- printk(KERN_INFO "%s: %uMB CM, %uMB PMTX, %uMB PMRX\n",
+ printk(KERN_INFO
+ "%s: %uMB CM, %uMB PMTX, %uMB PMRX, S/N: %s\n",
adap->name, t3_mc7_size(&adap->cm) >> 20,
t3_mc7_size(&adap->pmtx) >> 20,
- t3_mc7_size(&adap->pmrx) >> 20);
+ t3_mc7_size(&adap->pmrx) >> 20,
+ adap->params.vpd.sn);
}
}
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index dd3149d..23b1a16 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -505,7 +505,7 @@ struct t3_vpd {
u8 vpdr_len[2];
VPD_ENTRY(pn, 16); /* part number */
VPD_ENTRY(ec, 16); /* EC level */
- VPD_ENTRY(sn, 16); /* serial number */
+ VPD_ENTRY(sn, SERNUM_LEN); /* serial number */
VPD_ENTRY(na, 12); /* MAC address base */
VPD_ENTRY(cclk, 6); /* core clock */
VPD_ENTRY(mclk, 6); /* mem clock */
@@ -648,6 +648,7 @@ static int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
p->uclk = simple_strtoul(vpd.uclk_data, NULL, 10);
p->mdc = simple_strtoul(vpd.mdc_data, NULL, 10);
p->mem_timing = simple_strtoul(vpd.mt_data, NULL, 10);
+ memcpy(p->sn, vpd.sn_data, SERNUM_LEN);
/* Old eeproms didn't have port information */
if (adapter->params.rev == 0 && !vpd.port0_data[0]) {
^ permalink raw reply related
* [PATCH 7/13] cxgb3 - Fatal error update
From: Divy Le Ray @ 2007-08-11 6:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Stop the MAC when a fatal error is detected.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/cxgb3_main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index dc5d269..a1f94cf 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2270,6 +2270,10 @@ void t3_fatal_err(struct adapter *adapter)
if (adapter->flags & FULL_INIT_DONE) {
t3_sge_stop(adapter);
+ t3_write_reg(adapter, A_XGM_TX_CTRL, 0);
+ t3_write_reg(adapter, A_XGM_RX_CTRL, 0);
+ t3_write_reg(adapter, XGM_REG(A_XGM_TX_CTRL, 1), 0);
+ t3_write_reg(adapter, XGM_REG(A_XGM_RX_CTRL, 1), 0);
t3_intr_disable(adapter);
}
CH_ALERT(adapter, "encountered fatal error, operation suspended\n");
^ permalink raw reply related
* [PATCH 6/13] cxgb3 - tighten checks on TID values
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>
Enforce validity checks on connection ids
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/cxgb3_defs.h | 20 ++++++++++++++++++--
drivers/net/cxgb3/cxgb3_offload.c | 28 +++++++++++++++++++++++-----
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_defs.h b/drivers/net/cxgb3/cxgb3_defs.h
index 483a594..45e9216 100644
--- a/drivers/net/cxgb3/cxgb3_defs.h
+++ b/drivers/net/cxgb3/cxgb3_defs.h
@@ -79,9 +79,17 @@ static inline struct t3c_tid_entry *lookup_tid(const struct tid_info *t,
static inline struct t3c_tid_entry *lookup_stid(const struct tid_info *t,
unsigned int tid)
{
+ union listen_entry *e;
+
if (tid < t->stid_base || tid >= t->stid_base + t->nstids)
return NULL;
- return &(stid2entry(t, tid)->t3c_tid);
+
+ e = stid2entry(t, tid);
+ if ((void *)e->next >= (void *)t->tid_tab &&
+ (void *)e->next < (void *)&t->atid_tab[t->natids])
+ return NULL;
+
+ return &e->t3c_tid;
}
/*
@@ -90,9 +98,17 @@ static inline struct t3c_tid_entry *lookup_stid(const struct tid_info *t,
static inline struct t3c_tid_entry *lookup_atid(const struct tid_info *t,
unsigned int tid)
{
+ union active_open_entry *e;
+
if (tid < t->atid_base || tid >= t->atid_base + t->natids)
return NULL;
- return &(atid2entry(t, tid)->t3c_tid);
+
+ e = atid2entry(t, tid);
+ if ((void *)e->next >= (void *)t->tid_tab &&
+ (void *)e->next < (void *)&t->atid_tab[t->natids])
+ return NULL;
+
+ return &e->t3c_tid;
}
int process_rx(struct t3cdev *dev, struct sk_buff **skbs, int n);
diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c
index 522c1be..7fb526a 100644
--- a/drivers/net/cxgb3/cxgb3_offload.c
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -57,7 +57,7 @@ static DEFINE_RWLOCK(adapter_list_lock);
static LIST_HEAD(adapter_list);
static const unsigned int MAX_ATIDS = 64 * 1024;
-static const unsigned int ATID_BASE = 0x100000;
+static const unsigned int ATID_BASE = 0x10000;
static inline int offload_activated(struct t3cdev *tdev)
{
@@ -684,10 +684,19 @@ static int do_cr(struct t3cdev *dev, struct sk_buff *skb)
{
struct cpl_pass_accept_req *req = cplhdr(skb);
unsigned int stid = G_PASS_OPEN_TID(ntohl(req->tos_tid));
+ struct tid_info *t = &(T3C_DATA(dev))->tid_maps;
struct t3c_tid_entry *t3c_tid;
+ unsigned int tid = GET_TID(req);
- t3c_tid = lookup_stid(&(T3C_DATA(dev))->tid_maps, stid);
- if (t3c_tid->ctx && t3c_tid->client->handlers &&
+ if (unlikely(tid >= t->ntids)) {
+ printk("%s: passive open TID %u too large\n",
+ dev->name, tid);
+ t3_fatal_err(tdev2adap(dev));
+ return CPL_RET_BUF_DONE;
+ }
+
+ t3c_tid = lookup_stid(t, stid);
+ if (t3c_tid && t3c_tid->ctx && t3c_tid->client->handlers &&
t3c_tid->client->handlers[CPL_PASS_ACCEPT_REQ]) {
return t3c_tid->client->handlers[CPL_PASS_ACCEPT_REQ]
(dev, skb, t3c_tid->ctx);
@@ -769,16 +778,25 @@ static int do_act_establish(struct t3cdev *dev, struct sk_buff *skb)
{
struct cpl_act_establish *req = cplhdr(skb);
unsigned int atid = G_PASS_OPEN_TID(ntohl(req->tos_tid));
+ struct tid_info *t = &(T3C_DATA(dev))->tid_maps;
struct t3c_tid_entry *t3c_tid;
+ unsigned int tid = GET_TID(req);
- t3c_tid = lookup_atid(&(T3C_DATA(dev))->tid_maps, atid);
+ if (unlikely(tid >= t->ntids)) {
+ printk("%s: active establish TID %u too large\n",
+ dev->name, tid);
+ t3_fatal_err(tdev2adap(dev));
+ return CPL_RET_BUF_DONE;
+ }
+
+ t3c_tid = lookup_atid(t, atid);
if (t3c_tid && t3c_tid->ctx && t3c_tid->client->handlers &&
t3c_tid->client->handlers[CPL_ACT_ESTABLISH]) {
return t3c_tid->client->handlers[CPL_ACT_ESTABLISH]
(dev, skb, t3c_tid->ctx);
} else {
printk(KERN_ERR "%s: received clientless CPL command 0x%x\n",
- dev->name, CPL_PASS_ACCEPT_REQ);
+ dev->name, CPL_ACT_ESTABLISH);
return CPL_RET_BUF_DONE | CPL_RET_BAD_MSG;
}
}
^ permalink raw reply related
* [PATCH 5/13] cxgb3 - Expose HW memory page info
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>
Let the RDMA driver get HW page info to work around HW issues.
Assign explicit enum values.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/cxgb3_ctl_defs.h | 52 +++++++++++++++++++++---------------
drivers/net/cxgb3/cxgb3_offload.c | 7 +++++
2 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_ctl_defs.h b/drivers/net/cxgb3/cxgb3_ctl_defs.h
index 2095dda..6c4f320 100644
--- a/drivers/net/cxgb3/cxgb3_ctl_defs.h
+++ b/drivers/net/cxgb3/cxgb3_ctl_defs.h
@@ -33,27 +33,29 @@
#define _CXGB3_OFFLOAD_CTL_DEFS_H
enum {
- GET_MAX_OUTSTANDING_WR,
- GET_TX_MAX_CHUNK,
- GET_TID_RANGE,
- GET_STID_RANGE,
- GET_RTBL_RANGE,
- GET_L2T_CAPACITY,
- GET_MTUS,
- GET_WR_LEN,
- GET_IFF_FROM_MAC,
- GET_DDP_PARAMS,
- GET_PORTS,
-
- ULP_ISCSI_GET_PARAMS,
- ULP_ISCSI_SET_PARAMS,
-
- RDMA_GET_PARAMS,
- RDMA_CQ_OP,
- RDMA_CQ_SETUP,
- RDMA_CQ_DISABLE,
- RDMA_CTRL_QP_SETUP,
- RDMA_GET_MEM,
+ GET_MAX_OUTSTANDING_WR = 0,
+ GET_TX_MAX_CHUNK = 1,
+ GET_TID_RANGE = 2,
+ GET_STID_RANGE = 3,
+ GET_RTBL_RANGE = 4,
+ GET_L2T_CAPACITY = 5,
+ GET_MTUS = 6,
+ GET_WR_LEN = 7,
+ GET_IFF_FROM_MAC = 8,
+ GET_DDP_PARAMS = 9,
+ GET_PORTS = 10,
+
+ ULP_ISCSI_GET_PARAMS = 11,
+ ULP_ISCSI_SET_PARAMS = 12,
+
+ RDMA_GET_PARAMS = 13,
+ RDMA_CQ_OP = 14,
+ RDMA_CQ_SETUP = 15,
+ RDMA_CQ_DISABLE = 16,
+ RDMA_CTRL_QP_SETUP = 17,
+ RDMA_GET_MEM = 18,
+
+ GET_RX_PAGE_INFO = 50,
};
/*
@@ -161,4 +163,12 @@ struct rdma_ctrlqp_setup {
unsigned long long base_addr;
unsigned int size;
};
+
+/*
+ * Offload TX/RX page information.
+ */
+struct ofld_page_info {
+ unsigned int page_size; /* Page size, should be a power of 2 */
+ unsigned int num; /* Number of pages */
+};
#endif /* _CXGB3_OFFLOAD_CTL_DEFS_H */
diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c
index e620ed4..522c1be 100644
--- a/drivers/net/cxgb3/cxgb3_offload.c
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -317,6 +317,8 @@ static int cxgb_offload_ctl(struct t3cdev *tdev, unsigned int req, void *data)
struct iff_mac *iffmacp;
struct ddp_params *ddpp;
struct adap_ports *ports;
+ struct ofld_page_info *rx_page_info;
+ struct tp_params *tp = &adapter->params.tp;
int i;
switch (req) {
@@ -382,6 +384,11 @@ static int cxgb_offload_ctl(struct t3cdev *tdev, unsigned int req, void *data)
if (!offload_running(adapter))
return -EAGAIN;
return cxgb_rdma_ctl(adapter, req, data);
+ case GET_RX_PAGE_INFO:
+ rx_page_info = data;
+ rx_page_info->page_size = tp->rx_pg_size;
+ rx_page_info->num = tp->rx_num_pgs;
+ break;
default:
return -EOPNOTSUPP;
}
^ permalink raw reply related
* [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
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