Fix the following problem, related to hardware flow control (CTS/RTS):
Transmitting while CTS line is asserted in DMA mode, due to not checking
for tx-stopped condition.
We found these problems while testing the UARTs with hardware
flow-control.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: "Andrew Victor" <avictor.za@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update Documentation/sysctl/vm.txt and Documentation/filesystems/proc.txt.
More specifically, the section on /proc/sys/vm in
Documentation/filesystems/proc.txt was removed and a link to
Documentation/sysctl/vm.txt added.
Most of the verbiage from proc.txt was simply moved in vm.txt, with new
addtional text for "swappiness" and "stat_interval".
Signed-off-by: Peter W Morreale <pmorreale@novell.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 58dab916df, which
makes my Nehalem come to a nasty crawling almost-halt. It looks like it
turns off caching of regular kernel RAM, with the understandable
slowdown of a few orders of magnitude as a result.
Acked-by: Ingo Molnar <mingo@elte.hu>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
b44 chip has some hardware limitations, that need GFP_DMA bounce
buffers in some situations.
In order to not deplete DMA zone, we should keep allocated GFP_DMA skb
only for driver use. At rx time, we copy such skb to newly allocated
skb, reusing existing copybreak infrastructure.
On machines with low amount of memory, all skb meet the hardware limitation,
so no copy is needed. We detect this situation using a new device flag, set
to one if one GFP_DMA skb was ever allocated by b44_alloc_rx_skb().
Previously allocated skb, even outside from DMA zone will then be recycled,
to have minimal impact on DMA zone use.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Tested-by: Ionut Leonte <ionut.leonte@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When CONFIG_DMI is not enabled, dmi detection should flag that no board
could be detected (err=1) rather than another error condition (err<0).
This fixes the fallback to manual probing for all motherboards, even
those without DMI strings, when CONFIG_DMI=n.
Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Switch the IN9 32X MAX over from port probing to the preferred DMI
probe method.
Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
Tested-by: Paul Hartman <paul.hartman+gentoo@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The switch-over to using DMI board strings to identify abituguru3 compatible
mainboards works most of the time, but sometimes the vendor has substantially
modified the board string between BIOS revisions.
We have found that the vendor chipset identification string (provided in
brackets) changes frequently and is of no use to us. The rest of the board
string sometimes changes in subtle ways, e.g. whitespace or variations in
capitalization.
The new comparison code checks only a part of the supplied DMI board string,
trimming the bracketed content, whitespace, and ignoring case as necessary.
This fixes a bug where an IP35 Pro running an early BIOS would not be
detected without the force=1 module parameter, and also speculatively
fixes other similiar issues.
Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
Reported-by: Nick Pasich <NewsLetters@nickandbarb.net>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hwmon driver for the ADT7475 chip.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Current Temperature for K8 RevG desktop CPUs is a "normalized value"
which can be below ambient temperature.
As a consequence lots of RevG systems report temperatures like:
$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +17 C
Core0 Temp: +3 C
Core1 Temp: +21 C
Core1 Temp: +5 C
being quite below ambient temperature.
There are even reports of negative temperature values.
This patch corrects the temperature reporting of k8temp for
RevG desktop CPUs.
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Meaning of ThermSenseCoreSel bit was inverted beginning with K8 RevF.
That means with current driver temp1/temp2 belong to core 1 and
temp3/temp4 belong to core 0 on a K8 RevF/RevG CPU.
This patch ensures that temp1/temp2 always belong to core 0 and
temp3/temp4 to core 1 for all K8 revisions.
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Add warning about wrong CPU temperature readouts on all fam F rev F.
The allowed combinations of processors ensure that all processors
in a multisocket system have similar characteristics, e.g.
(1) provide temperature sensor interface (>=RevC && <RevF)
(2) are affected by erratum #141 (>=RevF)
Thus it is sufficient to check the revision of the boot CPU.
For "mixed silicon support" refer to
"Revision Guide for AMD Athlon 64 and AMD Opteron Processors" (RevA-E) and
"Revision Guide for AMD NPT Family 0Fh Processors" (RefF-G).
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
[IA64] SN specific version of dma_get_required_mask()
[IA64] generic_defconfig: Enable SATA_VITESSE
[IA64] dump stack on kernel unaligned warnings
[IA64] Turn on CONFIG_HAVE_UNSTABLE_CLOCK
[IA64] Update to use account_{steal,idle}_ticks
Update employer's care-of address in CREDITS file, and remove references
to some _very_ old stuff I'd forgotten I'd ever done.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda - Fix invalid amp value for STAC925x
ASoC: Fix the power update function for snd_soc_dapm_value_mux
sound: virtuoso: do not overwrite EEPROM on Xonar D2/D2X
ALSA: hda - Fix HP dv5 mic input
ALSA: hda - Fix missing initialization of NID 0x0e for STAC925x
ALSA: USB quirk for Logitech Quickcam Pro 9000 name
ALSA: hda - Fix stac92hd83xxx_amp_nids[]
ALSA: hda - Add automatic model setting for Samsung Q45
ALSA: hda - Don't reset HP pinctl in patch_sigmatel.c
ALSA: hda: stac92hd8xxx amp mixers
ALSA: hda - Fix silent headphone output on Panasonic CF-74
ALSA: hda - Update model descriptions in patch_sigmatel.c
ALSA: hda - Use queue_delayed_work()
ALSA: hda - Add quirk for another HP dv5
ALSA: hda - Add support of NVidia MCP78 HDMI
ALSA: hda - Fix a typo
ALSA: hda - More fixes on Gateway entries
ALSA: patch_sigmatel: Add missing Gateway entries and autodetection
ALSA: hda - Add a new function to seek for a codec ID
This patch is for Alan Cox as it related to the tty layer.
Hopefully the hso driver is again relatively stable with this fix.
Signed-off-by: Denis Joseph Barrow <D.Barow@option.com>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The HSO changes for kref introduced a recursive spinlock take. All
functions which call put_rxbuf_data already have serial->serial_lock
grabbed.
[Comment to code added-AC]
Signed-off-by: Denis Joseph Barrow <D.Barrow@option.com>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 4a90f09b20 added kref stuff to
ftdi_sio, but missed tty_kref_put at one exit point in
ftdi_process_read.
Signed-off-by: Jim Paris <jim@jtan.com>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This was not implemented correctly for the pnx8xxx_uart driver.
[From further discussion:
Correct, you can look to it as two separate bugs:
a) the next character is not ignored while it should;
b) the status bits 31-8 are copied to the 'ch' variable while they shouldn't.
Both bugs prevent correct break signal handling (and therefore correct
behaviour of the magic SysRq key). Bug b didn't cause too much trouble
earlier because in most situations the status bits are all zero; for
this case they unfortunately aren't.
]
Signed-off-by: Mischa Jonker <mischa.jonker@nxp.com>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add SupraExpress 336i PnP Voice Modem
Tested and working with the following device: (output from lspnp -v)
01:01.00 SUP1381 (unknown)
state = active
io 0x2f8-0x2ff
irq 3
Signed-off-by: Daniel Gagnon <daniel.gagnon@yahoo.com>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Most of netmos 9835 hardware is handled by parport-serial. IBM introduces
a device which doesn't have any parallel ports and have screwed subdevice
PCI id (not corresponding to port numbers).
Handle this device (9710:9835 1014:0299) properly.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If you issue an ioctl to flush a tty as the line discipline is changing or
otherwise unplugged you can get a crash. The bug is very old but the rest
of the BKL lock dropping and some very "good" luck on Ingo's part caught
an example.
Use the correct ldisc_ref form so that we wait for the ldisc change to
complete and then flush
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mike's change: 0a582440f "sched: fix sched_slice())" broke group
scheduling by forgetting to reload cfs_rq on each loop.
This patch fixes aim7 regression and specjbb2005 regression becomes
less than 1.5% on 8-core stokley.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Tested-by: Jayson King <dev@jaysonking.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
It is about time to bump up the version.
Features added since 0.21: fan suspend/resume support, preserve radio
state across power off (for some radio types), built-in UWB radio
rfkill support and thermal alarm events support.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
HKEY event 0x6030 is a helper for Lenovo's Advanced Thermal Management
Windows driver, which is, of course, completely undocumented.
Silence any warnings about it being an unknown alarm, and report it
unmodified for userspace.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Better document the Unitialized HFSP quirk, and modularize it a bit.
This makes the code flow easier to read and reduces LOC.
Apply the Unitialized HFSP closer to the source (i.e. inside the
get_fan_status()), this fixes a harmless buglet where at driver init
with the quirk active, the user could set the hwmon pwm1 attribute and
switch out of pwm1_mode=2 to pwm1_mode=0 without changing pwm1_mode
directly.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Ask users to tell us about any unhandled events they find.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Handle some HKEY events that are actually firmware alarms. For
now, we do the simple thing: log specific messages to the log and let
the thinkpad-specific event pass to userspace.
In the future, these events will be migrated to generic notifications
and subsystems.
These alarms are NOT available on all ThinkPads. E.g. the T43 only
issues 0x6011 and 0x6012.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Create a platform specific version of dma_get_required_mask()
for ia64 SN Altix. All SN Altix platforms support 64 bit DMA
addressing regardless of the size of system memory.
Create an ia64 machvec for dma_get_required_mask, with the
SN version unconditionally returning DMA_64BIT_MASK.
Signed-off-by: John Keller <jpk@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
CONFIG_SATA_VITESSE=y was not added to generic_defconfig when
sn2_defconfig was removed. SGI Altix systems that use an IO10
base IO card to drive the root device are unable to boot without
the Vitesse controller.
Signed-off-by: Brent Casavant <bcasavan@sgi.com>
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Clean up the hotkey_notify() handler, which handles the HKEY notifications
from the ACPI firmware. It was getting too long and deep.
No functional changes.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Unfortunately, POSIX in all of its braindamage, do not state that userspace has
to deal with EINTR in read/write and friends... so, lesser code just doesn't.
Switch from *_interruptible to *_killable on the sysfs- and procfs-related
mutexes. This closes this possible can of worms.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Often the cause of kernel unaligned access warnings is not
obvious from just the ip displayed in the warning. This adds
the option via proc to dump the stack in addition to the warning.
The default is off (just display the 1 line warning). To enable
the stack to be shown: echo 1 > /proc/sys/kernel/unaligned-dump-stack
Signed-off-by: Doug Chapman <doug.chapman@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Add rfkill support for USB UWB radio devices on very recent ThinkPad
laptop models.
The new subdriver is moslty a trimmed down copy of the wwan subdriver.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Store in firmware NVRAM the radio state on machine shutdown for WWAN and
bluetooth. Also, try to set the initial boot state of these radios as the
rfkill default state for their respective classes.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Instruct the firmware to not enable the radios when resuming. This
is safer, and the rfkill core will take care to manually enable any
radios that need to be enabled.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
This code is required to keep the thinkpad-acpi maintainer sane, and
it is disabled by default.
Add a debug facility to simulate an rfkill hardware rocker switch, a
bluetooth rfkill soft-switch, a WWAN rfkill soft-switch on thinkpads.
The simulated switches obviously do not kill any radios in hardware or
firmware (unlike the real one). They also don't issue deprecated proc
events.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
sched_clock() on ia64 is based on ar.itc, so is never
completely synchronized between cpus. On some platforms
(e.g. certain models of SGI Altix) it may be running at
radically different frequencies.
Based on a patch from Dimitri Sivanich which set this
just for SN2 && GENERIC kernels ... it is needed for
all ia64 machines.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Update documentation to reflect the new location of the
thinkpad-acpi driver.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch fixes the following errors caused by
79741dd357 which changed
the prototypes of account_steal_time() and account_idle_time().
> CC arch/ia64/xen/time.o
> arch/ia64/xen/time.c: In function 'consider_steal_time':
> arch/ia64/xen/time.c:132: warning: passing argument 1 of 'account_steal_time' makes integer from pointer without a cast
> arch/ia64/xen/time.c:132: error: too many arguments to function 'account_steal_time'
> arch/ia64/xen/time.c:133: warning: passing argument 1 of 'account_steal_time' makes integer from pointer without a cast
> arch/ia64/xen/time.c:133: error: too many arguments to function 'account_steal_time'
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Tony Luck <tony.luck@intel.com>
As the kernel warning states: "IRQF_DISABLED is not guaranteed on shared
IRQs". Since these IRQs' values are hardcoded and my test system doesn't
show any shared use of IRQs at all, rather make them non-shared than
non-disabled.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Apparently this doesn't make sense. Otherwise the queue gets disabled as
soon as it's getting empty and can only be resurrected by a driver
restart.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Originally this must have been a rewrite error when introducing
'chain_index'. But the original driver did not use the previous chain
item everywhere: when altering the address tx_chain_tail points to, it
should move forward, not backwards.
Also this is not an "index" but rather the penultimate element in the
chain, so rename it accordingly.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Triggering TX before the write to the DMA status mask register leads to
transferring packets with maximum payload no matter what the actual
packet size is.
While here, also trigger RX scheduling after writing the DMA status mask
register, like it was in the original driver before it was sent
upstream.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The called netif_rx_schedule() does all the work for us:
- it checks the return value of netif_rx_schedule_prep() and
- if everything is ok calls __netif_rx_schedule().
Before this change, the driver received absolutely nothing.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This function needs an early exit condition to function properly, or
else caller assumes napi workload wasn't enough to handle all received
packets and korina_rx is called again (and again and again and ...).
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Without this the driver will crash when the NIC is being restarted.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The new value is the one used in the external patch before and allows at
least a standard MTU of 1500 to be handled correctly. Impact of this
change gets visible when bigger packets are to be received, issuing:
| ping -s 492 <IP>
and bigger payload sized led to 100% packet loss.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Using platform_set_drvdata() here makes no sense, since the driver_data
field has already been filled with valuable data (i.e. the MAC address).
Also having driver_data point to the net_device is rather pointless
since struct korina_device contains an apropriate field for it.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Itai Levi