* Re: [2.6 patch] make UNIX a bool
From: Arjan van de Ven @ 2006-02-25 17:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Adrian Bunk, Andrew Morton, netdev, linux-kernel
In-Reply-To: <44009024.5050105@osdl.org>
On Sat, 2006-02-25 at 09:13 -0800, Stephen Hemminger wrote:
> Adrian Bunk wrote:
> > CONFIG_UNIX=m doesn't make much sense.
> >
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> >
> >
> Why? You can build unix domain sockets as a loadable module and
> it runs fine (or it did last I tried). Whether that makes sense from a
> distribution point of
you didn't use to when modutils used unix sockets internally :)
unix also needs a bunch of deeply internals exported that apparently
people want to play with...
^ permalink raw reply
* Re: [2.6 patch] make UNIX a bool
From: Stephen Hemminger @ 2006-02-25 17:13 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, netdev, linux-kernel
In-Reply-To: <20060225160150.GX3674@stusta.de>
Adrian Bunk wrote:
> CONFIG_UNIX=m doesn't make much sense.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
>
>
Why? You can build unix domain sockets as a loadable module and
it runs fine (or it did last I tried). Whether that makes sense from a
distribution point of
view, because everybody wants it, is another story.
^ permalink raw reply
* [2.6 patch] make UNIX a bool
From: Adrian Bunk @ 2006-02-25 16:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
CONFIG_UNIX=m doesn't make much sense.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 20 Feb 2006
--- linux-2.6.16-rc4-mm1-full/net/unix/Kconfig.old 2006-02-20 14:40:19.000000000 +0100
+++ linux-2.6.16-rc4-mm1-full/net/unix/Kconfig 2006-02-20 14:40:27.000000000 +0100
@@ -3,7 +3,7 @@
#
config UNIX
- tristate "Unix domain sockets"
+ bool "Unix domain sockets"
---help---
If you say Y here, you will include support for Unix domain sockets;
sockets are the standard Unix mechanism for establishing and
^ permalink raw reply
* Re: [-mm patch] net/dccp/ipv4.c: make struct dccp_v4_prot static
From: Arnaldo Carvalho de Melo @ 2006-02-25 14:31 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, davem, acme, linux-kernel, netdev
In-Reply-To: <20060225132729.GP3674@stusta.de>
On 2/25/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Fri, Feb 24, 2006 at 03:10:02AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-rc4-mm1:
> >...
> > git-net.patch
> >...
> > git trees.
> >...
>
>
> There's no reason for struct dccp_v4_prot being global.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.16-rc4-mm2-full/net/dccp/ipv4.c.old 2006-02-25 04:32:45.000000000 +0100
> +++ linux-2.6.16-rc4-mm2-full/net/dccp/ipv4.c 2006-02-25 04:32:53.000000000 +0100
> @@ -1022,7 +1022,7 @@
> .twsk_obj_size = sizeof(struct inet_timewait_sock),
> };
>
> -struct proto dccp_v4_prot = {
> +static struct proto dccp_v4_prot = {
> .name = "DCCP",
> .owner = THIS_MODULE,
> .close = dccp_close,
Heck, the last series of patches were exactly to separate ipv4/ipv6 in
DCCP more clearly, how could I forget the cherry on top (sticking this static
in front of dccp_v4_prot)?
Eagle eyes indeed.
Thanks.
- Arnaldo
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Jan Engelhardt @ 2006-02-25 14:19 UTC (permalink / raw)
To: gene.heskett
Cc: Christoph Hellwig, James Ketrenos, NetDev, linux-kernel, okir
In-Reply-To: <200602250549.47547.gene.heskett@verizon.net>
>If the modules crc changes,
>it must do an instant disable of the transmitter functions and exit or
>crash, thereby precluding any 'hot rodding' of the chipset.
>
Would not it be easiest to have the chipset enforce the acceptable bands?
So that software can't switch the chipset to 1337 GHz no matter how hard
you forward/reverse-engineer it.
Jan Engelhardt
--
^ permalink raw reply
* [-mm patch] net/dccp/ipv4.c: make struct dccp_v4_prot static
From: Adrian Bunk @ 2006-02-25 13:27 UTC (permalink / raw)
To: Andrew Morton, davem, acme; +Cc: linux-kernel, netdev
In-Reply-To: <20060224031002.0f7ff92a.akpm@osdl.org>
On Fri, Feb 24, 2006 at 03:10:02AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc4-mm1:
>...
> git-net.patch
>...
> git trees.
>...
There's no reason for struct dccp_v4_prot being global.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc4-mm2-full/net/dccp/ipv4.c.old 2006-02-25 04:32:45.000000000 +0100
+++ linux-2.6.16-rc4-mm2-full/net/dccp/ipv4.c 2006-02-25 04:32:53.000000000 +0100
@@ -1022,7 +1022,7 @@
.twsk_obj_size = sizeof(struct inet_timewait_sock),
};
-struct proto dccp_v4_prot = {
+static struct proto dccp_v4_prot = {
.name = "DCCP",
.owner = THIS_MODULE,
.close = dccp_close,
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Michael Buesch @ 2006-02-25 13:26 UTC (permalink / raw)
To: Jeff V. Merkey; +Cc: NetDev, linux-kernel, James Ketrenos
In-Reply-To: <43FF9B3A.5010307@wolfmountaingroup.com>
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
On Saturday 25 February 2006 00:48, you wrote:
>
> Awesome. Now all we need is someone to write the bcm series for wireless
> and ndiswrapper
> can go away.
What, eh? We have a bcm43xx driver. Or what do you mean?
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Michael Buesch @ 2006-02-25 13:19 UTC (permalink / raw)
To: Gene Heskett; +Cc: Christoph Hellwig, James Ketrenos, NetDev, linux-kernel
In-Reply-To: <200602250619.04567.gene.heskett@verizon.net>
[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]
On Saturday 25 February 2006 12:19, Gene Heskett wrote:
> On Saturday 25 February 2006 05:53, Christoph Hellwig wrote:
> >On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote:
> >> As someone (a broadcast engineer with 40+ years of carrying what
> >> used to be a 1st phone) obviously more familiar with the FCC R&R
> >> than you apparently are, Christoph, I'll have to argue that point.
> >
> >Please stop spreading the bullshit. Please quote the FCC regulation
> > on this.
>
> Its not "bullshit" as you so "eloquently" put it, Christoph. As for
> looking it up, I'd imagine your ability to run a search engine at
> fcc.gov exceeds mine. Hint, its probably in the section called "Rules
> that apply to all". These rules go back to about the time of when they
> outlawed any transmit tunability in CB radios in the later 70's, so its
> not a new item by any means as its just an extension of that edict to
> cover this newer technology. The fact that it effectively put a stop to
> conference call type use of single sideband because no 2 radios were on
> the same, now non-adjustable frequency was an undesirable thing, but
> thats the breaks. I might try and look it up after I've had some zz's,
> as I just came from doing transmitter maintainance overnight.
Well, be it this or that way. I don't see how a binary blob is
able to prevent that the user operates the device on illegal
freqs. In fact, it is a void protection and is just inconvenient.
An open source regdomain implementation is just as safe against
modifications, as this binary blob. There is no point in doing this
binary.
In fact, if you really want to prevent people from doing
Something Bad (tm), you must take technologies such as Trusted Computing.
And even that can, by the opinion of many people, circumvented somehow.
The best way to prevent, that a device is driven on illegal freqs,
is by not selling the device.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Stefan Rompf @ 2006-02-25 12:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: gene.heskett, James Ketrenos, NetDev, linux-kernel
In-Reply-To: <20060225105340.GA23643@infradead.org>
Am Samstag 25 Februar 2006 11:53 schrieb Christoph Hellwig:
>From a short glance over the driver code, the protocol between the _open
source_ driver and the binary user space daemon seems to be quite defined and
unobfuscated. Obviously, someone owning the device has to verify that the
daemon doesn't tamper the hardware beyond the driver's back.
> We have support for other software radios.
There is a difference. As kernel developers, we can put the responsibility to
verify that a device can be operated legally on the user, as you said. A
manufacturer, especially a huge one as Intel, is obligated to take this
burden from their customers - obligated may be by law, may be by company
policy.
> If intel doesn't do the right
> thing support for their hardware will have to wait until someone has
> reverse-engineered their daemon [1].
If someone else reverse engineers and replaces the daemon, it may not be
Intel's problem anymore - but that's all not the point.
Actually, Intel invested a lot of time to avoid shipping a binary only driver
or a HAL like madwifi does. So however this settles, they deserve at least to
be adressed in a less insulting tone than you do in your mails.
Thanks,
Stefan
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Gene Heskett @ 2006-02-25 11:19 UTC (permalink / raw)
To: Christoph Hellwig, James Ketrenos, NetDev, linux-kernel
In-Reply-To: <20060225105340.GA23643@infradead.org>
On Saturday 25 February 2006 05:53, Christoph Hellwig wrote:
>On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote:
>> As someone (a broadcast engineer with 40+ years of carrying what
>> used to be a 1st phone) obviously more familiar with the FCC R&R
>> than you apparently are, Christoph, I'll have to argue that point.
>
>Please stop spreading the bullshit. Please quote the FCC regulation
> on this.
Its not "bullshit" as you so "eloquently" put it, Christoph. As for
looking it up, I'd imagine your ability to run a search engine at
fcc.gov exceeds mine. Hint, its probably in the section called "Rules
that apply to all". These rules go back to about the time of when they
outlawed any transmit tunability in CB radios in the later 70's, so its
not a new item by any means as its just an extension of that edict to
cover this newer technology. The fact that it effectively put a stop to
conference call type use of single sideband because no 2 radios were on
the same, now non-adjustable frequency was an undesirable thing, but
thats the breaks. I might try and look it up after I've had some zz's,
as I just came from doing transmitter maintainance overnight.
>> So basicly, you can accept it with the wrappers Intel provides, or
>> linux will not have access to the use of these devices, any of them
>> that fit in the category of "software radios".
>
>We have support for other software radios. If intel doesn't do the
> right thing support for their hardware will have to wait until
> someone has reverse-engineered their daemon [1].
>
>[1] they disallow it in their license, but that's completely void in
> many countries.
I don't think you'll find that to be the case here in the states.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Christoph Hellwig @ 2006-02-25 10:53 UTC (permalink / raw)
To: gene.heskett; +Cc: James Ketrenos, NetDev, linux-kernel
In-Reply-To: <200602250549.47547.gene.heskett@verizon.net>
On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote:
> As someone (a broadcast engineer with 40+ years of carrying what used to
> be a 1st phone) obviously more familiar with the FCC R&R than you
> apparently are, Christoph, I'll have to argue that point.
Please stop spreading the bullshit. Please quote the FCC regulation on
this.
> So basicly, you can accept it with the wrappers Intel provides, or linux
> will not have access to the use of these devices, any of them that fit
> in the category of "software radios".
We have support for other software radios. If intel doesn't do the right
thing support for their hardware will have to wait until someone has
reverse-engineered their daemon [1].
[1] they disallow it in their license, but that's completely void in many
countries.
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Gene Heskett @ 2006-02-25 10:49 UTC (permalink / raw)
To: Christoph Hellwig, James Ketrenos, NetDev, linux-kernel, okir
In-Reply-To: <20060225084139.GB22109@infradead.org>
On Saturday 25 February 2006 03:41, Christoph Hellwig wrote:
>On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos wrote:
>> As a result of this change, some of the capabilities currently
>> required to be provided on the host include enforcement of
>> regulatory limits for the radio transmitter (radio calibration,
>> transmit power, valid channels, 802.11h, etc.) In order to meet the
>> requirements of all geographies into which our adapters ship (over
>> 100 countries) we have placed the regulatory enforcement logic into
>> a user space daemon that we provide as a binary under the same
>> license agreement as the microcode. We provide that binary
>> pre-compiled as both a 32-bit and
>
>the regualatory problems are not true. they are completely focused on
>the users. Someone who wants to change it can always do it, may it be
>by binary patching. I don't know of a single country that forbids
>implementing those bits in source code shipped, and in those countries
>we alredy couldn't distribute the kernel.
>
>A binary daemon is completely unacceptable and unless you fix that
> there is zero chance the driver could get into mainline. I'd also
> like to urge the distributors to not put this crap in to weaken our
> free drivers future. Intel, please stop this madness and play by the
> rules.
As someone (a broadcast engineer with 40+ years of carrying what used to
be a 1st phone) obviously more familiar with the FCC R&R than you
apparently are, Christoph, I'll have to argue that point. Intel has no
legal choice in the matter because the FCC had decreed that the stuff
to enforce the radiation limits either has to be in a custom made for
each country chip, or in binaries that check themselves for tampering
by secure crc, md5sum or similar methods. If the modules crc changes,
it must do an instant disable of the transmitter functions and exit or
crash, thereby precluding any 'hot rodding' of the chipset.
So basicly, you can accept it with the wrappers Intel provides, or linux
will not have access to the use of these devices, any of them that fit
in the category of "software radios". Intel et all has NO choice in
the matter in this country by FCC decree, and I believe its copycatted
by the Canadien DOC by treaty. Other locales may change the rules
slightly and often do, hence the requirement for manufacture of the
software radio, one thats totally controlled by the software issued for
that locale's use.
The fact that they are furnishing a wrapper, somewhat in the ndiswrapper
style, says that Intel would like a piece of this market, but with the
choice you are giving them with this arbitrary statement, they have no
choice but to quietly fold up their tents and go home. You are asking
Intel to break the laws designed to enforce the use of the 802-11 bands
in a legal manner.
So you might want to rethink your objections. I agree that it should
never become a piece of the kernel because it can't be audited, nor
even dissed without a DMCA prosecution, but we've been using nvidia's
stuff in modular fashion for quite some time, usually with decent
results. Its up to the user to install it of course, but thats
precisely the same scenario here with the Intel code. Intel will have
to put it someplace where the *user* can download it, meaning a server
setup someplace as opposed to handing the kernel developers one copy,
but thats the breaks as we've chosen to do it. Intel will also be
expected to supply a method of fileing bugs in case it doesn't work. A
publicly postable list that is actually supported for any and all bug
claims posted. Its an expense for intel of course but thats their
price of having a dog in this fight.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Paul Rolland @ 2006-02-25 10:08 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, linux.nics, cramerj, john.ronciak, Ganesh.Venkatesan
In-Reply-To: <20060225085409.GA22456@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
Hello,
This patch is based on Linux 2.4.32, and I've verified the same problem
exists on 2.6.15.4.
Working on a machine with a 2.4.32 kernel, I was surprised to see the driver
complaining when setting the speed to 100FD using mii-tool, but accepting
the setting with ethtool.
Digging into the code, I found that there is some confusion with :
- DUPLEX_FULL and FULL_DUPLEX,
- DUPLEX_HALF and HALF_DUPLEX
in the code :
...
spddplx += (mii_reg & 0x100)
? FULL_DUPLEX :
HALF_DUPLEX;
retval = e1000_set_spd_dplx(adapter,
spddplx);
...
and
int
e1000_set_spd_dplx(struct e1000_adapter *adapter, uint16_t spddplx)
{
adapter->hw.autoneg = 0;
switch(spddplx) {
case SPEED_10 + DUPLEX_HALF:
adapter->hw.forced_speed_duplex = e1000_10_half;
break;
....
when the constants don't have the same value.
This patch is simply changing the code in the e1000_set_spd_dplx to use the
same constants as does the caller of the function : FULL_DUPLEX and
HALF_DUPLEX
whose values are not 0, to make sure we have had a successfull init
(DUPLEX_HALF value is 0, and the DUPLEX_xxx are defined in ethtool.h, thus
are probably not meant to be used in the mii interface).
Signed-off-by: Paul Rolland <rol@as2917.net>
diff -urN linux-2.4.32-orig/drivers/net/e1000/e1000_main.c
linux-2.4.32/drivers/net/e1000/e1000_main.c
--- linux-2.4.32-orig/drivers/net/e1000/e1000_main.c Mon Apr 4 01:42:19
2005
+++ linux-2.4.32/drivers/net/e1000/e1000_main.c Sat Feb 25 09:36:23 2006
@@ -2944,23 +2944,23 @@
adapter->hw.autoneg = 0;
switch(spddplx) {
- case SPEED_10 + DUPLEX_HALF:
+ case SPEED_10 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_half;
break;
- case SPEED_10 + DUPLEX_FULL:
+ case SPEED_10 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_full;
break;
- case SPEED_100 + DUPLEX_HALF:
+ case SPEED_100 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_half;
break;
- case SPEED_100 + DUPLEX_FULL:
+ case SPEED_100 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_full;
break;
- case SPEED_1000 + DUPLEX_FULL:
+ case SPEED_1000 + FULL_DUPLEX:
adapter->hw.autoneg = 1;
adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL;
break;
- case SPEED_1000 + DUPLEX_HALF: /* not supported */
+ case SPEED_1000 + HALF_DUPLEX: /* not supported */
default:
DPRINTK(PROBE, ERR,
"Unsupported Speed/Duplexity configuration\n");
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
[-- Attachment #2: e1000.patch --]
[-- Type: application/octet-stream, Size: 1487 bytes --]
diff -urN linux-2.4.32-orig/drivers/net/e1000/e1000_main.c linux-2.4.32/drivers/net/e1000/e1000_main.c
--- linux-2.4.32-orig/drivers/net/e1000/e1000_main.c Mon Apr 4 01:42:19 2005
+++ linux-2.4.32/drivers/net/e1000/e1000_main.c Sat Feb 25 09:36:23 2006
@@ -2944,23 +2944,23 @@
adapter->hw.autoneg = 0;
switch(spddplx) {
- case SPEED_10 + DUPLEX_HALF:
+ case SPEED_10 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_half;
break;
- case SPEED_10 + DUPLEX_FULL:
+ case SPEED_10 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_full;
break;
- case SPEED_100 + DUPLEX_HALF:
+ case SPEED_100 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_half;
break;
- case SPEED_100 + DUPLEX_FULL:
+ case SPEED_100 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_full;
break;
- case SPEED_1000 + DUPLEX_FULL:
+ case SPEED_1000 + FULL_DUPLEX:
adapter->hw.autoneg = 1;
adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL;
break;
- case SPEED_1000 + DUPLEX_HALF: /* not supported */
+ case SPEED_1000 + HALF_DUPLEX: /* not supported */
default:
DPRINTK(PROBE, ERR,
"Unsupported Speed/Duplexity configuration\n");
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Christoph Hellwig @ 2006-02-25 8:41 UTC (permalink / raw)
To: James Ketrenos; +Cc: NetDev, linux-kernel, okir
In-Reply-To: <43FF88E6.6020603@linux.intel.com>
On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos wrote:
> As a result of this change, some of the capabilities currently required
> to be provided on the host include enforcement of regulatory limits for
> the radio transmitter (radio calibration, transmit power, valid
> channels, 802.11h, etc.) In order to meet the requirements of all
> geographies into which our adapters ship (over 100 countries) we have
> placed the regulatory enforcement logic into a user space daemon that
> we provide as a binary under the same license agreement as the
> microcode. We provide that binary pre-compiled as both a 32-bit and
the regualatory problems are not true. they are completely focused on
the users. Someone who wants to change it can always do it, may it be
by binary patching. I don't know of a single country that forbids
implementing those bits in source code shipped, and in those countries
we alredy couldn't distribute the kernel.
A binary daemon is completely unacceptable and unless you fix that there
is zero chance the driver could get into mainline. I'd also like to
urge the distributors to not put this crap in to weaken our free drivers
future. Intel, please stop this madness and play by the rules.
^ permalink raw reply
* Re: [PATCH] Add Wake on LAN support to sis900 (2)
From: John Reiser @ 2006-02-25 0:08 UTC (permalink / raw)
To: Daniele Venzano
Cc: Jeff Garzik, netdev, Linux Kernel Mailing List, Dave Jones
In-Reply-To: <5698750A-4231-4500-B060-B06165E5C0FD@brownhat.org>
Daniele Venzano wrote:
> Attached you find the patch that fixes two bugs in the WoL
> implementation of sis900. The first causes hangs on some system on
> driver load, the second causes troubles when disabling WoL support.
> Both fixes are one liner and really simple. Patch is against latest
> netdev-2.6 tree.
Thank you for your prompt attention. The patch works for me
(my SiS 730 board now boots again) when applied to Fedora Core
kernel-2.6.15-1.1977_FC5 which claims to be 2.6.16rc4-git6
of 2006-02-23.
--
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Jeff V. Merkey @ 2006-02-24 23:48 UTC (permalink / raw)
To: James Ketrenos; +Cc: NetDev, linux-kernel
In-Reply-To: <43FF88E6.6020603@linux.intel.com>
Awesome. Now all we need is someone to write the bcm series for wireless
and ndiswrapper
can go away.
Jeff
James Ketrenos wrote:
>Intel is pleased to announce the launch of an open source project to
>support the Intel PRO/Wireless 3945ABG Network Connection mini-PCI
>express adapter (IPW3945).
>
>The project is hosted at http://ipw3945.sourceforge.net. A development
>mailing list is available (linked from the top of the IPW3945 project
>page.) You can find the current development release for the adapter by
>following the links on the project home page.
>
>A stable [end user targetted] version is not yet available. Those
>interested in using the development version should review
>the notice linked to from the project page. A stable version should
>be available in the next few weeks.
>
>Aside from a form factor change (our prior wireless cards were mini PCI
>while this one is mini PCI express), this project has also changed the
>division of work between what occurs on the adapter and what the host is
>responsible for performing. The microcode and hardware provide lower
>level MAC services (timings, backoffs, transmit queue management, etc.)
>The host is responsible for middle and upper layer MAC services.
>
>As a result of this change, some of the capabilities currently required
>to be provided on the host include enforcement of regulatory limits for
>the radio transmitter (radio calibration, transmit power, valid
>channels, 802.11h, etc.) In order to meet the requirements of all
>geographies into which our adapters ship (over 100 countries) we have
>placed the regulatory enforcement logic into a user space daemon that
>we provide as a binary under the same license agreement as the
>microcode. We provide that binary pre-compiled as both a 32-bit and
>64-bit application. The daemon utilizes a sysfs interface exposed by
>the driver in order to communicate with the hardware and configure the
>required regulatory parameters.
>
>Those familiar with our prior projects may be pleased with the changes
>we have made with the license agreement for binary portions of this new
>project. We were able to provide a more easily understood agreement
>for the binary components required for the adapter to function. While
>this new license still restricts against reverse engineering and
>modification, it has been changed to allow easier redistribution. You
>can find the terms of the agreement accessible from the microcode
>and daemon download page linked to from the project site.
>
>The current development snapshot contains backward compatibility code
>to allow the driver to work in older kernels. We will be removing
>that code prior to submitting the driver for inclusion in the kernel.
>
>Thanks,
>James
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Dax Kelson @ 2006-02-24 23:34 UTC (permalink / raw)
To: James Ketrenos; +Cc: NetDev, linux-kernel
In-Reply-To: <43FF88E6.6020603@linux.intel.com>
On Fri, 2006-02-24 at 16:29 -0600, James Ketrenos wrote:
> Intel is pleased to announce the launch of an open source project to
> support the Intel PRO/Wireless 3945ABG Network Connection mini-PCI
> express adapter (IPW3945).
Cool!
> In order to meet the requirements of all
> geographies into which our adapters ship (over 100 countries) we have
> placed the regulatory enforcement logic into a user space daemon that
> we provide as a binary under the same license agreement as the
> microcode. We provide that binary pre-compiled as both a 32-bit and
> 64-bit application. The daemon utilizes a sysfs interface exposed by
> the driver in order to communicate with the hardware and configure the
> required regulatory parameters.
It was exciting to watch the "centrino" wireless cards go from the least
supported cards in the Linux to the near the best G and A cards from a
feature and licensing stand point (modulo the firmware restart issues).
I have a ipw2200 and have recommended it and now the ipw2915 to anyone
who has asked (myself and ipw2xxx using co-workers have taught thousands
of students and decision makers in Linux classes worldwide).
It is very disappointing to see this binary user space daemon (that must
run as root, presumably to write into /sys/) requirement. I recognize
that it is a better poison than a binary kernel module.
At the point when I'm in the market for a mini-PCI express wireless
adapter I hope there are other cards available that don't require any
kernel or userland binary pieces. I'll vote with my wallet so to speak.
Dax Kelson
Guru Labs
^ permalink raw reply
* [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: James Ketrenos @ 2006-02-24 22:29 UTC (permalink / raw)
To: NetDev, linux-kernel
Intel is pleased to announce the launch of an open source project to
support the Intel PRO/Wireless 3945ABG Network Connection mini-PCI
express adapter (IPW3945).
The project is hosted at http://ipw3945.sourceforge.net. A development
mailing list is available (linked from the top of the IPW3945 project
page.) You can find the current development release for the adapter by
following the links on the project home page.
A stable [end user targetted] version is not yet available. Those
interested in using the development version should review
the notice linked to from the project page. A stable version should
be available in the next few weeks.
Aside from a form factor change (our prior wireless cards were mini PCI
while this one is mini PCI express), this project has also changed the
division of work between what occurs on the adapter and what the host is
responsible for performing. The microcode and hardware provide lower
level MAC services (timings, backoffs, transmit queue management, etc.)
The host is responsible for middle and upper layer MAC services.
As a result of this change, some of the capabilities currently required
to be provided on the host include enforcement of regulatory limits for
the radio transmitter (radio calibration, transmit power, valid
channels, 802.11h, etc.) In order to meet the requirements of all
geographies into which our adapters ship (over 100 countries) we have
placed the regulatory enforcement logic into a user space daemon that
we provide as a binary under the same license agreement as the
microcode. We provide that binary pre-compiled as both a 32-bit and
64-bit application. The daemon utilizes a sysfs interface exposed by
the driver in order to communicate with the hardware and configure the
required regulatory parameters.
Those familiar with our prior projects may be pleased with the changes
we have made with the license agreement for binary portions of this new
project. We were able to provide a more easily understood agreement
for the binary components required for the adapter to function. While
this new license still restricts against reverse engineering and
modification, it has been changed to allow easier redistribution. You
can find the terms of the agreement accessible from the microcode
and daemon download page linked to from the project site.
The current development snapshot contains backward compatibility code
to allow the driver to work in older kernels. We will be removing
that code prior to submitting the driver for inclusion in the kernel.
Thanks,
James
^ permalink raw reply
* (usagi-users 03617) Re: [PATCH] ip6_tunnel: release cached dst on change of tunnel params
From: David S. Miller @ 2006-02-24 21:16 UTC (permalink / raw)
To: vnuorval; +Cc: netdev, usagi-users
In-Reply-To: <43FF104B.1090006@tcs.hut.fi>
From: Ville Nuorvala <vnuorval@tcs.hut.fi>
Date: Fri, 24 Feb 2006 15:55:23 +0200
> Hugo Santos wrote:
> > Hi,
> >
> > The included patch fixes ip6_tunnel to release the cached dst entry
> > when the tunnel parameters (such as tunnel endpoints) are changed so
> > they are used immediatly for the next encapsulated packets.
> >
> > Signed-off-by: Hugo Santos <hsantos@av.it.pt>
> >
> > --- linux-2.6.16-rc4/net/ipv6/ip6_tunnel.c 2006-02-17 22:23:45.000000000 +0000
> > +++ linux-2.6.16-rc4-new/net/ipv6/ip6_tunnel.c 2006-02-24 01:40:17.000000000 +0000
> > @@ -884,6 +884,7 @@ ip6ip6_tnl_change(struct ip6_tnl *t, str
> > t->parms.encap_limit = p->encap_limit;
> > t->parms.flowinfo = p->flowinfo;
> > t->parms.link = p->link;
> > + ip6_tnl_dst_reset(t);
> > ip6ip6_tnl_link_config(t);
> > return 0;
> > }
> >
> Acked-by: Ville Nuorvala <vnuorval@tcs.hut.fi>
Applied, although the patch was tab/whitespace damaged by Hugo's
email client so I had to apply it by hand.
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Wolfgang Hoffmann @ 2006-02-24 17:28 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jeff Garzik, Andrew Morton, Linus Torvalds, netdev, linux-kernel
In-Reply-To: <43FF30D1.8060708@osdl.org>
On Friday 24 February 2006 17:14, Stephen Hemminger wrote:
> There is an outstanding bug where the sky2 will hang if it receives a
> packet larger than the MTU. At this point, there isn't enough information
> on chip behavior to fix.
>
> You could try using a larger mut or patching the driver so that the
> rx_buffer_size is always big (like 4k).
I've raised the MTU from 1500 to 3000 and still reproduced the hang. Would you
mind sending me a patch for forcing rx_buffer_size to 4k, so I can try that,
or is no sense in that, given that raising the MTU didn't help?
Concerning information on chip behavior, are you missing vendor specs, or
could I be helpful by reproducing the hang with an instrumented driver that
gives more information about the chip status at hang time?
Another thing that may be worth to find out is why 0.13 with Carl-Daniel
Hailfingers fix works. I didn't see a single hang with that version. I'm
currently resorting to that version, but well ...
I'd really like to help get this driver working robustly. I'm not enough into
networking to help by coding, but yes I'll give feedback on any driver
version you send me. I'd just like to provide you more helpful data than
repeating "new version still hangs" ;-)
Wolfgang
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Stephen Hemminger @ 2006-02-24 16:14 UTC (permalink / raw)
To: woho; +Cc: Jeff Garzik, Andrew Morton, Linus Torvalds, netdev, linux-kernel
In-Reply-To: <200602240859.23062.woho@woho.de>
Wolfgang Hoffmann wrote:
> On Friday 24 February 2006 06:22, Jeff Garzik wrote:
>
>> Please pull from 'upstream-fixes' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>>
>> [...]
>> Stephen Hemminger:
>> sky2: yukon-ec-u chipset initialization
>> sky2: limit coalescing values to ring size
>> sky2: poke coalescing timer to fix hang
>> sky2: force early transmit status
>> sky2: use device iomem to access PCI config
>> sky2: close race on IRQ mask update.
>> [...]
>>
>
> Thanks for the update.
>
> Still I'm seeing reproducable hangs with this version of sky2 (as reported in
> bugzilla 6084 and discussed on netdev).
>
> Stephen, if there is anything I can do to narrow down my hangs a bit more
> systematically, please let me know, I'd be happy to help.
>
> Wolfgang
>
There is an outstanding bug where the sky2 will hang if it receives a
packet larger than the
MTU. At this point, there isn't enough information on chip behavior to fix.
You could try using a larger mut or patching the driver so that the
rx_buffer_size is always big (like 4k).
^ permalink raw reply
* Re: [PATCH] Add Wake on LAN support to sis900 (2)
From: Daniele Venzano @ 2006-02-24 10:03 UTC (permalink / raw)
To: Jeff Garzik, netdev; +Cc: Linux Kernel Mailing List, Dave Jones
In-Reply-To: <20060224025759.GA14027@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
Attached you find the patch that fixes two bugs in the WoL
implementation of sis900. The first causes hangs on some system on
driver load, the second causes troubles when disabling WoL support.
Both fixes are one liner and really simple. Patch is against latest
netdev-2.6 tree.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Daniele Venzano <venza@brownhat.org>
[-- Attachment #2: sis900_wol_fix.diff --]
[-- Type: application/octet-stream, Size: 852 bytes --]
--- new/drivers/net/sis900.c.old 2006-02-24 10:46:06.000000000 +0100
+++ new/drivers/net/sis900.c 2006-02-24 09:57:57.000000000 +0100
@@ -540,7 +540,7 @@ static int __devinit sis900_probe(struct
printk("%2.2x.\n", net_dev->dev_addr[i]);
/* Detect Wake on Lan support */
- ret = inl(CFGPMC & PMESP);
+ ret = (inl(net_dev->base_addr + CFGPMC) & PMESP) >> 27;
if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0)
printk(KERN_INFO "%s: Wake on LAN only available from suspend to RAM.", net_dev->name);
@@ -2040,7 +2040,7 @@ static int sis900_set_wol(struct net_dev
if (wol->wolopts == 0) {
pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr);
- cfgpmcsr |= ~PME_EN;
+ cfgpmcsr &= ~PME_EN;
pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr);
outl(pmctrl_bits, pmctrl_addr);
if (netif_msg_wol(sis_priv))
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Wolfgang Hoffmann @ 2006-02-24 7:59 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jeff Garzik, Andrew Morton, Linus Torvalds, netdev, linux-kernel
In-Reply-To: <20060224052214.GA14586@havoc.gtf.org>
On Friday 24 February 2006 06:22, Jeff Garzik wrote:
> Please pull from 'upstream-fixes' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
> [...]
> Stephen Hemminger:
> sky2: yukon-ec-u chipset initialization
> sky2: limit coalescing values to ring size
> sky2: poke coalescing timer to fix hang
> sky2: force early transmit status
> sky2: use device iomem to access PCI config
> sky2: close race on IRQ mask update.
>[...]
Thanks for the update.
Still I'm seeing reproducable hangs with this version of sky2 (as reported in
bugzilla 6084 and discussed on netdev).
Stephen, if there is anything I can do to narrow down my hangs a bit more
systematically, please let me know, I'd be happy to help.
Wolfgang
^ permalink raw reply
* [git patches] net driver fixes
From: Jeff Garzik @ 2006-02-24 5:22 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/r8169.c | 189 ++++++++++++++++++++++++++++++++++++++++------------
drivers/net/skge.c | 75 ++++++++++++--------
drivers/net/skge.h | 1
drivers/net/sky2.c | 173 ++++++++++++++++++++++++++++-------------------
drivers/net/sky2.h | 85 ++++++++++++++++++++---
drivers/net/tlan.c | 2
6 files changed, 371 insertions(+), 154 deletions(-)
Adrian Bunk:
drivers/net/tlan.c: #ifdef CONFIG_PCI the PCI specific code
Francois Romieu:
r8169: fix broken ring index handling in suspend/resume
r8169: enable wake on lan
Stephen Hemminger:
sky2: yukon-ec-u chipset initialization
sky2: limit coalescing values to ring size
sky2: poke coalescing timer to fix hang
sky2: force early transmit status
sky2: use device iomem to access PCI config
sky2: close race on IRQ mask update.
skge: NAPI/irq race fix
skge: genesis phy initialzation
skge: protect interrupt mask
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 6e10184..8cc0d0b 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -287,6 +287,20 @@ enum RTL8169_register_content {
TxInterFrameGapShift = 24,
TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */
+ /* Config1 register p.24 */
+ PMEnable = (1 << 0), /* Power Management Enable */
+
+ /* Config3 register p.25 */
+ MagicPacket = (1 << 5), /* Wake up when receives a Magic Packet */
+ LinkUp = (1 << 4), /* Wake up when the cable connection is re-established */
+
+ /* Config5 register p.27 */
+ BWF = (1 << 6), /* Accept Broadcast wakeup frame */
+ MWF = (1 << 5), /* Accept Multicast wakeup frame */
+ UWF = (1 << 4), /* Accept Unicast wakeup frame */
+ LanWake = (1 << 1), /* LanWake enable/disable */
+ PMEStatus = (1 << 0), /* PME status can be reset by PCI RST# */
+
/* TBICSR p.28 */
TBIReset = 0x80000000,
TBILoopback = 0x40000000,
@@ -433,6 +447,7 @@ struct rtl8169_private {
unsigned int (*phy_reset_pending)(void __iomem *);
unsigned int (*link_ok)(void __iomem *);
struct work_struct task;
+ unsigned wol_enabled : 1;
};
MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
@@ -607,6 +622,80 @@ static void rtl8169_link_option(int idx,
*duplex = p->duplex;
}
+static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->mmio_addr;
+ u8 options;
+
+ wol->wolopts = 0;
+
+#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
+ wol->supported = WAKE_ANY;
+
+ spin_lock_irq(&tp->lock);
+
+ options = RTL_R8(Config1);
+ if (!(options & PMEnable))
+ goto out_unlock;
+
+ options = RTL_R8(Config3);
+ if (options & LinkUp)
+ wol->wolopts |= WAKE_PHY;
+ if (options & MagicPacket)
+ wol->wolopts |= WAKE_MAGIC;
+
+ options = RTL_R8(Config5);
+ if (options & UWF)
+ wol->wolopts |= WAKE_UCAST;
+ if (options & BWF)
+ wol->wolopts |= WAKE_BCAST;
+ if (options & MWF)
+ wol->wolopts |= WAKE_MCAST;
+
+out_unlock:
+ spin_unlock_irq(&tp->lock);
+}
+
+static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->mmio_addr;
+ int i;
+ static struct {
+ u32 opt;
+ u16 reg;
+ u8 mask;
+ } cfg[] = {
+ { WAKE_ANY, Config1, PMEnable },
+ { WAKE_PHY, Config3, LinkUp },
+ { WAKE_MAGIC, Config3, MagicPacket },
+ { WAKE_UCAST, Config5, UWF },
+ { WAKE_BCAST, Config5, BWF },
+ { WAKE_MCAST, Config5, MWF },
+ { WAKE_ANY, Config5, LanWake }
+ };
+
+ spin_lock_irq(&tp->lock);
+
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+
+ for (i = 0; i < ARRAY_SIZE(cfg); i++) {
+ u8 options = RTL_R8(cfg[i].reg) & ~cfg[i].mask;
+ if (wol->wolopts & cfg[i].opt)
+ options |= cfg[i].mask;
+ RTL_W8(cfg[i].reg, options);
+ }
+
+ RTL_W8(Cfg9346, Cfg9346_Lock);
+
+ tp->wol_enabled = (wol->wolopts) ? 1 : 0;
+
+ spin_unlock_irq(&tp->lock);
+
+ return 0;
+}
+
static void rtl8169_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
@@ -1025,6 +1114,8 @@ static struct ethtool_ops rtl8169_ethtoo
.get_tso = ethtool_op_get_tso,
.set_tso = ethtool_op_set_tso,
.get_regs = rtl8169_get_regs,
+ .get_wol = rtl8169_get_wol,
+ .set_wol = rtl8169_set_wol,
.get_strings = rtl8169_get_strings,
.get_stats_count = rtl8169_get_stats_count,
.get_ethtool_stats = rtl8169_get_ethtool_stats,
@@ -1442,6 +1533,11 @@ rtl8169_init_board(struct pci_dev *pdev,
}
tp->chipset = i;
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+ RTL_W8(Config1, RTL_R8(Config1) | PMEnable);
+ RTL_W8(Config5, RTL_R8(Config5) & PMEStatus);
+ RTL_W8(Cfg9346, Cfg9346_Lock);
+
*ioaddr_out = ioaddr;
*dev_out = dev;
out:
@@ -1612,49 +1708,6 @@ rtl8169_remove_one(struct pci_dev *pdev)
pci_set_drvdata(pdev, NULL);
}
-#ifdef CONFIG_PM
-
-static int rtl8169_suspend(struct pci_dev *pdev, pm_message_t state)
-{
- struct net_device *dev = pci_get_drvdata(pdev);
- struct rtl8169_private *tp = netdev_priv(dev);
- void __iomem *ioaddr = tp->mmio_addr;
- unsigned long flags;
-
- if (!netif_running(dev))
- return 0;
-
- netif_device_detach(dev);
- netif_stop_queue(dev);
- spin_lock_irqsave(&tp->lock, flags);
-
- /* Disable interrupts, stop Rx and Tx */
- RTL_W16(IntrMask, 0);
- RTL_W8(ChipCmd, 0);
-
- /* Update the error counts. */
- tp->stats.rx_missed_errors += RTL_R32(RxMissed);
- RTL_W32(RxMissed, 0);
- spin_unlock_irqrestore(&tp->lock, flags);
-
- return 0;
-}
-
-static int rtl8169_resume(struct pci_dev *pdev)
-{
- struct net_device *dev = pci_get_drvdata(pdev);
-
- if (!netif_running(dev))
- return 0;
-
- netif_device_attach(dev);
- rtl8169_hw_start(dev);
-
- return 0;
-}
-
-#endif /* CONFIG_PM */
-
static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
struct net_device *dev)
{
@@ -2700,6 +2753,56 @@ static struct net_device_stats *rtl8169_
return &tp->stats;
}
+#ifdef CONFIG_PM
+
+static int rtl8169_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+ struct rtl8169_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ if (!netif_running(dev))
+ goto out;
+
+ netif_device_detach(dev);
+ netif_stop_queue(dev);
+
+ spin_lock_irq(&tp->lock);
+
+ rtl8169_asic_down(ioaddr);
+
+ tp->stats.rx_missed_errors += RTL_R32(RxMissed);
+ RTL_W32(RxMissed, 0);
+
+ spin_unlock_irq(&tp->lock);
+
+ pci_save_state(pdev);
+ pci_enable_wake(pdev, pci_choose_state(pdev, state), tp->wol_enabled);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+out:
+ return 0;
+}
+
+static int rtl8169_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ if (!netif_running(dev))
+ goto out;
+
+ netif_device_attach(dev);
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_wake(pdev, PCI_D0, 0);
+
+ rtl8169_schedule_work(dev, rtl8169_reset_task);
+out:
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static struct pci_driver rtl8169_pci_driver = {
.name = MODULENAME,
.id_table = rtl8169_pci_tbl,
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index 67fb19b..25e028b 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -879,13 +879,12 @@ static int __xm_phy_read(struct skge_hw
int i;
xm_write16(hw, port, XM_PHY_ADDR, reg | hw->phy_addr);
- xm_read16(hw, port, XM_PHY_DATA);
+ *val = xm_read16(hw, port, XM_PHY_DATA);
- /* Need to wait for external PHY */
for (i = 0; i < PHY_RETRIES; i++) {
- udelay(1);
if (xm_read16(hw, port, XM_MMU_CMD) & XM_MMU_PHY_RDY)
goto ready;
+ udelay(1);
}
return -ETIMEDOUT;
@@ -918,7 +917,12 @@ static int xm_phy_write(struct skge_hw *
ready:
xm_write16(hw, port, XM_PHY_DATA, val);
- return 0;
+ for (i = 0; i < PHY_RETRIES; i++) {
+ if (!(xm_read16(hw, port, XM_MMU_CMD) & XM_MMU_PHY_BUSY))
+ return 0;
+ udelay(1);
+ }
+ return -ETIMEDOUT;
}
static void genesis_init(struct skge_hw *hw)
@@ -1168,13 +1172,17 @@ static void genesis_mac_init(struct skge
u32 r;
const u8 zero[6] = { 0 };
- /* Clear MIB counters */
- xm_write16(hw, port, XM_STAT_CMD,
- XM_SC_CLR_RXC | XM_SC_CLR_TXC);
- /* Clear two times according to Errata #3 */
- xm_write16(hw, port, XM_STAT_CMD,
- XM_SC_CLR_RXC | XM_SC_CLR_TXC);
+ for (i = 0; i < 10; i++) {
+ skge_write16(hw, SK_REG(port, TX_MFF_CTRL1),
+ MFF_SET_MAC_RST);
+ if (skge_read16(hw, SK_REG(port, TX_MFF_CTRL1)) & MFF_SET_MAC_RST)
+ goto reset_ok;
+ udelay(1);
+ }
+
+ printk(KERN_WARNING PFX "%s: genesis reset failed\n", dev->name);
+ reset_ok:
/* Unreset the XMAC. */
skge_write16(hw, SK_REG(port, TX_MFF_CTRL1), MFF_CLR_MAC_RST);
@@ -1191,7 +1199,7 @@ static void genesis_mac_init(struct skge
r |= GP_DIR_2|GP_IO_2;
skge_write32(hw, B2_GP_IO, r);
- skge_read32(hw, B2_GP_IO);
+
/* Enable GMII interface */
xm_write16(hw, port, XM_HW_CFG, XM_HW_GMII_MD);
@@ -1205,6 +1213,13 @@ static void genesis_mac_init(struct skge
for (i = 1; i < 16; i++)
xm_outaddr(hw, port, XM_EXM(i), zero);
+ /* Clear MIB counters */
+ xm_write16(hw, port, XM_STAT_CMD,
+ XM_SC_CLR_RXC | XM_SC_CLR_TXC);
+ /* Clear two times according to Errata #3 */
+ xm_write16(hw, port, XM_STAT_CMD,
+ XM_SC_CLR_RXC | XM_SC_CLR_TXC);
+
/* configure Rx High Water Mark (XM_RX_HI_WM) */
xm_write16(hw, port, XM_RX_HI_WM, 1450);
@@ -2170,8 +2185,10 @@ static int skge_up(struct net_device *de
skge->tx_avail = skge->tx_ring.count - 1;
/* Enable IRQ from port */
+ spin_lock_irq(&hw->hw_lock);
hw->intr_mask |= portirqmask[port];
skge_write32(hw, B0_IMSK, hw->intr_mask);
+ spin_unlock_irq(&hw->hw_lock);
/* Initialize MAC */
spin_lock_bh(&hw->phy_lock);
@@ -2229,8 +2246,10 @@ static int skge_down(struct net_device *
else
yukon_stop(skge);
+ spin_lock_irq(&hw->hw_lock);
hw->intr_mask &= ~portirqmask[skge->port];
skge_write32(hw, B0_IMSK, hw->intr_mask);
+ spin_unlock_irq(&hw->hw_lock);
/* Stop transmitter */
skge_write8(hw, Q_ADDR(txqaddr[port], Q_CSR), CSR_STOP);
@@ -2678,8 +2697,7 @@ static int skge_poll(struct net_device *
/* restart receiver */
wmb();
- skge_write8(hw, Q_ADDR(rxqaddr[skge->port], Q_CSR),
- CSR_START | CSR_IRQ_CL_F);
+ skge_write8(hw, Q_ADDR(rxqaddr[skge->port], Q_CSR), CSR_START);
*budget -= work_done;
dev->quota -= work_done;
@@ -2687,10 +2705,11 @@ static int skge_poll(struct net_device *
if (work_done >= to_do)
return 1; /* not done */
- netif_rx_complete(dev);
- hw->intr_mask |= portirqmask[skge->port];
- skge_write32(hw, B0_IMSK, hw->intr_mask);
- skge_read32(hw, B0_IMSK);
+ spin_lock_irq(&hw->hw_lock);
+ __netif_rx_complete(dev);
+ hw->intr_mask |= portirqmask[skge->port];
+ skge_write32(hw, B0_IMSK, hw->intr_mask);
+ spin_unlock_irq(&hw->hw_lock);
return 0;
}
@@ -2850,18 +2869,10 @@ static void skge_extirq(unsigned long da
}
spin_unlock(&hw->phy_lock);
- local_irq_disable();
+ spin_lock_irq(&hw->hw_lock);
hw->intr_mask |= IS_EXT_REG;
skge_write32(hw, B0_IMSK, hw->intr_mask);
- local_irq_enable();
-}
-
-static inline void skge_wakeup(struct net_device *dev)
-{
- struct skge_port *skge = netdev_priv(dev);
-
- prefetch(skge->rx_ring.to_clean);
- netif_rx_schedule(dev);
+ spin_unlock_irq(&hw->hw_lock);
}
static irqreturn_t skge_intr(int irq, void *dev_id, struct pt_regs *regs)
@@ -2872,15 +2883,17 @@ static irqreturn_t skge_intr(int irq, vo
if (status == 0 || status == ~0) /* hotplug or shared irq */
return IRQ_NONE;
- status &= hw->intr_mask;
+ spin_lock(&hw->hw_lock);
if (status & IS_R1_F) {
+ skge_write8(hw, Q_ADDR(Q_R1, Q_CSR), CSR_IRQ_CL_F);
hw->intr_mask &= ~IS_R1_F;
- skge_wakeup(hw->dev[0]);
+ netif_rx_schedule(hw->dev[0]);
}
if (status & IS_R2_F) {
+ skge_write8(hw, Q_ADDR(Q_R2, Q_CSR), CSR_IRQ_CL_F);
hw->intr_mask &= ~IS_R2_F;
- skge_wakeup(hw->dev[1]);
+ netif_rx_schedule(hw->dev[1]);
}
if (status & IS_XA1_F)
@@ -2922,6 +2935,7 @@ static irqreturn_t skge_intr(int irq, vo
}
skge_write32(hw, B0_IMSK, hw->intr_mask);
+ spin_unlock(&hw->hw_lock);
return IRQ_HANDLED;
}
@@ -3290,6 +3304,7 @@ static int __devinit skge_probe(struct p
hw->pdev = pdev;
spin_lock_init(&hw->phy_lock);
+ spin_lock_init(&hw->hw_lock);
tasklet_init(&hw->ext_tasklet, skge_extirq, (unsigned long) hw);
hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
diff --git a/drivers/net/skge.h b/drivers/net/skge.h
index 2efdacc..941f12a 100644
--- a/drivers/net/skge.h
+++ b/drivers/net/skge.h
@@ -2402,6 +2402,7 @@ struct skge_hw {
struct tasklet_struct ext_tasklet;
spinlock_t phy_lock;
+ spinlock_t hw_lock;
};
enum {
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index bfeba5b..ca8160d 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -195,11 +195,11 @@ static int sky2_set_power_state(struct s
pr_debug("sky2_set_power_state %d\n", state);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- pci_read_config_word(hw->pdev, hw->pm_cap + PCI_PM_PMC, &power_control);
+ power_control = sky2_pci_read16(hw, hw->pm_cap + PCI_PM_PMC);
vaux = (sky2_read16(hw, B0_CTST) & Y2_VAUX_AVAIL) &&
(power_control & PCI_PM_CAP_PME_D3cold);
- pci_read_config_word(hw->pdev, hw->pm_cap + PCI_PM_CTRL, &power_control);
+ power_control = sky2_pci_read16(hw, hw->pm_cap + PCI_PM_CTRL);
power_control |= PCI_PM_CTRL_PME_STATUS;
power_control &= ~(PCI_PM_CTRL_STATE_MASK);
@@ -223,7 +223,7 @@ static int sky2_set_power_state(struct s
sky2_write8(hw, B2_Y2_CLK_GATE, 0);
/* Turn off phy power saving */
- pci_read_config_dword(hw->pdev, PCI_DEV_REG1, ®1);
+ reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
reg1 &= ~(PCI_Y2_PHY1_POWD | PCI_Y2_PHY2_POWD);
/* looks like this XL is back asswards .. */
@@ -232,18 +232,28 @@ static int sky2_set_power_state(struct s
if (hw->ports > 1)
reg1 |= PCI_Y2_PHY2_COMA;
}
- pci_write_config_dword(hw->pdev, PCI_DEV_REG1, reg1);
+
+ if (hw->chip_id == CHIP_ID_YUKON_EC_U) {
+ sky2_pci_write32(hw, PCI_DEV_REG3, 0);
+ reg1 = sky2_pci_read32(hw, PCI_DEV_REG4);
+ reg1 &= P_ASPM_CONTROL_MSK;
+ sky2_pci_write32(hw, PCI_DEV_REG4, reg1);
+ sky2_pci_write32(hw, PCI_DEV_REG5, 0);
+ }
+
+ sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
+
break;
case PCI_D3hot:
case PCI_D3cold:
/* Turn on phy power saving */
- pci_read_config_dword(hw->pdev, PCI_DEV_REG1, ®1);
+ reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
if (hw->chip_id == CHIP_ID_YUKON_XL && hw->chip_rev > 1)
reg1 &= ~(PCI_Y2_PHY1_POWD | PCI_Y2_PHY2_POWD);
else
reg1 |= (PCI_Y2_PHY1_POWD | PCI_Y2_PHY2_POWD);
- pci_write_config_dword(hw->pdev, PCI_DEV_REG1, reg1);
+ sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
if (hw->chip_id == CHIP_ID_YUKON_XL && hw->chip_rev > 1)
sky2_write8(hw, B2_Y2_CLK_GATE, 0);
@@ -265,7 +275,7 @@ static int sky2_set_power_state(struct s
ret = -1;
}
- pci_write_config_byte(hw->pdev, hw->pm_cap + PCI_PM_CTRL, power_control);
+ sky2_pci_write16(hw, hw->pm_cap + PCI_PM_CTRL, power_control);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
return ret;
}
@@ -463,16 +473,31 @@ static void sky2_phy_init(struct sky2_hw
ledover |= PHY_M_LED_MO_RX(MO_LED_OFF);
}
- gm_phy_write(hw, port, PHY_MARV_LED_CTRL, ledctrl);
+ if (hw->chip_id == CHIP_ID_YUKON_EC_U && hw->chip_rev >= 2) {
+ /* apply fixes in PHY AFE */
+ gm_phy_write(hw, port, 22, 255);
+ /* increase differential signal amplitude in 10BASE-T */
+ gm_phy_write(hw, port, 24, 0xaa99);
+ gm_phy_write(hw, port, 23, 0x2011);
+
+ /* fix for IEEE A/B Symmetry failure in 1000BASE-T */
+ gm_phy_write(hw, port, 24, 0xa204);
+ gm_phy_write(hw, port, 23, 0x2002);
- if (sky2->autoneg == AUTONEG_DISABLE || sky2->speed == SPEED_100) {
- /* turn on 100 Mbps LED (LED_LINK100) */
- ledover |= PHY_M_LED_MO_100(MO_LED_ON);
- }
+ /* set page register to 0 */
+ gm_phy_write(hw, port, 22, 0);
+ } else {
+ gm_phy_write(hw, port, PHY_MARV_LED_CTRL, ledctrl);
- if (ledover)
- gm_phy_write(hw, port, PHY_MARV_LED_OVER, ledover);
+ if (sky2->autoneg == AUTONEG_DISABLE || sky2->speed == SPEED_100) {
+ /* turn on 100 Mbps LED (LED_LINK100) */
+ ledover |= PHY_M_LED_MO_100(MO_LED_ON);
+ }
+
+ if (ledover)
+ gm_phy_write(hw, port, PHY_MARV_LED_OVER, ledover);
+ }
/* Enable phy interrupt on auto-negotiation complete (or link up) */
if (sky2->autoneg == AUTONEG_ENABLE)
gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_IS_AN_COMPL);
@@ -953,6 +978,12 @@ static int sky2_rx_start(struct sky2_por
sky2->rx_put = sky2->rx_next = 0;
sky2_qset(hw, rxq);
+
+ if (hw->chip_id == CHIP_ID_YUKON_EC_U && hw->chip_rev >= 2) {
+ /* MAC Rx RAM Read is controlled by hardware */
+ sky2_write32(hw, Q_ADDR(rxq, Q_F), F_M_RX_RAM_DIS);
+ }
+
sky2_prefetch_init(hw, rxq, sky2->rx_le_map, RX_LE_SIZE - 1);
rx_set_checksum(sky2);
@@ -1035,9 +1066,10 @@ static int sky2_up(struct net_device *de
RB_RST_SET);
sky2_qset(hw, txqaddr[port]);
- if (hw->chip_id == CHIP_ID_YUKON_EC_U)
- sky2_write16(hw, Q_ADDR(txqaddr[port], Q_AL), 0x1a0);
+ /* Set almost empty threshold */
+ if (hw->chip_id == CHIP_ID_YUKON_EC_U && hw->chip_rev == 1)
+ sky2_write16(hw, Q_ADDR(txqaddr[port], Q_AL), 0x1a0);
sky2_prefetch_init(hw, txqaddr[port], sky2->tx_le_map,
TX_RING_SIZE - 1);
@@ -1047,8 +1079,10 @@ static int sky2_up(struct net_device *de
goto err_out;
/* Enable interrupts from phy/mac for port */
+ spin_lock_irq(&hw->hw_lock);
hw->intr_mask |= (port == 0) ? Y2_IS_PORT_1 : Y2_IS_PORT_2;
sky2_write32(hw, B0_IMSK, hw->intr_mask);
+ spin_unlock_irq(&hw->hw_lock);
return 0;
err_out:
@@ -1348,10 +1382,10 @@ static int sky2_down(struct net_device *
netif_stop_queue(dev);
/* Disable port IRQ */
- local_irq_disable();
+ spin_lock_irq(&hw->hw_lock);
hw->intr_mask &= ~((sky2->port == 0) ? Y2_IS_IRQ_PHY1 : Y2_IS_IRQ_PHY2);
sky2_write32(hw, B0_IMSK, hw->intr_mask);
- local_irq_enable();
+ spin_unlock_irq(&hw->hw_lock);
flush_scheduled_work();
@@ -1633,10 +1667,10 @@ static void sky2_phy_task(void *arg)
out:
up(&sky2->phy_sema);
- local_irq_disable();
+ spin_lock_irq(&hw->hw_lock);
hw->intr_mask |= (sky2->port == 0) ? Y2_IS_IRQ_PHY1 : Y2_IS_IRQ_PHY2;
sky2_write32(hw, B0_IMSK, hw->intr_mask);
- local_irq_enable();
+ spin_unlock_irq(&hw->hw_lock);
}
@@ -1863,6 +1897,17 @@ static int sky2_poll(struct net_device *
sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
+ /*
+ * Kick the STAT_LEV_TIMER_CTRL timer.
+ * This fixes my hangs on Yukon-EC (0xb6) rev 1.
+ * The if clause is there to start the timer only if it has been
+ * configured correctly and not been disabled via ethtool.
+ */
+ if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
+ sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
+ sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
+ }
+
hwidx = sky2_read16(hw, STAT_PUT_IDX);
BUG_ON(hwidx >= STATUS_RING_SIZE);
rmb();
@@ -1945,16 +1990,19 @@ exit_loop:
sky2_tx_check(hw, 0, tx_done[0]);
sky2_tx_check(hw, 1, tx_done[1]);
+ if (sky2_read8(hw, STAT_TX_TIMER_CTRL) == TIM_START) {
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
+ }
+
if (likely(work_done < to_do)) {
- /* need to restart TX timer */
- if (is_ec_a1(hw)) {
- sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
- sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
- }
+ spin_lock_irq(&hw->hw_lock);
+ __netif_rx_complete(dev0);
- netif_rx_complete(dev0);
hw->intr_mask |= Y2_IS_STAT_BMU;
sky2_write32(hw, B0_IMSK, hw->intr_mask);
+ spin_unlock_irq(&hw->hw_lock);
+
return 0;
} else {
*budget -= work_done;
@@ -2017,13 +2065,13 @@ static void sky2_hw_intr(struct sky2_hw
if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
- pci_read_config_word(hw->pdev, PCI_STATUS, &pci_err);
+ pci_err = sky2_pci_read16(hw, PCI_STATUS);
if (net_ratelimit())
printk(KERN_ERR PFX "%s: pci hw error (0x%x)\n",
pci_name(hw->pdev), pci_err);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- pci_write_config_word(hw->pdev, PCI_STATUS,
+ sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
@@ -2032,7 +2080,7 @@ static void sky2_hw_intr(struct sky2_hw
/* PCI-Express uncorrectable Error occurred */
u32 pex_err;
- pci_read_config_dword(hw->pdev, PEX_UNC_ERR_STAT, &pex_err);
+ pex_err = sky2_pci_read32(hw, PEX_UNC_ERR_STAT);
if (net_ratelimit())
printk(KERN_ERR PFX "%s: pci express error (0x%x)\n",
@@ -2040,7 +2088,7 @@ static void sky2_hw_intr(struct sky2_hw
/* clear the interrupt */
sky2_write32(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- pci_write_config_dword(hw->pdev, PEX_UNC_ERR_STAT,
+ sky2_pci_write32(hw, PEX_UNC_ERR_STAT,
0xffffffffUL);
sky2_write32(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
@@ -2086,6 +2134,7 @@ static void sky2_phy_intr(struct sky2_hw
hw->intr_mask &= ~(port == 0 ? Y2_IS_IRQ_PHY1 : Y2_IS_IRQ_PHY2);
sky2_write32(hw, B0_IMSK, hw->intr_mask);
+
schedule_work(&sky2->phy_task);
}
@@ -2099,6 +2148,7 @@ static irqreturn_t sky2_intr(int irq, vo
if (status == 0 || status == ~0)
return IRQ_NONE;
+ spin_lock(&hw->hw_lock);
if (status & Y2_IS_HW_ERR)
sky2_hw_intr(hw);
@@ -2127,7 +2177,7 @@ static irqreturn_t sky2_intr(int irq, vo
sky2_write32(hw, B0_Y2_SP_ICR, 2);
- sky2_read32(hw, B0_IMSK);
+ spin_unlock(&hw->hw_lock);
return IRQ_HANDLED;
}
@@ -2170,7 +2220,7 @@ static int sky2_reset(struct sky2_hw *hw
{
u16 status;
u8 t8, pmd_type;
- int i, err;
+ int i;
sky2_write8(hw, B0_CTST, CS_RST_CLR);
@@ -2192,25 +2242,18 @@ static int sky2_reset(struct sky2_hw *hw
sky2_write8(hw, B0_CTST, CS_RST_CLR);
/* clear PCI errors, if any */
- err = pci_read_config_word(hw->pdev, PCI_STATUS, &status);
- if (err)
- goto pci_err;
+ status = sky2_pci_read16(hw, PCI_STATUS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- err = pci_write_config_word(hw->pdev, PCI_STATUS,
- status | PCI_STATUS_ERROR_BITS);
- if (err)
- goto pci_err;
+ sky2_pci_write16(hw, PCI_STATUS, status | PCI_STATUS_ERROR_BITS);
+
sky2_write8(hw, B0_CTST, CS_MRST_CLR);
/* clear any PEX errors */
- if (pci_find_capability(hw->pdev, PCI_CAP_ID_EXP)) {
- err = pci_write_config_dword(hw->pdev, PEX_UNC_ERR_STAT,
- 0xffffffffUL);
- if (err)
- goto pci_err;
- }
+ if (pci_find_capability(hw->pdev, PCI_CAP_ID_EXP))
+ sky2_pci_write32(hw, PEX_UNC_ERR_STAT, 0xffffffffUL);
+
pmd_type = sky2_read8(hw, B2_PMD_TYP);
hw->copper = !(pmd_type == 'L' || pmd_type == 'S');
@@ -2309,8 +2352,7 @@ static int sky2_reset(struct sky2_hw *hw
sky2_write8(hw, STAT_FIFO_ISR_WM, 16);
sky2_write32(hw, STAT_TX_TIMER_INI, sky2_us2clk(hw, 1000));
- sky2_write32(hw, STAT_LEV_TIMER_INI, sky2_us2clk(hw, 100));
- sky2_write32(hw, STAT_ISR_TIMER_INI, sky2_us2clk(hw, 20));
+ sky2_write32(hw, STAT_ISR_TIMER_INI, sky2_us2clk(hw, 7));
}
/* enable status unit */
@@ -2321,14 +2363,6 @@ static int sky2_reset(struct sky2_hw *hw
sky2_write8(hw, STAT_ISR_TIMER_CTRL, TIM_START);
return 0;
-
-pci_err:
- /* This is to catch a BIOS bug workaround where
- * mmconfig table doesn't have other buses.
- */
- printk(KERN_ERR PFX "%s: can't access PCI config space\n",
- pci_name(hw->pdev));
- return err;
}
static u32 sky2_supported_modes(const struct sky2_hw *hw)
@@ -2852,11 +2886,11 @@ static int sky2_set_coalesce(struct net_
(ecmd->rx_coalesce_usecs_irq < tmin || ecmd->rx_coalesce_usecs_irq > tmax))
return -EINVAL;
- if (ecmd->tx_max_coalesced_frames > 0xffff)
+ if (ecmd->tx_max_coalesced_frames >= TX_RING_SIZE-1)
return -EINVAL;
- if (ecmd->rx_max_coalesced_frames > 0xff)
+ if (ecmd->rx_max_coalesced_frames > RX_MAX_PENDING)
return -EINVAL;
- if (ecmd->rx_max_coalesced_frames_irq > 0xff)
+ if (ecmd->rx_max_coalesced_frames_irq >RX_MAX_PENDING)
return -EINVAL;
if (ecmd->tx_coalesce_usecs == 0)
@@ -3198,17 +3232,6 @@ static int __devinit sky2_probe(struct p
}
}
-#ifdef __BIG_ENDIAN
- /* byte swap descriptors in hardware */
- {
- u32 reg;
-
- pci_read_config_dword(pdev, PCI_DEV_REG2, ®);
- reg |= PCI_REV_DESC;
- pci_write_config_dword(pdev, PCI_DEV_REG2, reg);
- }
-#endif
-
err = -ENOMEM;
hw = kzalloc(sizeof(*hw), GFP_KERNEL);
if (!hw) {
@@ -3226,6 +3249,18 @@ static int __devinit sky2_probe(struct p
goto err_out_free_hw;
}
hw->pm_cap = pm_cap;
+ spin_lock_init(&hw->hw_lock);
+
+#ifdef __BIG_ENDIAN
+ /* byte swap descriptors in hardware */
+ {
+ u32 reg;
+
+ reg = sky2_pci_read32(hw, PCI_DEV_REG2);
+ reg |= PCI_REV_DESC;
+ sky2_pci_write32(hw, PCI_DEV_REG2, reg);
+ }
+#endif
/* ring for status responses */
hw->st_le = pci_alloc_consistent(hw->pdev, STATUS_LE_BYTES,
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index fd12c28..3edb980 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -5,14 +5,22 @@
#define _SKY2_H
/* PCI config registers */
-#define PCI_DEV_REG1 0x40
-#define PCI_DEV_REG2 0x44
-#define PCI_DEV_STATUS 0x7c
-#define PCI_OS_PCI_X (1<<26)
-
-#define PEX_LNK_STAT 0xf2
-#define PEX_UNC_ERR_STAT 0x104
-#define PEX_DEV_CTRL 0xe8
+enum {
+ PCI_DEV_REG1 = 0x40,
+ PCI_DEV_REG2 = 0x44,
+ PCI_DEV_STATUS = 0x7c,
+ PCI_DEV_REG3 = 0x80,
+ PCI_DEV_REG4 = 0x84,
+ PCI_DEV_REG5 = 0x88,
+};
+
+enum {
+ PEX_DEV_CAP = 0xe4,
+ PEX_DEV_CTRL = 0xe8,
+ PEX_DEV_STA = 0xea,
+ PEX_LNK_STAT = 0xf2,
+ PEX_UNC_ERR_STAT= 0x104,
+};
/* Yukon-2 */
enum pci_dev_reg_1 {
@@ -37,6 +45,25 @@ enum pci_dev_reg_2 {
PCI_USEDATA64 = 1<<0, /* Use 64Bit Data bus ext */
};
+/* PCI_OUR_REG_4 32 bit Our Register 4 (Yukon-ECU only) */
+enum pci_dev_reg_4 {
+ /* (Link Training & Status State Machine) */
+ P_TIMER_VALUE_MSK = 0xffL<<16, /* Bit 23..16: Timer Value Mask */
+ /* (Active State Power Management) */
+ P_FORCE_ASPM_REQUEST = 1<<15, /* Force ASPM Request (A1 only) */
+ P_ASPM_GPHY_LINK_DOWN = 1<<14, /* GPHY Link Down (A1 only) */
+ P_ASPM_INT_FIFO_EMPTY = 1<<13, /* Internal FIFO Empty (A1 only) */
+ P_ASPM_CLKRUN_REQUEST = 1<<12, /* CLKRUN Request (A1 only) */
+
+ P_ASPM_FORCE_CLKREQ_ENA = 1<<4, /* Force CLKREQ Enable (A1b only) */
+ P_ASPM_CLKREQ_PAD_CTL = 1<<3, /* CLKREQ PAD Control (A1 only) */
+ P_ASPM_A1_MODE_SELECT = 1<<2, /* A1 Mode Select (A1 only) */
+ P_CLK_GATE_PEX_UNIT_ENA = 1<<1, /* Enable Gate PEX Unit Clock */
+ P_CLK_GATE_ROOT_COR_ENA = 1<<0, /* Enable Gate Root Core Clock */
+ P_ASPM_CONTROL_MSK = P_FORCE_ASPM_REQUEST | P_ASPM_GPHY_LINK_DOWN
+ | P_ASPM_CLKRUN_REQUEST | P_ASPM_INT_FIFO_EMPTY,
+};
+
#define PCI_STATUS_ERROR_BITS (PCI_STATUS_DETECTED_PARITY | \
PCI_STATUS_SIG_SYSTEM_ERROR | \
@@ -507,6 +534,16 @@ enum {
};
#define Q_ADDR(reg, offs) (B8_Q_REGS + (reg) + (offs))
+/* Q_F 32 bit Flag Register */
+enum {
+ F_ALM_FULL = 1<<27, /* Rx FIFO: almost full */
+ F_EMPTY = 1<<27, /* Tx FIFO: empty flag */
+ F_FIFO_EOF = 1<<26, /* Tag (EOF Flag) bit in FIFO */
+ F_WM_REACHED = 1<<25, /* Watermark reached */
+ F_M_RX_RAM_DIS = 1<<24, /* MAC Rx RAM Read Port disable */
+ F_FIFO_LEVEL = 0x1fL<<16, /* Bit 23..16: # of Qwords in FIFO */
+ F_WATER_MARK = 0x0007ffL, /* Bit 10.. 0: Watermark */
+};
/* Queue Prefetch Unit Offsets, use Y2_QADDR() to address (Yukon-2 only)*/
enum {
@@ -909,10 +946,12 @@ enum {
PHY_BCOM_ID1_C0 = 0x6044,
PHY_BCOM_ID1_C5 = 0x6047,
- PHY_MARV_ID1_B0 = 0x0C23, /* Yukon (PHY 88E1011) */
+ PHY_MARV_ID1_B0 = 0x0C23, /* Yukon (PHY 88E1011) */
PHY_MARV_ID1_B2 = 0x0C25, /* Yukon-Plus (PHY 88E1011) */
- PHY_MARV_ID1_C2 = 0x0CC2, /* Yukon-EC (PHY 88E1111) */
- PHY_MARV_ID1_Y2 = 0x0C91, /* Yukon-2 (PHY 88E1112) */
+ PHY_MARV_ID1_C2 = 0x0CC2, /* Yukon-EC (PHY 88E1111) */
+ PHY_MARV_ID1_Y2 = 0x0C91, /* Yukon-2 (PHY 88E1112) */
+ PHY_MARV_ID1_FE = 0x0C83, /* Yukon-FE (PHY 88E3082 Rev.A1) */
+ PHY_MARV_ID1_ECU= 0x0CB0, /* Yukon-ECU (PHY 88E1149 Rev.B2?) */
};
/* Advertisement register bits */
@@ -1837,8 +1876,9 @@ struct sky2_port {
struct sky2_hw {
void __iomem *regs;
struct pci_dev *pdev;
- u32 intr_mask;
struct net_device *dev[2];
+ spinlock_t hw_lock;
+ u32 intr_mask;
int pm_cap;
int msi;
@@ -1912,4 +1952,25 @@ static inline void gma_set_addr(struct s
gma_write16(hw, port, reg+4,(u16) addr[2] | ((u16) addr[3] << 8));
gma_write16(hw, port, reg+8,(u16) addr[4] | ((u16) addr[5] << 8));
}
+
+/* PCI config space access */
+static inline u32 sky2_pci_read32(const struct sky2_hw *hw, unsigned reg)
+{
+ return sky2_read32(hw, Y2_CFG_SPC + reg);
+}
+
+static inline u16 sky2_pci_read16(const struct sky2_hw *hw, unsigned reg)
+{
+ return sky2_read16(hw, Y2_CFG_SPC + reg);
+}
+
+static inline void sky2_pci_write32(struct sky2_hw *hw, unsigned reg, u32 val)
+{
+ sky2_write32(hw, Y2_CFG_SPC + reg, val);
+}
+
+static inline void sky2_pci_write16(struct sky2_hw *hw, unsigned reg, u16 val)
+{
+ sky2_write16(hw, Y2_CFG_SPC + reg, val);
+}
#endif
diff --git a/drivers/net/tlan.c b/drivers/net/tlan.c
index c2506b5..12076f8 100644
--- a/drivers/net/tlan.c
+++ b/drivers/net/tlan.c
@@ -536,6 +536,7 @@ static int __devinit TLan_probe1(struct
u16 device_id;
int reg, rc = -ENODEV;
+#ifdef CONFIG_PCI
if (pdev) {
rc = pci_enable_device(pdev);
if (rc)
@@ -547,6 +548,7 @@ static int __devinit TLan_probe1(struct
goto err_out;
}
}
+#endif /* CONFIG_PCI */
dev = alloc_etherdev(sizeof(TLanPrivateInfo));
if (dev == NULL) {
^ permalink raw reply related
* Re: [PATCH] iproute2 -- add fwmarkmask
From: Patrick McHardy @ 2006-02-24 4:59 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, netfilter-devel, shemminger
In-Reply-To: <18992.1140723572@sandelman.ottawa.on.ca>
Michael Richardson wrote:
>
>
>>>>>>>"Patrick" == Patrick McHardy <kaber@trash.net> writes:
>
> Patrick> The normal way to display masks is with a "/". Also I think
> Patrick> it shouldn't display the default mask to avoid breaking
> Patrick> scripts that parse the output.
>
> I generally dislike the /VALUE, since I expect /PREFIX-LEN.
> I agree that it shouldn't show if it is default.
>
> Patrick> ip should be able to parse its own output, and it would
> Patrick> also look nicer if I could just say "fwmark
> Patrick> 0x1/32". fwmarkmask is really an incredible ugly expression
> Patrick> :)
>
> Sure. Is that a 32-bit long mask (0xfffffff), or is it a 0x00000020?
> fwmark is not an address.
>
> Or would you like /32 to be a prefix-based mask, and &value and/or
> fwmarkmask to be a value?
That was not the greatest example :) I think it should be a bitmask.
^ 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