The ip event handler may present us non qeth network interfaces.
Add qeth card pointer check.
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
virtio_net uses a timer to free old transmitted packets, rather than
leaving callbacks enabled all the time. If the host promises to
always notify us when the transmit ring is empty, we can free packets
at that point and avoid the timer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
virtio_net currently only frees old transmit skbs just
before queueing new ones. If the queue is full, it then
enables interrupts and waits for notification that more
work has been performed.
However, a side-effect of this scheme is that there are
always xmit skbs left dangling when no new packets are
sent, against the Documentation/networking/driver.txt
guideline:
"... it is not allowed for your TX mitigation scheme
to let TX packets "hang out" in the TX ring unreclaimed
forever if no new TX packets are sent."
Add a timer to ensure that any time we queue new TX
skbs, we will shortly free them again.
This fixes an easily reproduced hang at shutdown where
iptables attempts to unload nf_conntrack and nf_conntrack
waits for an skb it is tracking to be freed, but virtio_net
never frees it.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
hdr->csum_start is the offset from the start of the ethernet
header to the transport layer checksum field. skb->csum_start
is the offset from skb->head.
skb_partial_csum_set() assumes that skb->data points to the
ethernet header - i.e. it computes skb->csum_start by adding
the headroom to hdr->csum_start.
Since eth_type_trans() skb_pull()s the ethernet header,
skb_partial_csum_set() should be called before
eth_type_trans().
(Without this patch, GSO packets from a guest to the world outside the
host are corrupted).
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
eHEA has to call firmware functions in order to change the mac address
of a logical port. This patch checks if the logical port is up
when calling the register / deregister mac address calls. If the port
is down these firmware calls would fail and are therefore not executed.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
RX queue flush can fail if traffic continues to arrive. Recover by
performing an invisible reset.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Add a workaround for lost MSI interrupts. There is a race condition in
the HW in which future interrupts could be missed. The workaround is to
toggle the MSI irq mask.
Added cleanup based on comments from Andrew Morton.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
We need to unshare the skb first as otherwise pskb_may_pull may
write to a shared skb which could be bad.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The length field in the PPPOE header wasn't checked completely.
This patch causes all packets shorter than the declared length
to be dropped.
It also changes the memcpy_toiovec call to skb_copy_datagram_iovec
so that paged packets (rare for PPPOE) are handled properly.
Thanks to Ilja of the Netric Security Team for discovering and
reporting this bug, and Chris Wright for the total_len check.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
1. creating proc entry and not saving pointer to PDE and checking it
is not going to work.
2. if proc entry wasn't created, no reason to remove it on error path.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
KERNEL_OFFSET macro in eni.h is not required as it is not used anywhere.
Remove the unused macro from eni.h header file.
Signed-off-by: Pradeep Singh <rautelap@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes a potential memory corruption in
pppol2tp_recvmsg(). If skb->len is bigger than the caller's buffer
length, memcpy_toiovec() will go into unintialized data on the kernel
heap, interpret it as an iovec and start modifying memory.
The fix is to change the memcpy_toiovec() call to
skb_copy_datagram_iovec() so that paged packets (rare for PPPOL2TP)
are handled properly. Also check that the caller's buffer is big
enough for the data and set the MSG_TRUNC flag if it is not so.
Reported-by: Ilja <ilja@netric.org>
Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch limits BLK_DEV_HD_ONLY to the ARM platforms offering
IRQ_HARDDISK, fixing the following compile error on others:
<-- snip -->
...
CC drivers/ide/legacy/hd.o
...
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c: In function 'hd_times_out':
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c:542: error: 'IRQ_HARDDISK' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c:542: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c:542: error: for each function it appears in.)
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c: In function 'do_hd_request':
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c:661: error: 'IRQ_HARDDISK' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c: In function 'hd_init':
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/legacy/hd.c:765: error: 'IRQ_HARDDISK' undeclared (first use in this function)
make[3]: *** [drivers/ide/legacy/hd.o] Error 1
<-- snip -->
Reported-by: Adrian Bunk <bunk@kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Don't fail the probe if there are no devices attached to the controller.
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Convert the driver to use struct ide_port_info - as a nice side-effect
this fixes racy setup of ->io_32bit/unmask settings (after ide_device_add()
call device can be already in use).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
hwif->dev was set too late (after ide_device_add() call)
so hwif->gendev.parent was not initialized properly.
Fix it by setting hw.dev and letting ide_init_port_hw()
do the rest.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide_find_port() now depends on ->chipset being set for occupied ide_hwifs[]
slots so all host drivers have to initialize hwif->chipset properly.
This patch fixes a regression on hosts with > 1 port or with a single port
but no devices attached to it for an affected host drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
hwif->chipset need to be set properly or ide-generic driver will break once
we make a final step in fixing host drivers' dependence on ide_hwifs[].
Problem was catched early thanks to IDE tree exposure in -mm / -next trees
and reported by people listed people (thank you guys!).
Reported-by: "John Keller" <jpk@sgi.com>
Reported-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
Reported-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
I forgot to remove the ide_etrax100 chipset type when removing the
ETRAX_IDE driver.
Reported-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
@r exists@
expression E,E1;
statement S;
position p1,p2,p3;
@@
E =@p1 \(kmalloc\|kcalloc\|kzalloc\)(...)
... when != E = E1
if (E == NULL || ...) S
... when != E = E1
if@p2 (...) {
... when != kfree(E)
}
... when != E = E1
kfree@p3(E);
@forall@
position r.p2;
expression r.E;
int E1 != 0;
@@
* if@p2 (...) {
... when != kfree(E)
when strict
return E1; }
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Priorities for I/O interruption subclasses range from 0 (highest)
to 7 (lowest). Unfortunately, the console has been using isc 7
instead of an isc with a higher priority than regular I/O
subchannels (which use 3). Fix this by making the console use
isc 1.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
sparse complains about signedness:
drivers/s390/cio/blacklist.c:132:28: warning: incorrect type in
argument 2 (different signedness)
drivers/s390/cio/blacklist.c:132:28: expected unsigned int *val
drivers/s390/cio/blacklist.c:132:28: got int *cssid
drivers/s390/cio/blacklist.c:136:28: warning: incorrect type in
argument 2 (different signedness)
drivers/s390/cio/blacklist.c:136:28: expected unsigned int *val
drivers/s390/cio/blacklist.c:136:28: got int *ssid
drivers/s390/cio/blacklist.c:140:28: warning: incorrect type in
argument 2 (different signedness)
drivers/s390/cio/blacklist.c:140:28: expected unsigned int *val
drivers/s390/cio/blacklist.c:140:28: got int *devno
cssid, ssid and devno are of course unsigned, so let's make the
variables unsigned as well.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/core: Remove IB_DEVICE_SEND_W_INV capability flag
IB/umem: Avoid sign problems when demoting npages to integer
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6:
Blackfin serial driver: fix up tty core set_ldisc API change breakage bug
Blackfin arch: protect only the SPI bus controller with CONFIG_SPI_BFIN
Blackfin arch: fixup warnings with the new cplb saved values
Blackfin Serial Driver: Clean up BF54x macro in blackfin UART driver.
-tip testing found the following build error:
drivers/built-in.o: In function `mcs_receive_irq':
mcs7780.c:(.text+0x4e429): undefined reference to `crc32_le'
drivers/built-in.o: In function `mcs_hard_xmit':
mcs7780.c:(.text+0x4e9af): undefined reference to `crc32_le'
with:
http://redhat.com/~mingo/misc/config-Sun_Jun__8_22_56_14_CEST_2008.bad
the reason is a missing enablement of the CRC32 library in the Kconfig.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch increments the version to 3.92.1.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On 5761 non-e devices, two problems prevent the administrator from
overriding the WOL settings in the device's NVRAM.
The first problem is that GPIO 0 and GPIO 2 have been swapped. This
change prevented the administrator from turning on WOL when it is
disabled in NVRAM. The fix is to add a new path for the 5761 that
swaps the two GPIOs in the code as well.
The second problem is that GPIO 1 could not be toggled by the driver
because the GPIO is shared with the debug UART GPIO. This will prevent
the administrator from being able to turn WOL off if it was enabled in
NVRAM. The fix is to always disable the debug UART after a GRC reset.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes a problem where the TG3_FLAG_10_100_ONLY flag was
testing against the wrong flags variable.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The git commit ef167e2703 entitled
"Fix supporting flowctrl code" introduced a bug that prevents 5714S,
5715S and 5780S devices from falling back to a forced link mode. The
problem is that the added flow control check will always fail if flow
control is set to autoneg and either RX or TX (or both) flow control
is enabled. The driver defaults to setting flow control to autoneg
and advertises both RX and TX flow control.
The fix is to remove the errant check.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 54d29ad33e (Power Supply: fix race
in device_create) introduced a race in power_supply_uevent. Previously it
checked that power_supply is available by checking for dev->driver_data.
But now dev->driver_data is set before power_supply->dev is initialised.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
fix race between:
ieee80211_open->ieee80211_led_radio->led_trigger_event->led_set_brightness->iwl3945_led_brightness_set
(which assumes that "led->priv" is not NULL)
and
iwl3945_pci_probe->iwl3945_setup_deferred_work->(...)->iwl3945_bg_alive_start->iwl3945_alive_start->iwl3945_led_register->iwl3945_led_register_led
which sets priv field in struct iwl3945_led
after
led->led_dev.brightness_set = iwl3945_led_brightness_set;
(...)
led_classdev_register(device, &led->led_dev);
http://kerneloops.org/guilty.php?guilty=iwl3945_led_brightness_set&version=2.6.25-release&start=1671168&end=1703935&class=oops
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: ipw3945-devel@lists.sourceforge.net
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a data alignment issue in the zd1211rw driver.
The IEEE80211_STYPE_QOS_DATA bit should be used as a bitwise test
to test for the presence of the 2 byte QoS control field.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes an issus that made "iwconfig eth1 power on" non-working.
When we get a "PS sleep" event, we have to confirm this to the firmware.
The confirm happens with a command, but this command is special: the
firmware won't send us a response. if_cs_host_to_card() is setting
priv->dnld_sent anyway, so this variable stayed at DNLD_DATA_SENT and
was never cleared back.
Now I put the special knowledge that the CMD_802_11_PS_MODE with
CMD_SUBCMD_SLEEP_CONFIRMED doesn't need to need a response by directly
clearing the dnld_sent state in lbs_send_confirmsleep().
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When another scan is in progress, a direct scan gets dropped on the
floor. However, that direct scan is usually the scan that's really
needed by userspace, and gets stomped on by all the broadcast scans the
ipw2200 driver issues internally. Make sure the direct scan happens
eventually, and as a bonus ensure that the passive scan worker is
cleaned up when appropriate.
The change of request_passive_scan form a struct work to struct
delayed_work is only to make the set_wx_scan() code a bit simpler, it's
still only used with a delay of 0 to match previous behavior.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Format string bug. Not exploitable, as this is only writable by root,
but worth fixing all the same.
Spotted-by: Ilja van Sprundel <ilja@netric.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
[POWERPC] ehea: Remove dependency on MEMORY_HOTPLUG
[POWERPC] Make walk_memory_resource available with MEMORY_HOTPLUG=n
[POWERPC] Use dev_set_name in pci_64.c
[POWERPC] Fix incorrect enabling of VMX when building signal or user context
[POWERPC] boot/Makefile CONFIG_ variable fixes
In 2.6.26, we added some support for send with invalidate work
requests, including a device capability flag to indicate whether a
device supports such requests. However, the support was incomplete:
the completion structure was not extended with a field for the key
contained in incoming send with invalidate requests.
Full support for memory management extensions (send with invalidate,
local invalidate, fast register through a send queue, etc) is planned
for 2.6.27. Since send with invalidate is not very useful by itself,
just remove the IB_DEVICE_SEND_W_INV bit before the 2.6.26 final
release; we will add an IB_DEVICE_MEM_MGT_EXTENSIONS bit in 2.6.27,
which makes things simpler for applications, since they will not have
quite as confusing an array of fine-grained bits to check.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
R8A66597 is similar to SH7723 USB 2.0 Host/Function module.
In addition, the USB of SH7366 is compatible with SH7723.
It can support SH7723 USB host by changing Kconfig.
Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Now that walk_memory_resource() is available regardless of
MEMORY_HOTPLUG's setting, this dependency is not needed.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
Acked-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is the patch that follows Linus's modification about set_ldisc.
Graf has built and tested it on BF537 using Linus's git Tree.
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
On a 64-bit architecture, if ib_umem_get() is called with a size value
that is so big that npages is negative when cast to int, then the
length of the page list passed to get_user_pages(), namely
min_t(int, npages, PAGE_SIZE / sizeof (struct page *))
will be negative, and get_user_pages() will immediately return 0 (at
least since 900cf086, "Be more robust about bad arguments in
get_user_pages()"). This leads to an infinite loop in ib_umem_get(),
since the code boils down to:
while (npages) {
ret = get_user_pages(...);
npages -= ret;
}
Fix this by taking the minimum as unsigned longs, so that the value of
npages is never truncated.
The impact of this bug isn't too severe, since the value of npages is
checked against RLIMIT_MEMLOCK, so a process would need to have an
astronomical limit or have CAP_IPC_LOCK to be able to trigger this,
and such a process could already cause lots of mischief. But it does
let buggy userspace code cause a kernel lock-up; for example I hit
this with code that passes a negative value into a memory registartion
function where it is promoted to a huge u64 value.
Cc: <stable@kernel.org>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/ipath: Fix SM trap forwarding
IB/ehca: Reject send WRs only for RESET, INIT and RTR state
MAINTAINERS: Update NetEffect (iw_nes) entry
IB/ipath: Fix device capability flags
IB/ipath: Avoid test_bit() on u64 SDMA status value
Packet sending is driven by two flags, tx_ready and tx_queued.
It was possible, that there were queued data for sending and
hardware was flagged as blocked but in fact it was not.
The tx_queued was indicator but should be really a counter else
first fragmented packet resets tx_queued flag, but there may be
pending packets which do not get sent.
New semantics:
tx_ready - set, if hw is ready to send packet, no packet is being
transferred right now
set the flag right at the place where data are copied
into hw memory and not earlier without checking if it
was succesful
tx_queued - count of enqueued packets, including fragments
Tested-by: Michal Rokos <michal.rokos@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Adds DMI system identifier for ThinkPad T61.
Originally written by Klaus S. Madsen.
Taken from http://launchpadlibrarian.net/10864950/hdaps-t61.patch
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: maximilian attems <max@stro.at>
Cc: Klaus S. Madsen <ubuntu@hjernemadsen.org>
Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This hooks up the platform-specific [gs]et_rtc_time functions so that
kernels using CONFIG_RTC_CLASS have RTC support on most PowerPC platforms.
A new driver, and one which we've been shipping in Fedora for a while
already, since otherwise RTC support breaks.
[akpm@linux-foundation.org: fix Kconfig indenting]
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Frame buffer and mode setting drivers can be built as modules,
so fb_mode_option needs to be exported to support these.
Prevents this error:
ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined!
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I made a change to u-boot that used the FP (Fractional Part) field of BRGR
to achieve more accurate baud rate generation. Unfortunately, the
atmel_serial driver looks at the whole BRGR register when trying to detect
the baud rate that the port is currently running at, so setting FP to a
nonzero value breaks the baud rate detection.
I'll sit on the u-boot patch for a while longer, but this is clearly a
bug in the atmel_serial driver which should be fixed.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Original report: """I used to force my console to black-on-white by the
command `setterm -inversescreen on`. In 2.6.26-rc4, I get lots of black
background characters."""
Another addendum to commit c9e587ab. This was previously missed out since
I was not aware of what vc_decscnm was for.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Reported-by: <thunder7@xs4all.nl>
Tested-by: <thunder7@xs4all.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If cpu specific cpufreq driver(i.e. longrun) has "setpolicy" function,
governor object isn't set into cpufreq_policy object at "__cpufreq_set_policy"
function in driver/cpufreq/cpufreq.c .
This causes a null object access at "store_scaling_setspeed" and
"show_scaling_setspeed" function in driver/cpufreq/cpufreq.c when reading or
writing through /sys interface (ex. cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed)
Addresses:
http://bugzilla.kernel.org/show_bug.cgi?id=10654https://bugzilla.redhat.com/show_bug.cgi?id=443354
Signed-off-by: CHIKAMA Masaki <masaki.chikama@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Chuck Ebbert <cebbert@redhat.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The interlaced and double line mode bits should not be copied to new
console when the console is switched. Otherwise, the new console may be
set to incorrect refresh rate.
Also, the x and y offsets does not need to be copied.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change the name of the device from "rtc-ds1374" to just "ds1374", to match
what all other RTC drivers do. I seem to remember that this name was
chosen to avoid possible confusion with an older ds1374 driver, but that
driver was removed 3 months ago.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Although if people have questions about ARCnet, perhaps it's _better_
for them to be mailing dwmw2@cam.ac.uk about it...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As commit 6089093e58 ("ip2: fix crashes on
load/unload") fixed the ip2 crashes on load/unload by making ip2/ip2main
one module (ip2), Kconfig shouldn't mention a now non-existing module.
Signed-off-by: Roland.Kletzing <devzero@web.de>
Acked-by: Alan Cox <alan@redhat.com>
Cc: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some drivers are using too generic "serial" name for driver_name, this
might cause issues, like this:
Freescale QUICC Engine UART device driver
proc_dir_entry 'serial' already registered
Call Trace:
[cf82de50] [c0007f7c] show_stack+0x4c/0x1ac (unreliable)
[cf82de90] [c00b03fc] proc_register+0xfc/0x1ac
[cf82dec0] [c00b05c8] create_proc_entry+0x60/0xac
[cf82dee0] [c00b23dc] proc_tty_register_driver+0x60/0x98
[cf82def0] [c016dbd8] tty_register_driver+0x1b4/0x228
[cf82df20] [c0184d70] uart_register_driver+0x144/0x194
[cf82df40] [c030a378] ucc_uart_init+0x2c/0x94
[cf82df50] [c02f21a0] kernel_init+0x98/0x27c
[cf82dff0] [c000fa74] kernel_thread+0x44/0x60
^^ The board is using ucc_uart.c and 8250.c, both registered as
"serial".
This patch fixes two drivers that are using "serial" for driver_name and
not "ttyS" for dev_name. Drivers that are using "ttyS" for dev_name, will
conflict anyway, so we don't bother with these.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Alan Cox <alan@redhat.com>
Acked-By: Timur Tabi <timur@freescale.com>
Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The temporary structure for calculated CVT mode is not initialized. Few
fields have only bits or-ed or and-ed so they may be left in incorrect
(random) state.
Testing of the tridentfb seems like a good exercise for the fbdev layer.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If a block is computed (rather than read) then a check/repair operation
may be lead to believe that the data on disk is correct, when infact it
isn't. So only compute blocks for failed devices.
This issue has been around since at least 2.6.12, but has become harder to
hit in recent kernels since most reads bypass the cache.
echo repair > /sys/block/mdN/md/sync_action will set the parity blocks to the
correct state.
Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If an array was created with --assume-clean we will oops when trying to
set ->resync_max.
Fix this by initializing ->recovery_wait in mddev_find.
Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During the initial array synchronization process there is a window between
when a prexor operation is scheduled to a specific stripe and when it
completes for a sync_request to be scheduled to the same stripe. When
this happens the prexor completes and the stripe is unconditionally marked
"insync", effectively canceling the sync_request for the stripe. Prior to
2.6.23 this was not a problem because the prexor operation was done under
sh->lock. The effect in older kernels being that the prexor would still
erroneously mark the stripe "insync", but sync_request would be held off
and re-mark the stripe as "!in_sync".
Change the write completion logic to not mark the stripe "in_sync" if a
prexor was performed. The effect of the change is to sometimes not set
STRIPE_INSYNC. The worst this can do is cause the resync to stall waiting
for STRIPE_INSYNC to be set. If this were happening, then STRIPE_SYNCING
would be set and handle_issuing_new_read_requests would cause all
available blocks to eventually be read, at which point prexor would never
be used on that stripe any more and STRIPE_INSYNC would eventually be set.
echo repair > /sys/block/mdN/md/sync_action will correct arrays that may
have lost this race.
Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This addresses other oopsing paths in "spidev" by changing how it manages
refcounting. It decouples the lifecycle of the per-device data from the
class device (not just the spi device):
- Use class_{create,destroy} not class_{register,unregister}.
- Use device_{create,destroy} not device_{register,unregister}.
- Free the per-device data only when TWO conditions are true:
* Driver is unbound from underlying SPI device, and
* Device is no longer open (new)
Also, spi_{get,set}_drvdata not dev_{get,set}_drvdata for simpler code.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Sebastian Siewior <bigeasy@tglx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SM/SMA traps received by the ipath driver should be forwarded to the
SM if it is running on the host. The ib_ipath driver was incorrectly
replying with "bad method."
Signed-off-by: Ralph Campbell <ralph.campbell@qlogic.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The low-level interrupt handler on s390 checks for _TIF_WORK_INT and
exits the guest context, if work is pending.
TIF_WORK_INT is defined as_TIF_SIGPENDING | _TIF_NEED_RESCHED |
_TIF_MCCK_PENDING. Currently the sie loop checks for signals and
reschedule, but it does not check for machine checks. That means that
we exit the guest context if a machine check is pending, but we do not
handle the machine check.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
CC: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Carsten Otte <cotte@de.ibm.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Fairly simple. "dev_use" was being allocated as a zero length array
because of bad math on 64-bit systems, causing a crash in
find_first_zero_bit(). One-liner follows:
Signed-off-by: Ben Collins <ben.collins@canonical.com>
Acked-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alias brd to rd in the hope of helping legacy users. Suggested by Jan.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We don't need to reserve "unset" resources. Trying to reserve
them results in messages like this, which are ugly but harmless:
system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but
we still need it for now.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering:
fixlet to a57c1bade5 libata-sff:
Fix oops reported in kerneloops.org for pnp devices with no ctl
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Tested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Check that tda827x_config is defined before attempting to use it.
Signed-off-by: Sigmund Augdal <sigmund@snap.tv>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
On the TDA18271HD/C1, we perform RF tracking filter correction for VHF low
band, only. If supplied a frequency out of range, the error must be returned
to the caller (tda18271c1_rf_tracking_filter_calibration) so that it can
decide whether or not to write to register EB14, RFC_CPROG[7:0]
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Testing whether xceive_pin is non-zero is not good enough as 0 is a valid
value. Instead explicitly test whether the Xceive tuner is used.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is patch for fix data structure in querycap syscall.
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
-tip testing found the following build failure:
LD .tmp_vmlinux1
drivers/built-in.o: In function `generic_set_freq':
tuner-xc2028.c:(.text+0xbd896): undefined reference to `request_firmware'
tuner-xc2028.c:(.text+0xbdd7a): undefined reference to `release_firmware'
drivers/built-in.o: In function `xc_load_fw_and_init_tuner':
xc5000.c:(.text+0xc68e6): undefined reference to `request_firmware'
xc5000.c:(.text+0xc6abe): undefined reference to `release_firmware'
with this config:
http://redhat.com/~mingo/misc/config-Tue_May_20_18_11_34_CEST_2008.bad
the reason is another kconfig tool bug that has to be worked around in
the driver's Kconfig file: if FW_LOADER is selected in a second
dependency, that is not properly propagated up the dependencies.
in this case, FW_LOADER is selected from MEDIA_TUNER_XC2028:
config MEDIA_TUNER_XC2028
tristate "XCeive xc2028/xc3028 tuners"
depends on VIDEO_MEDIA && I2C
depends on HOTPLUG
select FW_LOADER
which got selected by MEDIA_TUNER:
config MEDIA_TUNER
tristate
default VIDEO_MEDIA && I2C
depends on VIDEO_MEDIA && I2C
select FW_LOADER if !MEDIA_TUNER_CUSTOMIZE && HOTPLUG
but the kconfig tool did not pick up this second-order dependency and
allowed CONFIG_FW_LOADER=m to be selected - in which case the build
fails.
the workaround i found was to move the select of FW_LOADER one level up,
so that the buggy kconfig tool can notice it and can act appropriately.
This problem can probably be worked around in other ways as well, i went
for the minimal fix.
Obviously, the kconfig tool should be fixed, it is not reasonable to
expect driver authors to do manual dependency resolution (that kconfig
itself already does) and uglify the Kconfig files. The kconfig tool did
nothing to warn about this situation and did not prevent this faulty
.config from being constructed.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
