This patch fixes an out of sequence step in the bcm43xx_init_board
routine for bcm43xx-softmac.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes various bugs in the init and shutdown code
that would lead to lockups and crashes.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Caused by a documentation issue I mixed up fields of the zd_status
structure. This patch fixes it and improves also the average
computation, which is now using only measurements of packets sent
by the access point.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6:
usbtouchscreen: fix ITM data reading
USB: New device ID for ftdi_sio usb serial driver
USB: Support for USB20SVGA-WH & USB20SVGA-DG
USB: hid-core.c: fix duplicate USB_DEVICE_ID_GTCO_404
Inverting the write ordering of the TxDescAddr{High/Low} registers
suffices to trigger a sabbat of PCI errors which make the device
completely dysfunctional. The issue has not been reported on a
different platform.
Switching from MMIO accesses to I/O ones as done in Realtek's
own driver fixes (papers over ?) the bug as well but I am not
thrilled to see everyone pay the I/O price for an obscure bug.
This is the minimal change to handle the issue.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Reported-by: Lennert Buytenhek <buytenh@wantstofly.org>
There are two changes here. The first reverses the broken PCI_DEVICE
conversion back to the old format. The second adds a missing PCI ID so
you can actually boot 2.6.18 on 2 month old VIA motherboards (right now
only 2.6.18-mm works).
CC'd to Jeff to check the PCI ident but its a) in several distro kernels
and b) in 2.6.18-mm [twice ??]
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
dm9000_release_board calls release_resource with the platform resource
instead of the requested resource:
db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
db->addr_req = request_mem_region(db->addr_res->start, i, pdev->name);
dm9000_release_board:
if (db->addr_res != NULL) {
release_resource(db->addr_res);
kfree(db->addr_req);
With this behavior the kernel will crash on the second removal. The
attached patch fix this problem.
Signed-off-by: Dirk Opfer <Dirk@Opfer-Online.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This removes unnecessary messages that show up every time I put my
ethernet card in promiscuous mode. I'm already getting notification
from the networking layer, I don't need notification from the driver as
well.
There are probably other drivers that do this as well -- I'll look
around and see what I can find.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Include "tulip.h" in winbond-840.c and clean up lots of redundant
definitions.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Update/cleanup some definitions in tulip.h and tulip_core.c.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Move tulip_select_media() processing to a workqueue, instead of
delaying in interrupt context, edited by Kyle McMartin to use kevent
thread, instead of creating its own workqueue.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The obvious safe registers to read is one from PCI config space.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
As the cookie returned by pci_iomap() is fairly useless...
[Compile warning on pci_resource_start() format fixed up by Valerie
Henson.]
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Although the document says otherwise, some ich7m uses map 01b. This
patch adds separate map DB for ICH7M and adds map entry for 01b.
This was spotted on an ASUS laptop by Jonathan Dieter.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Jonathan Dieter <jdieter@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Fix a buglet; the errata check below this code is assuming the value in
the sstatus variable is what was pulled out of the SCR_STATUS register.
However, the status checks in the timeout loop clobber everything
but the first 4 bits of sstatus, so the errata checks are invalid.
This patch changes it to not clobber SStatus.
Signed-off-by: Andres Salomon <dilinger@debian.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Sometimes the logic to handle AGPx8->AGPx4 fallback failed, as can
be seen in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197346
The failures occured if the bridge was in AGPx8 mode, but the
user hadn't specified a mode in their X config. We weren't
setting the mode to the highest mode capable by the video card+bridge
(as we do in the AGPv2 case), which was leading to all kinds of
mayhem including us believing that after falling back from AGPx8, that
we couldn't do x4 mode (which is disastrous in AGPv3, as those are
the only two modes possible).
Signed-off-by: Dave Jones <davej@redhat.com>
Several DVB modules depends on I2C
Signed-off-by: Andrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
V4L1 support should be disabled when no CONFIG_VIDEO_V4L1_COMPAT is defined,
to allow checking for broken V4L2 ports. This is very important during the
migration phase for V4L2 API.
However, userspace apps should be capable of using both APIs, since they need
to test at runtime, via VIDIOCGCAP ioctl, if V4L1 is supported. So, when
__KERNEL__ is not defined, those ioctls and corresponding structs should be
visible.
This patch also removes the obsolete defines HAVE_V4L1 and HAVE_V4L2, that
where causing some confusion, and were replaced by CONFIG_VIDEO_V4L1_COMPAT
and CONFIG_VIDEO_V4L2.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The tena_9533_di_pal_ranges use 0x04 instead the original 0x08 for the
UHF (range 2) switching. This is wrong and therefore nothing happens.
Restore tuner_ymec_tvf66t5_b_dff_pal_ranges[] to make the UHF switch
working again.
Signed-off-by: Hermann Pitton <hermann-pitton@arcor.de>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
VIDIOCGMBUF should be compiled only when V4L1 support is selected, since
this ioctl is from the obsoleted API.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
New SiS south bridge device ID is 0x966.
Next coming product will be 0x968. (Will be released in Q4, this year)
We don't make any updates to the IDE controller.
Signed-off-by: David Wang <touch@sis.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Sergey Vlasov reported that his "FUJITSU MCC3064AP, ATAPI OPTICAL drive"
pops up as UNKNOWN in /proc/ide/*/media .
Closes#4145.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The patch adds a new device ID for the Gamma Scout Geiger counter
device.
Signed-off-by: Ralf Schlatterbeck <rsc@runtux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is support USB20SVGA-WH & USB20SVGA-DG of the sisusb device.
As for this device, Device ID is different according to the color of the
product. A blue device is supported. However, a green, white device is
not supported.
http://www.lubic.jp/uv_method.html ( Japanese only ) .
Green, white USB20SVGA comes to work by applying the patch .
And, it be able to use three USB20SVGA( Blue , Green , White ).
Signed-off-by: Nobuhiro Iwamatsu <hemamu@t-base.ne.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +gregkh-usb-hid-core.c-adds-all-gtco-calcomp-digitizers-and-interwrite-school-products-to-blacklist.patch
>...
> USB tree updates.
>...
The GNU C compiler spotted the following bug:
<-- snip -->
...
CC drivers/usb/input/hid-core.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/usb/input/hid-core.c:1446:1: warning: "USB_DEVICE_ID_GTCO_404" redefined
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/usb/input/hid-core.c:1445:1: warning: this is the location of the previous definition
...
<-- snip -->
This patch fixes this cut'n'paste error.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
CONFIG_SCSI_NETLINK can become a bool since the item its
selecting (CONFIG_NET) cannot be a module.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch implements the ability to set the minimum and maximum
linkrates for both libsas (for expanders) and aic94xx (for the host
phys). It also tidies up the setting of the hardware min and max to
make sure they're updated when the expander emits a change broadcast.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
According to SPEC, the minimum_linkrate and maximum_linkrate should be
settable by the user. This patch introduces a callback that allows the
sas class to pass these settings on to the driver.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
At the moment we have two separate linkspeed enumerations covering
roughly the same values. This patch consolidates on a single one enum
sas_linkspeed in scsi_transport_sas.h and uses it everywhere in the
aic94xx driver. Eventually I'll get around to removing the duplicated
fields in asd_sas_phy and sas_phy ...
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The recent change to the way scsi_device_get()/put() work broke the
non modular build (we do a module_refcount on a NULL). Fix this by
checking for non-null before checking module_refcount().
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Spotted by: Dan Aloni <da-xx@monatomic.org>
The problem is there's inconsistent locking semantic usage of
scsi_alloc_target(). Two callers assume the target comes back with
reference unincremented and the third assumes its incremented. Fix by
always making the reference incremented on return. Also fix path in
target alloc that could consistently increment the parent lock.
Finally document scsi_alloc_target() so its callers know what the
expectations are.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Both MMC and SD specifications specify (although a bit unclearly in
the MMC case) that a sector size of 512 bytes must always be
supported by the card.
Cards can report larger "native" size than this, and cards >= 2 GB
even must do so. Most other readers use 512 bytes even for these
cards. We should do the same to be compatible.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rather than having two places which independently calculate the
timeout for data transfers, make it a library function instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Pierre Ossman <drzeus@drzeus.cx>
