[PATCH] Update CREDITS and MAINTAINERS entries for Lennert Buytenhek
On Tue, Dec 26, 2006 at 10:56:30PM +, Russell King wrote: > > > >Small cleanup in the Cirrus Logic EP93xx ethernet driver: Check for NULL > > > >pointer before dereferencing it instead of after. Remove unreferenced > > > >variable. > > > > > > > >Signed-off-by: Yan Burman <[EMAIL PROTECTED]> > > > >Cc: Jeff Garzik <[EMAIL PROTECTED]> > > > >Cc: Russell King <[EMAIL PROTECTED]> > > > >Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > Why wasn't I CC'ed on this? > > Probably because akpm thinks it was something to do with me... may I > suggest it might help to have an entry in MAINTAINERS? You mean the file that still lists Bartlomiej as IDE maintainer? If people manage to miss the name and email address at the top of the very file being patched, I'm not sure whether anything else'll help, but fine, whatever. The patch below adds a MAINTAINERS entry for everything I would appreciate being CC'ed on, someone please apply it. --- From: Lennert Buytenhek <[EMAIL PROTECTED]> Update CREDITS and MAINTAINERS entries for Lennert Buytenhek Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]> Index: linux-2.6.20-rc2/CREDITS === --- linux-2.6.20-rc2.orig/CREDITS +++ linux-2.6.20-rc2/CREDITS @@ -516,9 +516,10 @@ S: Orlando, Florida S: USA N: Lennert Buytenhek -E: [EMAIL PROTECTED] -D: Rewrite of the ethernet bridging code -S: Ravenhorst 58B +E: [EMAIL PROTECTED] +D: Original (2.4) rewrite of the ethernet bridging code +D: Various ARM bits and pieces +S: Ravenhorst 58 S: 2317 AK Leiden S: The Netherlands Index: linux-2.6.20-rc2/MAINTAINERS === --- linux-2.6.20-rc2.orig/MAINTAINERS +++ linux-2.6.20-rc2/MAINTAINERS @@ -355,6 +355,24 @@ P: Ian Molton M: [EMAIL PROTECTED] S: Maintained +ARM/ADI ROADRUNNER MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/ADS SPHERE MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/AJECO 1ARM MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + ARM/ATMEL AT91RM9200 ARM ARCHITECTURE P: Andrew Victor M: [EMAIL PROTECTED] @@ -362,17 +380,89 @@ L: [EMAIL PROTECTED] W: http://maxim.org.za/at91_26.html S: Maintained +ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + ARM/CORGI MACHINE SUPPORT P: Richard Purdie M: [EMAIL PROTECTED] S: Maintained +ARM/GLOMATION GESBC9312SX MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + ARM/HP JORNADA 7XX MACHINE SUPPORT P: Kristoffer Ericson M: [EMAIL PROTECTED] W: www.jlime.com S: Maintained +ARM/INTEL IOP32X ARM ARCHITECTURE +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/INTEL IOP13XX ARM ARCHITECTURE +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/INTEL IQ81342EX MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/INTEL IXP2000 ARM ARCHITECTURE +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/INTEL IXDP2850 MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/INTEL IXP23XX ARM ARCHITECTURE +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/INTEL XSC3 (MANZANO) ARM CORE +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/IP FABRICS DOUBLE ESPRESSO MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + +ARM/LOGICPD PXA270 MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + ARM/TOSA MACHINE SUPPORT P: Dirk Opfer M: [EMAIL PROTECTED] @@ -391,6 +481,12 @@ L: [EMAIL PROTECTED] W: http://www.arm.linux.org.uk/ S: Maintained +ARM/RADISYS ENP2611 MACHINE SUPPORT +P: Lennert Buytenhek +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +S: Maintained + ARM/SHARK MACHINE SUPPORT P: Alexan
Re: Please pull 'upstream' branch of wireless-2.6
On Tue, Dec 26, 2006 at 04:39:38PM -0500, Jeff Garzik wrote: > John W. Linville wrote: > >The following changes since commit > >0c234ae655a45ac3ee53a25b2e56e9bb6c27d71d: > > Ulrich Kunitz (1): > >ieee80211softmac: Fix mutex_lock at exit of > >ieee80211_softmac_get_genie > > > >are found in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > > upstream > > > >Roy Marples (1): > > prism54: set carrier flags correctly > > Why is this not #upstream-fixes material? What's the impact? Just being cautious, really. I have no objection if you want to pull it as a fix. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20-rc1 00/10] TURBOchannel update to the driver model
> And last but not least, thanks to James Simmons for beginning this work a > while ago as his code was great to start with. Wow!! I thought the work was dropped along time ago. Thanks for bring it back. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 constants inside d80211_common.h
Thank you, i'll use directly IEEE80211_RATE_* ;-) Nick 2006/12/27, Michael Wu <[EMAIL PROTECTED]>: On Wednesday 27 December 2006 12:26, Nick Kossifidis wrote: > We need those definitions for setting up the rate tables in dadwifi, > phytypes are needed inside drivers, take a look here -> > http://madwifi.org/browser/branches/dadwifi-openhal/openhal/ar5xxx.h?rev=18 >67 > MODE_IEEE80211A/B/G and IEEE80211_RATE_* not enough? The definitions in d80211_common.h are used for communications with userspace, not drivers. If you are using the ieee80211_phytype_* in things that are passed to d80211, it is wrong. If you are not, you can switch to MODE_IEEE80211A/B/G and IEEE80211_RATE_*, though I think MODE_IEEE80211A/B/G should be all you need. > Even if it does get out, constants should be in capitals. > Sure. Submit a patch. :) -Michael Wu - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take24 0/6] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: > Why do we want to inject _ready_ event, when it is possible to mark > event as ready and wakeup thread parked in syscall? Going back to this old one: How do you want to mark an event ready if you don't want to introduce yet another layer of data structures? The event notification happens through entries in the ring buffer. Userlevel code should never add anything to the ring buffer directly, this would mean huge synchronization problems. Yes, one could add additional data structures accompanying the ring buffer which can specify userlevel-generated events. But this is a) clumsy and b) a pain to use when the same ring buffer is used in multiple threads (you'd have to have another shared memory segment). It's much cleaner if the userlevel code can get the kernel to inject a userlevel-generated event. This is the equivalent of userlevel code generating a signal with kill(). -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
[ANNOUNCE] 10GbE Xframe-II ASIC Programming Manual
The ASIC Programming Manual (aka Device Driver Guide) got updated to match current feature set of s2io driver, and posted at http://trac.neterion.com/cgi-bin/trac.cgi/wiki/TitleIndex?anonymous under "Documentation Download" (Xframe_II_OSDDG_2.1_LE.pdf). Some noteworthy updates include Chapter C Application notes on features like interrupt moderation and multi-queue receive traffic steering. Only little endian file is posted at present; if someone is interested in big endian flavor of the register map please e-mail to [EMAIL PROTECTED], and we will generate and post the BE pdf. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 constants inside d80211_common.h
On Wednesday 27 December 2006 12:26, Nick Kossifidis wrote: > We need those definitions for setting up the rate tables in dadwifi, > phytypes are needed inside drivers, take a look here -> > http://madwifi.org/browser/branches/dadwifi-openhal/openhal/ar5xxx.h?rev=18 >67 > MODE_IEEE80211A/B/G and IEEE80211_RATE_* not enough? The definitions in d80211_common.h are used for communications with userspace, not drivers. If you are using the ieee80211_phytype_* in things that are passed to d80211, it is wrong. If you are not, you can switch to MODE_IEEE80211A/B/G and IEEE80211_RATE_*, though I think MODE_IEEE80211A/B/G should be all you need. > Even if it does get out, constants should be in capitals. > Sure. Submit a patch. :) -Michael Wu pgpT0vuMOW8nC.pgp Description: PGP signature
Re: d80211 constants inside d80211_common.h
Anyway it's not a problem to get phytypes outside dadwifi, but i think it's low level stuff that's generaly needed. The main cause for my mail was to capitalize them, anywhere they get inside kernel source. Thanx for your time Nick 2006/12/27, Nick Kossifidis <[EMAIL PROTECTED]>: We need those definitions for setting up the rate tables in dadwifi, phytypes are needed inside drivers, take a look here -> http://madwifi.org/browser/branches/dadwifi-openhal/openhal/ar5xxx.h?rev=1867 Even if it does get out, constants should be in capitals. Thanx for your time Nick 2006/12/27, Michael Wu <[EMAIL PROTECTED]>: > On Wednesday 27 December 2006 03:32, Nick Kossifidis wrote: > > I did a grep inside drivers/net/wireless/d80211/* and they are not > > used yet in drivers. Can you plz fix it before drivers start using > > them ? > Already fixed, just waiting for wireless-dev to get it. > > http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff;h=4ae94181f808da96352478c6d4102e3b0b5dfaac > > -Michael Wu > > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 constants inside d80211_common.h
We need those definitions for setting up the rate tables in dadwifi, phytypes are needed inside drivers, take a look here -> http://madwifi.org/browser/branches/dadwifi-openhal/openhal/ar5xxx.h?rev=1867 Even if it does get out, constants should be in capitals. Thanx for your time Nick 2006/12/27, Michael Wu <[EMAIL PROTECTED]>: On Wednesday 27 December 2006 03:32, Nick Kossifidis wrote: > I did a grep inside drivers/net/wireless/d80211/* and they are not > used yet in drivers. Can you plz fix it before drivers start using > them ? Already fixed, just waiting for wireless-dev to get it. http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff;h=4ae94181f808da96352478c6d4102e3b0b5dfaac -Michael Wu - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
Jarek Poplawski wrote: On Fri, Dec 22, 2006 at 06:05:18AM -0800, Ben Greear wrote: Jarek Poplawski wrote: On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote: On 20-12-2006 03:13, Ben Greear wrote: This is from 2.6.18.2 kernel with my patch set. The MAC-VLANs are in active use. From the backtrace, I am thinking this might be a generic problem, however. Any ideas about what this could be? It seems to be reproducible every day or ... If it doesn't help, I hope lockdep will be more precise when you'll upgrade to 2.6.19 or higher. ... or when you enable lockdep in 2.6.18 (I've forgotten it's there alredy!). I got lucky..the system was available by ssh still. I see this in the boot logs..I assume this means lockdep is enabled? Should I have expected to see a lockdep trace in the case of his soft-lockup then? . Dec 19 04:33:48 localhost kernel: Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo MolnarDec 19 04:33:48 localhost kernel: ... MAX_LOCKDEP_SUBCLASSES:8 Yes, you got it enabled in the config. If there is no message later about validator turning off and no warnings which could point at lockdep then it is working. But then, IMHO, there is rather small probability this bug is really from lockup. Another possibility is hardware irqs (timer in particular) are turned off by something (maybe those hacks?) for extremely long time (~10 sec.). The system hangs and does not recover (well, a few processes continue on the other processor for a few minutes before they too deadlock...) I am guessing this problem has been around for a while, but it is only triggered when interfaces are created, and probably only when UDP traffic is already running heavily on the system. Most systems w/out virtual devices will not trigger this sort of race. Ben Regards, Jarek P. -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 constants inside d80211_common.h
On Wednesday 27 December 2006 03:32, Nick Kossifidis wrote: > I did a grep inside drivers/net/wireless/d80211/* and they are not > used yet in drivers. Can you plz fix it before drivers start using > them ? Already fixed, just waiting for wireless-dev to get it. http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff;h=4ae94181f808da96352478c6d4102e3b0b5dfaac -Michael Wu pgpiiIQUKezSE.pgp Description: PGP signature
Re: Network card IRQ balancing with Intel 5000 series chipsets
On Wed, 2006-12-27 at 09:44 -0500, jamal wrote: > On Wed, 2006-27-12 at 14:08 +0100, Arjan van de Ven wrote: > > > sure; however the kernel doesn't provide more accurate information > > currently (and I doubt it could even, it's not so easy to figure out > > which interface triggered the softirq if 2 interfaces share the cpu, and > > then, how much work came from which etc). > > > > If you sample CPU use and in between two samples you are able to know > which nic is tied to which CPU, how much cycles such cpu consumed in > user vs kernel, and how many packets were seen on such nic; then you > should have the info necessary to make a decision, no? Note that getting softirq time itself isn't a problem, that is available actually. (it's not very accurate but that's another kettle of fish entirely) But... No that isn't better than packet counts. Cases where it simply breaks 1) you have more nics than cpus, so you HAVE to have sharing 2) Other loads going on than just pure networking (storage but also timers and .. and ..) And neither is even remotely artificial. > Yes, I know it is > a handwave on my part and it is complex but by the same token, I would > suspect each kind of IO derived work (which results in interupts) will > have more inputs that could help you make a proper decision than a mere > glance of the interupts. I understand for example the SCSI subsystem > these days behaves very much like NAPI. the difference between scsi and networking is that the work scsi does per "sector" is orders and orders of magnitude less than what networking does. SCSI does it's work mostly per "transfer" not per sector, and if you're busy you tend to get larger transfers as well (megabytes is not special). SCSI also doesn't look at the payload at all, unlike networking (where there are those pesky headers every 1500 bytes or less that the kernel needs to look at :) > It is certainly much more promising now than before. Most people will > probably have symettrical type of apps, so it should work for them. > For someone like myself i will still not use it because i typically dont > have symettrical loads. unless you have more nics than you have cpus, irqbalance will do the right thing anyway (it'll tend to not share or move networking interrupts). And once you have more nics than you have cpus see above. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network card IRQ balancing with Intel 5000 series chipsets
On Wed, 2006-27-12 at 14:08 +0100, Arjan van de Ven wrote: > sure; however the kernel doesn't provide more accurate information > currently (and I doubt it could even, it's not so easy to figure out > which interface triggered the softirq if 2 interfaces share the cpu, and > then, how much work came from which etc). > If you sample CPU use and in between two samples you are able to know which nic is tied to which CPU, how much cycles such cpu consumed in user vs kernel, and how many packets were seen on such nic; then you should have the info necessary to make a decision, no? Yes, I know it is a handwave on my part and it is complex but by the same token, I would suspect each kind of IO derived work (which results in interupts) will have more inputs that could help you make a proper decision than a mere glance of the interupts. I understand for example the SCSI subsystem these days behaves very much like NAPI. I think one of the failures of the APIC load balancing is a direct result of not being able to factor in such enviromental factors. > also the "amount of work" estimate doesn't need to be accurate to 5 > digits to be honest... just number of packets seems to be a quite > reasonable approximation already. (if the kernel starts exporting more > accurate data, irqbalance can easily use it of course) It is certainly much more promising now than before. Most people will probably have symettrical type of apps, so it should work for them. For someone like myself i will still not use it because i typically dont have symettrical loads. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network card IRQ balancing with Intel 5000 series chipsets
On Wed, 2006-27-12 at 09:09 +0200, Robert Iakobashvili wrote: > > My scenario is treatment of RTP packets in kernel space with a single network > card (both Rx and Tx). The default of the Intel 5000 series chipset is > affinity of each > network card to a certain CPU. Currently, neither with irqbalance nor > with kernel > irq-balancing (MSI and io-apic attempted) I do not find a way to > balance that irq. In the near future, when the NIC vendors wake up[1] because CPU vendors - including big bad Intel - are going to be putting out a large number of hardware threads, you should be able to do more clever things with such a setup. At the moment, just tie it to a single CPU and have your other processes that are related running/bound on the other cores so you can utilize them. OTOH, you say you are only using 30% of the one CPU, so it may not be a big deal to tie your single nic to on cpu. cheers, jamal [1] If you are able to change the NIC in your setup try looking at netiron; email [EMAIL PROTECTED] they have a much clever nic than the e1000. It has multiple DMA receive rings which are selectable via a little classifier (example you could have RTP going to CPU0 and rest going to CPU1). The DMA rings could be tied to different interupts/MSI and with some little work could be made to appear like several interfaces. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network card IRQ balancing with Intel 5000 series chipsets
> Although still insufficient in certain cases. All flows are not equal; as an > example, an IPSEC flow with 1000 packets bound to one CPU will likely > utilize more cycles than 5000 packets that are being plain forwarded on > another CPU. sure; however the kernel doesn't provide more accurate information currently (and I doubt it could even, it's not so easy to figure out which interface triggered the softirq if 2 interfaces share the cpu, and then, how much work came from which etc). also the "amount of work" estimate doesn't need to be accurate to 5 digits to be honest... just number of packets seems to be a quite reasonable approximation already. (if the kernel starts exporting more accurate data, irqbalance can easily use it of course) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] cxgb3 - main header files
On Wed, 2006-12-27 at 00:52 -0800, Divy Le Ray wrote: > Jeff, > > You can grab the monolithic patch at this URL: > http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 > > This patch adds support for the latest 1G/10G Chelsio adapter, T3. > It is required by the T3 RDMA driver Steve Wise submitted. does this patch still contain all the private ioctls? They are being ripped out from another new driver, and cxgb3 should probably have the same treatment... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] cxgb3 - main header files
Jeff, You can grab the monolithic patch at this URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 This patch adds support for the latest 1G/10G Chelsio adapter, T3. It is required by the T3 RDMA driver Steve Wise submitted. Here is a brief description of its content: drivers/net/cxgb3/adapter.h, drivers/net/cxgb3/common.h, drivers/net/cxgb3/cxgb3_ioctl.h, drivers/net/cxgb3/firmware_exports.h: main header files drivers/net/cxgb3/cxgb3_main.c main source file drivers/net/cxgb3/t3_hw.c HW access routines drivers/net/cxgb3/sge.c, drivers/net/cxgb3/sge_defs.h scatter/gather engine drivers/net/cxgb3/ael1002.c, drivers/net/cxgb3/mc5.c, drivers/net/cxgb3/vsc8211.c, drivers/net/cxgb3/xgmac.c on board memory, MAC and PHY management drivers/net/cxgb3/cxgb3_ctl_defs.h, drivers/net/cxgb3/cxgb3_defs.h, drivers/net/cxgb3/cxgb3_offload.h, drivers/net/cxgb3/l2t.h, drivers/net/cxgb3/t3_cpl.h, drivers/net/cxgb3/t3cdev.h offload operations header files drivers/net/cxgb3/cxgb3_offload.c, drivers/net/cxgb3/l2t.c offload capabilities drivers/net/cxgb3/regs.h register definitions drivers/net/Kconfig drivers/net/Makefile drivers/net/cxgb3/Makefile drivers/net/cxgb3/version.h build files and versioning Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211 constants inside d80211_common.h
ieee80211_msg_type, ieee80211_phytype and ieee80211_ssi_type should be
in capitals as they are constants and must not be mistaken for vars...
enum ieee80211_msg_type {
IEEE80211_MSG_NORMAL= 0,
IEEE80211_MSG_TX_CALLBACK_ACK = 1,
IEEE80211_MSG_TX_CALLBACK_FAIL = 2,
IEEE80211_MSG_PASSIVE_SCAN = 3,
IEEE80211_MSG_WEP_FRAME_UNKNOWN_KEY = 4,
IEEE80211_MSG_MICHAEL_MIC_FAIL = 5,
/* hole at 6, was monitor but never sent to userspace */
IEEE80211_MSG_STA_NOT_ASSOC = 7,
IEEE80211_MSG_SET_AID_FOR_STA = 8 /* used by Intersil MVC driver */,
IEEE80211_MSG_KEY_THRESHOLD_NOTIFICATION = 9,
IEEE80211_MSG_RADAR = 11,
};
enum ieee80211_phytype {
IEEE80211_PHYTYPE_FHSS_DOT11_97 = 1,
IEEE80211_PHYTYPE_DSSS_DOT11_97 = 2,
IEEE80211_PHYTYPE_IRBASEBAND = 3,
IEEE80211_PHYTYPE_DSSS_DOT11_B = 4,
IEEE80211_PHYTYPE_PBCC_DOT11_B = 5,
IEEE80211_PHYTYPE_OFDM_DOT11_G = 6,
IEEE80211_PHYTYPE_PBCC_DOT11_G = 7,
IEEE80211_PHYTYPE_OFDM_DOT11_A = 8,
IEEE80211_PHYTYPE_DSSS_DOT11_TURBOG = 255,
IEEE80211_PHYTYPE_DSSS_DOT11_TURBO = 256,
};
enum ieee80211_ssi_type {
IEEE80211_SSI_NONE = 0,
IEEE80211_SSI_NORM = 1, /* normalized, 0-1000 */
IEEE80211_SSI_DBM = 2,
IEEE80211_SSI_RAW = 3, /* raw SSI */
};
I did a grep inside drivers/net/wireless/d80211/* and they are not
used yet in drivers. Can you plz fix it before drivers start using
them ?
Thanx for your time
Nick
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
On Fri, Dec 22, 2006 at 06:05:18AM -0800, Ben Greear wrote: > Jarek Poplawski wrote: > >On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote: > >>On 20-12-2006 03:13, Ben Greear wrote: > >>>This is from 2.6.18.2 kernel with my patch set. The MAC-VLANs are in > >>>active use. > >>> From the backtrace, I am thinking this might be a generic problem, > >>>however. > >>> > >>>Any ideas about what this could be? It seems to be reproducible every > >>>day or > >... > >>If it doesn't help, I hope lockdep will be more > >>precise when you'll upgrade to 2.6.19 or higher. > > > >... or when you enable lockdep in 2.6.18 (I've > >forgotten it's there alredy!). > > I got lucky..the system was available by ssh still. I see this in the boot > logs..I assume > this means lockdep is enabled? Should I have expected to see a lockdep > trace in the case of > his soft-lockup then? > > . > Dec 19 04:33:48 localhost kernel: Lock dependency validator: Copyright (c) > 2006 Red Hat, Inc., Ingo MolnarDec 19 04:33:48 localhost kernel: ... > MAX_LOCKDEP_SUBCLASSES:8 Yes, you got it enabled in the config. If there is no message later about validator turning off and no warnings which could point at lockdep then it is working. But then, IMHO, there is rather small probability this bug is really from lockup. Another possibility is hardware irqs (timer in particular) are turned off by something (maybe those hacks?) for extremely long time (~10 sec.). Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] NetXen: Fix for PPC machines.
On Wed, Dec 27, 2006 at 07:58:54AM +, Christoph Hellwig wrote: > On Mon, Dec 18, 2006 at 05:53:59AM -0800, Amit S. Kale wrote: > > Signed-off-by: Amit S. Kale <[EMAIL PROTECTED]> > > > > netxen_nic.h |2 +- > > netxen_nic_init.c | 12 ++-- > > netxen_nic_main.c |4 ++-- > > 3 files changed, 9 insertions(+), 9 deletions(-) > > Please use __le* types for all hardware data structures and use sparse > to verify all your endianess handling is correct. I have preliminary endianness annotations for that puppy; FWIW, a part of it consists of _removing_ __le. Folks, readl() returns host-endian and writel() takes host-endian as argument. They do conversions themselves. One needs fixed-endian types in data structures shared with device - i.e. anything in ioremapped area or dma'd to/from device. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
