| Age | Commit message (Collapse) | Author |
|---|
|
The adt7475 driver creates pwm#_auto_channel_temp attributes instead
of the standard pwm#_auto_channels_temp. Fix it.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
|
|
The comment says that limits are cached for 60 seconds but the code
actually caches them for only 2 seconds. Align the code on the
comment, as 60 seconds makes more sense.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
|
|
The logic of temperature fault flags is wrong, it shows faults when
there are none and vice versa. Fix it.
I can't believe this has been broken since the driver was added, 8
months ago, basically breaking temp1 and temp3, and nobody ever
complained.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
|
|
Avoid registering channels that have zero divider settings in them, as this
will only lead to kernel OOPS from divide-by-zero when the sysfs entry is
read.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
wm831x_gp_ldo_get_mode()
If ret is unsigned, the checks for negative wm831x_reg_read() return values
are wrong. The error value should be transmitted to its caller, e.g.
wm831x_gp_ldo_get_status() which tests for a negative return value.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
|
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
|
implementation."
This reverts commit 38783e671399b5405f1fd177d602c400a9577ae6.
It causes kernel bugzilla #14594
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the NAPI poll function(emac_poll), check for netif_running()
is unnecassary. In addition to associated runtime overhead, it
also results in a continuous softirq loop when the interface is
brought down under heavy traffic(tested wit Traffic Generator).
Once the interface is disabled, the poll function always returns
zero(with the check for netif_running) and napi_complete() would
never get called resulting in softirq loop.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the NAPI poll function, check for netif_running() is unnecassary.
In addition to associated runtime overhead, it also results in
continuous softirq loop when the interface is brought down under heavy
traffic(tested with Traffic Generator).Once the interface is disabled,
the poll function always returns zero(with the check for netif_running)
and napi_complete() would never get called resulting in softirq loop.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The returned error should stay negative
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Karsten Keil <keil@b1-systems.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use the existing random_ether_addr() to generate random MAC
instead of doing it by-hand.
Signed-off-by: Stanislav O. Bezzubtsev <stas@lvk.cs.msu.su>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The version string already contains the printk level
specifying it again results in the following message
being printed:
<6>r6040: RDC R6040 NAPI ...
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
|
|
* git://git.infradead.org/users/dwmw2/iommu-2.6.32:
intel-iommu: Support PCIe hot-plug
intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough
intel-iommu: Check for 'DMAR at zero' BIOS error earlier.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: psmouse - remove unneeded '\n' from psmouse.proto parameter
Input: atkbd - restore LED state at reconnect
Input: force LED reset on resume
Input: fix locking in memoryless force-feedback devices
|
|
* 'for-linus' of git://neil.brown.name/md:
md/raid5: Allow dirty-degraded arrays to be assembled when only party is degraded.
Don't unconditionally set in_sync on newly added device in raid5_reshape
md: allow v0.91 metadata to record devices as being active but not in-sync.
md: factor out updating of 'recovery_offset'.
|
|
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
[S390] s390: fix single stepping on svc0
[S390] sclp: undo quiesce handler override on resume
[S390] reset cputime accounting after IPL from NSS
[S390] monreader: fix use after free bug with suspend/resume
|
|
If the waker is killed before it can replay outstanding URBs, these URBs
won't be freed or will be replayed at the next open. This patch closes
the window by explicitely discarding outstanding URBs.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.
For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22
Bug:
driver for all MTU up to 1536 use receive buffer size 1536
As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.
Example:
host_good> ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good> ping host_r8169
Ok
host_good> ping -s 1500 host_r8169
Fail
host_good> ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good> ping -s 1500 host_r8169
Ok
Bonus: got rid of magic number 8
Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch adds the missing "get_xstats_size" callback for the
netlink interface, which is required if "fill_xstats" is used,
as pointed out by Patrick McHardy.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In 2.6.32-rc the new EMS USB CAN driver was contributed and added the Kconfig
entry right behind an entry of the same *vendor*. This teared the SJA1000
based driver selection into pieces.
This fix cleans up the 2.6.32-rc Kconfig files for the CAN drivers and moves
the SJA1000 and USB Kconfig portions into the belonging directories.
As there are many new CAN drivers in the queue getting this cleanup into
2.6.32-rc would massively reduce the problems for the upcoming drivers.
Thanks,
Oliver
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Due commit 4b77b0a2ba27d64f58f16d8d4d48d8319dda36ff, it is not more
possible to pci_restore_state() more than once without calling
pci_save_state() in the middle.
Actually running a ethtool test on s2io makes the card inactive,
and it needs to unload/reload the module to fix.
This patch just save the state just after it restore in order to
keep the old behaviour
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 2.6.32-rc6 from wireless-testing, the following warning is emitted:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:860 check_for_stack+0xaa/0xe0()
Hardware name: HP Pavilion dv2700 Notebook PC
ehci_hcd 0000:00:02.1: DMA-API: device driver maps memory fromstack
[addr=ffff8800b6e2bca8]
Modules linked in: <Removed>
Pid: 16378, comm: modprobe Not tainted 2.6.32-rc6-wl #244
Call Trace:
[<ffffffff81049698>] warn_slowpath_common+0x78/0xb0
[<ffffffff8104972c>] warn_slowpath_fmt+0x3c/0x40
[<ffffffff811ae52a>] check_for_stack+0xaa/0xe0
[<ffffffff811afc8d>] debug_dma_map_page+0xfd/0x170
[<ffffffffa006297a>] usb_hcd_submit_urb+0x3da/0x9c0 [usbcore]
[<ffffffff81076e6f>] ? lockdep_init_map+0x5f/0x5d0
[<ffffffffa0063365>] usb_submit_urb+0xe5/0x260 [usbcore]
[<ffffffffa0064b7e>] usb_start_wait_urb+0x5e/0xf0 [usbcore]
[<ffffffffa0063943>] ? usb_init_urb+0x23/0x40 [usbcore]
[<ffffffffa0064cd4>] usb_bulk_msg+0xc4/0x150 [usbcore]
[<ffffffffa0441a91>] T.719+0x31/0x40 [p54usb]
[<ffffffffa0441acf>] p54u_upload_firmware_3887+0x2f/0x490 [p54usb]
[<ffffffffa049c667>] ? p54_parse_firmware+0x427/0x450 [p54common]
<Rest of traceback removed>
---[ end trace f77df0316ddad3de ]---
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This reverts commit b8ecd988b1670035a05035c553c08331214d6603.
Due to poor API call balancing by me, this commit not only broke ipw2200
if it can't find it's firmware, it broke ipw2100 basically anytime you
removed the module. At this point in the cycle, let's just put it back
to a sane state and try again next time...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
In a system where the ctrl-alt-del init action initiated by signal
quiesce suspends the machine the quiesce handler override for
_machine_restart, _machine_halt and _machine_power_off needs to be
undone, otherwise the override is still present in the resumed
system. The next shutdown would then load the quiesce state psw
instead of performing the correct shutdown action.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
The monreader device driver doesn't set dev->driver_data to NULL after
freeing the corresponding data structure. This leads to a use after
free bug in the freeze/thaw suspend/resume functions after the device
has been opened and closed once. Fix this by clearing dev->driver_data
in the close() function.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
The get parameter function should return a string without a life-feed.
Otherwise you'll see additional empty line in sysfs parameters file.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
Even though input core tells us to restore LED state and repeat rate
at resume keyboard may be reconnected either by request from userspace
(via sysfs) or just by pulling it from the box and plugging it back in.
In these cases we still need to restore state ourselves.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
We should be sending EV_LED event down to drivers upon resume even in cases
when in-kernel state of the LED is off since device could come up with some
leds turned on.
Reported-and-tested-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
degraded.
Normally is it not safe to allow a raid5 that is both dirty and
degraded to be assembled without explicit request from that admin, as
it can cause hidden data corruption.
This is because 'dirty' means that the parity cannot be trusted, and
'degraded' means that the parity needs to be used.
However, if the device that is missing contains only parity, then
there is no issue and assembly can continue.
This particularly applies when a RAID5 is being converted to a RAID6
and there is an unclean shutdown while the conversion is happening.
So check for whether the degraded space only contains parity, and
in that case, allow the assembly.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
When a reshape finds that it can add spare devices into the array,
those devices might already be 'in_sync' if they are beyond the old
size of the array, or they might not if they are within the array.
The first case happens when we change an N-drive RAID5 to an
N+1-drive RAID5.
The second happens when we convert an N-drive RAID5 to an
N+1-drive RAID6.
So set the flag more carefully.
Also, ->recovery_offset is only meaningful when the flag is clear,
so only set it in that case.
This change needs the preceding two to ensure that the non-in_sync
device doesn't get evicted from the array when it is stopped, in the
case where v0.90 metadata is used.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
This is a combination that didn't really make sense before.
However when a reshape is converting e.g. raid5 -> raid6, the extra
device is not fully in-sync, but is certainly active and contains
important data.
So allow that start to be meaningful and in particular get
the 'recovery_offset' value (which is needed for any non-in-sync
active device) from the reshape_position.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
PPS events must be recorded according to PPS's mode settings.
If a process asks for (i.e.) capture-assert events only, when the PPS
client calls the pps_event() function to save the current PPS event, we
should verify the event type and then discard unwanted ones.
Also, without this patch userland processes waiting for a specific PPS
event (assert or clear but not both) may be awakened at wrong time.
Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: William S. Brasher <billb958@door.net>
Tested-by: Reg Clemens <clemens@dwf.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Userland programs may read/write PPS parameters at same time and these
operations may corrupt PPS data.
Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Reg Clemens <clemens@dwf.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
TASK_INTERRUPTIBLE and friends are now only available after including
<linux/sched.h>, so include it when needed.
bus_id is no longer available/necessary, so remove that.
Android pmem driver is not available in mainline, so remove its hooks
from drivers/video.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
In case of failure, device_create() returns not NULL but the error code.
The current code checks for non-NULL though which causes kernel oops in
sysfs_create_group() when device_create() fails. Check for error using
IS_ERR() and propagate the error value using PTR_ERR() instead of fixed
-ENODEV code returned now...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
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>
|
|
v3020_mmio_read_bit() always returns 0 when left_shift > 7.
v3020_mmio_read_bit()'s return type is (unsigned char). The code returns
a value masked by (1 << left_shift) that is casted to the return type. If
left_shift is larger than 7, the cast will always result in a 0 return
value. The problem was discovered with left_shift = 16, and the included
patch corrects the problem.
The bug was introduced in the last (Apr 3 2009) commit of the file, kernel
versions 2.6.30 and later.
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Raphael Assenat <raph@8d.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
drivers/rtc/rtc-vr41xx.c: In function 'vr41xx_rtc_irq_set_freq':
drivers/rtc/rtc-vr41xx.c:217: warning: comparison of distinct pointer types lacks a cast
drivers/rtc/rtc-vr41xx.c:217: warning: right shift count >= width of type
drivers/rtc/rtc-vr41xx.c:217: warning: passing argument 1 of '__div64_32' from incompatible pointer type
include/asm-generic/div64.h:35: note: expected 'uint64_t *' but argument is of type 'long unsigned int *'
Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The config FB_PRE_INIT_FB entry in drivers/video/Kconfig pushes all entries
below it out of the menuconfig selection. Fix this.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Free IRQ on remove.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This seems to be a different model (with a different PCI ID) than the
"Quatro" card that is also in the list.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
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>
|
|
struct uart_port::iobase is unsigned long, so use %lx as printk format
specifier.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
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>
|
|
According to Documentation/rtc.txt, RTC_WKALM_SET sets the alarm time and
enables/disables the alarm. We implement RTC_WKALM_SET through
pcf50633_rtc_set_alarm. The enabling/disabling part was missing.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
Reported-by: Michael 'Mickey' Lauer <mickey@openmoko.org>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Balaji Rao <balajirrao@openmoko.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The PCF50633 stores a month value of 1-12, but the kernel wants 0-11.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Balaji Rao <balajirrao@openmoko.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
at91sam9g45 non ES lots have an alternate pixel clock calculation formula.
Introduce this one with condition on the cpu_is_xxxxx() macros.
Newer 9g45 SOC will not have good pixel clock calculation without this
fix.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Fix wrong bit mask for blanking register. Due to the error a CRT monitor
blanks off due to wrong frequency (out of range) instead of PM signal
(vertical and horizontal frequencies cut off).
Just compare the mask with bits set in the switch(blank) clause below the
changed line.
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>
|
|
Remove fb_save_state() and fb_restore_state operations from frame buffer layer.
They are used only in two drivers:
1. savagefb - and cause bug #11248
2. uvesafb
Usage of these operations is misunderstood in both drivers so kill these
operations, fix the bug #11248 and avoid confusion in the future.
Tested on Savage 3D/MV card and the patch fixes the bug #11248.
The frame buffer layer uses these funtions during switch between graphics
and text mode of the console, but these drivers saves state before
switching of the frame buffer (in the fb_open) and after releasing it (in
the fb_release). This defeats the purpose of these operations.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11248
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Reported-by: Jochen Hein <jochen@jochen.org>
Tested-by: Jochen Hein <jochen@jochen.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michal Januszewski <spock@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
To support PCIe hot plug in IOMMU, we register a notifier to respond to device
change action.
When the notifier gets BUS_NOTIFY_UNBOUND_DRIVER, it removes the device
from its DMAR domain.
A hot added device will be added into an IOMMU domain when it first does IOMMU
op. So there is no need to add more code for hot add.
Without the patch, after a hot-remove, a hot-added device on the same
slot will not work.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
The model for IOMMU passthrough is that decent devices that can cope
with DMA to all of memory get passthrough; crappy devices with a limited
dma_mask don't -- they get to use the IOMMU anyway.
This is done on the basis that IOMMU passthrough is usually wanted for
performance reasons, and it's only the decent PCI devices that you
really care about performance for, while the crappy 32-bit ones like
your USB controller can just use the IOMMU and you won't really care.
Unfortunately, the check for this was only looking at dev->dma_mask, not
at dev->coherent_dma_mask. And some devices have a 32-bit
coherent_dma_mask even though they have a full 64-bit dma_mask.
Even more unfortunately, fixing that simple oversight would upset
certain broken HP devices. Not only do they have a 32-bit
coherent_dma_mask, but they also have a tendency to do stray DMA to
unmapped addresses. And then they die when they take the DMA fault they
so richly deserve.
So if we do the 'correct' fix, it'll mean that affected users have to
disable IOMMU support completely on "a large percentage of servers from
a major vendor."
Personally, I have little sympathy -- given that this is the _same_
'major vendor' who is shipping machines which claim to have IOMMU
support but have obviously never _once_ booted a VT-d capable OS to do
any form of QA. But strictly speaking, it _would_ be a regression even
though it only ever worked by fluke.
For 2.6.33, we'll come up with a quirk which gives swiotlb support
for this particular device, and other devices with an inadequate
coherent_dma_mask will just get normal IOMMU mapping.
The simplest fix for 2.6.32, though, is just to jump through some hoops
to try to allocate coherent DMA memory for such devices in a place that
they can reach. We'd use dma_generic_alloc_coherent() for this if it
existed on IA64.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
