On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote:
Sure -- we can have on the ieee80211_conf struct an array of all
regulatory domains stack values that the device supports
(REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees
the device has been certified to match the
On Tue, 2006-10-24 at 17:10, Johannes Berg wrote:
On Tue, 2006-10-24 at 16:38 +0800, Hong Liu wrote:
The first time when we set the TKIP key, we can set the phase1 key if
the driver requires.
Right.
The problem is when IV16 wraps, who will generate the new phase1 key?
Ok, I was
When using H-TCP with a single flow on a 500Mbit connection (or less
actually), alpha can exceed 65000, so alpha needs to be a u32.
Signed-off-by: Gavin McCullagh [EMAIL PROTECTED]
Signed-off-by: Doug Leith [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp_htcp.c b/net/ipv4/tcp_htcp.c
index
On Wed, 2006-10-25 at 16:28 +0800, Hong Liu wrote:
I'd prefer to let the stack tell the driver when there is new phase1 key
generated.
Fine too, I guess.
+ u8 tkip_keylen;
What do you need that for? The driver should know whether it requested a
phase 1 or phase 2 key.
+ u8
Hi,
s2io_card_down() will do few BAR0 read/write. As per
pci-error-recovery.txt Documentation we are not supposed to do any new
IO in error_detected().
Can you try using
atomic_set(sp-card_state, CARD_DOWN);
instead of s2io_card_down().
Also we have to add following if statement in
Hi,
I am reading the 802.11i IBSS spec and
trying to find if it is OK to add patches to d80211 to support this feature.
For 802.11i IBSS to work, each STA assumes two roles: supplicant +
authenticator.
Usually in BSS network, authenticator is in AP.
The problem is the distribution of group keys.
On Wednesday 25 October 2006 00:39, Johannes Berg wrote:
resulted in this:
[10261.556773] BUG: sleeping function called from invalid context at
kernel/mutex.c:86
Yeah, there are a few bugs of this type left and I know most of them. ;)
The stack should never call atomically into the driver.
On Wednesday 25 October 2006 02:37, John W. Linville wrote:
Michael,
It looks like you have a patch that I don't have, one that moves the
netif_tx_disable and spin_lock_irqsave outside of the if (badness
BADNESS_LIMIT) conditional.
Could you pass that one along as well, or correct this
This patch fixes kzalloc parameters (GFP_ATOMIC instead of GFP_KERNEL)
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index eb7d44d..4538c99 100644
--- a/drivers/net/ehea/ehea_main.c
+++
This patch fixes the 64K page support
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_phyp.h | 14 +-
drivers/net/ehea/ehea_qmr.c | 13 +++--
3 files changed, 21 insertions(+), 8 deletions(-)
diff
* Ben Greear | 2006-10-23 17:44:24 [-0700]:
Since IOCTLs are out of favor these days, what would be
a preferred way to get a block of binary data out of the
kernel?
I suggest netlink socket for that purpose! Netlink scales also well if the
amount of data surprisedly rise.
Thanks,
Ben
HGN
-
To
On 10/25/06, Michael Chan [EMAIL PROTECTED] wrote:
...
Can you cat /proc/interrupts a few times to see if the interrupt
counts on eth1 and eth2 are increasing?
# grep eth /proc/interrupts
9: 0 0 0 0IO-APIC-edge eth2
16: 177724 0 371238
On Wednesday 25 October 2006 10:54, Hong Liu wrote:
2. wpa_supplicant: this is the big part, we need to implement the
authenticator
in it. Not sure how much efforts needed?
Well, I think that should go together with a merge of wpa_supplicant
with hostapd (which I think is desired anyway).
The following patch reworks the myri10ge driver to use physical pages for skb
allocation. A similar patch has been submitted about a month ago within our LRO
patches. The LRO code won't be sent here since we are waiting for the core
stack to implement a generic LRO.
Please consider this single
Physical pages are used instead of 16kB contiguous buffers for the
skb frags. And we also put as much fragments as possible in any page
so that we do not have to allocate a page for every fragments.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
Signed-off-by: Andrew J. Gallatin [EMAIL PROTECTED]
On 10/25/06, David Miller [EMAIL PROTECTED] wrote:
It's an interrupt routing problem for sure, Adrian Bunk
posted a potential fix to this poster an hour or so
ago.
I'm running with arch=i386 and the only related postings I see are for
x86_64 :-(.
-
To unsubscribe from this list: send the line
Hi,
This problem originally occurred in a very large cluster system using snmp
for server management. About two servers panicked each day. The program I
sent
is to reproduce this problem in a very short time. It does occur under normal
load when there is a lot of servers.
hmm, not good -
On 10/24/06, Johannes Berg [EMAIL PROTECTED] wrote:
On Tue, 2006-10-24 at 11:59 -0400, Luis R. Rodriguez wrote:
also if we index based on alpha3 we get O(1)
access to the elements. Will make these changes.
I wouldn't do that, it's bound to make the array size explode because
there'll be one
On 10/24/06, Anand Kumria [EMAIL PROTECTED] wrote:
On Mon, 23 Oct 2006 18:45:23 -0400, Luis R. Rodriguez wrote:
iso3166-1
ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names
of countries and dependent areas. It was first published in 1974 by
the International
On Wed, Oct 25, 2006 at 02:29:33AM -0400, Ananda Raju wrote:
Hi,
s2io_card_down() will do few BAR0 read/write. As per
pci-error-recovery.txt Documentation we are not supposed to do any new
IO in error_detected().
Hmm, actually, its harmless to do further i/o. The s2io driver barks
(as it
On 10/24/06, Anand Kumria [EMAIL PROTECTED] wrote:
On Mon, 23 Oct 2006 18:47:25 -0400, Luis R. Rodriguez wrote:
ieee80211_regdomains
Breaks down regulatory domains into data structures which allow
drivers to share channel and power contraints based on stack
regulatory domain. This driver
On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote:
I am reading the 802.11i IBSS spec and
trying to find if it is OK to add patches to d80211 to support this feature.
Large parts of this will be outside d80211, but yes, I think d80211
should be made ready to support this (mainly in the
Hi Stephen,
currently the work to make the container enablement into the kernel is
doing good progress. The ipc, pid, utsname and filesystem system
ressources are isolated/virtualized relying on the namespaces concept.
But, there is missing the network virtualization/isolation. Two
Hello,
the build with the attached .config failed, make ends with:
...
LD arch/i386/boot/compressed/vmlinux
OBJCOPY arch/i386/boot/vmlinux.bin
HOSTCC arch/i386/boot/tools/build
BUILD arch/i386/boot/bzImage
Root device is (3, 8)
Boot sector 512 bytes.
Setup is 4714 bytes.
System
On Wed, 25 Oct 2006 17:51:28 +0200
Daniel Lezcano [EMAIL PROTECTED] wrote:
Hi Stephen,
currently the work to make the container enablement into the kernel is
doing good progress. The ipc, pid, utsname and filesystem system
ressources are isolated/virtualized relying on the namespaces
On 10/25/06, Jiri Benc [EMAIL PROTECTED] wrote:
On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote:
Sure -- we can have on the ieee80211_conf struct an array of all
regulatory domains stack values that the device supports
(REGDOMAIN_FCC or 0x10 for FCC for example) if the developer
Jeff Garzik wrote:
On Tue, Oct 24, 2006 at 09:35:49PM -0700, Randy Dunlap wrote:
Please grep for sysfs_create_bin_file, you will find plenty of examples.
Hm, I thought that sysfs binary files were supposed to be
for transparent blobs of data, not for structured data.
E.g., a firmware
On Wed, 2006-10-25 at 09:02 -0400, Richard Bollinger wrote:
# ethtool -t eth2
The test result is FAIL
The test extra info:
nvram test (online) 0
link test (online) 1
register test (offline) 0
memory test(offline) 0
loopback test (offline)
Shouldn't the e100 driver wait for PHY reset to complete before
proceeding in e100_set_settings()?
I'm asking because the interface (82551) sometimes ends up in loopback
when I try to set AUTONEG.
I'm thinking something like this patch.
Anders
--- linux-2.6.18.orig/drivers/net/e100.c
On 10/24/06, Michael Wu [EMAIL PROTECTED] wrote:
On Tuesday 24 October 2006 18:03, Luis R. Rodriguez wrote:
1. Anyone working on completing FullMAC support on d80211?
That doesn't really make sense. Fullmac devices should just use WE or cfg80211
because they, for the most part, do what d80211
tmp is unused.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3843,7 +3843,7 @@ void
Hi,
+#ifdef CONFIG_PPC_64K_PAGES
+ /* To support 64k pages we must round to 64k page boundary */
+ epas-kernel.addr =
+ ioremap((paddr_kernel 0x), PAGE_SIZE) +
+ (paddr_kernel 0x);
+#else
epas-kernel.addr = ioremap(paddr_kernel,
All three one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_KEY_* definitions. The 8 bit
keyidx bitfield is converted to type s8.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
Continue d80211 bitfield removal. In general, compilers have
difficulty generating efficient code for bitfields. This patchset
removes all bitfields from include/net/d80211.h.
I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags
structure member. Larger bitfields I converted
All one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TXCTL_* definitions. The
multiple bit members were converted to u8, s8 or u16 as appropriate.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
All four one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_CONF_* definitions.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
---
All twelve one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_HW_* definitions.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
Both one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TX_STATUS_* definitions.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
---
On Wed, Oct 25, 2006 at 11:42:44AM -0700, David Kimdon wrote:
Continue d80211 bitfield removal. In general, compilers have
difficulty generating efficient code for bitfields. This patchset
removes all bitfields from include/net/d80211.h.
I converted the 1 bit bitfields into a bit in a
Anders Grafstrom [EMAIL PROTECTED] :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of iterations
- put the break on a line of its own
- add a
On Wed, Oct 25, 2006 at 03:01:29PM -0400, Jeff Garzik wrote:
On Wed, Oct 25, 2006 at 11:42:44AM -0700, David Kimdon wrote:
Continue d80211 bitfield removal. In general, compilers have
difficulty generating efficient code for bitfields. This patchset
removes all bitfields from
On Wed, Oct 25, 2006 at 12:17:02PM -0700, David Kimdon wrote:
That is how I originally had the patch, but then had a question about
increasing structure size so I dropped flags to u16 or u8 for
structures that were made larger by the bitfield removal.
On non-x86 platforms, u16 and u8 generate
On 10/25/06, Michael Chan [EMAIL PROTECTED] wrote:
This confirms that it's some kind of interrupt problem as David had
suggested, at least on eth2. You can try booting with noapic to see
if it works if you haven't got the patch from Adrian Bunk yet.
No joy. Here's the dmesg after boot w/
One area that needs work is the 802.11 qdisc - there is no provision in
the current implementation for queueing certain frames because the
802.11 link is not ready to traqnsmit them yet, while letting other
frames through.
E.G. for normal client mode links it would be nice for the qdisc to
allow
Francois Romieu wrote:
Anders Grafstrom [EMAIL PROTECTED] :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of iterations
- put the break on a line of
Auke Kok wrote:
Francois Romieu wrote:
Anders Grafstrom [EMAIL PROTECTED] :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of
iterations
- put the
On Wed, 2006-10-25 at 08:48 -0700, Jouni Malinen wrote:
1. for the d80211 part: I don't think there will be much efforts.
We may add a group key to each sta_info for decrypting multicast data
from that STA.
And in RX path, we need to add code to select the correct group key for
On Wed, Oct 25, 2006 at 10:11:24AM -0500, Linas Vepstas wrote:
Also we have to add following if statement in beginning of s2io_isr().
Done, below,
If it is ok to do BAR0 read/write in error_detected() then patch is OK.
I re-wrote that section to avoid doing I/O. It seems to work well,
On Wed, 2006-10-25 at 13:43 -0400, Luis R. Rodriguez wrote:
I guess my hope was that d80211 would just be more than a softmac
implementation. When I hear wireless stack I don't think softmac
implementation, I think a robust set of headers and device
definitions which all wireless devices can
Auke Kok [EMAIL PROTECTED] :
[...]
okay, I don't think this is needed at all:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with some debugging output on a few boxes and did some speed/duplex
settings, and the PHY reset returned succesfull after the very
I ran some congestion window tests against 2.6.19-rc3.
For congestion window graphs see:
http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/
The connection was a single flow with a 500ms RTT and a
100Mbit slowest link speed.
BIC OK
CUBIC OK (after
If user asks for a congestion control type with setsockopt() then it
may be available as a module not included in the kernel already.
It should be autoloaded if needed. This is done already when
the default selection is change with sysctl, but not when application
requests via sysctl.
Only
Not sure why the slow start for cubic is slower than the others.
We will check on this.
- Original Message -
From: Stephen Hemminger [EMAIL PROTECTED]
To: Douglas Leith [EMAIL PROTECTED]; Sangtae Ha [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Sent: Wednesday, October 25, 2006 2:02 PM
The purpose of this patch is to fix the compile-time warnings usch as:
warning: 'crypto_cipher_encrypt' is deprecated (declared at
include/linux/crypto.h:842)
I have tested static WEP and it still works after this change.
AECS/CCM and TKIP I am assuming work as well.
I don't actually know the
Doug Leith observed a discrepancy between the version of CUBIC described
in the papers and the version in 2.6.18. A math error related to scaling
causes Cubic to grow too slowly.
Patch is from Sangtae Ha [EMAIL PROTECTED]. I validated that
it does fix the problems.
See the following to show
Stephen Hemminger wrote:
If user asks for a congestion control type with setsockopt() then it
may be available as a module not included in the kernel already.
It should be autoloaded if needed. This is done already when
the default selection is change with sysctl, but not when application
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any msleep(10)
is executed.
On Wed, Oct 25, 2006 at 03:41:50PM -0700, David Kimdon wrote:
I don't actually know the implications of that first hunk where we do
arc4 - ecb(arc4). I look though the various commits by Herbert
Xu and that appeared to be the right thing.
Basically if you encrypt/decrypt more than a block
From: Randy Dunlap [EMAIL PROTECTED]
USB network drivers that use mii_*() interfaces should
cause those interfaces to be built. Or depend on them,
but this is what all drivers/net/ drivers do.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/usb/net/Kconfig |3 +++
1 file changed,
@@ -94,6 +95,7 @@ config USB_RTL8150
config USB_USBNET
tristate Multi-purpose USB Networking Framework
+ select MII
---help---
This driver supports several kinds of network links over USB,
with minidrivers built around a common network driver core
The
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
Instead, usbnet.c should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit to
use usbnet with peripherals that don't need MII.
---
From: Randy Dunlap [EMAIL PROTECTED]
usbnet driver should use
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
The other parts are right, this isn't.
Instead, usbnet.c should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit to
use usbnet with peripherals that don't need MII.
Ugh. OK. How's this? (2
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any
Patrick McHardy wrote:
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
-#define
On Wed, 25 Oct 2006 18:34:17 -0400
Injong Rhee [EMAIL PROTECTED] wrote:
Not sure why the slow start for cubic is slower than the others.
We will check on this.
I think it is because cubic initializes with a ssthresh of 100,
and others leave ssthresh uninitialized until the first loss.
This
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Simon Barber wrote:
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
It wouldn't really hurt though since all frames queued
Simon Barber wrote:
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
This patch should be enough to use it without NET_SCHED.
On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote:
Considering that it is possibly and may be desirable to attach a
different qdisc than the built-in multiband qdisc, it might also
make sense to split the 80211 specific classification in a seperate
classifier module to allow
On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote:
On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote:
I am reading the 802.11i IBSS spec and
trying to find if it is OK to add patches to d80211 to support this feature.
Large parts of this will be outside d80211, but yes, I think
The Wi-Fi alliance's test plans for their WMM specification are written
assuming you use certain specific DSCP values. Since WMM is the only QoS
mechanism that is widely used with 802.11 I followed the WMM values in
the default 802.11 qdisc implementation. Most windows 802.11 drivers do
the same
On Mon, 2006-10-23 at 10:09, Zang Roy-r61911 wrote:
On Thu, 2006-09-21 at 12:46, Jeff Garzik wrote:
you should have a chip structure, that contains two structs (one for
each interface/port)
Jeff,
I updated the code according to all your feedback and post it here
It's not possible to 'negotiate keys at the beginning' - since there is
no indication of a new station joining an IBSS. The first you ever know
about a station joining an IBSS is when you receive a frame from that
station.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Doing this will slow down the qdisc - it does already run an external
classifier first if you install one. On typical laptops performance is
not a problem, but one common usage does have problems. The performance
of a wireless home gateway based on a simple linux kernel configuration
(NAT,
On Wed, Oct 25, 2006 at 11:38:38AM +0200, Michael Buesch wrote:
On Wednesday 25 October 2006 02:37, John W. Linville wrote:
Michael,
It looks like you have a patch that I don't have, one that moves the
netif_tx_disable and spin_lock_irqsave outside of the if (badness
BADNESS_LIMIT)
The e100 fix finally fixes the netconsole problems.
The e1000 fixes look pretty safe, but don't have hardware at the
moment to test. A non-Intel list member verified the e1000 stuff at
least works for him.
Please pull from 'upstream-linus' branch of
From: Dominik Brodowski [EMAIL PROTECTED]
Date: Sun, 2 Jul 2006 21:21:51 +0200
Subject: [PATCH] pcmcia: add more IDs to hostap_cs.c
As a replacement for the broad manufactor/card ID match we commented out
because of conflicts with pcnet_cs, add two product ID matches.
Signed-off-by: Dominik
Hi,
The following eleven patches have all been queued in -mm for quite some
time; the only change is that one suggestion by Pavel Roskin (to remove the
RevA part of the new ID for hostap_cs.c) is implemented. Please let me
know if there are any objections to any of these patches; if not, I'll
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
The other parts are right, this isn't.
Instead, usbnet.c should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit to
use usbnet
On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote:
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
Instead, usbnet.c should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit to
use usbnet with peripherals that don't need MII.
I had
On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote:
Doing this will slow down the qdisc - it does already run an external
classifier first if you install one. On typical laptops performance is
not a problem, but one common usage does have problems. The performance
of a wireless home
Re: registering as a real protocol - yes this I have been going on about
for a while. This needs a few changes in how things work:
1. Register as a real protocol.
2. Change drivers to use netif_rx to receive frames (will also be more
efficient)
I would also like to see:
Drivers to use
On Wed, Oct 25, 2006 at 11:08:43AM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
If user asks for a congestion control type with setsockopt() then it
may be available as a module not included in the kernel already.
It should be autoloaded if needed. This is done already when
the
David Brownell wrote:
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
The other parts are right, this isn't.
Instead, usbnet.c should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit
On Wednesday 25 October 2006 10:05 pm, Randy.Dunlap wrote:
... MII should still depend on ETHERNET, right?
Just not limited to 10/100 Ethernet.
There is no such config symbol. NET_ETHERNET means 10/100 ethernet.
Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use
this
86 matches
Mail list logo
