* all places where we assign ->addr get cpu_to_le32(pci_map_single(....)), so
we ought to convert back to host-endian before doing pci_unmap_single() et.al.
* poisoning addresses in netdev_close() should be done _after_ unmapping them,
not before it...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

I'm using a Marvell 88E8062 on a custom PPC64 blade and ran into RX
lockups while validating the sky2 driver.  The receive MAC FIFO would
become stuck during testing with high traffic.  One port of the 88E8062
would lockup, while the other port remained functional.  Re-inserting
the sky2 module would not fix the problem - only a power cycle would.

I looked over Marvell's most recent sk98lin driver and it looks like
they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
The sk98lin driver disables the RX MAC FIFO flush feature for all
revisions of the Yukon XL.

According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
(needed for ASF see dev. #4.29), but the flushing mask should be
disabled (see dev. #4.115)".  Nice. I implemented this same change in
the sky2 driver and verified that the RX lockup I was seeing was
resolved.
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Fix endless loop in cheetah_xcall_deliver().
  [SERIAL] sparc: Infrastructure to fix section mismatch bugs.

* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
  i2c/isp1301_omap: Build fix
  i2c: Add missing spaces in split log messages
  i2c-gpio: Initialize adapter class
  i2c: Delete an outdated piece of documentation

We need to mask out the proper bits when testing the dispatch status
register else we can see unrelated NACK bits from previous cross call
sends.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch against 2.6.23 sparc-2.6.git contains a number of minor
cleanups of the sparc serial drivers.  Initially I fixed this build
warning:

WARNING: vmlinux.o(.text+0x107a2c): Section mismatch: reference to .init.text:add_preferred_console (between 'sunserial_console_match' and 'sunserial_console_termios')

which is done by declaring sunserial_console_match() as __init.  This
resulted in build warnings on sunserial_current_minor.  To resolve
these the variable was changed so it is no longer global, and to hide
operations on it inside 2 new functions. These functions handle the
UART minor handling code that is common to all sparc serial drivers.

These changes allowed to clean up the uart counters in all the sparc
serial drivers, and the administration of minor device numbers.

Lastly, sunserial_console_termios() does not need to be exported since
it is only called from non-modular code.

Sadly, the following build warning still exists:

WARNING: vmlinux.o(__ksymtab+0x2910): Section mismatch: reference to .init.text:sunserial_console_match (between '__ksymtab_sunserial_console_match' and '__ksymtab_sunserial_unregister_minors')

This could be resolved by not exporting sunserial_console_match(), but
this is not possible at the moment because it is being called from
modular code. On the other hand, this is a bogus warning since it
comes from a ksymtab section.
Signed-off-by: NMartin Habets <errandir_news@mph.eclipse.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Build fix to the isp1301_omap driver ... this driver gets built
more often in the OMAP tree than in mainline, partly because the
defconfig for H2 (plus probably H3 and H4) needs updating.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This is required to let hwmon drivers attach to the adapter.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

I'm amazed that this old piece of documentation managed to survive
until today.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

videobuf_dvb needs videobuf_read_start. The EXPORT_SYMBOL_GPL() were removed by
a previous patch. However, videobuf_dvb needs this.

This patch re-adds videobuf_read_start, doing the proper lock.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This reverts commit 70eba18b, as per
Jeff Garzik:

   "That was meant for 2.6.25, and actually (due to patching) applied to
    a completely unrelated 2.6.24 net driver."
Noted-by: NRoland Dreier <rdreier@cisco.com>
Requested-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:

<--  snip  -->

...
...

<--  snip  -->
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:

<--  snip  -->

...
...

<--  snip  -->
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

As reported by Andrew Morton:

> ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/dvb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined!
> ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/dvb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined!
> ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined!
> ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined!
> ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/dvb/dvb-usb/dvb-usb-a800.ko] undefined!
> ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/dvb/dvb-usb/dvb-usb-a800.ko] undefined
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

On Tue, 4 Dec 2007, Ingo Molnar wrote:

>  drivers/built-in.o: In function `dibusb_dib3000mc_tuner_attach':
>  : undefined reference to `dib3000mc_get_tuner_i2c_master'
>  drivers/built-in.o: In function `dibusb_dib3000mc_tuner_attach':
>  : undefined reference to `dib3000mc_set_config'

Seems like -common part contains also code that is not completely
common to all the modules.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Tested-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

cxusb needs tuner-xc2028*.h files, but Makefile is not adding its patch

drivers/media/dvb/dvb-usb/cxusb.c:33:26: error: tuner-xc2028.h: File not found
drivers/media/dvb/dvb-usb/cxusb.c:34:32: error: tuner-xc2028-types.h: File not found
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

There are several months my hvr1110 stop working.
This is very simple to fix, for my card revision at least, by setting a
missing field to the hauppauge_hvr_1110_config.
Signed-off-by: NBenoit Istin <beistin@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This is pretty serious bug.  map->count is never initialized after the
call to kmalloc making the count start at some random trash value.  The
end result is leaking videobufs.

Also, fix up the debug statements to print unsigned values.

Pushed to http://ifup.org/hg/v4l-dvb too
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The saa7134 video driver starts dropping frames when used together with the
saa7134-alsa driver. Frames are dropped because when an audio event is waiting
the driver simply ignores the interrupt and passes it on to the saa7134-alsa
interrupt handler. The alsa interrupt handler in turn acknowledges all types
of events thus clearing the pending video events as well. Fix by only masking
out the audio event in the video interrupt handler and by only acknowledging
the audio event in the alsa driver.
Signed-off-by: NHeikki Lindholm  <holindho@cs.helsinki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The vmux for composite over s-video input was wrong.
Signed-off-by: NHermann Pitton <hermann-pitton@arcor.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Complement va_start() with va_end() + minor style fixes in the same function.
Signed-off-by: NRichard Knutsson <ricknu-0@student.ltu.se>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The period handling in saa7134-alsa is broken in two ways. First, the
minimum number of periods of two does not work, because the dma is setup
two periods ahead in the irq handler. Fix the minimum to four periods.
Second, the code assumes that the number of periods is divisible by two,
which isn't always the case on ALSA. Fix by adding a constraint.
Signed-off-by: NHeikki Lindholm  <holindho@cs.helsinki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The default adc_clock for the zl10353 is different from what was originally
thought to be the case and the TRL nominal rate formula was incorrect as a
result.  Use a better (and hopefully now correct) formula.
Signed-off-by: NChris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fallout from videobuf_mmap_setup() locking fixes.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Drivers were using cookie cutter code for stopping the read/stream.  Use the
new videobuf_stop function which is lock safe.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

- Add comments to functions that require that caller hold q->lock
- Add __videobuf_mmap_free that doesn't hold q->lock for use within videobuf
- Add locking to videobuf_mmap_free
- Fix linux/drivers/media/common/saa7146_video.c which was holding lock around
  videobuf_read_stop
- Add locking to functions that operate on a queue
- Add videobuf_stop to take care of stopping in both the read and stream case

TODO: bttv still has an unsafe call to videobuf_queue_is_busy
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This is a modified version of a patch previously posted by Thomas
Unverzagt.
Signed-off-by: NHartmut Hackmann <hartmut.hackmann@t-online.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Thanks to Markus Reichberger to point this.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The attached patch is required so that the autodetecion code also works after
a reboot.

Setting the I2C speed does not seem to be supported for em2800.
Signed-off-by: NSascha Sommer <saschasommer@freenet.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

If we get an error during the actual policy lookup we don't free the
original dst while the caller expects us to always free the original
dst in case of error.

This patch fixes that.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The vlan module cleanup function starts with

	vlan_netlink_fini();
	vlan_ioctl_set(NULL);

The first call removes all the vlan devices and
the second one closes the vlan ioctl.

AFAIS there's a tiny race window between these two
calls - after rtnl unregistered all the vlans, but
the ioctl handler isn't set to NULL yet, user can
manage to call this ioctl and create one vlan device,
and that this function will later BUG_ON seeing
non-emply hashes.

I think, that we must first close the vlan ioctl
and only after this remove all the vlans with the
vlan_netlink_fini() call.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Acked-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are some return value comments for void functions.
Fixed it.
Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Packets can be left in the RX ring if the NAPI budget is reached.
This is caused by storing the latest rx index at the beginning of
bnx2_rx_int().  We may not process all the work up to this index
if the budget is reached and so some packets in the RX ring may rot
when we later check for more work using this stored rx index.

The fix is to not store this latest hw index and only store the
processed rx index.  We use a new function bnx2_get_hw_rx_cons()
to fetch the latest hw rx index.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

5709 Ax and Bx chips all need this workaround.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Recently, Wang Chen submitted a patch
(d30f53ae) to move a call to netif_rx(skb)
after a subsequent reference to skb, because netif_rx may call kfree_skb on
its argument.  netif_rx_ni calls netif_rx, so the same problem occurs in
the files below.

I have left the updating of dev->last_rx after the calls to netif_rx_ni
because it seems time dependent, but moved the other field updates before.

This was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression skb, e,e1;
@@

(
 netif_rx(skb);
|
 netif_rx_ni(skb);
)
  ... when != skb = e
(
  skb = e1
|
* skb
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Recently, Wang Chen submitted a patch
(d30f53ae) to move a call to netif_rx(skb)
after a subsequent reference to skb, because netif_rx may call kfree_skb on
its argument.  The same problem occurs in some other drivers as well.

This was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression skb, e,e1;
@@

(
 netif_rx(skb);
|
 netif_rx_ni(skb);
)
  ... when != skb = e
(
  skb = e1
|
* skb
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>