linux.git/drivers/net/typhoon.c, branch v2.6.27

[netdrvr] remove unnecessary #include

2008-08-14T08:26:38+00:00

The drivers below do not use LINUX_VERSION_CODE nor KERNEL_VERSION.
  drivers/net/acenic.c
  drivers/net/bnx2x_link.c
  drivers/net/bnx2x_main.c
  drivers/net/cpmac.c
  drivers/net/gianfar_sysfs.c
  drivers/net/ipg.h
  drivers/net/ppp_mppe.c
  drivers/net/pppol2tp.c
  drivers/net/r6040.c
  drivers/net/sh_eth.c
  drivers/net/sky2.c
  drivers/net/tehuti.h
  drivers/net/typhoon.c

This patch removes the said #include .

Signed-off-by: Huang Weiyi 
Signed-off-by: Jeff Garzik

[netdrvr] kill sync_irq-before-freq_irq pattern

2008-06-28T14:23:38+00:00

synchronize_irq() is superfluous when free_irq() call immediately follows it,
because free_irq() also does a synchronize_irq() call of its own.

Signed-off-by: Jeff Garzik

[netdrvr] typhoon: typhoon_resume - remove call to start_queue

2008-04-25T06:08:08+00:00

While trying to fix http://bugzilla.kernel.org/show_bug.cgi?id=8952
I looked at a few other drivers to figure out what drivers _should_
be doing for suspend/resume. I noticed typhoon driver is likely doing
more than it needs to.  Patch below is untested since I don't have the HW.

Suspend/resume code across NIC drivers is fairly inconsistent.
And I couldn't find any documentation on what the canonical sequence
NICs need to do for suspend or resume.  Is there any?

Barring contrary advice, I'm going model the tulip suspend/resume
fixes after tg3.c since a number of "modern" (< 5 years old) laptops
have that and I'm silly enough to assume it works.

Signed-off-by: Jeff Garzik

typhoon: section fix

2008-02-10T07:40:34+00:00

gcc-3.4.4 on powerpc:

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

Cc: Jeff Garzik 
Cc: Sam Ravnborg 
Signed-off-by: Andrew Morton 
Signed-off-by: David S. Miller

typhoon: trivial endianness annotations

2007-12-23T03:53:06+00:00

Signed-off-by: Al Viro 
Signed-off-by: Jeff Garzik

typhoon: memory corruptor on big-endian if TSO is enabled

2007-12-23T03:53:06+00:00

txlo_dma_addr should be host-endian; we pass it to typhoon_tso_fill(),
which does arithmetics on it, converts to l-e and passes it to card.
Unfortunately, we forgot le32_to_cpu() when initializing it from
face->txLoAddr, which sits in shared memory and is little-endian.

Signed-off-by: Al Viro 
Signed-off-by: Jeff Garzik

typhoon: missed rx overruns on big-endian

2007-12-23T03:53:05+00:00

rxBuffCleared is little-endian; we miss le32_to_cpu() in checks for
rx ring overruns.

Signed-off-by: Al Viro 
Signed-off-by: Jeff Garzik

typhoon: set_settings broken on big-endian

2007-12-23T03:53:05+00:00

One cpu_to_le16() too many when passing argument for TYPHOON_CMD_XCVR_SELECT;
we end up passing host-endian while the hardware expects little-endian.  The
other place doing that (typhoon_start_runtime()) does the right thing, so the
card will recover at the next ifconfig up/tx timeout/resume, which limits the
amount of mess, but still, WTF?

Signed-off-by: Al Viro 
Signed-off-by: Jeff Garzik

typhoon: missing le32_to_cpu() in get_drvinfo

2007-12-23T03:53:05+00:00

in typhoon_get_drvinfo() .parm2 is little-endian; not critical
since we just get the firmware id flipped in get_drvinfo output
on big-endian boxen, but...

Signed-off-by: Al Viro 
Signed-off-by: Jeff Garzik

typhoon: endianness bug in tx/rx byte counters

2007-12-23T03:53:05+00:00

txBytes and rxBytesGood are both 64bit; using le32_to_cpu() won't work
on big-endian for obvious reasons.

Signed-off-by: Al Viro 
Signed-off-by: Jeff Garzik