We really don't want the BIOS flash mapping hacks to get automatically
loaded.
No idea why it isn't using pci_register_driver() though -- that should
be fine... and is even _present_ but disabled by #if 0.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
xen/blkfront: use blk_rq_map_sg to generate ring entries
block: reduce stack footprint of blk_recount_segments()
cciss: shorten 30s timeout on controller reset
block: add documentation for register_blkdev()
block: fix bogus gcc warning for uninitialized var usage
It needs to happen before any firewire driver actually registers itself,
and that was previously handled by having the Makefile list the core
ieee1394 files before the drivers.
But now there are firewire drivers in drivers/media, and the Makefile
games aren't enough. So just make ieee1394_init happen earlier in the
init sequence, the way all other bus layers already do.
Reported-and-tested-by: Ingo Molnar <mingo@elte.hu>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Henrik Kurelid <henrik@kurelid.se>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Ben Backx <ben@bbackx.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On occasion, the request will apparently have more segments than we
fit into the ring. Jens says:
> The second problem is that the block layer then appears to create one
> too many segments, but from the dump it has rq->nr_phys_segments ==
> BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
> xen-blkfront not handling the merging on its own. It should check that
> the new page doesn't form part of the previous page. The
> rq_for_each_segment() iterates all single bits in the request, not dma
> segments. The "easiest" way to do this is to call blk_rq_map_sg() and
> then iterate the mapped sg list. That will give you what you are
> looking for.
> Here's a test patch, compiles but otherwise untested. I spent more
> time figuring out how to enable XEN than to code it up, so YMMV!
> Probably the sg list wants to be put inside the ring and only
> initialized on allocation, then you can get rid of the sg on stack and
> sg_init_table() loop call in the function. I'll leave that, and the
> testing, to you.
[Moved sg array into info structure, and initialize once. -J]
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
If reset_devices is set for kexec, then cciss will delay 30 seconds
since the old 5i controller _may_ need that long to recover. Replace
the long sleep with incremental sleep and tests to reduce the 30 seconds
to worst case for 5i, so that other controllers will proceed quickly.
Reviewed-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
With the mandatory algorithm testing at registration, we have
now created a deadlock with algorithms requiring fallbacks.
This can happen if the module containing the algorithm requiring
fallback is loaded first, without the fallback module being loaded
first. The system will then try to test the new algorithm, find
that it needs to load a fallback, and then try to load that.
As both algorithms share the same module alias, it can attempt
to load the original algorithm again and block indefinitely.
As algorithms requiring fallbacks are a special case, we can fix
this by giving them a different module alias than the rest. Then
it's just a matter of using the right aliases according to what
algorithms we're trying to find.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
[libata] pata_legacy: for VLB 32bit PIO don't try tricks with slop
[libata] pata_amd: program FIFO
sata_mv: fix SoC interrupt breakage
pata_it821x: resume from hibernation fails with RAID volume
These devices are generally used with ATA anyway and it seems that some
ATAPI will need us to issue the right number of words. Therefore as we
can't switch mid burst on VLB devices we should only use 32bit I/O for
suitable block sizes.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
With 32bit PIO we can use the posted write buffers, but only for 32bit I/O
cycles. This means we must disable the FIFO for ATAPI where a final 16bit
cycle may occur.
Rework the FIFO logic so that we disable the FIFO then selectively
re-enable it when we set the timings on AMD devices. Also fix a case
where we scribbled on PCI config 0x41 of Nvidia chips when we shouldn't.
Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
For some reason, sata_mv doesn't clear interrupt status during init
when it's running on an SoC host adapter. If the bootloader has
touched the SATA controller before starting Linux, Linux can end up
enabling the SATA interrupt with events pending, which will cause the
interrupt to be marked as spurious and then be disabled, which then
breaks all further accesses to the controller.
This patch makes the SoC path clear interrupt status on init like in
the non-SoC case.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Hibernation didn't work for me since I started to use IT8212 controller.
I did some debugging (booting with no_console_suspend init=/bin/sh).
Found that resume fails (2.6.28) with "serial number mismatch 'some
garbage' != 'some other garbage'" and "revalidation failed" messages.
That's because the controller firmware fills different serial number in
the IDENTIFY every boot.
The patch below fixes the resume simply clearing the serial number. The
proper fix would be probably to fill in the serial number of the RAID
volume instead. I assume that there must be something like that stored on
the drives but I don't know where.
Fix resume on pata_it821x RAID volume by clearing the serial number in
IDENTIFY data, which is otherwise different on each boot.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
During host driver module removal del_gendisk() results in a final
put on drive->gendev and freeing the drive by drive_release_dev().
Convert device drivers from using struct kref to use struct device
so device driver's object holds reference on ->gendev and prevents
drive from prematurely going away.
Also fix ->remove methods to not erroneously drop reference on a
host driver by using only put_device() instead of ide*_put().
Reported-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Just copy the comment from drivers/scsi/sr.c::sr_done()
(from which the capacity hack has been originated).
Cc: Borislav Petkov <petkovbb@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix missing parentheses so PIO/DMA timings for master device on the
second channel are programmed correctly (IOW "8 0 24 16" offset values
should be used instead of the current "8 0 16 16").
[ The bug went unnoticed because after PIO/DMA timings get programmed
incorrectly for the third device they are overwritten with timings
for the fourth device and since BIOS should also program timings for
the third device everything should work fine until suspend/resume
cycle or user requested transfer mode changes. ]
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
[bart: update patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Documentation/kernel-parameters.txt
- ide=nodma is no longer valid.
drivers/ide/Kconfig
- The module is ide-core.ko not ide.
drivers/ide/ide.c
- It took me a while to figure out what the arguments %d.%d:%d to nodma
module parameter ment, so I added a comment to each.
- Added a comment to each of the sscanf lines.
- There is a bug, if j is 0 it would previously clear all the other bits
except the current device, changed in three different places.
mask &= (1 << i) should be mask &= ~(1 << i).
Signed-off-by: David Fries <david@fries.net>
[bart: s/disk/device/ in ide.c, beautify patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* 'for-linus' of git://neil.brown.name/md:
md: avoid races when stopping resync.
md/raid10: Don't call bitmap_cond_end_sync when we are doing recovery.
md/raid10: Don't skip more than 1 bitmap-chunk at a time during recovery.
When iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults
because PTE write bit is not set on some of PTE's. This is because
iwlan driver calls DMA mapping with PCI_DMA_TODEVICE which is read only
in mapping PTE. But iwlan device actually writes to the mapped page to
update its contents. This issue is not exposed in swiotlb. But VT-d
hardware can capture this fault and stop the fault transaction.
The following patch fixes the issue.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Bhavesh Davda <bhavesh@vmware.com>
Tested-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
io_mapping_create_wc can return NULL on error and io_mapping_free() should be
called on one of the error-cleanup path.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch adds two new device ids to the asix driver.
One comes directly from the asix driver on their web site, the other was
reported by Armani Liao as needed for the MSI X320 to get the driver to
work properly for it.
Reported-by: Armani Liao <aliao@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
However we still have another issue with ioremap_wc not falling back
properly or somehow doing something else stupid, this probably needs
to be tracked down.
Signed-off-by: Dave Airlie <airlied@redhat.com>
edid->revision == 0 should be valid (at least, so the error message
indicates. :) and wikipedia seems to indicate that EDID 1.0 existed.
We can dump the entire check, since edid->revision is a u8, so
it can't ever be less than 0.
Marko reports in RH bz#476735 that his monitor claims to be
EDID 1.0, and therefore hits the check and is stuck at 800x600 because
of it.
Reported-by: Marko Ristola <marko.ristola@kolumbus.fi>
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
The first time we install a mode, the vblank will be disabled for a pipe
and so drm_vblank_get() in drm_vblank_pre_modeset() will fail. As we
unconditionally call drm_vblank_put() afterwards, the vblank reference
counter becomes unbalanced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
In some cases we may receive a mode config that has a different
CRTC<->encoder map that the current configuration. In that case, we
need to disable any re-routed encoders before setting the mode,
otherwise they may not pick up the new CRTC (if the output types are
incompatible for example).
Tested-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
We've seen cases in the wild where the VBT sync data is wrong, so add
some code to fix it up in that case, taking care to make sure that the
total is greater than the sync end.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
These are normal; we walk through different values looking for the right
one, so why flood the screen with messages?
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
There has been a race in raid10 and raid1 for a long time
which has only recently started showing up due to a scheduler changed.
When a sync_read request finishes, as soon as reschedule_retry
is called, another thread can mark the resync request as having
completed, so md_do_sync can finish, ->stop can be called, and
->conf can be freed. So using conf after reschedule_retry is not
safe.
Similarly, when finishing a sync_write, calling md_done_sync must be
the last thing we do, as it allows a chain of events which will free
conf and other data structures.
The first of these requires action in raid10.c
The second requires action in raid1.c and raid10.c
Cc: stable@kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
For raid1/4/5/6, resync (fixing inconsistencies between devices) is
very similar to recovery (rebuilding a failed device onto a spare).
The both walk through the device addresses in order.
For raid10 it can be quite different. resync follows the 'array'
address, and makes sure all copies are the same. Recover walks
through 'device' addresses and recreates each missing block.
The 'bitmap_cond_end_sync' function allows the write-intent-bitmap
(When present) to be updated to reflect a partially completed resync.
It makes assumptions which mean that it does not work correctly for
raid10 recovery at all.
In particularly, it can cause bitmap-directed recovery of a raid10 to
not recovery some of the blocks that need to be recovered.
So move the call to bitmap_cond_end_sync into the resync path, rather
than being in the common "resync or recovery" path.
Cc: stable@kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
When doing recovery on a raid10 with a write-intent bitmap, we only
need to recovery chunks that are flagged in the bitmap.
However if we choose to skip a chunk as it isn't flag, the code
currently skips the whole raid10-chunk, thus it might not recovery
some blocks that need recovering.
This patch fixes it.
In case that is confusing, it might help to understand that there
is a 'raid10 chunk size' which guides how data is distributed across
the devices, and a 'bitmap chunk size' which says how much data
corresponds to a single bit in the bitmap.
This bug only affects cases where the bitmap chunk size is smaller
than the raid10 chunk size.
Cc: stable@kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
Add i2c_board_info for RiscPC PCF8583
i2c: Make sure i2c_algo_bit_data.timeout is HZ-independent
i2c-dev: Clarify the unit of ioctl I2C_TIMEOUT
i2c: Timeouts reach -1
i2c: Fix misplaced parentheses
Add the necessary i2c_board_info structure to fix the lack of PCF8583
RTC on RiscPC.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
i2c_algo_bit_data.timeout is supposed to be in jiffies, so drivers
should use set this value in terms of HZ.
Ultimately I think this field should be discarded in favor of
i2c_adapter.timeout, but that's left for a future patch.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Lennert Buytenhek <kernel@wantstofly.org>
Acked-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
The unit in which user-space can set the bus timeout value is jiffies
for historical reasons (back when HZ was always 100.) This is however
not good because user-space doesn't know how long a jiffy lasts. The
timeout value should instead be set in a fixed time unit. Given the
original value of HZ, this unit should be 10 ms, for compatibility.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
With a postfix decrement these timeouts reach -1 rather than 0, but
after the loop it is tested whether they have become 0.
As pointed out by Jean Delvare, the condition we are waiting for should
also be tested before the timeout. With the current order, you could
exit with a timeout error while the job is actually done.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The PCIe port driver currently sets the PCIe AER error reporting bits for
any root or switch port without first checking to see if firmware will grant
control. This patch moves setting these bits to the AER service driver
aer_enable_port routine. The bits are then set for the root port and any
downstream switch ports after the check for firmware support (aer_osc_setup)
is made. The patch also unsets the bits in a similar fashion when the AER
service driver is unloaded.
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Andrew Patterson <andrew.patterson@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan>
Move the enabling of interrupts after all of the data structures
are setup so that we can safely run the interrupt handler as
soon as it is registered.
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan>
Prakash reported that his c51-mcp51 ondie sound card doesn't work with
MSI. But if he hacks out the HT-MSI quirk, MSI works fine.
So this patch reworks the nv_msi_ht_cap_quirk(). It will now only
enable ht_msi on own its root device, avoiding enabling it on devices
following that root dev.
Reported-by: Prakash Punnoor <prakash@punnoor.de>
Tested-by: Prakash Punnoor <prakash@punnoor.de>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan>
I found that the function fdtv_frontend_init in the file firedtv-fe.c was
missing a case for FIREDTV_DVB_S2 which resulted in "frequency limits
undefined" errors in syslog.
Signed-off-by: Beat Michel Liechti <bml303@gmail.com>
Change by Stefan R: combine it with case case FIREDTV_DVB_S as
originally suggested by Beat Michel. This enables FE_CAN_FEC_AUTO also
for FireDTV-S2 devices which is possible as long as only DVB-S channels
are used. FE_CAN_FEC_AUTO would be wrong for DVB-S2 channels, but those
cannot be used yet since the driver is not yet converted to S2API.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Combination of the following changes:
Mon, 23 Feb 2009 14:21:10 +0100 (CET)
firedtv: reinstate debug logging option
Henrik Kurelid tells me that FCP debug logging (which I removed during
cleanups) is still useful when working on driver issues together with
end users. So bring it back in an updated form with only 60% of the
original code footprint.
Logging can be enabled with
# echo -1 > /sys/module/firedtv/parameters/debug
1 instead of -1 enables only FCP header logging,
2 instead of -1 enables only hexdumps of the entire FCP frames.
0 switches logging off again.
Fri, 20 Feb 2009 20:54:27 +0100 (CET)
firedtv: build fix for INPUT=m and DVB_FIREDTV=y
Thu, 19 Feb 2009 20:40:39 +0100
firedtv: use msecs_to_jiffies
Pointed out by Mauro Carvalho Chehab.
Sun Feb 15 20:50:46 CET 2009
firedtv: some more housekeeping
Fix an old checkpatch warning and a new compiler warning.
Sun Feb 15 15:33:17 CET 2009
firedtv: rename a file once more
At the moment, about a third of avc.c is specific to FireDTVs rather
than generic AV/C code. Rename it to firedtv-avc.c.
Sun Feb 15 15:33:17 CET 2009
firedtv: dvb demux: more compact channels backing store
Replace struct firedtv_channel { bool active; int pid; } channel[16];
by unsigned long channel_active; u16 channel_pid[16];.
Sun Feb 15 15:33:17 CET 2009
firedtv: dvb demux: some simplifications
c->active was unnecessarily cleared twice.
Also, by marking the channel inactive before the for loop,
the loop becomes identical with fdtv_channel_collect().
Sun Feb 15 15:33:17 CET 2009
firedtv: dvb demux: remove a bogus loop
This loop is unnecessary because
- only active channel[].pid's will be sent to the device,
- when a channel is activated, its pid is set to dvbdmxfeed->pid.
Perhaps the original code was there because it was initially not fully
covered by the fdtv->demux_mutex.
Sun Feb 15 15:33:17 CET 2009
firedtv: dvb demux: fix mutex protection
fdtv_start_feed() accessed the channel list unsafely.
Fully serialize it with itself and fdtv_stop_feed().
Sun Feb 15 15:33:17 CET 2009
firedtv: dvb demux: fix missing braces
Original code was:
...
case DMX_TS_PES_OTHER:
//Dirty fix to keep firesat->channel pid-list up to date
for(k=0;k<16;k++){
if(firesat->channel[k].active == 0)
firesat->channel[k].pid =
dvbdmxfeed->pid;
break;
}
channel = firesat_channel_allocate(firesat);
break;
default:
...
Looks bogus in several respects. For now let's just add braces to the if
because that seems to be what the author meant.
Sun Feb 15 15:33:17 CET 2009
firedtv: allow build without input subsystem
!CONFIG_INPUT is very unlikely on systems on which firedtv is of
interest. But we can easily support it.
Sun Feb 15 15:33:17 CET 2009
firedtv: replace EXTRA_CFLAGS by ccflags
The former are deprecated.
The latter can depend on Kconfig variables.
Sun Feb 15 15:33:17 CET 2009
firedtv: concentrate ieee1394 dependencies
Move the entire interface with drivers/ieee1394 to firedtv-1394.c.
Move 1394-independent module initialization code to firedtv-dvb.c.
This prepares interfacing with drivers/firewire.
Sun Feb 15 15:33:17 CET 2009
firedtv: amend Kconfig menu prompt
Sun Feb 15 15:33:17 CET 2009
firedtv: remove kernel version compatibility macro
Sun Feb 15 15:33:17 CET 2009
firedtv: combine header files
avc.h and firedtv-*.h are small and currently not shared with other
drivers, hence concatenate them all into firedtv.h.
Sun Feb 15 15:33:17 CET 2009
firedtv: misc style touch-ups
Standardize on lower-case hexadecimal constants. Adjust whitespace.
Omit unnecessary pointer type casts and an unnecessary list head
initialization. Use dev_printk.
Wed Feb 11 21:21:04 CET 2009
firedtv: avc, ci: remove unused constants
Wed Feb 11 21:21:04 CET 2009
firedtv: avc: remove bitfields from read descriptor response operands
Don't use bitfields in struct types of on-the-wire data.
Wed Feb 11 21:21:04 CET 2009
firedtv: avc: remove bitfields from DSD command operands
Don't use bitfields in struct types of on-the-wire data.
Wed Feb 11 21:21:04 CET 2009
firedtv: avc: header file cleanup
Remove unused constants and declarations.
Move privately used constants into .c files.
Wed Feb 11 21:21:04 CET 2009
firedtv: avc: remove bitfields from FCP frame types
Don't use bitfields in struct types of on-the-wire data.
Also move many privately used constants from avc.h to avc.c
and remove some unused constants.
Sun, 18 Jan 2009 16:30:00 +0100 (CET)
firedtv: avc: fix offset in avc_tuner_get_ts
The parentheses were wrong. It didn't matter though because this code
only writes a 0 into an area which is already initialized to 0.
Sun, 18 Jan 2009 16:30:00 +0100 (CET)
firedtv: avc: reduce stack usage, remove two typedefs
It is safe to share a memory buffer for command frame and response frame
because the response data come in after the command frame was last used.
Even less stack would be required if only the actual required frame size
instead of the entire FCP register size was allocated.
Also, rename the defined types AVCCmdFrm and AVCRspFrm to
struct avc_command_frame and struct avc_response_frame.
TODO: Remove the bitfields in these types.
Sun, 18 Jan 2009 16:30:00 +0100 (CET)
firedtv: cmp: move code to avc
Sun, 18 Jan 2009 16:30:00 +0100 (CET)
firedtv: iso: move code to firedtv-1394
Sun, 18 Jan 2009 16:30:00 +0100 (CET)
firedtv: iso: remove unnecessary struct type definitions
Sun, 18 Jan 2009 16:30:00 +0100 (CET)
firedtv: iso: style changes and fixlets
Add cleanup after failure in setup_iso_channel.
Replace printk() by dv_err().
Decrease indentation level in rawiso_activity_cb().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Combination of the following changes:
Sat, 17 Jan 2009 14:47:34 +0100
firedtv: rename variables and functions from firesat to firedtv
Signed-off-by: Rambaldi <Rambaldi@xs4all.nl>
Additional changes by Stefan Richter:
Renamed struct firedtv *firedtv to struct firedtv *fdtv and
firedtv_foo_bar() to fdtv_foo_bar() for brevity.
Sat, 17 Jan 2009 13:07:44 +0100
firedtv: rename files from firesat to firedtv
Signed-off-by: Rambaldi <Rambaldi@xs4all.nl>
Additional changes by Stefan Richter:
Name the directory "firewire" instead of "firedtv".
Standardize on "-" instead of "_" in file names, because that's what
drivers/firewire/ and drivers/media/dvb/dvb-usb/ use too.
Build fix.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
SPIN_LOCK_UNLOCKED is deprecated. The following makes the change suggested
in Documentation/spinlocks.txt
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
There was a bug causing the initialization to fail if adapter number was
greater than zero. The adapter was however registered which caused the driver
to oops the second time initialization was tried.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Parsed and used the length_field() of the PMT message instead of using
the length field of the message struct, which does not seem to be filled
correctly by e.g. MythTV.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The SystemId of the ca_info message was filled with garbage.
It now returns what the card returns.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Combination of the following changes:
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: increase FCP frame length for DVB-S2 tune QSPK
The last three bytes didn't go out to the wire.
Effect of the fix not yet tested.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: replace mdelay by msleep
These functions can sleep (and in fact sleep for the duration of a whole
FCP transaction). Hence msleep is more appropriate here.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: trivial reorganization in avc_api
Reduce nesting level by factoring code out of avc_tuner_dsd() into
helper functions.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: trivial cleanups in avc_api
Use dev_err(), no CamelCase function names, adjust comment style, put
#if 0 around unused code and add FIXME comments, standardize on
lower-case hexadecimal constants, use ALIGN() for some frame length
calculations, make a local function static...
The code which writes FCP command frames and reads FCP response frames
is not yet brought into canonical kernel coding style because this
involves changes of typedefs (on-the-wire bitfields).
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: don't retry oPCR updates endlessly
In the theoretical case that the target node wasn't handling the lock
transactions as expected or there was continued interference by other
initiating nodes, these functions wouldn't return for ages.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: remove bitfield typedefs from cmp, fix for big endian CPUs
Use macros/ inline functions/ standard byte order accessors to read and
write oPCR register values (big endian bitfields, on-the-wire data).
The new code may not be the ultimate optimum, but it doesn't occur in a
hot path.
This fixes the CMP code for big endian CPUs. So far I tested it only on
a little endian CPU though.
For now, include <asm/byteorder.h> instead of <linux/byteorder.h>
because drivers/ieee1394/*.h also include the former. I will fix this
in drivers/ieee1394 and firedtv later.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: trivial cleanups in cmp
Reduce nesting level by means of early exit and goto.
Remove obsolete includes, use dev_err(), no CamelCase function names...
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: trivial cleanups in firesat-ci
Whitespace, variable names, comment style...
Also, use dvb_generic_open() and dvb_generic_release() directly as
our hooks in struct file_operations because firedtv's wrappers merely
called these generic functions.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: remove CA debug code
This looks like it is not necessary to have available for endusers who
cannot patch kernels for bug reporting and tests of fixes.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: remove AV/C debug code
This looks like it is not necessary to have available for endusers who
cannot patch kernels for bug reporting and tests of fixes.
Sun, 2 Nov 2008 13:45:00 +0100 (CET)
firedtv: remove various debug code
Most of this was already commented out. And that which wasn't is not
relevant in normal use.
Mon, 29 Sep 2008 19:22:48 +0200 (CEST)
firedtv: register input device as child of a FireWire device
Instead of one virtual input device which exists for the whole lifetime
of the driver and receives events from all connected FireDTVs, register
one input device for each firedtv device. These input devices will show
up as children of the respective firedtv devices in the sysfs hierarchy.
However, the implementation falls short because of a bug in userspace:
Udev's path_id script gets stuck with 100% CPU utilization, maybe
because of an assumption about the maximum ieee1394 device hierarchy
depth.
To avoid this bug, we use the fw-host device instead of the proper
unit_directory device as parent of the input device.
There is hope that the port to the new firewire stack won't be inhibited
by this userspace bug because there are no fw-host devices there.
Mon, 29 Sep 2008 19:21:52 +0200 (CEST)
firedtv: fix string comparison and a few sparse warnings
Sparse found a bug:
while ((kv_buf + kv_len - 1) == '\0')
should have been
while (kv_buf[kv_len - 1] == '\0')
We fix it by a better implementation without a temporary copy.
Also fix sparse warnings of 0 instead of NULL and signedness mismatches.
Mon, 29 Sep 2008 19:21:20 +0200 (CEST)
firedtv: remove unused struct members
and redefine an int as a bool.
Mon, 29 Sep 2008 19:20:36 +0200 (CEST)
firedtv: fix initialization of dvb_frontend.ops
There was a NULL pointer reference if no dvb_frontend_info was found.
Also, don't directly assign struct typed values to struct typed
variables. Instead write out assignments to individual strcut members.
This reduces module size by about 1 kB.
Mon, 29 Sep 2008 19:19:41 +0200 (CEST)
firedtv: remove unused dual subunit code from initialization
No FireDTVs with more than one subunit exists, hence simplify the
initialization for the special case of one subunit. The driver was able
to check for more than one subunit but was broken for more than two
subunits.
While we are at it, add several missing cleanups after failure, and
include a few dynamically allocated structures diretly into struct
firesat instead of allocating them separately.
Mon, 29 Sep 2008 19:19:08 +0200 (CEST)
firedtv: add vendor_id and version to driver match table
Now that nodemgr was enhanced to match against the root directory's
vendor ID if there isn't one in the unit directory, use this to
prevent firedtv to be bound to wrong devices by accident.
Also add the AV/C software version ID to the match flags for
completeness; specifier ID and software only make sense as a pair.
Mon, 29 Sep 2008 19:18:30 +0200 (CEST)
firedtv: use hpsb_node_read(), _write(), _lock()
because they are simpler and treat the node generation more correctly.
While we are at it, clean up and simplify surrounding code.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
hpsb_read, hpsb_write, hpsb_lock are sleeping functions which nobody is
in danger to use in atomic context. Besides, in_interrupt does not
cover all types of atomic context.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
While Module_Vendor_ID in the configuration ROM's root directory is
mandatory, there often aren't vendor IDs in unit directories. This
affects the new firedtv driver which is meant to be auto-loaded and
matched only for vendor-specific devices.
We now always copy ne->vendor_id into ud->vendor_id before we scan a
unit directory (and fill in a possibly present vendor ID from there).
This way, the root directory's vendor ID is used as fallback in the
"uevent" environment for modprobe'ing per module alias when a node was
plugged in, and in the driver match routine when protocol drivers are
bound to unit directories. It will however not be used as sysfs
attribute of a unit directory device.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
These will be used by the firedtv driver. Like hpsb_node_write() they
are much better APIs for high-level drivers than hpsb_write() and its
siblings --- easier to use correctly and also terser.
Unlike hspb_node_write(), the two new functions will only be used by
one call site. Hence make them static inline instead of exported
symbols.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
A compiler barrier (explicit on the read side, implicit on the write
side) is not quite enough for what has to be accomplished here. Use
hardware memory barriers on systems which need them.
(Of course a full fix of generation handling would require much more
than this. The ieee1394 core's bus generation counter had to be tied to
the controller's bus generation counter; cf. Kristian's stack. It's
just that I have other current business with the code around these
barrier()s, so why not do at least this small fix.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Combination of the following changes:
Tue, 26 Aug 2008 00:17:30 +0200 (CEST)
firedtv: fix remote control input
and update the scancode-to-keycode mapping to a current model. Per
default, various media key keycodes are emitted which closely match what
is printed on the remote. Userland can modify the mapping by means of
evdev ioctls. (Not tested.)
The old scancode-to-keycode mapping is left in the driver but cannot be
modified by ioctls. This preserves status quo for old remotes.
Tue, 26 Aug 2008 00:11:28 +0200 (CEST)
firedtv: replace tasklet by workqueue job
Non-atomic context is a lot nicer to work with.
Sun, 24 Aug 2008 23:30:00 +0200 (CEST)
firedtv: move some code back to ieee1394 core
Partially reverts "ieee1394: remove unused code" of Linux 2.6.25.
Sun, 24 Aug 2008 23:29:30 +0200 (CEST)
firedtv: replace semaphore by mutex
firesat->avc_sem and ->demux_sem have been used exactly like a mutex.
The only exception is the schedule_remotecontrol tasklet which did a
down_trylock in atomic context. This is not possible with
mutex_trylock; however the whole remote control related code is
non-functional anyway at the moment. This should be fixed eventually,
probably by turning the tasklet into a worqueue job.
Convert everything else from semaphore to mutex.
Also rewrite a few of the affected functions to unlock the mutex at a
single exit point, instead of in several branches.
Sun, 24 Aug 2008 23:28:45 +0200 (CEST)
firedtv: some header cleanups
Unify #ifndef/#define/#endif guards against multiple inclusion.
Drop extern keyword from function declarations.
Remove #include's into header files where struct declarations suffice.
Remove unused ohci1394 interface and related unused ieee1394 interfaces.
Add a few missing #include's and remove a few apparently obsolete ones.
Sort them alphabetically.
Sun, 24 Aug 2008 23:27:45 +0200 (CEST)
firedtv: nicer registration message and some initialization fixes
Print the correct name in dvb_register_adapter().
While we are at it, replace two switch cascades by one for loop, remove
a superfluous member of struct firesat and of two unused arguments of
AVCIdentifySubunit(), and fix bogus kfree's in firesat_dvbdev_init().
Tue, 26 Aug 2008 14:24:17 +0200 (CEST)
firesat: rename to firedtv
Suggested by Andreas Monitzer. Besides DVB-S/-S2 receivers, the driver
also supports DVB-C and DVB-T receivers, hence the previous project name
is too narrow now.
Not yet done: Rename source directory, files, types, variables...
Sun, 24 Aug 2008 23:26:23 +0200 (CEST)
firesat: add missing copyright notes
Reported by Andreas Monitzer and Christian Dolzer.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
- Add resending of AVC message to the card if no answer is received
- Replace the homebrewed event_wait function with a standard wait queue
- Clean up of log/error messages
- Increase debug level of avc communication
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
I have finally managed to get the CI support for the card working. The
implementation is a bare minimum to get encrypted channels to work in
kaffeine. It works fine with my T/CI card. Now and then I get an AVC
timeout and have to retune a channel in order to get it to work. Once
the CAM seemed to hang so I needed to remove and insert it again. I.e.
there are a number of glitches.
The latest version contains the following changes:
- Implemented the new hpsb iso interface so that data can be received
from the card
- Reduced some timers for demux setup which caused scanning to timeout
- Added possibility to unload driver
- Added support for getting C/N ratio
- Added two debug parameters to the driver; ca_debug and
avc_comm_debug.
- Added CI support that works for me in kaffeine
- Started working on CI MMI support. It now supports:
o Enter menu
o Receiving MMI objects
- Added support for 64-bit platforms
- Corrected DVB-C modulations problems
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (rebased, whitespace)
...so S2 owners now can at least watch DVB-S channels in linux.
Signed-off-by: Ben Backx <ben@bbackx.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This only makes sure that a DVB-S2 device is really recognized as a S2,
nothing else is added yet. It's using the string containing the model
that is stored in the configuration ROM, the older version was using
some hardware revision dependent part of the ROM.
Signed-off-by: Ben Backx <ben@bbackx.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Original code written by Christian Dolzer <c.dolzer@digital-everywhere.com>
Cleaned up by Greg.
Major cleanup and reorg by Manu Abraham <manu@linuxtv.org>
Additions also by Ben Backx <ben@bbackx.com>
Cc: Christian Dolzer <c.dolzer@digital-everywhere.com>
Cc: Andreas Monitzer <andy@monitzer.com>
Cc: Manu Abraham <manu@linuxtv.org>
Cc: Fabio De Lorenzo <delorenzo.fabio@gmail.com>
Cc: Robert Berger <robert.berger@reliableembeddedsystems.com>
Signed-off-by: Ben Backx <ben@bbackx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Added missing dependency to dvb/firesat/Kconfig,
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Tweaked dvb/Makefile.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
PCI bar 0 is used for memory mapped register access.
If ioremap fails (returns NULL), register access results
in crash.
Use pci_ioremap_bar() instead of ioremap(), the latter
fails on on 32 bit powerpc where pci resource address is
> 32 bits.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The PCI function to physical port mapping is valid only for
old firmware. New firmware (4.0.0+) abstracts this.
So driver should never try to access phy using invalid
mapping. The behavior is unpredictable when PCI functions
4-7 are enabled on the same NIC.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The existing driver code wasn't working. Neither the timeout was set
correctly, nor system reset was being triggered, as the driver seemed
to keep the WDT alive himself. There was also some unnecessary code.
Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>
In the KMS case, enter/leavevt won't fix up the interrupt handler for
us, so we need to do it at suspend/resume time. Make sure we don't fail
the resume if the chip is hung either.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
dev_priv->hw_status_page can be NULL, if i915_gem_retire_requests()
is called from i915_gem_busy_ioctl().
Signed-off-by Karsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
netns: fix double free at netns creation
veth : add the set_mac_address capability
sunlance: Beyond ARRAY_SIZE of ib->btx_ring
sungem: another error printed one too early
ISDN: fix sc/shmem printk format warning
SMSC: timeout reaches -1
smsc9420: handle magic field of ethtool_eeprom
sundance: missing parentheses?
smsc9420: fix another postfixed timeout
wimax/i2400m: driver loads firmware v1.4 instead of v1.3
vlan: Update skb->mac_header in __vlan_put_tag().
cxgb3: Add support for PCI ID 0x35.
tcp: remove obsoleted comment about different passes
TG3: &&/|| confusion
ATM: misplaced parentheses?
net/mv643xx: don't disable the mib timer too early and lock properly
net/mv643xx: use GFP_ATOMIC while atomic
atl1c: Atheros L1C Gigabit Ethernet driver
net: Kill skb_truesize_check(), it only catches false-positives.
net: forcedeth: Fix wake-on-lan regression
Add new USB ID codes. These come from two postings on forums and
mailing lists, and four are derived from the .inf that accompanies
the latest Realtek Windows driver for the RTL8187L.
Thanks to Viktor Ilijašić <viktor.ilijasic@gmail.com> and Xose Vazquez
Perez <xose.vazquez@gmail.com> for reporting these new ID's.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With DEBUG_NOTIFIERS it results in
[11330.890966] WARNING: at /home/bor/src/linux-git/kernel/notifier.c:88
notifier_call_chain+0x91/0xa0()
[11330.890977] Hardware name: PORTEGE 4000
[11330.890983] Invalid notifier called! ...
Without DEBUG_NOTIFIERS it most likely crashes on NULL pointer.
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Acked-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
there might be a nicer way to fix this but this is the simplest for now.
Signed-off-by: Pierre Willenbrock <pierre@pirsoft.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The object is dereferenced before the NULL check. Oops.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20235
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This ensures that the user gets the latest information from the hardware
on whether the buffer is busy, potentially reducing the working set of objects
that the user chooses.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the KMS case, we need to suspend/resume GEM as well. So on suspend, make
sure we idle GEM and stop any new rendering from coming in, and on resume,
re-init the framebuffer and clear the suspended flag.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The problem was that object_set_to_gpu_domain would set the new write_domains
that are getting set by this batchbuffer, then the accumulated flushes required
for all the objects in preparation for this batchbuffer were posted, and the
brand new write domain would get cleared by the flush being posted. Instead,
hang on to the new (or old if we're not changing it) value and set it after
the flush is queued.
Results from this noticably included conformance test failures from reads
shortly after writes (where the new write domain had been lost and thus not
flushed and waited on), but is a suspected cause of hangs in some apps when
a write domain is lost on a buffer that gets reused for instruction or
commmand state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
While not strictly required, it helped while thinking about the following
change. This change should be invariant.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Impact: module build fix
Fix:
ERROR: "sysdev_resume" [arch/x86/kernel/apm.ko] undefined!
ERROR: "sysdev_suspend" [arch/x86/kernel/apm.ko] undefined!
As these APIs are now used by the APM driver, which can be built
as a module.
Also fix a few extra (and inconsistent) newlines in comment blocks
preceding these functions.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move the sysdev_suspend/resume from the callee to the callers, with
no real change in semantics, so that we can rework the disabling of
interrupts during suspend/hibernation.
This is based on an earlier patch from Linus.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: remove CONFIG_ACPI_SYSTEM
fujitsu-laptop: Use RFKILL support bitmask from firmware
x86_64: Fix S3 fail path
x86_64: acpi/wakeup_64 cleanup
battery: don't assume we are fully charged when not charging or discharging
ACPI: EC: Add delay for slow MSI controller
http://kisskb.ellerman.id.au/kisskb/buildresult/72115/:
| net/mac80211/ieee80211_i.h:327: error: syntax error before 'volatile'
| net/mac80211/ieee80211_i.h:350: error: syntax error before '}' token
| net/mac80211/ieee80211_i.h:455: error: field 'sta' has incomplete type
| distcc[19430] ERROR: compile net/mac80211/main.c on sprygo/32 failed
This is caused by
| # define mfp ((*(volatile struct MFP*)MFP_BAS))
in arch/m68k/include/asm/atarihw.h, which conflicts with the new "mfp" enum in
net/mac80211/ieee80211_i.h.
Rename "mfp" to "st_mfp", as it's a way too generic name for a global #define.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Impact: fix bug
the third param in module_param(,,) is perm instead of default value.
we still need to assign default at first. Also, the default is now
zero not one, so fix the parameter text to reflect that.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Kashyap Desai <kadesai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The 8390 driver was structured by Al Viro to allow the flexibility
required by platforms. lib8390.c contains the core code which drivers
explicitly include:
- 8390.c includes lib8390.c to provide the standard ISA based driver.
- etherh.c includes it with the accessors defined for RiscPC platforms,
where it is addressed via the MMIO accessors with a device dependent
register spacing.
Other platform drivers do something similar.
However, b9a9b4b caused the kernel to contain not only the etherh
private build of lib8390 (included in etherh.c) but also lib8390.c
itself, and referred the new net_device_ops methods to the ISA version.
The result of this is is not pretty:
Unable to handle kernel paging request at virtual address 12032030
pgd = c8330000
[12032030] *pgd=00000000
Internal error: Oops: 18331805 [#1]
Modules linked in: ipv6
CPU: 0 Not tainted (2.6.29-rc3 #167)
PC is at do_set_multicast_list+0xd0/0x190
LR is at bitrev32+0x28/0x34
pc : [<c017aab4>] lr : [<c0139120>] psr: a0000093
sp : c8321d9c ip : c8321d84 fp : c8321dbc
r10: c80c6800 r9 : 00000000 r8 : c80c6b60
r7 : c80c6b80 r6 : cc80c800 r5 : c80c6800 r4 : 00000000
r3 : cc80c80c r2 : 00000004 r1 : 00000007 r0 : e0000000
Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
...
Fix up b9a9b4b by making etherh's net_device_ops refer to the internal
lib8390 functions, and remove the build of the ISA 8390.c driver.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove CONFIG_ACPI_SYSTEM. It was always set the same as CONFIG_ACPI,
and it had no menu label, so there was no way to set it to anything
other than "y".
Some things under CONFIG_ACPI_SYSTEM (acpi_irq_handled, acpi_os_gpe_count(),
event_is_open, register_acpi_notifier(), etc.) are used unconditionally
by the CA, the OSPM, and drivers, so we depend on them always being
present.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Up until now, we polled the rfkill status for every incoming FUJ02E3 ACPI event.
It turns out that the firmware has a bitmask which indicates what rfkill-related
state it can report.
The rfkill_supported bitmask is now used to avoid polling for rfkill at all in
the notification handler if there is no support. Also, it is used in the platform
device callbacks. As before we register all callbacks and report "unknown" if the
firmware does not give us status updates for that particular bit.
This was fed through checkpatch.pl and tested on the S6420, S7020 and P8010
platforms.
Signed-off-by: Tony Vroon <tony@linx.net>
Tested-by: Stephen Gildea <stepheng+linux@gildea.com>
Acked-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: Len Brown <len.brown@intel.com>
Instead of terminating after five retries, commands terminated by
ABORTED_COMMAND sense are retrying forever. The problem was
introduced by:
commit b60af5b0ad
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Nov 3 15:56:47 2008 -0500
[SCSI] simplify scsi_io_completion()
Which introduced an error whereby ABORTED_COMMAND now gets erroneously
retried in scsi_io_completion. Fix this by returning the behaviour
back to the default no retry.
Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Commit f27bac2761 which converted sd to
use ida instead of idr incorrectly removed sd_index_lock around id
allocation and free. idr/ida do have internal locks but they protect
their free object lists not the allocation itself. The caller is
responsible for that. This missing synchronization led to the same id
being assigned to multiple devices leading to oops.
Reported and tracked down by Stuart Hayes of Dell.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Stable Tree <stable@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Need to make sure the outgoing pdu can fit into a single skb. When
calulating the max. outgoing pdu payload size, take into consideration
of
- data can be held in the skb's fragment list, assume 512 bytes per
fragment, and
- data can be held in the headroom.
Signed-off-by: Karen Xie <kxie@chelsio.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
added per-task struct cxgb3i_task_data to track the data transmiting
progress and the state of the pdus to be transmitted.
Signed-off-by: Karen Xie <kxie@chelsio.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
- resize the work-request credit array to be based on skb's MAX_SKB_FRAGS.
- split the skb cb into tx and rx portion
- increase the default transmit window to 128K.
- stop queueing up the outgoing pdus if transmit window is full.
Signed-off-by: Karen Xie <kxie@chelsio.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* hibernate:
PM: Fix suspend_console and resume_console to use only one semaphore
PM: Wait for console in resume
PM: Fix pm_notifiers during user mode hibernation
swsusp: clean up shrink_all_zones()
swsusp: dont fiddle with swappiness
PM: fix build for CONFIG_PM unset
PM/hibernate: fix "swap breaks after hibernation failures"
PM/resume: wait for device probing to finish
Consolidate driver_probe_done() loops into one place
there's a few places that currently loop over driver_probe_done(), and
I'm about to add another one. This patch abstracts it into a helper
to reduce duplication.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <lenb@kernel.org>
Acked-by: Greg KH <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On hardware like the T61 it can take a couple of seconds for the battery
to start charging after the power is connected, and we incorrectly tell
userspace that we are fully charged, and then go back to charging.
Only mark a battery as fully charged when the preset charge matches either
the last full charge, or the design charge.
http://bugzilla.kernel.org/show_bug.cgi?id=12632
Signed-off-by: Richard Hughes <hughsient@gmail.com>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (26 commits)
drm/radeon: update sarea copies of last_ variables on resume.
drm/i915: Keep refs on the object over the lifetime of vmas for GTT mmap.
drm/i915: take struct mutex around fb unref
drm: Use spread spectrum when the bios tells us it's ok.
drm: Collapse identical i8xx_clock() and i9xx_clock().
drm: Bring PLL limits in sync with DDX values.
drm: Add locking around cursor gem operations.
drm: Propagate failure from setting crtc base.
drm: Check for a NULL encoder when reverting on error path
drm/i915: Cleanup the hws on ringbuffer constrution failure.
drm/i915: Don't add panel_fixed_mode to the probed modes list at LVDS init.
drm: Release user fbs in drm_release
drm/i915: Unpin the fb on error during construction.
drm/i915: Unpin the hws if we fail to kmap.
drm/i915: Unpin the ringbuffer if we fail to ioremap it.
drm/i915: unpin for an invalid memory domain.
drm/i915: Release and unlock on mmap_gtt error path.
drm/i915: Set framebuffer alignment based upon the fence constraints.
drm: Do not leak a new reference for flink() on an existing name
drm/i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()
...
Intel 8257x Ethernet boards have a feature called Serial Over Lan.
This feature works by emulating a serial port, and it is detected by
kernel as a normal 8250 port. However, this emulation is not perfect, as
also noticed on changeset 7500b1f602.
Before this patch, the kernel were trying to check if the serial TX is
capable of work using IRQ's.
This were done with a code similar this:
serial_outp(up, UART_IER, UART_IER_THRI);
lsr = serial_in(up, UART_LSR);
iir = serial_in(up, UART_IIR);
serial_outp(up, UART_IER, 0);
if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT)
up->bugs |= UART_BUG_TXEN;
This works fine for other 8250 ports, but, on 8250-emulated SoL port, the
chip is a little lazy to down UART_IIR_NO_INT at UART_IIR register.
Due to that, UART_BUG_TXEN is sometimes enabled. However, as TX IRQ keeps
working, and the TX polling is now enabled, the driver miss-interprets the
IRQ received later, hanging up the machine until a key is pressed at the
serial console.
This is the 6 version of this patch. Previous versions were trying to
introduce a large enough delay between serial_outp and serial_in(up,
UART_IIR), but not taking forever. However, the needed delay couldn't be
safely determined.
At the experimental tests, a delay of 1us solves most of the cases, but
still hangs sometimes. Increasing the delay to 5us was better, but still
doesn't solve. A very high delay of 50 ms seemed to work every time.
However, poking around with delays and pray for it to be enough doesn't
seem to be a good approach, even for a quirk.
So, instead of playing with random large arbitrary delays, let's just
disable UART_BUG_TXEN for all SoL ports.
[akpm@linux-foundation.org: fix warnings]
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The "break" would just result in reusing a free'd pointer. I don't have
the cards myself to test it though. :/
Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Caused by 736d54533a (sx.c: fix missed unlock_kernel() on error path in
sx_fw_ioctl()). You guys keep breaking things this way in every single
kernel release in at least couple of places... :-(
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix isdn/sc/shmem.c printk format warning:
drivers/isdn/sc/shmem.c:57: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With a postfix decrement timeouts will reach -1 rather than 0, so
the error path does not appear.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ethtool.h says the driver should set the magic field in get_eeprom and
verify it in set_eeprom. This patch adds this functionality using an
arbitary driver-specific magic value constant (0x9420).
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Roel Kluin recently fixed several instances where variables reach -1,
but 0 is tested afterwards. This patch fixes another, so the timeout
will be correctly detected and a warning printed.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a one liner change to have the driver use by default the v1.4
of the i2400m firmware instead of v1.3. The v1.4 version of the
firmware has been submitted to David Woodhouse for inclusion in the
linux-firmware tree and it is already available at
http://linuxwimax.org/Download.
The reason for this change is that the 1.3 release of the user space
software and firmware has a few issues that will make it difficult to
use with currently deployed commercial networks such as Xohm and
Clearwire.
As well, the new 1.4 release of the user space software (which matches
the 1.4 firmware) has intermitent issues with the 1.3 firmware.
The 1.4 release in http://linuxwimax.org/Download has been widely
deployed and tested with the codebase in 2.6.29-rc, the 1.4 firmware
and the 1.4 user space components.
We understand it is quite late in the rc process for such a change,
but would like to ask for the change to be taken into consideration.
Alternatively, a user could always force feed a 1.4 firmware into a
driver that doesn't have this modification by:
$ cd /lib/firmware
$ mv i2400m-fw-usb-1.3.sbcf i2400m-fw-usb-1.3.real.sbcf
$ ln -sf i2400m-fw-usb-1.4.sbc i2400m-fw-usb-1.3.sbcf
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a regression reported in bug #12613.
[airlied: not I tweaked the patch slightly and fixed it by etienne did
all the hardwork so gets authorship]
Signed-off-by: etienne <etienne.basset@numericable.fr>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes potential fault at fault time if the object was unreferenced
while the mapping still existed. Now, while the mmap_offset only lives
for the lifetime of the object, the object also stays alive while a vma
exists that needs it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to do this in case the unref ends up doing a free.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Lifted from the DDX modesetting.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
They used to be different. Now they're identical.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to hold the struct_mutex around pinning and the phys object
operations.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check the error paths within intel_pipe_set_base() to first cleanup and
then report back the error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
We need to skip the connectors with a NULL encoder to match the success
path and avoid an OOPS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
If we fail to create the ringbuffer, then we need to cleanup the allocated
hws.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
In the case where no EDID data is read from the device, adding the
panel_fixed_mode pointer to the probed modes list causes data corruption.
If the panel_fixed_mode pointer is added to the probed modes list at
init time, a copy of the mode is added again at drm_get_modes() request
time. Then, the panel_fixed_mode pointer is freed because it is seen as
a duplicate mode. Unfortunately, this pointer is still stored and used
in mode_fixup().
Because the panel_fixed_mode data is copied and returned at
drm_get_modes() time, it is unnecessary to add this information at init
time.
Signed-off-by: Steve Aarnio <steve.j.aarnio@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Avoids leaking fbs and associated buffers on release.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Tested-by: Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
If we fail whilst constructing the fb, then we need to unpin it as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
A missing unpin on the error path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
A missing unpin on the error path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
A missing unreference and unpin after rejecting the relocation for an
invalid memory domain.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
We failed to unlock the mutex after failing to create the mmap offset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Set the request alignment to 0, and leave it up to i915_gem_object_pin()
to set the appropriate alignment to match the fence covering the object.
Eric Anholt mentioned that the pinning code is meant to choose the
maximum of the request alignment and that of the fence covering the
object... However currently, the pinning code will only apply the fence
constraints if the supplied alignment is 0.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
The name table should only hold a single reference, so avoid leaking
additional references for secondary calls to flink().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
(which is called with mmap_sem already held) takes dev->struct_mutex.
So this is a potential AB-BA deadlock.
The way that i915_gem_execbuffer() triggers a page fault is by doing
copy_to_user() when returning new buffer offsets back to userspace;
however there is no reason to hold the struct_mutex when doing this
copy, since what is being copied is the contents of an array private to
i915_gem_execbuffer() anyway. So we can fix the potential deadlock (and
get rid of the lockdep warning) by simply moving the copy_to_user()
outside of where struct_mutex is held.
This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.
Reported-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
A missing unreference if the user calls pin() a second time on a pinned
buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Also spotted by Owain Ainsworth.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Ensure that the object is unreferenced if we fail to allocate during
drm_gem_flink_ioctl().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Remove the member from the hash table before we free the structure!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Standby memory detected with the sclp interface gets always registered
with add_memory calls without considering the limitationt that the
"mem=" kernel paramater implies.
So fix this and only register standby memory that is below the specified
limit.
This fixes zfcpdump since it uses "mem=32M". In case there is appr.
2GB standby memory present all of usable memory would be used for the
struct pages needed for standby memory.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Handle a malformed hardware response which some versions of the
Support Element (SE) may present during SE restart and which otherwise
would result in an endless loop in function sclp_dispatch_evbufs.
Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
*ep->reg_udccs is always set to 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
block: fix deadlock in blk_abort_queue() for drivers that readd to timeout list
block: fix booting from partitioned md array
block: revert part of 18ce3751cc
cciss: PCI power management reset for kexec
paride/pg.c: xs(): &&/|| confusion
fs/bio: bio_alloc_bioset: pass right object ptr to mempool_free
block: fix bad definition of BIO_RW_SYNC
bsg: Fix sense buffer bug in SG_IO
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
omap_hsmmc: Change while(); loops with finite version
omap_hsmmc: recover from transfer failures
omap_hsmmc: only MMC1 allows HCTL.SDVS != 1.8V
omap_hsmmc: card detect irq bugfix
sdhci: fix led naming
mmc_test: fix basic read test
s3cmci: Fix hangup in do_pio_write()
Revert "sdhci: force high speed capability on some controllers"
MMC: fix bug - SDHC card capacity not correct
Add support for adapters with a PCI id equal to 0x35.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
phyid Can't be both TG3_PHY_OUI_1 and TG3_PHY_OUI_2 and TG3_PHY_OUI_3.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
mib_counters_update() also restarts the timer.
So the timer is dequeued, the stats are read and then the timer is
enqueued again. This is "okay" unless someone unloads the module.
The locking here is also broken:
mib_counters_update() grabs just a simple spinlock. The only thing the
lock is good for is to protect the timer func against other callers
namely mv643xx_eth_stop() && mv643xx_eth_get_ethtool_stats(). That means
if the spinlock is taken via the ethtool path and than the timer kicks
in then the box will lock up.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
gpio_get_value() returns 0 or nonzero, but getmiso() expects 0 or 1.
Sanitize the value to a 0/1 boolean.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since I don't work for SUSE any more and the bwalle@suse.de address is
invalid, correct it in the copyright headers and documentation.
Signed-off-by: Bernhard Walle <bernhard.walle@gmx.de>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Build breaks when DELL_LAPTOP=y and POWER_SUPPLY=m. DELL_LAPTOP needs to
depend on POWER_SUPPLY.
dell-laptop.c:(.text+0x1ef3c4): undefined reference to `power_supply_is_system_supplied'
dell-laptop.c:(.text+0x1ef45e): undefined reference to `power_supply_is_system_supplied'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Submenus of the graphics support "Support for frame buffer devices" and
"Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" are
broken in half after latest changes for Intel 915 mode setting support.
The DRM subsection is broken because one option is put outside the choice
section it depends on.
The frame buffers part is broken then due to circular dependency. Fix
this by make Intel frame buffers depend on CONFIG_INTEL_AGP.
Kconfigs are broken by d2f5935770
("drm/i915: select framebuffer support automatically").
This is probably not only way to fix this.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The floppy driver requests an I/O port it doesn't need, and sometimes this
causes a conflict with a motherboard device reported by PNPBIOS.
This patch makes the floppy driver request and release only the ports it
actually uses. It also factors out the request/release stuff and the
io-ports list so they're all in one place now.
The current floppy driver uses only these ports:
0x3f2 (FD_DOR)
0x3f4 (FD_STATUS)
0x3f5 (FD_DATA)
0x3f7 (FD_DCR/FD_DIR)
but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port
0x3f3.
Some BIOSes report 0x3f3 as a motherboard resource. The PNP system driver
reserves that, which causes a conflict when the floppy driver requests
0x3f2-0x3f5 later.
Philippe reported that this conflict broke the floppy driver between
2.6.11 and 2.6.22. His PNPBIOS reports these devices:
$ cat 00:07/id 00:07/resources # motherboard device
PNP0c02
state = active
io 0x80-0x80
io 0x10-0x1f
io 0x22-0x3f
io 0x44-0x5f
io 0x90-0x9f
io 0xa2-0xbf
io 0x3f0-0x3f1
io 0x3f3-0x3f3
$ cat 00:03/id 00:03/resources # floppy device
PNP0700
state = active
io 0x3f4-0x3f5
io 0x3f2-0x3f2
Reference:
http://lkml.org/lkml/2009/1/31/162
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Reported-by: Philippe De Muyter <phdm@macqel.be>
Tested-by: Philippe De Muyter <phdm@macqel.be>
Cc: Adam M Belay <abelay@mit.edu>
Cc: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi
International Digi Neo 8 (rev 05)
that works with the jsm driver after using the following patch.
Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de>
Cc: Scott H Kilau <Scott_Kilau@digi.com>
Cc: Wendy Xiong <wendyx@us.ibm.com>
Acked-by: 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>
I found a problem of handling of modem status of atmel_serial driver.
With the commit 1ecc26 ("atmel_serial: split the interrupt handler"),
handling of modem status signal was splitted into two parts. The
atmel_tasklet_func() compares new status with irq_status_prev, but
irq_status_prev is not correct if signal status was changed while the port
is closed.
Here is a sequence to cause problem:
1. Remote side sets CTS (and DSR).
2. Local side close the port.
3. Local side clears RTS and DTR.
4. Remote side clears CTS and DSR.
5. Local side reopen the port. hw_stopped becomes 1.
6. Local side sets RTS and DTR.
7. Remote side sets CTS and DSR.
Then CTS change interrupt can be received, but since CTS bit in
irq_status_prev and new status is same, uart_handle_cts_change() will not
be called (so hw_stopped will not be cleared, i.e. cannot send any data).
I suppose irq_status_prev should be initialized at somewhere in open
sequence.
Itai Levi pointed out that we need to initialize atmel_port->irq_status
as well here. His analysis is as follows:
> Regarding the second part of the patch (which resets irq_status_prev),
> it turns out that both versions of the patch (mine and Atsushi's)
> still leave enough room for faulty behavior when opening the port.
>
> This is because we are not resetting both irq_status_prev and
> irq_status in atmel_startup() to CSR, which leads faulty behavior in
> the following sequences:
>
> First case:
> 1. closing the port while CTS line = 1 (TX not allowed)
> 2. setting CTS line = 0 (TX allowed)
> 3. opening the port
> 4. transmitting one char
> 5. Cannot transmit more chars, although CTS line is 0
>
> Second case:
> 1. closing the port while CTS line = 0 (TX allowed)
> 2. setting CTS line = 1 (TX not allowed)
> 3. opening the port
> 4. receiving some chars
> 5. Now we can transmit, although CTS line is 1
>
> This reason for this is that the tasklet is scheduled as a result of
> TX or RX interrupts (not a status change!), in steps 4 above. Inside
> the tasklet, the atmel_port->irq_status (which holds the value from
> the previous session) is compared to atmel_port->irq_status_prev.
> Hence, a status-change of the CTS line is faultily detected.
>
> Both cases were verified on 9260 hardware.
[haavard.skinnemoen@atmel.com: folded with patch from Itai Levi]
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Remy Bohmer <linux@bohmer.net>
Cc: Marc Pignat <marc.pignat@hevs.ch>
Cc: Itai Levi <itai.levi.devel@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>
The conversion of atmel-mci to dma_request_channel missed the
initialization of the channel dma_slave information. The filter_fn passed
to dma_request_channel is responsible for initializing the channel's
private data. This implementation has the additional benefit of enabling
a generic client-channel data passing mechanism.
Reviewed-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for HP Pavilion dv5.
Since Intel-based models have an inverted x axis, while AMD-based models
have an inverted y axis, we introduce a new macro that special-cases axis
orientation based on two DMI entries: HP dv5 axis configuration is then
based on both the PRODUCT and BOARD name.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: Eric Piel <Eric.Piel@tremplin-utc.net>
Cc: Pavel Machek <pavel@suse.cz>
Tested-by: Palatis Tseng <palatis@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sensors responding with 0x3B to WHO_AM_I only have one data register per
direction, thus returning a signed byte from the position which is
occupied by the MSB in sensors responding with 0x3A.
Since multiple sensors share the reply to WHO_AM_I, we rename the defines
to better indicate what they identify (family of single and double
precision sensors).
We support both kind of sensors by checking for the sensor type on init
and defining appropriate data-access routines and sensor limits (for the
joystick) depending on what we find.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Eric Piel <Eric.Piel@tremplin-utc.net>
Cc: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds freefall handling to hp_accel driver. According to HP, it
should just work, without us having to set the chip up by hand.
hpfall.c is example .c program that parks the disk when accelerometer
detects free fall. It should work; for now, it uses fixed 20seconds
protection period.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Otherwise with INPUT=m, EEEPC_LAPTOP=y one gets
drivers/built-in.o: In function `input_sync':
eeepc-laptop.c:(.text+0x18ce51): undefined reference to `input_event'
drivers/built-in.o: In function `input_report_key':
eeepc-laptop.c:(.text+0x18ce73): undefined reference to `input_event'
drivers/built-in.o: In function `eeepc_hotk_check':
eeepc-laptop.c:(.text+0x18d05f): undefined reference to `input_allocate_device'
eeepc-laptop.c:(.text+0x18d10f): undefined reference to `input_register_device'
eeepc-laptop.c:(.text+0x18d131): undefined reference to `input_free_device'
drivers/built-in.o: In function `eeepc_backlight_exit':
eeepc-laptop.c:(.text+0x18d546): undefined reference to `input_unregister_device'
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Welland ME-747K-SI AoE target generates unsolicited AoE responses that
are marked as vendor extensions. Instead of ignoring these packets, the
aoe driver was generating kernel messages for each unrecognized response
received. This patch corrects the behavior.
Signed-off-by: Ed Cashin <ecashin@coraid.com>
Reported-by: <karaluh@karaluh.pl>
Tested-by: <karaluh@karaluh.pl>
Cc: <stable@kernel.org>
Cc: Alex Buell <alex.buell@munted.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Replace the infinite 'while() ;' loops
with a finite loop version.
Signed-off-by: Jean Pihet <jpihet@mvista.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Timeouts during a command that has a data phase can result in the next
command issued after the command that failed not being processed, i.e. no
interrupt ever occurs to indicate the command has completed. This failure
can result in a deadlock.
This patch resets the data state machine to clear the error in case of a
command timeout.
Tested on OMAP3430 chip and intensive MMC/SD device removal while
transferring data.
Signed-off-by: Andy Lowe <alowe@mvista.com>
Signed-off-by: Jean Pihet <jpihet@mvista.com>
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Based on a patch from Tony Lindgren ... after initialization,
never change HCTL.SDVS except for MMC1. The other controller
instances only support 1.8V in that field, although they can
suport other card/SDIO/eMMC/... voltages with level shifting
solutions such as external transceivers.
MMC2 behavior sanity tested on Overo/WLAN, OMAP3430 SDP, and
custom hardware. MMC1 also sanity tested on those platforms
plus Beagle. This also fixes a bug preventing MMC2 (and also
presumably MMC3) from powering down when requested.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Work around lockdep issue when card detect IRQ handlers run in
thread context ... it forces IRQF_DISABLED, which prevents all
access to twl4030 card detect signals.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Fix the led device naming for the sdhci driver.
The led class documentation defines the led name to have the
form "devicename:colour:function" while not applicable sections
should be left blank.
To comply with the documentation the led device name is changed
from "mmc*" to "mmc*::".
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Due to a typo in the Basic Read test, it's currently identical to the
Basic Write test. Fix this.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This commit fixes the regression what was added by commit
088a78af97 "s3cmci: Support transfers
which are not multiple of 32 bits."
fifo_free() now returns amount of available space in FIFO buffer in
bytes. But do_pio_write() writes to FIFO 32-bit words. Condition for
return from cycle is (fifo_free() == 0), but when fifo has 1..3 bytes
of free space then this condition will never be true and system hangs.
This patch changes condition in the while() to (fifo_free() > 3).
Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
David reported that LSI SAS doesn't work with MSI. It turns out that
his BIOS doesn't enable it, but the HT MSI 8132 does support HT MSI.
Add quirk to enable it
Cc: stable@kernel.org
Reported-by: David Lang <david@lang.hm>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The kexec kernel resets the CCISS hardware in three steps:
1. Use PCI power management states to reset the controller in the
kexec kernel.
2. Clear the MSI/MSI-X bits in PCI configuration space so that MSI
initialization in the kexec kernel doesn't fail.
3. Use the CCISS "No-op" message to determine when the controller
firmware has recovered from the PCI PM reset.
[akpm@linux-foundation.org: cleanups]
Signed-off-by: Mike Miller <mike.miller@hp.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
We can't OR shift values, so get rid of BIO_RW_SYNC and use BIO_RW_SYNCIO
and BIO_RW_UNPLUG explicitly. This brings back the behaviour from before
213d9417fe.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
This reverts commit a4b7619377.
It turned out that the controller had problem running at the
higher speed, so go back to trusting the hardware capability
bits.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
If a USB PCI controller is behind a cardbus bridge, we are trying to
restore its configuration registers too early, before the cardbus
bridge is operational. To fix this, call pci_restore_state() from
usb_hcd_pci_resume() and remove usb_hcd_pci_resume_early() which is
no longer necessary (the configuration spaces of USB controllers that
are not behind cardbus bridges will be restored by the PCI PM core
with interrupts disabled anyway).
This patch fixes the regression from 2.6.28 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12659
[ Side note: the proper long-term fix is probably to just force the
unplug event at suspend time instead of doing a plug/unplug at resume
time, but this patch is fine regardless - Linus ]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Miles Lane <miles.lane@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
sata_nv: give up hardreset on nf2
libata-sff: fix 32-bit PIO ATAPI regression
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: fix bus endianity in file2alias
HID: move tmff and zpff devices from ignore_list to blacklist
HID: unlock properly on error paths in hidraw_ioctl()
HID: blacklist Powercom USB UPS
* 'for-linus' of git://git.o-hand.com/linux-mfd:
mfd: Fix sm501_register_gpio section mismatch
mfd: fix sm501 section mismatches
mfd: terminate pcf50633 i2c_device_id list
mfd: Ensure all WM8350 IRQs are masked at startup
mfd: fix htc-egpio iomem resource handling using resource_size
mfd: Fix TWL4030 build on some ARM variants
mfd: wm8350 tries reaches -1
mfd: Mark WM835x USB_SLV_500MA bit as accessible
mfd: Improve diagnostics for WM8350 ID register probe
mfd: Initialise WM8350 interrupts earlier
mfd: Fix egpio kzalloc return test
This is the cause of the DMA faults and disk corruption that people have
been seeing. Some chipsets neglect to report the RWBF "capability" --
the flag which says that we need to flush the chipset write-buffer when
changing the DMA page tables, to ensure that the change is visible to
the IOMMU.
Override that bit on the affected chipsets, and everything is happy
again.
Thanks to Chris and Bhavesh and others for helping to debug.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Chris Wright <chrisw@sous-sol.org>
Reviewed-by: Bhavesh Davda <bhavesh@vmware.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes a number of cases where things were not properly
cleaned up when acpi_check_resource_conflict() returned an error,
causing oopses such as the one reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=483208
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
If the F71882FG chip is at address 0x4e, then the probe at 0x2e will
fail with the following message in the logs:
f71882fg: Not a Fintek device
This is misleading because there is a Fintek device, just at a
different address. So I propose to degrade this message to a debug
message.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
The new v4l2_subdev_call used s_fmt instead of g_fmt.
Thanks-to: Andy Walls <awalls@radix.net>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The video_ioctl2 conversion of ivtv in kernel 2.6.27 introduced a bug
causing decoder commands to crash. The decoder commands should have been
handled from the video_ioctl2 default handler, ensuring correct mapping
of the argument between user and kernel space. Unfortunately they ended
up before the video_ioctl2 call, causing random crashes.
Thanks to hannes@linus.priv.at for testing and helping me track down the
cause!
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If a device using the gspca framework is unplugged while it is still streaming
then the call that is used to free the URBs that have been allocated occurs
after the pointer it uses becomes invalid at the end of gspca_disconnect.
Make another cleanup call in gspca_disconnect while the pointer is still
valid (multiple calls are OK as destroy_urbs checks for pointers already
being NULL.
Signed-off-by: Adam Baker <linux@baker-net.org.uk>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Mon, 02 Feb 2009, Hartmut wrote:
This change set is wrong. The affected functions cannot be called from
an interrupt context, because they may process large buffers. In this
case, interrupts are disabled for a long time. Functions, like
dvb_dmx_swfilter_packets(), could be called only from a tasklet.
This change set does hide some strong design bugs in dm1105.c and
au0828-dvb.c.
Please revert this change set and do fix the bugs in dm1105.c and
au0828-dvb.c (and other files).
On Sun, 15 Feb 2009, Oliver Endriss wrote:
This changeset _must_ be reverted! It breaks all kernels since 2.6.27
for applications which use DVB and require a low interrupt latency.
It is a very bad idea to call the demuxer to process data buffers with
interrupts disabled!
On Mon, 16 Feb 2009, Trent Piepho wrote:
I agree, this is bad. The demuxer is far too much work to be done with
IRQs off. IMHO, even doing it under a spin-lock is excessive. It should
be a mutex. Drivers should use a work-queue to feed the demuxer.
Thank you for testing this changeset and discovering the issues on it.
Cc: Trent Piepho <xyzzy@speakeasy.org>
Cc: Hartmut <e9hack@googlemail.com>
Cc: Oliver Endriss <o.endriss@gmx.de>
Cc: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch closes one of my todos that was since long on my list.
Some people reported clicks and glitches in the audio stream,
correlated to the LED color changing cycle.
Thanks to Rick Bronson <rick@efn.org>.
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Bob Ross <pigiron@gmx.com>
- correction of stereo detection/setting
- correction of signal strength indicator scaling
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>