from:"Randy.Dunlap"

On Tue, 22 Aug 2006 13:37:14 -0400 Jesse Huang wrote:

 Dear All:
 I had regenerate this patch from:
 git://git.kernel.org/pub/scm/linux/kernel/git/penberg/netdev-ipg-2.6.git
 
 And, submit those modifications as one patch.
 
 Add: Remove and add some whitespace
 
 From: Jesse Huang [EMAIL PROTECTED]
 
 Change Logs:
- update maintainer information
- remove some default phy params
- remove threshold config from ipg_io_config
- ip1000 ipg_config_autoneg rewrite
- modify coding style of ipg_config_autoneg
- Add IPG_AC_FIFO flag when Tx reset
- For compatible at PCI 66MHz issue
- Remove and add some whitespace
 
 Signed-off-by: Jesse Huang [EMAIL PROTECTED]


-   u8 phyctrl;
+   long mac_ctrl_value;

Should mac_ctrl_value be unsigned long or u32 instead of signed long?

We try to keep source lines limited to  80 columns when feasible
so that they fit nicely into an xterm.  There are a few lines here
that are  80 columns.

+   if((NextToFree != sp-CurrentTFD)  (NextToFree != 
CurrentTxTFDPtr))
+   {

Style:  need space after if; opening brace not on line by itself.

+   // Re-configure after DMA reset. 

Line ends with a space. :(

+   if (sp-ResetCurrentTFD != 0)
+   {

Opening brace not on line by itself -- put it on the previous line,
with a space between ) and {.

+   if (sp-LastTFDHoldAddr == sp-CurrentTFD) sp-LastTFDHoldCnt++;
+   else {sp-LastTFDHoldAddr = sp-CurrentTFD; 
sp-LastTFDHoldCnt=0; }

Split lines as:
if (condition)
action;
else {
action2;
}


---
~Randy
-
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 4/4] IP100A: Solve host error problem in low performance embedded system when continune down and up.

On Tue, 22 Aug 2006 14:31:32 -0400 Jesse Huang wrote:

 From: Jesse Huang [EMAIL PROTECTED]
 
 Change Logs:
- Solve host error problem in low performance embedded 
  system when continune down and up.
 
 Signed-off-by: Jesse Huang [EMAIL PROTECTED]
 
 ---
 
  sundance.c |   30 +-
  1 files changed, 25 insertions(+), 5 deletions(-)

Full path/file names above and below, please.

 a88c635933a981dd4fca87e5b8ca9426c5c98013
 diff --git a/sundance.c b/sundance.c
 index 424aebd..de55e0f 100755
 --- a/sundance.c
 +++ b/sundance.c
 @@ -1647,6 +1647,14 @@ static int netdev_close(struct net_devic
   struct sk_buff *skb;
   int i;
  
 + /* Wait and kill tasklet */
 + tasklet_kill(np-rx_tasklet);
 + tasklet_kill(np-tx_tasklet);
 +   np-cur_tx = 0;
 +   np-dirty_tx = 0;

Use same indentation/whitespace as surrounding code.
(tabs, not spaces)

 + np-cur_task = 0;
 + np-last_tx = 0;
 +
   netif_stop_queue(dev);
  
   if (netif_msg_ifdown(np)) {
 @@ -1667,9 +1675,20 @@ static int netdev_close(struct net_devic
   /* Stop the chip's Tx and Rx processes. */
   iowrite16(TxDisable | RxDisable | StatsDisable, ioaddr + MACCtrl1);
  
 - /* Wait and kill tasklet */
 - tasklet_kill(np-rx_tasklet);
 - tasklet_kill(np-tx_tasklet);
 +for (i = 2000; i  0; i--) {
 +  if ((ioread32(ioaddr + DMACtrl) 0xC000) == 0)
 + break;
 +  mdelay(1);
 +}
 +
 +iowrite16(GlobalReset | DMAReset | FIFOReset |NetworkReset, ioaddr 
 +ASICCtrl + 2);
 +
 +for (i = 2000; i  0; i--)
 +{
 +  if ((ioread16(ioaddr + ASICCtrl +2) ResetBusy) == 0)
 + break;
 +  mdelay(1);
 +}

Same comment about indentation/whitespace.

---
~Randy
-
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: [take12 0/3] kevent: Generic event handling mechanism.

On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:

 On Wed, 2006-08-23 at 00:16 +0400, Evgeniy Polyakov wrote:
  On Tue, Aug 22, 2006 at 12:57:38PM -0700, Nicholas Miell ([EMAIL 
  PROTECTED]) wrote:
   On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
   Of course, since you already know how all this stuff is supposed to
   work, you could maybe write it down somewhere?
  
  I will write documantation, but as you can see some interfaces are
  changed.
 
 Thanks; rapidly changing interfaces need good documentation even more
 than stable interfaces simply because reverse engineering the intended
 API from a changing implementation becomes even more difficult.

OK, I don't quite get it.
Can you be precise about what you would like?

a.  good documentation
b.  a POSIX API
c.  a Windows-compatible API
d.  other?

and we won't make you use any of this code.

---
~Randy
-
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: [take12 0/3] kevent: Generic event handling mechanism.

On Tue, 22 Aug 2006 15:58:12 -0700 Nicholas Miell wrote:

 On Tue, 2006-08-22 at 14:37 -0700, Randy.Dunlap wrote:
  On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:
  
   On Wed, 2006-08-23 at 00:16 +0400, Evgeniy Polyakov wrote:
On Tue, Aug 22, 2006 at 12:57:38PM -0700, Nicholas Miell ([EMAIL 
PROTECTED]) wrote:
 On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
 Of course, since you already know how all this stuff is supposed to
 work, you could maybe write it down somewhere?

I will write documantation, but as you can see some interfaces are
changed.
   
   Thanks; rapidly changing interfaces need good documentation even more
   than stable interfaces simply because reverse engineering the intended
   API from a changing implementation becomes even more difficult.
  
  OK, I don't quite get it.
  Can you be precise about what you would like?
  
  a.  good documentation
  b.  a POSIX API
  c.  a Windows-compatible API
  d.  other?
  
  and we won't make you use any of this code.
 
 I want something that I can be confident won't be replaced again in two
 years because nobody noticed problems with the old API design or they're
 just feeling very NIH with their snazzy new feature.
 
 Maybe then we won't end up with another in the { signal/sigaction,
 waitpid/wait4, select/pselect, poll/ppol,  msgrcv, mq_receive,
 io_getevents, aio_suspend/aio_return, epoll_wait, inotify read,
 kevent_get_events } collection -- or do you like having a maze of
 twisted interfaces, all subtly different and none supporting the
 complete feature set?
 
 Good documentation giving enough detail to judge the design and an API
 that fits with the current POSIX API (at least, the parts that everybody
 agrees don't suck) goes a long way toward assuaging my fears that this
 won't just be another waste of effort, doomed to be replaced by the Next
 Great Thing (We Really Mean It This Time!) in unified event loop API
 design or whatever other interface somebody happens to be working on.
 
 ---

OK, thank you for elaborating.

I suppose that I am more choose one {cynical, sarcastic,
practial, pragmatic}.  I don't have a crystal ball for 2 years
out and I don't know anyone who does.

IMO we do the best that we can given some human constraints
and probably some marketplace constraints (like ship something
instead of playing with it for 5 years before shipping it).


 This is made extraordinarily difficult by the fact kernel people don't
 even agree themselves on what APIs should look like anyway and Linus
 won't take a stand on the issue -- people with influence are
 simultaneously arguing things like:
 
 - ioctls are bad because they aren't typesafe and you should use
 syscalls instead because they are typesafe
 
 - ioctls are good, because they're much easier to add than syscalls,
 type safety can be supplied by the library wrapper, and syscalls are a
 (relatively) scarce resource, harder to wire up in the first place, and
 are more difficult to make optional or remove entirely if you decide
 they were a stupid idea.

Yes, I was recently part of that argument in Ottawa.

 - multiplexors are bad because they're too complex or not typesafe
 
 - multiplexors are good because they save syscall slots or ioctl numbers
 and the library wrapper provides the typesafety anyway.

Multiplexors have already lost AFAIK.  Unless someone changes their
mind.  Which happens and will continue to happen.

 - instead of syscalls or ioctls, you should create a whole new
 filesystem that has a bunch of magic files that you read from and write
 to in order to talk to the kernel

Yep.  Some people like that one.  Not everyone.

 - filesystem interfaces are bad, because they're take more effort to
 write than a syscall or a ioctl and nobody seems to know how to maintain
 and evolve a filesystem-based ABI or make them easy to use outside of a
 fragile shell script (see: sysfs)

Ack.

 - that everything in those custom filesystems should ASCII strings and
 nobody needs an actual grammar describing how to parse them, we can just
 break userspace whenever we feel like it

sysfs requires one value per file.  Little parsing required.
But I don't know how to capture atomic values from N files with sysfs.

 - that everything in those custom filesystems should be C structs, and
 screw the shell scripts

Hm, I don't recall that one.

 - new filesystem metadata should be exposed by:
   - xattrs
   - ioctls
   - new syscalls
   or
   - named streams/forks/not-xattrs
   and three out of four of these suggestions are completely wrong for
   some critical reason
 
 - meanwhile, the networking folks are doing everything via AF_NETLINK
 sockets instead of syscalls or ioctl or whatever, I guess because the
 network stack is what's most familiar to them

I sympathize with you on that one.  I don't care for netlink much
either.  To me it's still an ioctl, even though it is routable
and extensible

Re: [PATCH] IP1000A: IC Plus update

2006-08-21 Thread Randy.Dunlap

On Mon, 21 Aug 2006 16:32:07 -0400 Jesse Huang wrote:

 Dear All:
 I had regenerate this patch from:
 git://git.kernel.org/pub/scm/linux/kernel/git/penberg/netdev-ipg-2.6.git
 
 And, submit those modifications as one patch.
 
 From: Jesse Huang [EMAIL PROTECTED]
 
 Change Logs:
- update maintainer information
- remove some default phy params
- remove threshold config from ipg_io_config
- ip1000 ipg_config_autoneg rewrite
- modify coding style of ipg_config_autoneg
- Add IPG_AC_FIFO flag when Tx reset
- For compatible at PCI 66MHz issue
 
 Signed-off-by: Jesse Huang [EMAIL PROTECTED]
 ---
 
  ipg.c |  394 ++
 +-- ipg.h |   96
 +--- 2 files changed, 92 insertions(+), 398 deletions(-)

Please use diffstat -p1 -w 70 for diffstat output so that we can
see the full path/file names that are modified in the patch.

 8bd0325e52d2578c37cd251aeac2136f7cca9098
 diff --git a/ipg.c b/ipg.c
 index 754ddb5..7c541c2 100644
 --- a/ipg.c
 +++ b/ipg.c

Similar to the diffstat comment, the diff a  b filenames should
show the full path to the source file, e.g.:

--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c

 @@ -511,14 +513,13 @@ static int ipg_config_autoneg(struct net
*/
   sp-tenmbpsmode = 0;
  
 - printk(Link speed = );
 + printk(KERN_INFO Link speed = );
  
   /* Determine actual speed of operation. */
   switch (phyctrl  IPG_PC_LINK_SPEED) {
   case IPG_PC_LINK_SPEED_10MBPS:
   printk(10Mbps.\n);
 - printk(KERN_INFO %s: 10Mbps operational mode
 enabled.\n,
 -dev-name);
 + printk(%s: 10Mbps operational mode enabled.
 \n,dev-name);

Space before dev-name.
Why dropping the KERN_INFO here?  The previous printk contains
a newline character, so KERN_* is still valid.

   sp-tenmbpsmode = 1;
   break;
   case IPG_PC_LINK_SPEED_100MBPS:

 @@ -530,283 +531,50 @@ static int ipg_config_autoneg(struct net

 + /* Configure full duplex, and flow control. */
 + if (fullduplex == 1) {
 + /* Configure IPG for full duplex operation. */
 + printk(KERN_INFO setting full duplex, );

This series of printk calls needs some kind of device or driver
identification.

 - if ((advertisement  ADVERTISE_1000XFULL) ==
 - (linkpartner_ability  ADVERTISE_1000XFULL)) {
 - fullduplex = 1;
 + mac_ctrl_value |= IPG_MC_DUPLEX_SELECT_FD;
  
 - /* In 1000BASE-X using IPG's internal PCS
 -  * layer, so write to the GMII duplex bit.
 -  */
 - bmcr |= ADVERTISE_1000HALF; // Typo ?
 + if (txflowcontrol == 1) {
 + printk(TX flow control);
 + mac_ctrl_value |=
 IPG_MC_TX_FLOW_CONTROL_ENABLE; } else {
 - fullduplex = 0;
 -
 - /* In 1000BASE-X using IPG's internal PCS
 -  * layer, so write to the GMII duplex bit.
 -  */
 - bmcr = ~ADVERTISE_1000HALF; // Typo ?
 + printk(no TX flow control);
 + mac_ctrl_value =
 ~IPG_MC_TX_FLOW_CONTROL_ENABLE; }
 - mdio_write(dev, phyaddr, MII_BMCR, bmcr);
 - }

 + } else {
 + /* Configure IPG for half duplex operation. */
 + printk(KERN_INFO setting half duplex, no TX flow
 control, no RX flow control.\n); 

Same here:  needs device (preferably) or driver identification.

 - default:
 - txflowcontrol = 0;
 - rxflowcontrol = 0;
 - }
 + mac_ctrl_value = ~IPG_MC_DUPLEX_SELECT_FD 
 ~IPG_MC_TX_FLOW_CONTROL_ENABLE  ~IPG_MC_RX_FLOW_CONTROL_ENABLE; }

 @@ -1158,6 +916,7 @@ static void ipg_nic_txfree(struct net_de
   struct ipg_nic_private *sp = netdev_priv(dev);
   int NextToFree;
   int maxtfdcount;
 + long CurrentTxTFDPtr=(ioread32(ipg_ioaddr(dev)
 +TFD_LIST_PTR_0)-(long)sp-TFDListDMAhandle)/(long)sizeof(struct
 TFD);

Space before and after '=' sign.
 
 @@ -1180,8 +939,10 @@ static void ipg_nic_txfree(struct net_de
* If the TFDDone bit is set, free the associated
* buffer.
*/
 - if ((le64_to_cpu(sp-TFDList[NextToFree].TFC) 
 -  IPG_TFC_TFDDONE)  (NextToFree !=
 sp-CurrentTFD)) {
 + if((NextToFree != sp-CurrentTFD)(NextToFree!
 =CurrentTxTFDPtr))

Spaces before and after  and != etc. (as in the former code).

 + {
 + //JesseAdd: setup TFDDONE for compatible
 issue.
 + sp-TFDList[NextToFree].TFC = cpu_to_le64
 (sp-TFDList[NextToFree].TFC|IPG_TFC_TFDDONE); /* Free the transmit
 buffer. */ if (sp-TxBuff[NextToFree] != NULL) {
   pci_unmap_single(sp-pdev,
 @@ -1204,6 +965,15

Re: [PATCH] IP1000A: IC Plus update

2006-08-21 Thread Randy.Dunlap

On Tue, 22 Aug 2006 11:11:16 +0800 Jesse Huang wrote:

 Hi Randy:
 
 Thanks for your review. I will follow your suggestions. I used
 git-format-diff
 to generate this patch, should I use diffstat to instead of it?

Sorry, I really can't advise you on how to use git.
Did you have a complete kernel tree and then make changes to
the .c and .h files?  Or did you only have the ip1000 .c and .h
files?  If only the latter, that won't include the full path  file
names unless you force it to.


 The old DefaultPhyParam table content a lot of furture hardware parameters.
 We are sure now that is not need for new version of IP1000A, so I remove
 those.

OK, I see.

~Randy

 Thanks for help.
 
 Jesse
 
 - Original Message - 
 From: Randy.Dunlap [EMAIL PROTECTED]
 To: Jesse Huang [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
 netdev@vger.kernel.org
 Sent: Tuesday, August 22, 2006 12:25 AM
 Subject: Re: [PATCH] IP1000A: IC Plus update
 
 
 On Mon, 21 Aug 2006 16:32:07 -0400 Jesse Huang wrote:
 
  Dear All:
  I had regenerate this patch from:
  git://git.kernel.org/pub/scm/linux/kernel/git/penberg/netdev-ipg-2.6.git
 
  And, submit those modifications as one patch.
 
  From: Jesse Huang [EMAIL PROTECTED]
 
  Change Logs:
 - update maintainer information
 - remove some default phy params
 - remove threshold config from ipg_io_config
 - ip1000 ipg_config_autoneg rewrite
 - modify coding style of ipg_config_autoneg
 - Add IPG_AC_FIFO flag when Tx reset
 - For compatible at PCI 66MHz issue
 
  Signed-off-by: Jesse Huang [EMAIL PROTECTED]
  ---
 
   ipg.c |  394 ++
  +-- ipg.h |   96
  +--- 2 files changed, 92 insertions(+), 398 deletions(-)
 
 Please use diffstat -p1 -w 70 for diffstat output so that we can
 see the full path/file names that are modified in the patch.
 
  8bd0325e52d2578c37cd251aeac2136f7cca9098
  diff --git a/ipg.c b/ipg.c
  index 754ddb5..7c541c2 100644
  --- a/ipg.c
  +++ b/ipg.c
 
 Similar to the diffstat comment, the diff a  b filenames should
 show the full path to the source file, e.g.:
 
 --- a/drivers/net/ipg.c
 +++ b/drivers/net/ipg.c
 
  @@ -511,14 +513,13 @@ static int ipg_config_autoneg(struct net
   */
   sp-tenmbpsmode = 0;
 
  - printk(Link speed = );
  + printk(KERN_INFO Link speed = );
 
   /* Determine actual speed of operation. */
   switch (phyctrl  IPG_PC_LINK_SPEED) {
   case IPG_PC_LINK_SPEED_10MBPS:
   printk(10Mbps.\n);
  - printk(KERN_INFO %s: 10Mbps operational mode
  enabled.\n,
  -dev-name);
  + printk(%s: 10Mbps operational mode enabled.
  \n,dev-name);
 
 Space before dev-name.
 Why dropping the KERN_INFO here?  The previous printk contains
 a newline character, so KERN_* is still valid.
 
  sp-tenmbpsmode = 1;
   break;
   case IPG_PC_LINK_SPEED_100MBPS:
 
  @@ -530,283 +531,50 @@ static int ipg_config_autoneg(struct net
 
  + /* Configure full duplex, and flow control. */
  + if (fullduplex == 1) {
  + /* Configure IPG for full duplex operation. */
  + printk(KERN_INFO setting full duplex, );
 
 This series of printk calls needs some kind of device or driver
 identification.
 
  - if ((advertisement  ADVERTISE_1000XFULL) ==
  - (linkpartner_ability  ADVERTISE_1000XFULL)) {
  - fullduplex = 1;
  + mac_ctrl_value |= IPG_MC_DUPLEX_SELECT_FD;
 
  - /* In 1000BASE-X using IPG's internal PCS
  - * layer, so write to the GMII duplex bit.
  - */
  - bmcr |= ADVERTISE_1000HALF; // Typo ?
  + if (txflowcontrol == 1) {
  + printk(TX flow control);
  + mac_ctrl_value |=
  IPG_MC_TX_FLOW_CONTROL_ENABLE; } else {
  - fullduplex = 0;
  -
  - /* In 1000BASE-X using IPG's internal PCS
  - * layer, so write to the GMII duplex bit.
  - */
  - bmcr = ~ADVERTISE_1000HALF; // Typo ?
  + printk(no TX flow control);
  + mac_ctrl_value =
  ~IPG_MC_TX_FLOW_CONTROL_ENABLE; }
  - mdio_write(dev, phyaddr, MII_BMCR, bmcr);
  - }
 
  + } else {
  + /* Configure IPG for half duplex operation. */
  + printk(KERN_INFO setting half duplex, no TX flow
  control, no RX flow control.\n);
 
 Same here:  needs device (preferably) or driver identification.
 
  - default:
  - txflowcontrol = 0;
  - rxflowcontrol = 0;
  - }
  + mac_ctrl_value = ~IPG_MC_DUPLEX_SELECT_FD 
  ~IPG_MC_TX_FLOW_CONTROL_ENABLE  ~IPG_MC_RX_FLOW_CONTROL_ENABLE; }
 
  @@ -1158,6 +916,7 @@ static void ipg_nic_txfree(struct net_de
   struct ipg_nic_private *sp = netdev_priv(dev);
   int NextToFree;
   int maxtfdcount;
  + long CurrentTxTFDPtr=(ioread32(ipg_ioaddr(dev)
  +TFD_LIST_PTR_0)-(long)sp-TFDListDMAhandle)/(long)sizeof(struct
  TFD);
 
 Space before and after '=' sign.
 
  @@ -1180,8 +939,10 @@ static void ipg_nic_txfree(struct net_de
   * If the TFDDone bit is set, free the associated
   * buffer.
   */
  - if ((le64_to_cpu(sp-TFDList[NextToFree].TFC) 
  -  IPG_TFC_TFDDONE)  (NextToFree !=
  sp-CurrentTFD

Re: [PATCH 7/7] [I/OAT] Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma

2006-08-15 Thread Randy.Dunlap

On Tue, 15 Aug 2006, Chris Leech wrote:

 Signed-off-by: Chris Leech [EMAIL PROTECTED]
 ---

  MAINTAINERS |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 21116cc..9ae73c9 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -881,6 +881,11 @@ M:   [EMAIL PROTECTED]
  L:   linux-kernel@vger.kernel.org
  S:   Maintained

 +DMA GENERIC MEMCPY SUBSYSTEM
 +P:   Chris Leech
 +M:   [EMAIL PROTECTED]
 +S:   Maintained
 +
  DOCBOOK FOR DOCUMENTATION
  P:   Martin Waitz
  M:   [EMAIL PROTECTED]
 @@ -1469,6 +1474,11 @@ P: Tigran Aivazian
  M:   [EMAIL PROTECTED]
  S:   Maintained

 +INTEL I/OAT DMA DRIVER
 +P:   Chris Leech
 +M:   [EMAIL PROTECTED]
 +S:   Supported
 +
  INTEL IXP4XX RANDOM NUMBER GENERATOR SUPPORT
  P:   Deepak Saxena
  M:   [EMAIL PROTECTED]

Can you also add an appropriate mailing list for these,
such as netdev or lkml etc.?

Thanks,
-- 
~Randy
-
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] eth: docbook comments

2006-08-15 Thread Randy.Dunlap

On Tue, 15 Aug 2006, Stephen Hemminger wrote:



Acked-by: Randy Dunlap [EMAIL PROTECTED]


 ---
  net/ethernet/eth.c |   90 
 +
  1 file changed, 64 insertions(+), 26 deletions(-)

 --- net-2.6.19.orig/net/ethernet/eth.c
 +++ net-2.6.19/net/ethernet/eth.c

Thanks, Steve.

-- 
~Randy
-
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 0/5] net socket family patches

2006-08-10 Thread Randy.Dunlap

On Thu, 10 Aug 2006 05:36:13 + (UTC) Alexey Toptygin wrote:

On Wed, 9 Aug 2006, David Miller wrote:

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 09 Aug 2006 11:31:38 -0700

These patches cleanup the net socket family interface and
convert it to RCU. This is new stuff that should go into 2.6.19
(if it is ready). Andrew could you put it in -mm as well?

Andrew pulls net-2.6.19 so there is no need to ask him to
put networking patches explicitly into -mm

I've been wondering - are the relationships of which of the various kernel
trees pull patches from which other ones documented anywhere? If so, I'd
love to read about it.

Not really documented AFAIK, except what Andrew pulls into his -mm tree
for testing. His announcements [used to] list which (git or other) trees that
he has merged, along with non-tree patches. Now that is just in the
patch-list file, e.g., see

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/patch-list
and then search for git- to see which git trees it contains.

If you go down the maintainer's hierarchy, it gets more fuzzy. :)
Jeff Garzik pulls the wireless tree from John Linville and several
net driver trees from Francois Romieu, e.g. And Jeff pulls SATA
patches from Tejun Heo.

DaveM pulls net patches from Yoshifuji etc.

James Bottomley usually maintains 2 SCSI git trees: one for
2.6.current-rc fixes and one for 2.6.next merges. He recently documented
that in email to [EMAIL PROTECTED]

Most kernel git trees can be seen at www.kernel.org/git/.
Most kernel patch trees (git or other) are now listed in the
MAINTAINERS file.

HTH.
---
~Randy
-
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

[PATCH] tiacx sparse cleanups

2006-08-07 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

tiacx sparse cleanups:
- use NULL instead of 0 for pointer value
- use C99 struct initializers
- use ANSI function declaration

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/wireless/tiacx/common.c |2 
 drivers/net/wireless/tiacx/ioctl.c  |  202 ++--
 drivers/net/wireless/tiacx/pci.c|2 
 drivers/net/wireless/tiacx/usb.c|2 
 4 files changed, 104 insertions(+), 104 deletions(-)


--- linux-2618-rc3mm2.orig/drivers/net/wireless/tiacx/common.c
+++ linux-2618-rc3mm2/drivers/net/wireless/tiacx/common.c
@@ -1396,7 +1396,7 @@ manage_proc_entries(const struct net_dev
log(L_INIT, %sing /proc entry %s\n,
remove ? remov : creat, procbuf);
if (!remove) {
-   if (!create_proc_read_entry(procbuf, 0, 0, 
proc_funcs[i], adev)) {
+   if (!create_proc_read_entry(procbuf, 0, NULL, 
proc_funcs[i], adev)) {
printk(acx: cannot register /proc entry %s\n, 
procbuf);
return NOT_OK;
}
--- linux-2618-rc3mm2.orig/drivers/net/wireless/tiacx/ioctl.c
+++ linux-2618-rc3mm2/drivers/net/wireless/tiacx/ioctl.c
@@ -2163,7 +2163,7 @@ acx_ioctl_set_rates(struct net_device *n
 
log(L_IOCTL, set_rates %s\n, extra);
result = fill_ratemasks(extra, brate, orate,
-   acx111_supported, acx111_gen_mask, 0);
+   acx111_supported, acx111_gen_mask, NULL);
if (result) goto end;
SET_BIT(orate, brate);
log(L_IOCTL, brate %08X orate %08X\n, brate, orate);
@@ -2615,107 +2615,107 @@ static const iw_handler acx_ioctl_privat
 
 static const struct iw_priv_args acx_ioctl_private_args[] = {
 #if ACX_DEBUG
-{ cmd : ACX100_IOCTL_DEBUG,
-   set_args : IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetDebug },
+{  .cmd = ACX100_IOCTL_DEBUG,
+   .set_args = IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
+   .get_args = 0,
+   .name = SetDebug },
 #endif
-{ cmd : ACX100_IOCTL_SET_PLED,
-   set_args : IW_PRIV_TYPE_BYTE | 2,
-   get_args : 0,
-   name : SetLEDPower },
-{ cmd : ACX100_IOCTL_GET_PLED,
-   set_args : 0,
-   get_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 2,
-   name : GetLEDPower },
-{ cmd : ACX100_IOCTL_SET_RATES,
-   set_args : IW_PRIV_TYPE_CHAR | 256,
-   get_args : 0,
-   name : SetRates },
-{ cmd : ACX100_IOCTL_LIST_DOM,
-   set_args : 0,
-   get_args : 0,
-   name : ListRegDomain },
-{ cmd : ACX100_IOCTL_SET_DOM,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetRegDomain },
-{ cmd : ACX100_IOCTL_GET_DOM,
-   set_args : 0,
-   get_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   name : GetRegDomain },
-{ cmd : ACX100_IOCTL_SET_SCAN_PARAMS,
-   set_args : IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 4,
-   get_args : 0,
-   name : SetScanParams },
-{ cmd : ACX100_IOCTL_GET_SCAN_PARAMS,
-   set_args : 0,
-   get_args : IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 4,
-   name : GetScanParams },
-{ cmd : ACX100_IOCTL_SET_PREAMB,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetSPreamble },
-{ cmd : ACX100_IOCTL_GET_PREAMB,
-   set_args : 0,
-   get_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   name : GetSPreamble },
-{ cmd : ACX100_IOCTL_SET_ANT,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetAntenna },
-{ cmd : ACX100_IOCTL_GET_ANT,
-   set_args : 0,
-   get_args : 0,
-   name : GetAntenna },
-{ cmd : ACX100_IOCTL_RX_ANT,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetRxAnt },
-{ cmd : ACX100_IOCTL_TX_ANT,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetTxAnt },
-{ cmd : ACX100_IOCTL_SET_PHY_AMP_BIAS,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetPhyAmpBias},
-{ cmd : ACX100_IOCTL_GET_PHY_CHAN_BUSY,
-   set_args : 0,
-   get_args : 0,
-   name : GetPhyChanBusy },
-{ cmd : ACX100_IOCTL_SET_ED,
-   set_args : IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetED },
-{ cmd : ACX100_IOCTL_SET_CCA,
-   set_args : IW_PRIV_TYPE_BYTE | IW_PRIV_SIZE_FIXED | 1,
-   get_args : 0,
-   name : SetCCA },
-{ cmd : ACX100_IOCTL_MONITOR,
-   set_args : IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 2,
-   get_args : 0,
-   name : monitor },
-{ cmd : ACX100_IOCTL_TEST,
-   set_args : 0,
-   get_args : 0,
-   name : Test },
-{ cmd : ACX100_IOCTL_DBG_SET_MASKS,
-   set_args : IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 2,
-

Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

2006-08-03 Thread Randy.Dunlap

On Thu, 3 Aug 2006 12:32:05 -0400 Theodore Tso wrote:

 On Thu, Aug 03, 2006 at 08:00:35PM +1000, Herbert Xu wrote:
  Theodore Tso [EMAIL PROTECTED] wrote:
   
   I'm sending this on mostly because it was a bit of a pain to track down,
   and hopefully it will save time if anyone else hits this while playing
   with the -rt kernel.  It is NOT the right way to fix things, so please
   don't even think of applying this patch (unless you need it, in your own
   local tree :-).
   
   One of these days when we have time to breath we'll look into fixing
   this the right way, if someone doesn't beat us to it first.  :-)
  
  You probably should resend the patch to netdev and Michael Chan
  [EMAIL PROTECTED].  He might have ideas on how this could be
  avoided.
 
 This only shows up with the real-time kernel where timer softirq's run
 in their own processes, and a high priority process preempts the timer
 softirq.  I don't really consider this a networking bug, or even
 driver bug, although it does seem unfortunate that Broadcom hardware
 locks up and goes unresponsive if the OS doesn't tickle it every tenth
 of a second or so.  (Definitely a bad idea if the tg3 gets used on any
 laptops, from a power usage perspective.)  But that seems like a
 (lame) hardware bug, not a driver bug

Interesting.  On my Dell D610 notebook with tg3 and vpn,
I have to ping a server on the vpn to keep it alive, otherwise
it disappears soon and I have to restart the vpn.  Of course,
this could just be the vpn or some other software problem
instead of a tg3 problem.

---
~Randy
-
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: Runtime power management for network interfaces

2006-07-30 Thread Randy.Dunlap

On Tue, 25 Jul 2006 09:20:06 -0700 Auke Kok wrote:

 Alan Stern wrote:
  During a Power Management session at the Ottawa Linux Symposium, it was
  generally agreed that network interface drivers ought to automatically
  suspend their devices (if possible) whenever:
  
  (1) The interface is ifconfig'ed down, or
  
  (2) No link is available.
  
  Presumably (1) should be easy enough to implement.  (2) might or might not
  be feasible, depending on how much WOL support is available.  (It might
  not be feasible at all for wireless networking.)  Still, there can be no
  question that it would be a Good Thing for laptops to power-down their
  ethernet controllers when the network cable is unplugged.
  
  Has any progress been made in this direction?  If not, a natural approach 
  would be to start with a reference implementation in one driver which 
  could then be copied to other drivers.
 
 
 Intel's newer e1000's (ich7 onboard e1000 and newer versions for instance) 
 already support this feature partially - the MAC stays on but the PHY can be 
 powered off when no link is present.
 
 In order to enable this feature you will need to turn it on explicitly at 
 load 
 time:
 
 modprobe e1000 SmartPowerDownEnable=1

Please add that to Documentation/networking/e1000.txt.


 Allthough not the entire NIC is powered off, it still saves a significant 
 part 
 of the power consumed by the NIC. All bits help. The power automatically 
 restores once a cable is plugged in.


---
~Randy
-
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: [DOC]: generic netlink

2006-07-13 Thread Randy.Dunlap

On Mon, 19 Jun 2006 09:41:22 -0400 jamal wrote:

 
 Folks,
 
 Attached is a document that should help people wishing to use generic
 netlink interface. It is a WIP so a lot more to go if i see interest.

Hi,
I have a few random questions about gen-netlink.

1.  Provider IDs (numbers) and names must be unique.  Does
this affect virtualization in any way or is it just transparent?

2.  Is (generic) netlink meant (expected, OK) to be used for
non-networking ioctl/sysfs replacements?

Thanks,
---
~Randy
-
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/2] correct dev_alloc_skb kerneldoc

2006-07-13 Thread Randy.Dunlap

On Thu, 13 Jul 2006 22:36:16 +0200 Christoph Hellwig wrote:

...
 
 I gave converting the dev_alloc_skb prototype everywhere a spin and it
 doesn't look too bad.  There's only a few places that don't have a
 netdevice at hand, and all these look bogus:
 
...

  - drivers/infiniband/hw/ipath/ipath_driver.c:
   Uses skbbuffs in a driver that has absolutely nothing to do
   with networking.  Duh..

Doesn't using netlink at all have that same effect?  (using skbs
in some code that may have nothing to do with networking)

Or should netlink be limited in its scope?

---
~Randy
-
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: [DOC]: generic netlink

2006-07-11 Thread Randy.Dunlap

On Tue, 20 Jun 2006 10:50:13 -0400 jamal wrote:

 
   PS:- I dont have a good place to put this doc and point to, hence the
   17K attachment
  
  
  http://www.kernel.org/pub/linux/kernel/people/hadi/ ?
  
  (unless your permissions have been revoked for lack of use ! :-)
  
 
 I am only allowed to put kernel patches there by the powers that be. So
 this wont fit the criteria. It is hard to believe in these
 times my ISP charges me $1/M/month every time i exceed my allocated 5M
 quota. I have been with this ISP for  10 years, hence migration gets
 harder - and given that many years on the same account, even my .bashrc
 approaches 5M ;-

so make it a patch to Documentation/networking/...

I have some doc corrections, Jamal.  Do I send them against
the 2006-june-19 doc posting?  and as email comments or as a patch?

thanks,
---
~Randy
-
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

xfrm6: move define/ifdef check order and add a Kconfig option

2006-07-03 Thread Randy.Dunlap

On Mon, 03 Jul 2006 19:46:55 -0700 (PDT) David Miller wrote:

 Yes, indeed.  Nothing named CONFIG_* should be defined explicitly
 by the source files, only through Kconfig.
 
 I would rather address that than apply this patch.

by adding a Kconfig option or not?  This patch adds one.


From: Randy Dunlap [EMAIL PROTECTED]

Convert CONFIG_IPV6_XFRM6_TUNNEL_DEBUG (not a Kconfig option)
to CONFIG_INET6_XFRM6_TUNNEL_DEBUG, which is a Kconfig option.

Then #define XFRM6_TUNNEL_SPI_MAGIC before it is first used.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 net/ipv6/Kconfig|6 ++
 net/ipv6/xfrm6_tunnel.c |7 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

--- linux-2617-g20.orig/net/ipv6/xfrm6_tunnel.c
+++ linux-2617-g20/net/ipv6/xfrm6_tunnel.c
@@ -31,8 +31,9 @@
 #include linux/icmpv6.h
 #include linux/mutex.h
 
-#ifdef CONFIG_IPV6_XFRM6_TUNNEL_DEBUG
+#ifdef CONFIG_INET6_XFRM_TUNNEL_DEBUG
 # define X6TDEBUG  3
+# define XFRM6_TUNNEL_SPI_MAGIC 0xdeadbeef
 #else
 # define X6TDEBUG  1
 #endif
@@ -67,10 +68,6 @@ struct xfrm6_tunnel_spi {
 #endif
 };
 
-#ifdef CONFIG_IPV6_XFRM6_TUNNEL_DEBUG
-# define XFRM6_TUNNEL_SPI_MAGIC 0xdeadbeef
-#endif
-
 static DEFINE_RWLOCK(xfrm6_tunnel_spi_lock);
 
 static u32 xfrm6_tunnel_spi;
--- linux-2617-g20.orig/net/ipv6/Kconfig
+++ linux-2617-g20/net/ipv6/Kconfig
@@ -106,6 +106,12 @@ config INET6_TUNNEL
tristate
default n
 
+config INET6_XFRM_TUNNEL_DEBUG
+   bool IPv6: xfrm tunnel debug
+   depends on INET6_XFRM_TUNNEL
+   ---help---
+ Enable IPv6 tunnel debug code.
+
 config INET6_XFRM_MODE_TRANSPORT
tristate IPv6: IPsec transport mode
depends on IPV6



---
-
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

[PATCH] xfrm6: move define/ifdef check order

2006-07-02 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

The first check for #ifdef XFRM6_TUNNEL_SPI_MAGIC needs to come after
the optional #define of it, otherwise the variable won't be there
for the rest of the code to use.

Shouldn't that CONFIG_IPV6_XFRM6_TUNNEL_DEBUG be part of Kconfig
or have its name changed?

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 net/ipv6/xfrm6_tunnel.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2617-g20.orig/net/ipv6/xfrm6_tunnel.c
+++ linux-2617-g20/net/ipv6/xfrm6_tunnel.c
@@ -52,6 +52,10 @@
 # define X6TPRINTK3X6TNOPRINTK
 #endif
 
+#ifdef CONFIG_IPV6_XFRM6_TUNNEL_DEBUG
+# define XFRM6_TUNNEL_SPI_MAGIC 0xdeadbeef
+#endif
+
 /*
  * xfrm_tunnel_spi things are for allocating unique id (spi) 
  * per xfrm_address_t.
@@ -67,10 +71,6 @@ struct xfrm6_tunnel_spi {
 #endif
 };
 
-#ifdef CONFIG_IPV6_XFRM6_TUNNEL_DEBUG
-# define XFRM6_TUNNEL_SPI_MAGIC 0xdeadbeef
-#endif
-
 static DEFINE_RWLOCK(xfrm6_tunnel_spi_lock);
 
 static u32 xfrm6_tunnel_spi;


---
-
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

[PATCH] net: add+use poison defines

2006-07-02 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Add and use poison defines in net/.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 include/linux/poison.h  |4 
 net/atm/clip.c  |3 ++-
 net/ipv6/netfilter/ip6_tables.c |3 ++-
 3 files changed, 8 insertions(+), 2 deletions(-)

--- linux-2617-g20.orig/include/linux/poison.h
+++ linux-2617-g20/include/linux/poison.h
@@ -45,6 +45,10 @@
 /** drivers/atm/ **/
 #define ATM_POISON_FREE0x12
 
+/** net/ **/
+#define NEIGHBOR_DEAD  0xdeadbeef
+#define NETFILTER_LINK_POISON  0xdead57ac
+
 /** kernel/mutexes **/
 #define MUTEX_DEBUG_INIT   0x11
 #define MUTEX_DEBUG_FREE   0x22
--- linux-2617-g20.orig/net/atm/clip.c
+++ linux-2617-g20/net/atm/clip.c
@@ -23,6 +23,7 @@
 #include linux/if.h /* for IFF_UP */
 #include linux/inetdevice.h
 #include linux/bitops.h
+#include linux/poison.h
 #include linux/proc_fs.h
 #include linux/seq_file.h
 #include linux/rcupdate.h
@@ -266,7 +267,7 @@ static void clip_neigh_destroy(struct ne
DPRINTK(clip_neigh_destroy (neigh %p)\n, neigh);
if (NEIGH2ENTRY(neigh)-vccs)
printk(KERN_CRIT clip_neigh_destroy: vccs != NULL !!!\n);
-   NEIGH2ENTRY(neigh)-vccs = (void *) 0xdeadbeef;
+   NEIGH2ENTRY(neigh)-vccs = (void *) NEIGHBOR_DEAD;
 }
 
 static void clip_neigh_solicit(struct neighbour *neigh, struct sk_buff *skb)
--- linux-2617-g20.orig/net/ipv6/netfilter/ip6_tables.c
+++ linux-2617-g20/net/ipv6/netfilter/ip6_tables.c
@@ -25,6 +25,7 @@
 #include linux/vmalloc.h
 #include linux/netdevice.h
 #include linux/module.h
+#include linux/poison.h
 #include linux/icmpv6.h
 #include net/ipv6.h
 #include asm/uaccess.h
@@ -376,7 +377,7 @@ ip6t_do_table(struct sk_buff **pskb,
} while (!hotdrop);
 
 #ifdef CONFIG_NETFILTER_DEBUG
-   ((struct ip6t_entry *)table_base)-comefrom = 0xdead57ac;
+   ((struct ip6t_entry *)table_base)-comefrom = NETFILTER_LINK_POISON;
 #endif
read_unlock_bh(table-lock);
 


---
-
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

[PATCH 2/2] ATM: add+use poison defines

2006-07-02 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

ATM: add and use POISON define values.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/atm/ambassador.c |3 ++-
 drivers/atm/idt77252.c   |3 ++-
 include/linux/poison.h   |1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

--- linux-2617-g20.orig/drivers/atm/ambassador.c
+++ linux-2617-g20/drivers/atm/ambassador.c
@@ -31,6 +31,7 @@
 #include linux/atmdev.h
 #include linux/delay.h
 #include linux/interrupt.h
+#include linux/poison.h
 
 #include asm/atomic.h
 #include asm/io.h
@@ -1995,7 +1996,7 @@ static int __devinit ucode_init (loader_
 }
 i += 1;
   }
-  if (*pointer == 0xdeadbeef) {
+  if (*pointer == ATM_POISON) {
 return loader_start (lb, dev, ucode_start);
   } else {
 // cast needed as there is no %? for pointer differnces
--- linux-2617-g20.orig/drivers/atm/idt77252.c
+++ linux-2617-g20/drivers/atm/idt77252.c
@@ -35,6 +35,7 @@ static char const rcsid[] =
 
 #include linux/module.h
 #include linux/pci.h
+#include linux/poison.h
 #include linux/skbuff.h
 #include linux/kernel.h
 #include linux/vmalloc.h
@@ -3657,7 +3658,7 @@ probe_sram(struct idt77252_dev *card)
writel(SAR_CMD_WRITE_SRAM | (0  2), SAR_REG_CMD);
 
for (addr = 0x4000; addr  0x8; addr += 0x4000) {
-   writel(0xdeadbeef, SAR_REG_DR0);
+   writel(ATM_POISON, SAR_REG_DR0);
writel(SAR_CMD_WRITE_SRAM | (addr  2), SAR_REG_CMD);
 
writel(SAR_CMD_READ_SRAM | (0  2), SAR_REG_CMD);
--- linux-2617-g20.orig/include/linux/poison.h
+++ linux-2617-g20/include/linux/poison.h
@@ -44,6 +44,7 @@
 
 /** drivers/atm/ **/
 #define ATM_POISON_FREE0x12
+#define ATM_POISON 0xdeadbeef
 
 /** net/ **/
 #define NEIGHBOR_DEAD  0xdeadbeef
-
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

[PATCH] IOAT: fix header file kernel-doc

2006-06-30 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Fix kernel-doc problems in include/linux/dmaengine.h:
- add some fields/parameters
- expand some descriptions
- fix typos

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 include/linux/dmaengine.h |   43 +--
 1 files changed, 25 insertions(+), 18 deletions(-)

--- linux-2617-g13.orig/include/linux/dmaengine.h
+++ linux-2617-g13/include/linux/dmaengine.h
@@ -44,7 +44,7 @@ enum dma_event {
 };
 
 /**
- * typedef dma_cookie_t
+ * typedef dma_cookie_t - an opaque DMA cookie
  *
  * if dma_cookie_t is 0 it's a DMA request cookie, 0 it's an error code
  */
@@ -80,14 +80,14 @@ struct dma_chan_percpu {
 
 /**
  * struct dma_chan - devices supply DMA channels, clients use them
- * @client: ptr to the client user of this chan, will be NULL when unused
- * @device: ptr to the dma device who supplies this channel, always !NULL
+ * @client: ptr to the client user of this chan, will be %NULL when unused
+ * @device: ptr to the dma device who supplies this channel, always !%NULL
  * @cookie: last cookie value returned to client
- * @chan_id:
- * @class_dev:
+ * @chan_id: channel ID for sysfs
+ * @class_dev: class device for sysfs
  * @refcount: kref, used in bigref slow-mode
- * @slow_ref:
- * @rcu:
+ * @slow_ref: indicates that the DMA channel is free
+ * @rcu: the DMA channel's RCU head
  * @client_node: used to add this to the client chan list
  * @device_node: used to add this to the device chan list
  * @local: per-cpu pointer to a struct dma_chan_percpu
@@ -162,10 +162,17 @@ struct dma_client {
  * @chancnt: how many DMA channels are supported
  * @channels: the list of struct dma_chan
  * @global_node: list_head for global dma_device_list
- * @refcount:
- * @done:
- * @dev_id:
- * Other func ptrs: used to make use of this device's capabilities
+ * @refcount: reference count
+ * @done: IO completion struct
+ * @dev_id: unique device ID
+ * @device_alloc_chan_resources: allocate resources and return the
+ * number of allocated descriptors
+ * @device_free_chan_resources: release DMA channel's resources
+ * @device_memcpy_buf_to_buf: memcpy buf pointer to buf pointer
+ * @device_memcpy_buf_to_pg: memcpy buf pointer to struct page
+ * @device_memcpy_pg_to_pg: memcpy struct page/offset to struct page/offset
+ * @device_memcpy_complete: poll the status of an IOAT DMA transaction
+ * @device_memcpy_issue_pending: push appended descriptors to hardware
  */
 struct dma_device {
 
@@ -211,7 +218,7 @@ void dma_async_client_chan_request(struc
  * Both @dest and @src must be mappable to a bus address according to the
  * DMA mapping API rules for streaming mappings.
  * Both @dest and @src must stay memory resident (kernel memory or locked
- * user space pages)
+ * user space pages).
  */
 static inline dma_cookie_t dma_async_memcpy_buf_to_buf(struct dma_chan *chan,
void *dest, void *src, size_t len)
@@ -225,7 +232,7 @@ static inline dma_cookie_t dma_async_mem
 }
 
 /**
- * dma_async_memcpy_buf_to_pg - offloaded copy
+ * dma_async_memcpy_buf_to_pg - offloaded copy from address to page
  * @chan: DMA channel to offload copy to
  * @page: destination page
  * @offset: offset in page to copy to
@@ -250,18 +257,18 @@ static inline dma_cookie_t dma_async_mem
 }
 
 /**
- * dma_async_memcpy_buf_to_pg - offloaded copy
+ * dma_async_memcpy_pg_to_pg - offloaded copy from page to page
  * @chan: DMA channel to offload copy to
- * @dest_page: destination page
+ * @dest_pg: destination page
  * @dest_off: offset in page to copy to
- * @src_page: source page
+ * @src_pg: source page
  * @src_off: offset in page to copy from
  * @len: length
  *
  * Both @dest_page/@dest_off and @src_page/@src_off must be mappable to a bus
  * address according to the DMA mapping API rules for streaming mappings.
  * Both @dest_page/@dest_off and @src_page/@src_off must stay memory resident
- * (kernel memory or locked user space pages)
+ * (kernel memory or locked user space pages).
  */
 static inline dma_cookie_t dma_async_memcpy_pg_to_pg(struct dma_chan *chan,
struct page *dest_pg, unsigned int dest_off, struct page *src_pg,
@@ -278,7 +285,7 @@ static inline dma_cookie_t dma_async_mem
 
 /**
  * dma_async_memcpy_issue_pending - flush pending copies to HW
- * @chan:
+ * @chan: target DMA channel
  *
  * This allows drivers to push copies to HW in batches,
  * reducing MMIO writes where possible.


---
-
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

[PATCH] IOAT: fix kernel-doc in source files

2006-06-30 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Fix kernel-doc warnings in drivers/dma/:
- use correct function  parameter names
- add descriptions where omitted

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/dma/dmaengine.c |   20 
 drivers/dma/ioatdma.c   |8 +---
 2 files changed, 17 insertions(+), 11 deletions(-)

--- linux-2617-g13.orig/drivers/dma/dmaengine.c
+++ linux-2617-g13/drivers/dma/dmaengine.c
@@ -166,8 +166,8 @@ static struct dma_chan *dma_client_chan_
 }
 
 /**
- * dma_client_chan_free - release a DMA channel
- * @chan: dma_chan
+ * dma_chan_cleanup - release a DMA channel's resources
+ * @kref: kernel reference structure that contains the DMA channel device
  */
 void dma_chan_cleanup(struct kref *kref)
 {
@@ -199,7 +199,7 @@ static void dma_client_chan_free(struct 
  * dma_chans_rebalance - reallocate channels to clients
  *
  * When the number of DMA channel in the system changes,
- * channels need to be rebalanced among clients
+ * channels need to be rebalanced among clients.
  */
 static void dma_chans_rebalance(void)
 {
@@ -264,7 +264,7 @@ struct dma_client *dma_async_client_regi
 
 /**
  * dma_async_client_unregister - unregister a client and free the dma_client
- * @client:
+ * @client: dma_client to free
  *
  * Force frees any allocated DMA channels, frees the dma_client memory
  */
@@ -306,7 +306,7 @@ void dma_async_client_chan_request(struc
 }
 
 /**
- * dma_async_device_register -
+ * dma_async_device_register - registers DMA devices found
  * @device: dma_device
  */
 int dma_async_device_register(struct dma_device *device)
@@ -348,8 +348,8 @@ int dma_async_device_register(struct dma
 }
 
 /**
- * dma_async_device_unregister -
- * @device: dma_device
+ * dma_async_device_cleanup - function called when all references are released
+ * @kref: kernel reference object
  */
 static void dma_async_device_cleanup(struct kref *kref)
 {
@@ -359,7 +359,11 @@ static void dma_async_device_cleanup(str
complete(device-done);
 }
 
-void dma_async_device_unregister(struct dma_device* device)
+/**
+ * dma_async_device_unregister - unregisters DMA devices
+ * @device: dma_device
+ */
+void dma_async_device_unregister(struct dma_device *device)
 {
struct dma_chan *chan;
unsigned long flags;
--- linux-2617-g13.orig/drivers/dma/ioatdma.c
+++ linux-2617-g13/drivers/dma/ioatdma.c
@@ -217,7 +217,7 @@ static void ioat_dma_free_chan_resources
 
 /**
  * do_ioat_dma_memcpy - actual function that initiates a IOAT DMA transaction
- * @chan: IOAT DMA channel handle
+ * @ioat_chan: IOAT DMA channel handle
  * @dest: DMA destination address
  * @src: DMA source address
  * @len: transaction length in bytes
@@ -383,7 +383,7 @@ static dma_cookie_t ioat_dma_memcpy_buf_
  * @dest_off: offset into that page
  * @src_pg: pointer to the page to copy from
  * @src_off: offset into that page
- * @len: transaction length in bytes. This is guaranteed to not make a copy
+ * @len: transaction length in bytes. This is guaranteed not to make a copy
  *  across a page boundary.
  */
 
@@ -407,7 +407,7 @@ static dma_cookie_t ioat_dma_memcpy_pg_t
 }
 
 /**
- * ioat_dma_memcpy_issue_pending - push potentially unrecognoized appended 
descriptors to hw
+ * ioat_dma_memcpy_issue_pending - push potentially unrecognized appended 
descriptors to hw
  * @chan: DMA channel handle
  */
 
@@ -510,6 +510,8 @@ static void ioat_dma_memcpy_cleanup(stru
  * ioat_dma_is_complete - poll the status of a IOAT DMA transaction
  * @chan: IOAT DMA channel handle
  * @cookie: DMA transaction identifier
+ * @done: if not %NULL, updated with last completed transaction
+ * @used: if not %NULL, updated with last used transaction
  */
 
 static enum dma_status ioat_dma_is_complete(struct dma_chan *chan,


---
-
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

[PATCH] fix net-core kernel-doc

2006-06-22 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Warning(/var/linsrc/linux-2617-g4//include/linux/skbuff.h:304): No description 
found for parameter 'dma_cookie'
Warning(/var/linsrc/linux-2617-g4//include/net/sock.h:1274): No description 
found for parameter 'copied_early'
Warning(/var/linsrc/linux-2617-g4//net/core/dev.c:3309): No description found 
for parameter 'chan'
Warning(/var/linsrc/linux-2617-g4//net/core/dev.c:3309): No description found 
for parameter 'event'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 include/linux/skbuff.h |2 ++
 include/net/sock.h |1 +
 net/core/dev.c |4 ++--
 3 files changed, 5 insertions(+), 2 deletions(-)

--- linux-2617-g4.orig/include/linux/skbuff.h
+++ linux-2617-g4/include/linux/skbuff.h
@@ -209,6 +209,8 @@ enum {
  * @nf_bridge: Saved data about a bridged frame - see br_netfilter.c
  * @tc_index: Traffic control index
  * @tc_verd: traffic control verdict
+ * @dma_cookie: a cookie to one of several possible DMA operations
+ * done by skb DMA functions
  * @secmark: security marking
  */
 
--- linux-2617-g4.orig/include/net/sock.h
+++ linux-2617-g4/include/net/sock.h
@@ -1265,6 +1265,7 @@ sock_recv_timestamp(struct msghdr *msg, 
  * sk_eat_skb - Release a skb if it is no longer needed
  * @sk: socket to eat this skb from
  * @skb: socket buffer to eat
+ * @copied_early: flag indicating whether DMA operations copied this data early
  *
  * This routine must be called with interrupts disabled or with the socket
  * locked so that the sk_buff queue operation is ok.
--- linux-2617-g4.orig/net/core/dev.c
+++ linux-2617-g4/net/core/dev.c
@@ -3301,8 +3301,8 @@ static void net_dma_rebalance(void)
 /**
  * netdev_dma_event - event callback for the net_dma_client
  * @client: should always be net_dma_client
- * @chan:
- * @event:
+ * @chan: DMA channel for the event
+ * @event: event type
  */
 static void netdev_dma_event(struct dma_client *client, struct dma_chan *chan,
enum dma_event event)


---
-
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.17-rc6] Section mismatch in drivers/net/ne.o during modpost

2006-06-13 Thread Randy.Dunlap

On Tue, 13 Jun 2006 15:35:29 +1000 Keith Owens wrote:

 Mikael Pettersson (on Sun, 11 Jun 2006 02:51:21 +0200 (MEST)) wrote:
 On Sat, 10 Jun 2006 12:13:35 -0700, Randy.Dunlap wrote:
 On Sat, 10 Jun 2006 14:11:42 +0200 (MEST) Mikael Pettersson wrote:
 
  While compiling 2.6.17-rc6 for a 486 with an NE2000 ISA ethernet card, I 
  got:
  
  WARNING: drivers/net/ne.o - Section mismatch: reference to 
  .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
  0x158) and 'ne_block_input'
  WARNING: drivers/net/ne.o - Section mismatch: reference to 
  .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
  0x176) and 'ne_block_input'
  WARNING: drivers/net/ne.o - Section mismatch: reference to 
  .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
  0x183) and 'ne_block_input'
  WARNING: drivers/net/ne.o - Section mismatch: reference to 
  .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
  0x1ea) and 'ne_block_input'
  WARNING: drivers/net/ne.o - Section mismatch: reference to 
  .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
  0x251) and 'ne_block_input'
  WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: 
  from .text between 'init_module' (at offset 0x266) and 'ne_block_input'
  WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: 
  from .text between 'init_module' (at offset 0x29b) and 'ne_block_input'
  
  Not sure how serious this is; the driver seems to work fine later on.
 
 Doesn't look serious.  init_module() is not __init, but it calls
 some __init functions and touches some __initdata.
 
 BTW, I would be happy to see some consistent results from modpost
 section checking.  I don't see all of these warnings (I see only 1)
 when using gcc 3.3.6.  What gcc version are you using?
 Does that matter?  (not directed at anyone in particular)
 
 The messages above are from when I used gcc-4.1.1.
 With gcc-3.2.3 I only see a single warning.
 
 Probably over enthusiastic gcc inlining.  gcc 4 will inline functions
 that are not declared as inline.  That is not so bad, except that some
 versions of gcc will ignore a mismatch in function attributes and
 inline a __init function into normal text, generating additional
 section mismatches.  For a specific example, see
 
 http://marc.theaimsgroup.com/?l=linux-kernelm=113824309203482w=2

Yes, I am seeing lots of that.  :(

---
~Randy
-
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] wan/sdla section fixes

2006-06-12 Thread Randy.Dunlap

On Mon, 12 Jun 2006 19:50:22 +0200 Krzysztof Halasa wrote:

 Hi,
 
 Randy.Dunlap [EMAIL PROTECTED] writes:
 
  Priority: tossup.
  netdev-set_config can be called at any time, so these references
  to __initdata would be a real problem.
  However, problem has not been observed AFAIK.
 
  Fix section mismatch warnings:
  WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to 
  .init.data: from .text between 'sdla_set_config' (at offset 0x1b8e) and 
  'sdla_stats'
  WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to 
  .init.data: from .text between 'sdla_set_config' (at offset 0x1e76) and 
  'sdla_stats'
 
 Is sdla.c still in use? I remember someone mentioned that Sangoma
 drivers are now outside the kernel but I don't know how do they
 relate to sdla.c and friend(s).

No idea.

   static const char* version = SDLA driver v0.30, 12 Sep 1996,
  [EMAIL PROTECTED];
 
 1996 doesn't look encouraging but it may be misleading.

Yep.  You could ignore it :) or rm drivers/net/wan/slda*  :)

---
~Randy
-
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

[PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost

On Sat, 10 Jun 2006 14:11:42 +0200 (MEST) Mikael Pettersson wrote:

 While compiling 2.6.17-rc6 for a 486 with an NE2000 ISA ethernet card, I got:
 
 WARNING: drivers/net/ne.o - Section mismatch: reference to 
 .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
 0x158) and 'ne_block_input'
 WARNING: drivers/net/ne.o - Section mismatch: reference to 
 .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
 0x176) and 'ne_block_input'
 WARNING: drivers/net/ne.o - Section mismatch: reference to 
 .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
 0x183) and 'ne_block_input'
 WARNING: drivers/net/ne.o - Section mismatch: reference to 
 .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
 0x1ea) and 'ne_block_input'
 WARNING: drivers/net/ne.o - Section mismatch: reference to 
 .init.data:isapnp_clone_list from .text between 'init_module' (at offset 
 0x251) and 'ne_block_input'
 WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from 
 .text between 'init_module' (at offset 0x266) and 'ne_block_input'
 WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from 
 .text between 'init_module' (at offset 0x29b) and 'ne_block_input'
 
 Not sure how serious this is; the driver seems to work fine later on.

Doesn't look serious.  init_module() is not __init, but it calls
some __init functions and touches some __initdata.

BTW, I would be happy to see some consistent results from modpost
section checking.  I don't see all of these warnings (I see only 1)
when using gcc 3.3.6.  What gcc version are you using?
Does that matter?  (not directed at anyone in particular)

Patch below fixes it for me.  Please test/report.
---

From: Randy Dunlap [EMAIL PROTECTED]

Fix section mismatch warnings:
WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from 
.text between 'init_module' (at offset 0x396) and 'cleanup_card'
WARNING: drivers/net/ne2.o - Section mismatch: reference to .init.text: from 
.text between 'init_module' (at offset 0x483) and 'cleanup_card'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/ne.c  |2 +-
 drivers/net/ne2.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2617-rc6.orig/drivers/net/ne.c
+++ linux-2617-rc6/drivers/net/ne.c
@@ -829,7 +829,7 @@ that the ne2k probe is the last 8390 bas
 is at boot) and so the probe will get confused by any other 8390 cards.
 ISA device autoprobes on a running machine are not recommended anyway. */
 
-int init_module(void)
+int __init init_module(void)
 {
int this_dev, found = 0;
 
--- linux-2617-rc6.orig/drivers/net/ne2.c
+++ linux-2617-rc6/drivers/net/ne2.c
@@ -780,7 +780,7 @@ MODULE_PARM_DESC(bad, (ignored));
 
 /* Module code fixed by David Weinehall */
 
-int init_module(void)
+int __init init_module(void)
 {
struct net_device *dev;
int this_dev, found = 0;
-
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

[PATCH] hp ethernet: fix section mismatches

From: Randy Dunlap [EMAIL PROTECTED]

Priority: not critical; makes init code discardable.

Fix section mismatch warnings:
WARNING: drivers/net/hp-plus.o - Section mismatch: reference to .init.text: 
from .text between 'init_module' (at offset 0x387) and 'cleanup_card'
WARNING: drivers/net/hp.o - Section mismatch: reference to .init.data: from 
.text between 'hp_init_card' (at offset 0x310) and 'init_module'
WARNING: drivers/net/hp.o - Section mismatch: reference to .init.text: from 
.text between 'init_module' (at offset 0x367) and 'cleanup_card'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/hp-plus.c |2 +-
 drivers/net/hp.c  |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2617-rc6.orig/drivers/net/hp-plus.c
+++ linux-2617-rc6/drivers/net/hp-plus.c
@@ -446,7 +446,7 @@ MODULE_LICENSE(GPL);
 
 /* This is set up so that only a single autoprobe takes place per call.
 ISA device autoprobes on a running machine are not recommended. */
-int
+int __init
 init_module(void)
 {
struct net_device *dev;
--- linux-2617-rc6.orig/drivers/net/hp.c
+++ linux-2617-rc6/drivers/net/hp.c
@@ -384,7 +384,7 @@ hp_block_output(struct net_device *dev, 
 }
 
 /* This function resets the ethercard if something screws up. */
-static void
+static void __init
 hp_init_card(struct net_device *dev)
 {
int irq = dev-irq;
@@ -409,7 +409,7 @@ MODULE_LICENSE(GPL);
 
 /* This is set up so that only a single autoprobe takes place per call.
 ISA device autoprobes on a running machine are not recommended. */
-int
+int __init
 init_module(void)
 {
struct net_device *dev;


---
-
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

[PATCH] smc ethernet: fix section mismatch warnings

From: Randy Dunlap [EMAIL PROTECTED]

Priority: not critical; makes init code discardable.
Removes one duplicate assignment.

Fix section mismatch warnings:
WARNING: drivers/net/smc-ultra.o - Section mismatch: reference to .init.text: 
from .text between 'init_module' (at offset 0x369) and 'cleanup_card'
WARNING: drivers/net/smc-ultra32.o - Section mismatch: reference to 
.init.text:ultra32_probe from .text between 'init_module' (at offset 0x254) and 
'cleanup_module'
WARNING: drivers/net/smc9194.o - Section mismatch: reference to 
.init.text:smc_init from .text between 'init_module' (at offset 0x997) and 
'cleanup_module'
WARNING: drivers/net/smc9194.o - Section mismatch: reference to .init.data: 
from .data between 'smcdev.0' (at offset 0x44) and '__param_str_io'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/smc-ultra.c   |2 +-
 drivers/net/smc-ultra32.c |2 +-
 drivers/net/smc9194.c |7 ++-
 3 files changed, 4 insertions(+), 7 deletions(-)

--- linux-2617-rc6.orig/drivers/net/smc-ultra.c
+++ linux-2617-rc6/drivers/net/smc-ultra.c
@@ -553,7 +553,7 @@ MODULE_LICENSE(GPL);
 
 /* This is set up so that only a single autoprobe takes place per call.
 ISA device autoprobes on a running machine are not recommended. */
-int
+int __init
 init_module(void)
 {
struct net_device *dev;
--- linux-2617-rc6.orig/drivers/net/smc-ultra32.c
+++ linux-2617-rc6/drivers/net/smc-ultra32.c
@@ -421,7 +421,7 @@ static struct net_device *dev_ultra[MAX_
 MODULE_DESCRIPTION(SMC Ultra32 EISA ethernet driver);
 MODULE_LICENSE(GPL);
 
-int init_module(void)
+int __init init_module(void)
 {
int this_dev, found = 0;
 
--- linux-2617-rc6.orig/drivers/net/smc9194.c
+++ linux-2617-rc6/drivers/net/smc9194.c
@@ -732,12 +732,9 @@ static int ifport;
 struct net_device * __init smc_init(int unit)
 {
struct net_device *dev = alloc_etherdev(sizeof(struct smc_local));
-   static struct devlist *smcdev = smc_devlist;
+   struct devlist *smcdev = smc_devlist;
int err = 0;
 
-#ifndef NO_AUTOPROBE
-   smcdev = smc_devlist;
-#endif
if (!dev)
return ERR_PTR(-ENODEV);
 
@@ -1607,7 +1604,7 @@ MODULE_PARM_DESC(io, SMC 99194 I/O base
 MODULE_PARM_DESC(irq, SMC 99194 IRQ number);
 MODULE_PARM_DESC(ifport, SMC 99194 interface port (0-default, 1-TP, 2-AUI));
 
-int init_module(void)
+int __init init_module(void)
 {
if (io == 0)
printk(KERN_WARNING


---
-
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: Updated sysctl documentation take #2

On Thu, 8 Jun 2006 00:18:06 +0200 Diego Calleja wrote:

 El Wed, 7 Jun 2006 13:06:53 -0700,
 Randy.Dunlap [EMAIL PROTECTED] escribió:
 
  OK, that's all for the README file.  I'll look at the rest of it
  sometime this week.  I don't think that it's quite ready to be merged.
 
 Thank's for your review, altought I didn't though someone was to review
 so deeply a documentation patch ;) I've gone through all the files and
 fixed the 72-col limit and everything I could. I've updated the patch
 http://terra.es/personal/diegocg/sysctl-docs

Here are some more comments for you.

1.  There are quite a few lines (17) ending with ^M (carriage return)
that should be removed.

2.  Lines like this one should end with a period (full stop):

+This file is SPARC-only

3.  I would put this comment near the top of each file, not at
the end:

+PLEASE KEEP THIS FILE ORDERED ALPHABETICALLY.


Other than that, it's looking good to me.

Thanks,
---
~Randy
-
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 5/5] ehea: makefile and Kconfig

On Thu, 08 Jun 2006 11:56:05 +0200 Jan-Bernd Themann wrote:

 Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
 
 
   drivers/net/ehea/Kconfig  |6 ++
   drivers/net/ehea/Makefile |7 +++
   2 files changed, 13 insertions(+)
 
 
 
 --- linux-2.6.16-rc5-orig/drivers/net/ehea/Makefile   1969-12-31 
 16:00:00.0 -0800
 +++ kernel/drivers/net/ehea/Makefile  2006-06-08 01:58:28.839212488 -0700
 @@ -0,0 +1,7 @@
 +#
 +# Makefile for the eHEA ethernet device driver for IBM eServer System p
 +#
 +
 +ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o ehea_phyp.o
 +obj-$(CONFIG_EHEA) += ehea_mod.o
 +
 --- linux-2.6.16-rc5-orig/drivers/net/ehea/Kconfig1969-12-31 
 16:00:00.0 -0800
 +++ kernel/drivers/net/ehea/Kconfig   2006-06-08 01:58:28.842212032 -0700
 @@ -0,0 +1,6 @@
 +config EHEA
 +   tristate eHEA Ethernet support
 +   depends on IBMEBUS
 +   ---help---
 +   This driver supports the IBM pSeries ethernet adapter
 +

Hi,
Will you be modifying drivers/net/Makefile and drivers/net/Kconfig
to use these files?

And help text is normally indented (convention is 2 spaces)
since (from Documentation/kbuild/kconfig-language.txt):

  The end of the help text is determined by
  the indentation level, this means it ends at the first line which has
  a smaller indentation than the first line of the help text.

---
~Randy
-
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: [RFT] Realtek 8168 ethernet support

On Thu,  1 Jun 2006 21:02:00 +0100 (BST) Daniel Drake wrote:

 I've produced this patch which should allow the r8169 driver to work with the
 new Realtek 8168 chips. These are found in PCI-Express form and onboard some
 newer motherboards.
 
 Does anyone own this hardware? I'm looking for someone to test it before I
 send it on.
 
 Signed-off-by: Daniel Drake [EMAIL PROTECTED]
 
 Index: linux/drivers/net/r8169.c
 ===
 --- linux.orig/drivers/net/r8169.c
 +++ linux/drivers/net/r8169.c
 @@ -184,6 +184,7 @@ static const struct {
  
  static struct pci_device_id rtl8169_pci_tbl[] = {
   { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
 + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
   { PCI_DEVICE(PCI_VENDOR_ID_DLINK,   0x4300), },
   { PCI_DEVICE(0x16ec,0x0116), },
   { PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },


The (GPL) RealTek driver (from
http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=1famid=4series=2003072Software=True)
contains this PCI device table:

static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
{ 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{0,}
};

Any reason not to include all of those?
Conversely, any reason to use the RealTek r1000 driver?


 @@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
   struct net_device *dev;
   struct rtl8169_private *tp;
   int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
 + u32 mmio_base = 0;
  
   assert(ioaddr_out != NULL);
  
 @@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
   }
   }
  
 - /* make sure PCI base addr 1 is MMIO */
 - if (!(pci_resource_flags(pdev, 1)  IORESOURCE_MEM)) {
 - if (netif_msg_probe(tp)) {
 - printk(KERN_ERR PFX
 -region #1 not an MMIO resource, aborting\n);
 - }
 - rc = -ENODEV;
 - goto err_out_mwi;
 + /* find MMIO resource: this varies between 8168 and 8169 */
 + for (i = 0; i  5; i++) {
 + /* check resource type */
 + if (!(pci_resource_flags(pdev, i)  IORESOURCE_MEM))
 + continue;
 +
 + /* check for weird/broken PCI region reporting */
 + if (pci_resource_len(pdev, i)  R8169_REGS_SIZE)
 + continue;
 +
 + mmio_base = pci_resource_start(pdev, i);
 + break;
   }
 - /* check for weird/broken PCI region reporting */
 - if (pci_resource_len(pdev, 1)  R8169_REGS_SIZE) {
 +
 + if (mmio_base == 0) {
   if (netif_msg_probe(tp)) {
   printk(KERN_ERR PFX
 -Invalid PCI region size(s), aborting\n);
 +couldn't find valid MMIO resource, aborting\n);
   }
   rc = -ENODEV;
   goto err_out_mwi;
 @@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
   pci_set_master(pdev);
  
   /* ioremap MMIO region */
 - ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
 + ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
   if (ioaddr == NULL) {
   if (netif_msg_probe(tp))
   printk(KERN_ERR PFX cannot remap MMIO, aborting\n);
 -

---
~Randy
-
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: [RFT] Realtek 8168 ethernet support

On Thu, 08 Jun 2006 22:40:05 -0400 Jeff Garzik wrote:

 Randy.Dunlap wrote:
  Conversely, any reason to use the RealTek r1000 driver?
 
 FWIW, RealTek emailed me about merging r1000.  I suggested that, if the 
 register sets were similar, that r8169 should be updated instead, to 
 preserve compatibility with existing users (and not lose existing work).

Sounds good to me.  I'm not terribly interested in seeing
multiple drivers for the same hardware in the kernel tree.

---
~Randy
-
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

[PATCH] wan/sdla section fixes

From: Randy Dunlap [EMAIL PROTECTED]

Priority: tossup.
netdev-set_config can be called at any time, so these references
to __initdata would be a real problem.
However, problem has not been observed AFAIK.

Fix section mismatch warnings:
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data: 
from .text between 'sdla_set_config' (at offset 0x1b8e) and 'sdla_stats'
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data: 
from .text between 'sdla_set_config' (at offset 0x1e76) and 'sdla_stats'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/wan/sdla.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2617-rc6.orig/drivers/net/wan/sdla.c
+++ linux-2617-rc6/drivers/net/wan/sdla.c
@@ -60,9 +60,9 @@
 
 static const char* version = SDLA driver v0.30, 12 Sep 1996, [EMAIL 
PROTECTED];
 
-static unsigned int valid_port[] __initdata = { 0x250, 0x270, 0x280, 0x300, 
0x350, 0x360, 0x380, 0x390};
+static unsigned int valid_port[] = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360, 
0x380, 0x390};
 
-static unsigned int valid_mem[]  __initdata = {
+static unsigned int valid_mem[] = {
0xA, 0xA2000, 0xA4000, 0xA6000, 
0xA8000, 0xAA000, 0xAC000, 0xAE000, 
 0xB, 0xB2000, 0xB4000, 0xB6000, 
0xB8000, 0xBA000, 0xBC000, 0xBE000,
 0xC, 0xC2000, 0xC4000, 0xC6000, 
0xC8000, 0xCA000, 0xCC000, 0xCE000,


---
-
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 4/4] ehea: Kconfig and Makefile

2006-06-07 Thread Randy.Dunlap

On Wed, 07 Jun 2006 19:06:03 +0200 Jan-Bernd Themann wrote:

 Signed-off-by:  Jan-Bernd Themann [EMAIL PROTECTED]
 
 
 drivers/net/ehea/Kconfig  |6 ++
 drivers/net/ehea/Makefile |   45 +
 2 files changed, 51 insertions(+)
 
 
 
 --- linux-2.6.16-rc5-orig/drivers/net/ehea/Makefile1969-12-31 
 16:00:00.0 -0800
 +++ kernel/drivers/net/ehea/Makefile2006-06-07 07:01:14.634178704 -0700
 @@ -0,0 +1,45 @@
 +# Server eHEA ethernet device driver for Linux on POWER
 +#
 +#
 +#  linux/drivers/net/ehea/Makefile
 +#
 +#  eHEA ethernet device driver for IBM eServer System p
 +#
 +#  (C) Copyright IBM Corp. 2006
 +#
 +#  Authors:
 +#   Christoph Raisch [EMAIL PROTECTED]
 +#   Jan-Bernd Themann [EMAIL PROTECTED]
 +#   Heiko-Joerg Schick [EMAIL PROTECTED]
 +#   Thomas Klein [EMAIL PROTECTED]
 +#
 +#
 +# This program is free software; you can redistribute it and/or modify
 +# it under the terms of the GNU General Public License as published by
 +# the Free Software Foundation; either version 2, or (at your option)
 +# any later version.
 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program; if not, write to the Free Software
 +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 +
 +
 +
 +
 +# To compile module type:
 +# make -C /root/linux-2.6.5-7.244 SUBDIRS=`pwd` V=1 modules CONFIG_EHEA=m
 +# make -C /usr/src/linux-2.6.17-rc5 SUBDIRS=`pwd` V=1 modules CONFIG_EHEA=m
 +
 +ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o ehea_phyp.o
 +
 +obj-$(CONFIG_EHEA) += ehea_mod.o
 +
 +#CFLAGS += -Werror
 +
 +
 +

45 lines for a 5-line makefile.  :(

You need to integrate the Makefile and Kconfig into the upper-level
directory Makefile and Kconfig files.  Don't expect/require people
to enter thing like this:
 +# make -C /root/linux-2.6.5-7.244 SUBDIRS=`pwd` V=1 modules CONFIG_EHEA=m
 +# make -C /usr/src/linux-2.6.17-rc5 SUBDIRS=`pwd` V=1 modules CONFIG_EHEA=m


 --- linux-2.6.16-rc5-orig/drivers/net/ehea/Kconfig1969-12-31 
 16:00:00.0 -0800
 +++ kernel/drivers/net/ehea/Kconfig2006-06-07 07:01:14.637178248 -0700
 @@ -0,0 +1,6 @@
 +config EHEA
 +   tristate eHEA Ethernet support
 +   depends on IBMEBUS
 +   ---help---
 +   This driver supports the IBM pSeries
 +   Ethernet adapter

That last sentence can be on one line, please.

---
~Randy
-
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: Updated sysctl documentation take #2

2006-06-07 Thread Randy.Dunlap

On Wed, 7 Jun 2006 20:53:16 +0200 Diego Calleja wrote:

 Since people didn't like the many small files approach, I've moved
 it to directories containing index.txt files:
 
 Documentation/sysctl/vm/index.txt
 Documentation/sysctl/net/core/index.txt
 Documentation/sysctl/net/unix/index.txt
 Documentation/sysctl/net/ipv4/index.txt
 Documentation/sysctl/net/ipv4/conf/index.txt
 Documentation/sysctl/net/ipv4/route/index.txt
 Documentation/sysctl/net/ipv4/neigh/index.txt
 
 and so on.
 
 As previously, this moves all sysctl documentation (including
 XFS and network) to Documentation/sysctl/*. The patch is
 against linus tree and weights more than 200K in size
 and is place at: http://www.terra.es/personal/diegocg/sysctl-docs

~ diffstat -p1 -w 70 sysctl-docs 
 Documentation/filesystems/proc.txt| 1210 
 Documentation/filesystems/xfs.txt |   84 -
 Documentation/networking/00-INDEX |2 
 Documentation/networking/Configurable |2 
 Documentation/networking/decnet.txt   |4 
 Documentation/networking/ip-sysctl.txt|  899 ---
 Documentation/networking/xfrm_sync.txt|   11 
 Documentation/sysctl/README   |  121 -
 Documentation/sysctl/abi.txt  |   54 
 Documentation/sysctl/abi/index.txt|   49 
 Documentation/sysctl/dev/README   |2 
 Documentation/sysctl/fs.txt   |  150 -
 Documentation/sysctl/fs/index.txt |  240 +++
 Documentation/sysctl/fs/xfs/index.txt |  170 ++
 Documentation/sysctl/kernel.txt   |  344 
 Documentation/sysctl/kernel/index.txt |  628 
 Documentation/sysctl/net/README   |8 
 Documentation/sysctl/net/appletalk/index.txt  |   38 
 Documentation/sysctl/net/bridge/index.txt |   44 
 Documentation/sysctl/net/core/index.txt   |  115 +
 Documentation/sysctl/net/ipv4/conf/index.txt  |  270 +++
 Documentation/sysctl/net/ipv4/index.txt   |  739 +
 Documentation/sysctl/net/ipv4/neigh/index.txt |  138 +
 Documentation/sysctl/net/ipv4/route/index.txt |  143 +
 Documentation/sysctl/net/ipv6/conf/index.txt  |  256 +++
 Documentation/sysctl/net/ipv6/icmp/index.txt  |   15 
 Documentation/sysctl/net/ipv6/index.txt   |   65 
 Documentation/sysctl/net/ipv6/neigh/index.txt |  134 +
 Documentation/sysctl/net/ipv6/route/index.txt |   78 +
 Documentation/sysctl/net/unix/index.txt   |   15 
 Documentation/sysctl/sunrpc.txt   |   20 
 Documentation/sysctl/sunrpc/index.txt |   64 
 Documentation/sysctl/vm.txt   |  180 --
 Documentation/sysctl/vm/index.txt |  334 
 Documentation/sysrq.txt   |   20 
 35 files changed, 3611 insertions(+), 3035 deletions(-)
I don't know how long it takes to review such a large patch, but
I'll continue to do so.  For now:

README:

1. +Documentation for /proc/sys/, aka. sysctl

a.k.a. or just aka.  Not aka..  or spell it out, or omit it,
maybe like:

Documentation for /proc/sys/ (sysctl)

2.  Limit lines to max. of 80 characters, but around 70-72 is better
IMO.  That allows someone to make minor corrections without having
to fudge the lines around.

3.  +This means there're several parameters
use there are

4.  +are: enabling or disabling forwading in a certain network interface
forwarding

5.  +is also used to export some stadistic information, ej: some
statistic or statistics or statistical
ej: ??  use e.g.: (preferred) or eg:

6.  +can be read but can _not_ be written.
_cannot_

7.  +own program to read them aswell)
as well)

8.  +to change '/' by '.' and ignore the '/proc/sys' part of the path, ie
s/by/to/
s/ie/i.e./

9.  +means that any tweak that you do will be lost the next time you restart  
your
* collapse 2 spaces to 1

10. +_VERY_ DANGEROUS and can ruin the performance performance,
drop one performance

11. +As a quick 'ls /proc/sys' will show, the directory consists of several 
subdirs.
+Each subdir is mainly about one part of the kernel, so you can do configuration

Spell out subdirectories and subdirectory.

12. +fs/specific filesystems filehandle, inode, dentry and 
quota tuning

insert : after filesystems


OK, that's all for the README file.  I'll look at the rest of it
sometime this week.  I don't think that it's quite ready to be merged.

---
~Randy
-
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: new driver for IBM ethernet chip

2006-06-02 Thread Randy.Dunlap

On Fri, 2 Jun 2006 13:02:37 +0200 Christoph Raisch wrote:

 We're currently developing a new Ethernet device driver for a 10G IBM chip
 for System p. (ppc64)
 
 A later version of the driver should end up in mainline kernel.
 How should we proceed to get first comments by the community?
 Either post this code as a patch to netdev or
yes

 put a full tarball on for example sourceforge?
nope.

Please read and observe:  Documentation/SubmittingPatches
and Section 3 of it, References, for other sources of
expectations/requirements.

The -mm tree also contains Documentation/SubmitChecklist
that you may find useful.

---
~Randy
-
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

[PATCH] arlan: fix section mismatch warnings

2006-05-25 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Fix section mismatch warnings:
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.init.text:arlan_probe from .text between 'init_module' (at offset
0x3526) and 'cleanup_module'
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.init.text:init_arlan_proc from .text between 'init_module' (at offset
0x3539) and 'cleanup_module'
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.exit.text:cleanup_arlan_proc from .text between 'cleanup_module' (at
offset 0x356c) and 'arlan_diagnostic_info_string'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/wireless/arlan-main.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2617-rc5.orig/drivers/net/wireless/arlan-main.c
+++ linux-2617-rc5/drivers/net/wireless/arlan-main.c
@@ -1838,7 +1838,7 @@ struct net_device * __init arlan_probe(i
 }
 
 #ifdef  MODULE
-int init_module(void)
+int __init init_module(void)
 {
int i = 0;
 
@@ -1860,7 +1860,7 @@ int init_module(void)
 }
 
 
-void cleanup_module(void)
+void __exit cleanup_module(void)
 {
int i = 0;
struct net_device *dev;


---
-
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

[PATCH] wavelan: fix section mismatch

2006-05-25 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Fix section mismatch warning:
WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
.init.text: from .text between 'init_module' (at offset 0x371e) and
'cleanup_module'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/wireless/wavelan.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2617-rc5.orig/drivers/net/wireless/wavelan.c
+++ linux-2617-rc5/drivers/net/wireless/wavelan.c
@@ -4306,7 +4306,7 @@ out:
  * Insertion of the module
  * I'm now quite proud of the multi-device support.
  */
-int init_module(void)
+int __init init_module(void)
 {
int ret = -EIO; /* Return error if no cards found */
int i;


---
-
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] wavelan: fix section mismatch

2006-05-25 Thread Randy.Dunlap

On Thu, 25 May 2006 11:39:49 -0700 Jean Tourrilhes wrote:

 On Thu, May 25, 2006 at 11:09:21AM -0700, Randy.Dunlap wrote:
  From: Randy Dunlap [EMAIL PROTECTED]
  
  Fix section mismatch warning:
  WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
  .init.text: from .text between 'init_module' (at offset 0x371e) and
  'cleanup_module'
  
  Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
 
   I did not check that kernel, but it seems a no brainer. Would
 you mind sending to John Linville or Jeff Garzik as I'm about to go on
 vacvation.
   Thanks !
 
   Jean

Hi, John L. was copied on the patch.

Thanks, have a nice vacation.

---
~Randy
-
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/4] myri10ge - Driver header files

2006-05-17 Thread Randy.Dunlap

On Wed, 17 May 2006 18:04:35 -0400 Brice Goglin wrote:

 [PATCH 2/4] myri10ge - Driver header files
 
  myri10ge_mcp.h|  205 
 ++
  myri10ge_mcp_gen_header.h |   58 +

Please use diffstat -p 1 -w 70 is documented in
Documentation/SubmittingPatches.

  2 files changed, 263 insertions(+)
 
 --- /dev/null 2006-05-16 20:08:50.920483500 +0200
 +++ linux-tmp//drivers/net/myri10ge/myri10ge_mcp.h2006-05-17 
 11:02:48.0 +0200
 @@ -0,0 +1,205 @@
 +#ifndef __MYRI10GE_MCP_H__
 +#define __MYRI10GE_MCP_H__
 +
 +#define MYRI10GE_MCP_VERSION_MAJOR   1
 +#define MYRI10GE_MCP_VERSION_MINOR   4
 +
 +/* 16 Bytes */

What is 16 bytes here?

 +struct mcp_slot {
 + u16 checksum;
 + u16 length;
 +};


---
~Randy
-
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: [RFC] changing value of NETDEV_ALIGN to cacheline size

2006-05-15 Thread Randy.Dunlap

On Mon, 15 May 2006 14:08:29 +0200 Christian Borntraeger wrote:

 while digging through the alloc_netdev function I asked myself why there is a
 fixed alignment for netdevices. Is there a special reason for choosing 32? If
 yes, I suggest to add a comment to the definition. 
 
 If not, I suspect cacheline alignment might be beneficial:
 struct net_device contains several variables which are cache aligned 
 (poll_list, queue_lock .). As far as I can see, the compiler tries to 
 increase the size of the structure to make that possible, but expects the
 whole structure to be aligned to cache line size as well. With the current
 value for NETDEV_ALIGN we dont align struct net_device to the cache line,
 instead we align it to 32 bytes. That means that poll_list, queue_lock and 
 friends are not always cache aligned, but 32 bytes aligned.
 
 The only reason why everything worked so far is the slab allocator design, 
 which gives us a page aligned struct net_device in most cases. I think we 
 should not rely on the behaviour of the memory allocator and use a different 
 value for NETDEV_ALIGN instead. Any comments or corrections?
 
 cheers Christian
 
 
 
 The patch below is compile and boot tested on s390 and x86.
 
 Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
 
 include/linux/netdevice.h |2 +-
 net/core/dev.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 --
 
 --- a/include/linux/netdevice.h   4 Apr 2006 07:25:47 -
 +++ b/include/linux/netdevice.h   15 May 2006 11:06:05 -
 @@ -504,7 +504,7 @@
   struct class_device class_dev;
  };
  
 -#define  NETDEV_ALIGN32
 +#define  NETDEV_ALIGNL1_CACHE_BYTES
  #define  NETDEV_ALIGN_CONST  (NETDEV_ALIGN - 1)

I don't know about the fixed value of 32, but if this patch is
accepted, I'd prefer NETDEV_ALIGN_MASK instead of NETDEV_ALIGN_CONST.

  static inline void *netdev_priv(struct net_device *dev)
 --- a/net/core/dev.c  4 Apr 2006 07:25:50 -
 +++ b/net/core/dev.c  15 May 2006 11:06:05 -
 @@ -2986,7 +2986,7 @@
   struct net_device *dev;
   int alloc_size;
  
 - /* ensure 32-byte alignment of both the device and private area */
 + /* ensure cacheline alignment of both the device and private area */
   alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST)  ~NETDEV_ALIGN_CONST;
   alloc_size += sizeof_priv + NETDEV_ALIGN_CONST;

---
~Randy
-
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] Documentation: add missing operstates.txt

2006-05-12 Thread Randy.Dunlap

On Sun, 7 May 2006 12:18:59 +0200 Stefan Rompf wrote:

 Hi,
 
 seems documentation got lost when the RFC2863-patch was applied. Having
 documentation is good, so I resend it ;-)

I have a few comments/questions about this.

 --- /dev/null 2005-03-19 20:36:14.0 +0100
 +++ linux-2.6.17-rc3/Documentation/networking/operstates.txt  2006-04-27 
 22:15:23.0 +0200
 @@ -0,0 +1,161 @@
 +
 +1. Introduction
 +
 +Linux distinguishes between administrative and operational state of an
 +interface. Admininstrative state is the result of ip link set dev
 +dev up or down and reflects whether the administrator wants to use
 +the device for traffic.
 +
 +However, an interface is not usable just because the admin enabled it

Put hyphen/dash at end of previous line, not on next line.

 +- ethernet requires to be plugged into the switch and, depending on

2 small items here, one grammar and the other is that 'switch'
isn't always the link partner device.  so maybe:

ethernet requires a physical link partner and, depending on

 +a site's networking policy and configuration, an 802.1X authentication
 +to be performed before user data can be transferred. Operational state
 +shows the ability of an interface to transmit this user data.
 +
 +Thanks to 802.1X, userspace must be granted the possibility to
 +influence operational state. To accommodate this, operational state is
 +split into two parts: Two flags that can be set by the driver only, and
 +a RFC2863 compatible state that is derived from these flags, a policy,
 +and changeable from userspace under certain rules.
 +
 +
 +2. Querying from userspace
 +
 +Both admin and operational state can be queried via the netlink
 +operation RTM_GETLINK. It is also possible to subscribe to RTMGRP_LINK
 +to be notified of updates. This is important for setting from userspace.
 +
 +These values contain interface state:
 +
 +ifinfomsg::if_flags  IFF_UP:
 + Interface is admin up
 +ifinfomsg::if_flags  IFF_RUNNING:
 + Interface is in RFC2863 operational state UP or UNKNOWN. This is for
 + backward compatibility, routing daemons, dhcp clients can use this
 + flag to determine whether they should use the interface.
 +ifinfomsg::if_flags  IFF_LOWER_UP:
 + Driver has signaled netif_carrier_on()
 +ifinfomsg::if_flags  IFF_DORMANT:
 + Driver has signaled netif_dormant_on()

Could above list have more spacing added for readability?

 +These interface flags can also be queried without netlink using the
 +SIOCGIFFLAGS ioctl.
 +
 +TLV IFLA_OPERSTATE
 +
 +contains RFC2863 state of the interface in numeric representation:
 +
 +IF_OPER_UNKNOWN (0):
 + Interface is in unknown state, neither driver nor userspace has set
 + operational state. Interface must be considered for user data as
 + setting operational state has not been implemented in every driver.
 +IF_OPER_NOTPRESENT (1):
 + Unused in current kernel (notpresent interfaces normally disappear),
 + just a numerical placeholder.
 +IF_OPER_DOWN (2):
 + Interface is unable to transfer data on L1, f.e. ethernet is not
 + plugged or interface is ADMIN down.

maybe:
ethernet is not plugged in
or
ethernet is not connected
or
ethernet is not physically connected

Also, is f.e. well known to mean for example?
I think that I see e.g. more often than f.e. and I prefer
e.g..

 +IF_OPER_LOWERLAYERDOWN (3):
 + Interfaces stacked on an interface that is IF_OPER_DOWN show this
 + state (f.e. VLAN).
 +IF_OPER_TESTING (4):
 + Unused in current kernel.
 +IF_OPER_DORMANT (5):
 + Interface is L1 up, but waiting for an external event, f.e. for a
 + protocol to establish. (802.1X)
 +IF_OPER_UP (6):
 + Interface is operational up and can be used.
 +
 +This TLV can also be queried via sysfs.

What is TLV?

 +TLV IFLA_LINKMODE
 +
 +contains link policy. This is needed for userspace interaction
 +described below.
 +
 +This TLV can also be queried via sysfs.
 +
 +
 +3. Kernel driver API
 +
 +Kernel drivers have access to two flags that map to IFF_LOWER_UP and
 +IFF_DORMANT. These flags can be set from everywhere, even from
 +interrupts. It is guaranteed that only the driver has write access,
 +however, if different layers of the driver manipulate the same flag,
 +the driver has to provide the synchronisation needed.
 +
 +__LINK_STATE_NOCARRIER, maps to !IFF_LOWER_UP:
 +
 +The driver uses netif_carrier_on() to clear and netif_carrier_off() to
 +set this flag. On netif_carrier_off(), the scheduler stops sending
 +packets. The name 'carrier' and the inversion are historical, think of
 +it as lower layer.
 +
 +netif_carrier_ok() can be used to query that bit.
 +
 +__LINK_STATE_DORMANT, maps to IFF_DORMANT:
 +
 +Set by the driver to express that the device cannot yet be used
 +because some driver controlled protocol establishment has to
 +complete. Corresponding functions are netif_dormant_on() to set the
 +flag, netif_dormant_off() to clear it and netif_dormant() to query.
 +
 +On device allocation, networking core sets the flags equivalent to
 +netif_carrier_ok()

Re: [PATCH] irda-usb: use NULL instead of 0

2006-05-01 Thread Randy.Dunlap


 I could be mistaken, but wasn't the usb_control_msg timeout type changed in 
 kernel 2.6.12?
 The timeout value is no longer in jiffies but in msecs.

ugh, correct.  Here's a new patch.
Thanks.

---
From: Randy Dunlap [EMAIL PROTECTED]

Use NULL instead of 0 for a null pointer value (sparse warning):
drivers/net/irda/irda-usb.c:1781:30: warning: Using plain integer as NULL 
pointer

Correct timeout argument to use milliseconds instead of jiffies.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/irda/irda-usb.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2617-rc3.orig/drivers/net/irda/irda-usb.c
+++ linux-2617-rc3/drivers/net/irda/irda-usb.c
@@ -1778,7 +1778,7 @@ static int irda_usb_probe(struct usb_int
 
if (self-needspatch) {
ret = usb_control_msg (self-usbdev, usb_sndctrlpipe 
(self-usbdev, 0),
-  0x02, 0x40, 0, 0, 0, 0, 
msecs_to_jiffies(500));
+  0x02, 0x40, 0, 0, NULL, 0, 500);
if (ret  0) {
IRDA_DEBUG (0, usb_control_msg failed %d\n, ret);
goto err_out_3;
-
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] compile error in ieee80211_ioctl.c

2006-04-23 Thread Randy.Dunlap

On Sun, 23 Apr 2006 17:26:39 -0700 (PDT) Alex Davis wrote:

 Hello:
 
 I cloned 
 git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
 last night and got compile errors while compiling net/d80211/ieee80211_ioctl.c
 into a module. This patch fixes it.
 
 Signed-off-by: Alex Davis [EMAIL PROTECTED]
 
 diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
 index 42a7abe..4949e52 100644
 --- a/net/d80211/ieee80211_ioctl.c
 +++ b/net/d80211/ieee80211_ioctl.c
 @@ -30,7 +30,7 @@ #include aes_ccm.h
  
  
  static int ieee80211_regdom = 0x10; /* FCC */
 -MODULE_PARM(ieee80211_regdom, i);
 +module_param(ieee80211_regdom, int, 0x10);
  MODULE_PARM_DESC(ieee80211_regdom, IEEE 802.11 regulatory domain; 64=MKK);

The last parameter of module_param() is a permission value, not
an init value.  The int is already initialized above.
Typical permission values are 0, 0444, 0644, ... (octal,
or use the available #defines).

  /*
 @@ -40,7 +40,7 @@ MODULE_PARM_DESC(ieee80211_regdom, IEEE
   * module.
   */
  static int ieee80211_japan_5ghz /* = 0 */;
 -MODULE_PARM(ieee80211_japan_5ghz, i);
 +module_param(ieee80211_japan_5ghz, int, 0);
  MODULE_PARM_DESC(ieee80211_japan_5ghz, Vendor-updated firmware for 5 GHz);

---
~Randy
-
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.17-rc1] Fix RtNetlink ENCODE security permissions

2006-04-14 Thread Randy.Dunlap

On Fri, 14 Apr 2006 10:47:26 -0700 Jean Tourrilhes wrote:

   Hi John,
 
   I've just realised that the RtNetlink code does not check the
 permission for SIOCGIWENCODE and SIOCGIWENCODEEXT, which means that
 any user can read the encryption keys. The fix is trivial and should
 go in 2.6.17 alonside the two other patch I sent you last week.
   Fully tested on 2.6.17-rc1.

and for -stable ??

   Have fun...
 
   Jean
 
 Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]
 
 ---
 
 diff -u -p linux/net/core/wireless.j1.c linux/net/core/wireless.c
 --- linux/net/core/wireless.j1.c  2006-04-13 18:29:49.0 -0700
 +++ linux/net/core/wireless.c 2006-04-13 18:35:59.0 -0700
 @@ -1726,6 +1726,14 @@ int wireless_rtnetlink_get(struct net_de
   if(!IW_IS_GET(request-cmd))
   return -EOPNOTSUPP;
  
 + /* If command is `get the encoding parameters', check if
 +  * the user has the right to do it */
 + if (request-cmd == SIOCGIWENCODE ||
 + request-cmd == SIOCGIWENCODEEXT) {
 + if (!capable(CAP_NET_ADMIN))
 + return -EPERM;
 + }
 +
   /* Special cases */
   if(request-cmd == SIOCGIWSTATS)
   /* Get Wireless Stats */
 
 -
 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
 


---
~Randy
-
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

[PATCH] bcm43 wireless: fix printk format warnings

2006-04-11 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Fix printk format warnings:
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:456: warning: format ‘%u’ 
expects type ‘unsigned int’, but argument 3 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:460: warning: format ‘%08x’ 
expects type ‘unsigned int’, but argument 2 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:476: warning: format ‘%u’ 
expects type ‘unsigned int’, but argument 3 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:480: warning: format ‘%08x’ 
expects type ‘unsigned int’, but argument 2 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:200: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:311: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:733: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |8 
 drivers/net/wireless/bcm43xx/bcm43xx_dma.c |   13 +++--
 2 files changed, 11 insertions(+), 10 deletions(-)

--- linux-2617-rc1g5.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ linux-2617-rc1g5/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -196,8 +196,9 @@ static int alloc_ringmemory(struct bcm43
}
if (ring-dmabase + BCM43xx_DMA_RINGMEMSIZE  BCM43xx_DMA_BUSADDRMAX) {
printk(KERN_ERR PFX FATAL ERROR  DMA RINGMEMORY 1G 
-   (0x%08x, len: %lu)\n,
-  ring-dmabase, BCM43xx_DMA_RINGMEMSIZE);
+   (0x%llx, len: %lu)\n,
+   (unsigned long long)ring-dmabase,
+   BCM43xx_DMA_RINGMEMSIZE);
dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
  ring-vbase, ring-dmabase);
return -ENOMEM;
@@ -307,8 +308,8 @@ static int setup_rx_descbuffer(struct bc
unmap_descbuffer(ring, dmaaddr, ring-rx_buffersize, 0);
dev_kfree_skb_any(skb);
printk(KERN_ERR PFX FATAL ERROR  DMA RX SKB 1G 
-   (0x%08x, len: %u)\n,
-  dmaaddr, ring-rx_buffersize);
+   (0x%llx, len: %u)\n,
+   (unsigned long long)dmaaddr, ring-rx_buffersize);
return -ENOMEM;
}
meta-skb = skb;
@@ -729,8 +730,8 @@ static int dma_tx_fragment(struct bcm43x
if (unlikely(meta-dmaaddr + skb-len  BCM43xx_DMA_BUSADDRMAX)) {
return_slot(ring, slot);
printk(KERN_ERR PFX FATAL ERROR  DMA TX SKB 1G 
-   (0x%08x, len: %u)\n,
-  meta-dmaaddr, skb-len);
+   (0x%llx, len: %u)\n,
+   (unsigned long long)meta-dmaaddr, skb-len);
return -ENOMEM;
}
 
--- linux-2617-rc1g5.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ linux-2617-rc1g5/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -452,12 +452,12 @@ void bcm43xx_printk_dump(const char *dat
size_t i;
char c;
 
-   printk(KERN_INFO PFX Data dump (%s, %u bytes):,
+   printk(KERN_INFO PFX Data dump (%s, %zd bytes):,
   description, size);
for (i = 0; i  size; i++) {
c = data[i];
if (i % 8 == 0)
-   printk(\n KERN_INFO PFX 0x%08x:  0x%02x, , i, c  
0xff);
+   printk(\n KERN_INFO PFX 0x%08zx:  0x%02x, , i, c  
0xff);
else
printk(0x%02x, , c  0xff);
}
@@ -472,12 +472,12 @@ void bcm43xx_printk_bitdump(const unsign
int j;
const unsigned char *d;
 
-   printk(KERN_INFO PFX *** Bitdump (%s, %u bytes, %s) ***,
+   printk(KERN_INFO PFX *** Bitdump (%s, %zd bytes, %s) ***,
   description, bytes, msb_to_lsb ? MSB to LSB : LSB to MSB);
for (i = 0; i  bytes; i++) {
d = data + i;
if (i % 8 == 0)
-   printk(\n KERN_INFO PFX 0x%08x:  , i);
+   printk(\n KERN_INFO PFX 0x%08zx:  , i);
if (msb_to_lsb) {
for (j = 7; j = 0; j--) {
if (*d  (1  j))


---
-
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

[PATCH] bcm43: fix config menu alignment

2006-04-11 Thread Randy.Dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Use depends on to make all bcm43 driver options be listed
at the same level.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/wireless/bcm43xx/Kconfig |3 +++
 1 files changed, 3 insertions(+)

--- linux-2617-rc1g5.orig/drivers/net/wireless/bcm43xx/Kconfig
+++ linux-2617-rc1g5/drivers/net/wireless/bcm43xx/Kconfig
@@ -17,8 +17,11 @@ config BCM43XX_DEBUG
 
 config BCM43XX_DMA
bool
+   depends on BCM43XX
+
 config BCM43XX_PIO
bool
+   depends on BCM43XX
 
 choice
prompt BCM43xx data transfer mode


---
-
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: 2.4.32: unresolved symbol unregister_qdisc

2006-04-09 Thread Randy.Dunlap

On Sun, 9 Apr 2006 22:05:33 -0400 (EDT) George P Nychis wrote:

 
  On Sun, 9 Apr 2006 13:37:25 -0400 (EDT) George P Nychis wrote:
  
  Thanks for the help.
  
  Here is the makefile: http://rafb.net/paste/results/auchPH75.html
  
  And here is the full errors I receive: 
  http://rafb.net/paste/results/Qplpqw74.html
  
  Greatly appreciate it
  
  - George
  
  [repeat: please don't top-post]
  
  I don't know how much I can help you.  It's been a long time since I've
  built external modules on 2.4.x.
  
  Problems that I see: - the Makefile does not use the expected 2.4 kernel
  build infrastructure; - kernel Makefile uses -nostdinc to prevent use of
  userspace headers; - Makefile is trying to include userspace headers
  instead of kernel headers, e.g.: In file included from
  /usr/include/linux/if_ether.h:107, from /usr/include/linux/netdevice.h:29,
   from sch_xcp.c:8: - this specified include directory is only in 2.6.x,
  not 2.4.x: -I/lib/modules/`uname -r`/build/include/asm/mach-default
  
  It's not clear to me how this makefile could work with 2.4.x at all. Is it
  supposed to, or that's just what you want to see it do?
  
  You could try to fix the Makefile based on makefile-changes articles at
  lwn.net. E.g.: http://lwn.net/Articles/151784/ 
  http://lwn.net/Articles/79984/ http://lwn.net/Articles/74767/ 
  http://lwn.net/Articles/69148/ http://lwn.net/Articles/21823/
  
  
  
  On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:
  
  Yeah, this module is unfortunately not under the GPL, it was made
  for research and i am not the author, I was only given the code for
  my own research.
  
  I enabled that support in the kernel, and then tried to recompile
  and get tons of errors/warnings... so maybe I am missing something
  else to be enabled in the kernel... here are a few examples of
  errors: /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such
  file or directory /usr/include/asm/irq.h:16:25: irq_vectors.h: No
  such file or directory /usr/include/linux/irq.h:72: error: `NR_IRQS'
  undeclared here (not in a function) /usr/include/asm/hw_irq.h:28:
  error: `NR_IRQ_VECTORS' undeclared here (not in a function)
  
  I think those are the top most errors, so if i can fix those
  hopefully the rest shall vanish!
  
  Looks like a Makefile problem then.  Can you post the Makefile?
  Hopefully it is using a Makefile and not just an elaborate gcc command
  line.
  
  [and please don't top-post]
  
  - George
  
  
  From: George P Nychis [EMAIL PROTECTED] Date: Sat, 8 Apr 2006 
  18:47:34 -0400 (EDT)
  
  Hey,
  
  I have a kernel module that uses unregister_qdisc and 
  register_qdisc, whenever i try to insert the module I get: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved
  symbol unregister_qdisc
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved
  symbol register_qdisc
  
  Am i missing some sort of support in the kernel?
  
  Make sure CONFIG_NET_SCHED is enabled and that you compiled your 
  module against that kernel.
  
  Where does this sch_xcp come from?  It's not in the vanilla
  sources.
  
  Also, please direct networking questions to the 
  netdev@vger.kernel.org mailing list which I have added to the
  CC:.
  
  --- ~Randy
  
  
 
 By the way, if I add -I/usr/src/linux/include to the compile line, it 
 successfully compiles, however, i am back to the start:
 lanthanum-ini src-1.0.1 # insmod sch_xcp
 Using /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o
 /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
 /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
 unregister_qdisc
 /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
 /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
 register_qdisc

Yet your 2.4.32 kernel image file does have those symbols in it?
Can you verify that by using 'nm' on the kernel image file?

If so, then I suppose that you'll need to make a small module test case
that exhibits this behavior, or just tell us where to get the sch_xcp files...

(re-added cc: for netdev)

---
~Randy
-
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: 2.4.32: unresolved symbol unregister_qdisc

2006-04-09 Thread Randy.Dunlap

On Sun, 9 Apr 2006 22:49:50 -0400 (EDT) George P Nychis wrote:

 
  On Sun, 9 Apr 2006 22:05:33 -0400 (EDT) George P Nychis wrote:
  
  
  On Sun, 9 Apr 2006 13:37:25 -0400 (EDT) George P Nychis wrote:
  
  Thanks for the help.
  
  Here is the makefile: http://rafb.net/paste/results/auchPH75.html
  
  And here is the full errors I receive: 
  http://rafb.net/paste/results/Qplpqw74.html
  
  Greatly appreciate it
  
  - George
  
  [repeat: please don't top-post]
  
  I don't know how much I can help you.  It's been a long time since
  I've built external modules on 2.4.x.
  
  Problems that I see: - the Makefile does not use the expected 2.4
  kernel build infrastructure; - kernel Makefile uses -nostdinc to
  prevent use of userspace headers; - Makefile is trying to include
  userspace headers instead of kernel headers, e.g.: In file included
  from /usr/include/linux/if_ether.h:107, from
  /usr/include/linux/netdevice.h:29, from sch_xcp.c:8: - this specified
  include directory is only in 2.6.x, not 2.4.x: -I/lib/modules/`uname
  -r`/build/include/asm/mach-default
  
  It's not clear to me how this makefile could work with 2.4.x at all.
  Is it supposed to, or that's just what you want to see it do?
  
  You could try to fix the Makefile based on makefile-changes articles
  at lwn.net. E.g.: http://lwn.net/Articles/151784/ 
  http://lwn.net/Articles/79984/ http://lwn.net/Articles/74767/ 
  http://lwn.net/Articles/69148/ http://lwn.net/Articles/21823/
  
  
  
  On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:
  
  Yeah, this module is unfortunately not under the GPL, it was
  made for research and i am not the author, I was only given the
  code for my own research.
  
  I enabled that support in the kernel, and then tried to
  recompile and get tons of errors/warnings... so maybe I am
  missing something else to be enabled in the kernel... here are a
  few examples of errors: /usr/include/linux/skbuff.h:30:26:
  net/checksum.h: No such file or directory
  /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or
  directory /usr/include/linux/irq.h:72: error: `NR_IRQS' 
  undeclared here (not in a function)
  /usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared
  here (not in a function)
  
  I think those are the top most errors, so if i can fix those 
  hopefully the rest shall vanish!
  
  Looks like a Makefile problem then.  Can you post the Makefile? 
  Hopefully it is using a Makefile and not just an elaborate gcc
  command line.
  
  [and please don't top-post]
  
  - George
  
  
  From: George P Nychis [EMAIL PROTECTED] Date: Sat, 8 Apr
  2006 18:47:34 -0400 (EDT)
  
  Hey,
  
  I have a kernel module that uses unregister_qdisc and 
  register_qdisc, whenever i try to insert the module I get: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved 
  symbol unregister_qdisc 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved 
  symbol register_qdisc
  
  Am i missing some sort of support in the kernel?
  
  Make sure CONFIG_NET_SCHED is enabled and that you compiled
  your module against that kernel.
  
  Where does this sch_xcp come from?  It's not in the vanilla 
  sources.
  
  Also, please direct networking questions to the 
  netdev@vger.kernel.org mailing list which I have added to the
   CC:.
  
  --- ~Randy
  
  
  
  By the way, if I add -I/usr/src/linux/include to the compile line, it
  successfully compiles, however, i am back to the start: lanthanum-ini
  src-1.0.1 # insmod sch_xcp Using
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
  unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
  register_qdisc
  
  Yet your 2.4.32 kernel image file does have those symbols in it? Can you
  verify that by using 'nm' on the kernel image file?
  
  If so, then I suppose that you'll need to make a small module test case 
  that exhibits this behavior, or just tell us where to get the sch_xcp
  files...
  
  (re-added cc: for netdev)
  
  --- ~Randy
  
  
 
 By kernel image, do you mean /usr/src/linux/vmlinux ?
 if so,
 lanthanum-ini linux # nm vmlinux | grep register_qdisc
 c0399200 R __kstrtab_register_qdisc
 c0399240 R __kstrtab_unregister_qdisc
 c039ebc8 R __ksymtab_register_qdisc
 c039ebd0 R __ksymtab_unregister_qdisc
 c02eda40 T register_qdisc
 c02edaf0 T unregister_qdisc

Yes.  That's good, then.

---
~Randy
-
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: 2.4.32: unresolved symbol unregister_qdisc

2006-04-09 Thread Randy.Dunlap

On Sun, 9 Apr 2006 23:20:01 -0400 (EDT) George P Nychis wrote:

 
  On Sun, 9 Apr 2006 22:49:50 -0400 (EDT) George P Nychis wrote:
  
  
  On Sun, 9 Apr 2006 22:05:33 -0400 (EDT) George P Nychis wrote:
  
  
  On Sun, 9 Apr 2006 13:37:25 -0400 (EDT) George P Nychis wrote:
  
  Thanks for the help.
  
  Here is the makefile:
  http://rafb.net/paste/results/auchPH75.html
  
  And here is the full errors I receive: 
  http://rafb.net/paste/results/Qplpqw74.html
  
  Greatly appreciate it
  
  - George
  
  [repeat: please don't top-post]
  
  I don't know how much I can help you.  It's been a long time
  since I've built external modules on 2.4.x.
  
  Problems that I see: - the Makefile does not use the expected 2.4
   kernel build infrastructure; - kernel Makefile uses -nostdinc to
   prevent use of userspace headers; - Makefile is trying to
  include userspace headers instead of kernel headers, e.g.: In file
  included from /usr/include/linux/if_ether.h:107, from 
  /usr/include/linux/netdevice.h:29, from sch_xcp.c:8: - this
  specified include directory is only in 2.6.x, not 2.4.x:
  -I/lib/modules/`uname -r`/build/include/asm/mach-default
  
  It's not clear to me how this makefile could work with 2.4.x at
  all. Is it supposed to, or that's just what you want to see it do?
  
  
  You could try to fix the Makefile based on makefile-changes
  articles at lwn.net. E.g.: http://lwn.net/Articles/151784/ 
  http://lwn.net/Articles/79984/ http://lwn.net/Articles/74767/ 
  http://lwn.net/Articles/69148/ http://lwn.net/Articles/21823/
  
  
  
  On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis
  wrote:
  
  Yeah, this module is unfortunately not under the GPL, it
  was made for research and i am not the author, I was only
  given the code for my own research.
  
  I enabled that support in the kernel, and then tried to 
  recompile and get tons of errors/warnings... so maybe I am 
  missing something else to be enabled in the kernel... here
  are a few examples of errors:
  /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such
  file or directory /usr/include/asm/irq.h:16:25:
  irq_vectors.h: No such file or directory
  /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared
  here (not in a function) /usr/include/asm/hw_irq.h:28:
  error: `NR_IRQ_VECTORS' undeclared here (not in a function)
  
  I think those are the top most errors, so if i can fix
  those hopefully the rest shall vanish!
  
  Looks like a Makefile problem then.  Can you post the
  Makefile? Hopefully it is using a Makefile and not just an
  elaborate gcc command line.
  
  [and please don't top-post]
  
  - George
  
  
  From: George P Nychis [EMAIL PROTECTED] Date: Sat, 8
  Apr 2006 18:47:34 -0400 (EDT)
  
  Hey,
  
  I have a kernel module that uses unregister_qdisc and 
  register_qdisc, whenever i try to insert the module I
  get: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
  unresolved symbol unregister_qdisc 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
  unresolved symbol register_qdisc
  
  Am i missing some sort of support in the kernel?
  
  Make sure CONFIG_NET_SCHED is enabled and that you
  compiled your module against that kernel.
  
  Where does this sch_xcp come from?  It's not in the
  vanilla sources.
  
  Also, please direct networking questions to the 
  netdev@vger.kernel.org mailing list which I have added to
  the CC:.
  
  --- ~Randy
  
  
  
  By the way, if I add -I/usr/src/linux/include to the compile line,
  it successfully compiles, however, i am back to the start:
  lanthanum-ini src-1.0.1 # insmod sch_xcp Using 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
  unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
  register_qdisc
  
  Yet your 2.4.32 kernel image file does have those symbols in it? Can
  you verify that by using 'nm' on the kernel image file?
  
  If so, then I suppose that you'll need to make a small module test
  case that exhibits this behavior, or just tell us where to get the
  sch_xcp files...
  
  (re-added cc: for netdev)
  
  --- ~Randy
  
  
  
  By kernel image, do you mean /usr/src/linux/vmlinux ? if so, 
  lanthanum-ini linux # nm vmlinux | grep register_qdisc c0399200 R
  __kstrtab_register_qdisc c0399240 R __kstrtab_unregister_qdisc c039ebc8 R
  __ksymtab_register_qdisc c039ebd0 R __ksymtab_unregister_qdisc c02eda40 T
  register_qdisc c02edaf0 T unregister_qdisc
  
  Yes.  That's good, then.
  
  --- ~Randy
  
  
 
 *sigh* ... still getting the unresolved symbols, i totally don't get it, my 
 /usr/src/linux/vmlinux says that the symbols exist, i install the kernel, 
 reboot, and still get the same errors

Yes, I understood that.

 Any other way of doing

Re: 2.4.32: unresolved symbol unregister_qdisc

2006-04-08 Thread Randy.Dunlap

On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:

 Yeah, this module is unfortunately not under the GPL, it was made for 
 research and i am not the author, I was only given the code for my own 
 research.
 
 I enabled that support in the kernel, and then tried to recompile and get 
 tons of errors/warnings... so maybe I am missing something else to be enabled 
 in the kernel... here are a few examples of errors:
 /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or directory
 /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or directory
 /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here (not in a 
 function)
 /usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared here (not in 
 a function)
 
 I think those are the top most errors, so if i can fix those hopefully the 
 rest shall vanish!

Looks like a Makefile problem then.  Can you post the Makefile?
Hopefully it is using a Makefile and not just an elaborate gcc command line.

[and please don't top-post]

 - George
 
 
  From: George P Nychis [EMAIL PROTECTED] Date: Sat, 8 Apr 2006 18:47:34
  -0400 (EDT)
  
  Hey,
  
  I have a kernel module that uses unregister_qdisc and register_qdisc,
  whenever i try to insert the module I get: 
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
  unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
  /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
  register_qdisc
  
  Am i missing some sort of support in the kernel?
  
  Make sure CONFIG_NET_SCHED is enabled and that you compiled your module
  against that kernel.
  
  Where does this sch_xcp come from?  It's not in the vanilla sources.
  
  Also, please direct networking questions to the netdev@vger.kernel.org 
  mailing list which I have added to the CC:.

---
~Randy
-
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

gcc warnings on 2.6.17-rc1: wireless

on x86-64 and gcc 4.0.2:

drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:456: warning: format ‘%u’ 
expects type ‘unsigned int’, but argument 3 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:460: warning: format ‘%08x’ 
expects type ‘unsigned int’, but argument 2 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:476: warning: format ‘%u’ 
expects type ‘unsigned int’, but argument 3 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:480: warning: format ‘%08x’ 
expects type ‘unsigned int’, but argument 2 has type ‘size_t’
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:200: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:311: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:733: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’

---
~Randy
-
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] acenic: fix section mismatches

On Sun, 2 Apr 2006 23:12:03 +0200 Sam Ravnborg wrote:

 On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:
   
   Sam, I am now seeing this error (not a WARNING like the previous ones 
   were):
   
   drivers/net/typhoon.c:137: error: version causes a section type conflict
   
   but I don't see a real problem in the driver source file.
   Ideas, anyone?
  
  This happens for typhoon (above) as well as:
  
  drivers/net/natsemi.c:241: error: version causes a section type conflict
 
 I have taken a look at natsemi.c.
 Following patch fixes the error:
 
 diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
 index 7826afb..a36a15e 100644
 --- a/drivers/net/natsemi.c
 +++ b/drivers/net/natsemi.c
 @@ -372,7 +372,7 @@ enum pcistuff {
  static const struct {
   const char *name;
   unsigned long flags;
 -} natsemi_pci_info[] __devinitdata = {
 +} natsemi_pci_info[] /*__devinitdata*/ = {
   { NatSemi DP8381[56], PCI_IOTYPE },
  };
 
 The reason why gcc barfs over it seems to be conflicting sections
 between the function natsemi_probe1() where natsemi_pci_info[] is used
 and the section of natsemi_pci_info.
 But putting them in same section did not help.
 
 I'm a bit puzzeled what is going on. Randy - any insight in this?

How weird.  I can't reproduce this at all now.  Tried several times.

---
~Randy
-
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] acenic: fix section mismatches

On Mon, 3 Apr 2006 19:27:25 +0200 Sam Ravnborg wrote:

 On Mon, Apr 03, 2006 at 10:27:32AM -0700, Randy.Dunlap wrote:
  On Sun, 2 Apr 2006 23:12:03 +0200 Sam Ravnborg wrote:
  
   On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:
 
 Sam, I am now seeing this error (not a WARNING like the previous ones 
 were):
 
 drivers/net/typhoon.c:137: error: version causes a section type 
 conflict
 
 but I don't see a real problem in the driver source file.
 Ideas, anyone?

This happens for typhoon (above) as well as:

drivers/net/natsemi.c:241: error: version causes a section type conflict
   
   I have taken a look at natsemi.c.
   Following patch fixes the error:
   
   diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
   index 7826afb..a36a15e 100644
   --- a/drivers/net/natsemi.c
   +++ b/drivers/net/natsemi.c
   @@ -372,7 +372,7 @@ enum pcistuff {
static const struct {
 const char *name;
 unsigned long flags;
   -} natsemi_pci_info[] __devinitdata = {
   +} natsemi_pci_info[] /*__devinitdata*/ = {
 { NatSemi DP8381[56], PCI_IOTYPE },
};
   
   The reason why gcc barfs over it seems to be conflicting sections
   between the function natsemi_probe1() where natsemi_pci_info[] is used
   and the section of natsemi_pci_info.
   But putting them in same section did not help.
   
   I'm a bit puzzeled what is going on. Randy - any insight in this?
  
  How weird.  I can't reproduce this at all now.  Tried several times.
 You need to build with CONFIG_HOTPLUG undefined to see it..

Thanks for the reminder.  I see the problem.

gcc doesn't like for some __initdata to be const and others not, which is
what it's complaining about.  Marking the driver version as 'const'
also fixes this problem.  This needs to be done in:
  typhoon, starfire, natsemi, and bnx2

Any volunteers to do this?

---
~Randy
-
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

[PATCH] softmac uses Wiress Ext.

I still get this on 2.6.17-rc1...
Did anyone on netdev pick it up last week?

Date: Mon, 27 Mar 2006 14:53:41 -0800
From: Randy.Dunlap [EMAIL PROTECTED]
To: netdev netdev@vger.kernel.org
Cc: [EMAIL PROTECTED]
Subject: [PATCH] softmac uses Wiress Ext.

From: Randy Dunlap [EMAIL PROTECTED]

softmac uses wireless extensions, so let it SELECT that config option;
WARNING: wireless_send_event [net/ieee80211/softmac/ieee80211softmac.ko] 
undefined!

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 net/ieee80211/softmac/Kconfig |1 +
 1 files changed, 1 insertion(+)

--- linux-2616-g13.orig/net/ieee80211/softmac/Kconfig
+++ linux-2616-g13/net/ieee80211/softmac/Kconfig
@@ -1,6 +1,7 @@
 config IEEE80211_SOFTMAC
tristate Software MAC add-on to the IEEE 802.11 networking stack
depends on IEEE80211  EXPERIMENTAL
+   select WIRELESS_EXT
---help---
This option enables the hardware independent software MAC addon
for the IEEE 802.11 networking stack.

---
-
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

[PATCH] net drivers: fix section attributes for gcc

From: Randy Dunlap [EMAIL PROTECTED]

If CONFIG_HOTPLUG=n, gcc doesn't like some __initdata to be
const (rodata) and other __initdata not const, so make the
non-const __initdata const.

gcc errors:
drivers/net/bnx2.c:66: error: version causes a section type conflict
drivers/net/starfire.c:338: error: version causes a section type conflict
drivers/net/typhoon.c:137: error: version causes a section type conflict
drivers/net/natsemi.c:241: error: version causes a section type conflict

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 drivers/net/bnx2.c |2 +-
 drivers/net/natsemi.c  |2 +-
 drivers/net/starfire.c |2 +-
 drivers/net/typhoon.c  |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2617-rc1.orig/drivers/net/bnx2.c
+++ linux-2617-rc1/drivers/net/bnx2.c
@@ -63,7 +63,7 @@
 /* Time in jiffies before concluding the transmitter is hung. */
 #define TX_TIMEOUT  (5*HZ)
 
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
Broadcom NetXtreme II Gigabit Ethernet Driver  DRV_MODULE_NAME  v 
DRV_MODULE_VERSION  ( DRV_MODULE_RELDATE )\n;
 
 MODULE_AUTHOR(Michael Chan [EMAIL PROTECTED]);
--- linux-2617-rc1.orig/drivers/net/natsemi.c
+++ linux-2617-rc1/drivers/net/natsemi.c
@@ -238,7 +238,7 @@ static int full_duplex[MAX_UNITS];
 #define NATSEMI_RX_LIMIT   2046/* maximum supported by hardware */
 
 /* These identify the driver base version and may not be removed. */
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
   KERN_INFO DRV_NAME  dp8381x driver, version 
   DRV_VERSION ,  DRV_RELDATE \n
   KERN_INFO   originally by Donald Becker [EMAIL PROTECTED]\n
--- linux-2617-rc1.orig/drivers/net/starfire.c
+++ linux-2617-rc1/drivers/net/starfire.c
@@ -335,7 +335,7 @@ do { \
 
 
 /* These identify the driver base version and may not be removed. */
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
 KERN_INFO starfire.c:v1.03 7/26/2000  Written by Donald Becker [EMAIL 
PROTECTED]\n
 KERN_INFO  (unofficial 2.2/2.4 kernel port, version  DRV_VERSION ,  
DRV_RELDATE )\n;
 
--- linux-2617-rc1.orig/drivers/net/typhoon.c
+++ linux-2617-rc1/drivers/net/typhoon.c
@@ -134,7 +134,7 @@ static const int multicast_filter_limit 
 #include typhoon.h
 #include typhoon-firmware.h
 
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
 typhoon.c: version  DRV_MODULE_VERSION  ( DRV_MODULE_RELDATE )\n;
 
 MODULE_AUTHOR(David Dillow [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] acenic: fix section mismatches

2006-03-28 Thread Randy.Dunlap

On Tue, 28 Mar 2006 07:10:30 +0200 Sam Ravnborg wrote:

 On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:

Nope, only with HOTPLUG enabled.  I can try without also (but
disabling it is a pain :).
   
   ugh, FW_LOADER is the beast (not CONFIG_HOTPLUG itself).
   
   Sam, I am now seeing this error (not a WARNING like the previous ones 
   were):
 Can you send me your .config.
 Tried but did not manage to get rid of FW_LOADER.
 OK - did not try hard though.

I took a simple way out, disabling large sections of drivers, like all USB,
all IEEE1394, etc.  It's attached.

---
~Randy


config-nothotplug
Description: Binary data

Re: net TODO

On Mon, 20 Mar 2006 19:36:25 -0800 Stephen Hemminger wrote:

 On Mon, 20 Mar 2006 19:30:17 -0800
 Randy.Dunlap [EMAIL PROTECTED] wrote:
 
  
  in Documentation/networking/TODO, the Jamal netdev Rx polling API change
  is done, right?  (NAPI)
  
  Are any of the others done?
  Should this TODO file be removed or updated or reference
http://vger.kernel.org/~davem/net_todo.html ?
  
 
 The updated version of TODO is kept on the wiki:
   http://linux-net.osdl.org/index.php/TODO

so Dave, can you just remove Documentation/networking/TODO ?
or do you want a patch for that?

or want it to reference the wiki instead?

---
~Randy
-
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] acenic: fix section mismatches

On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote:

 On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote:
  From: Randy Dunlap [EMAIL PROTECTED]
  
  Fix section mismatches in acenic driver:
  WARNING: drivers/net/acenic.o - Section mismatch: reference to 
  .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 
  0x2409) and 'ace_interrupt'
  WARNING: drivers/net/acenic.o - Section mismatch: reference to 
  .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at offset 
  0x2422) and 'ace_interrupt'
  
  Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
 
 I'm glad to see these fixes appear.
 Did you manage to compile with and without HOTPLUG enabled?
 This is important since HOTPLUG redefined __dev* to nothing = no
 section mismatchs.

Nope, only with HOTPLUG enabled.  I can try without also (but
disabling it is a pain :).

---
~Randy
-
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] acenic: fix section mismatches

On Mon, 27 Mar 2006 13:19:41 -0800 Randy.Dunlap wrote:

 On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote:
 
  On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote:
   From: Randy Dunlap [EMAIL PROTECTED]
   
   Fix section mismatches in acenic driver:
   WARNING: drivers/net/acenic.o - Section mismatch: reference to 
   .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 
   0x2409) and 'ace_interrupt'
   WARNING: drivers/net/acenic.o - Section mismatch: reference to 
   .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at 
   offset 0x2422) and 'ace_interrupt'
   
   Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
  
  I'm glad to see these fixes appear.
  Did you manage to compile with and without HOTPLUG enabled?
  This is important since HOTPLUG redefined __dev* to nothing = no
  section mismatchs.
 
 Nope, only with HOTPLUG enabled.  I can try without also (but
 disabling it is a pain :).

ugh, FW_LOADER is the beast (not CONFIG_HOTPLUG itself).

Sam, I am now seeing this error (not a WARNING like the previous ones were):

drivers/net/typhoon.c:137: error: version causes a section type conflict

but I don't see a real problem in the driver source file.
Ideas, anyone?

---
~Randy
-
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] acenic: fix section mismatches

On Mon, 27 Mar 2006 13:19:41 -0800 Randy.Dunlap wrote:

 On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote:
 
  On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote:
   From: Randy Dunlap [EMAIL PROTECTED]
   
   Fix section mismatches in acenic driver:
   WARNING: drivers/net/acenic.o - Section mismatch: reference to 
   .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 
   0x2409) and 'ace_interrupt'
   WARNING: drivers/net/acenic.o - Section mismatch: reference to 
   .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at 
   offset 0x2422) and 'ace_interrupt'
   
   Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
  
  I'm glad to see these fixes appear.
  Did you manage to compile with and without HOTPLUG enabled?
  This is important since HOTPLUG redefined __dev* to nothing = no
  section mismatchs.
 
 Nope, only with HOTPLUG enabled.  I can try without also (but
 disabling it is a pain :).

With HOTPLUG disabled, there are no section warnings before or after
this patch.

---
~Randy
-
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] acenic: fix section mismatches