It appears that some PCI-E bridges do the wrong thing in the presense of
CRS Software Visibility and MMCONFIG. In particular, it looks like an
ATI bridge (device ID 7936) will return 0001 in the vendor ID field of
any bridged devices indefinitely.
Not enabling CRS SV avoids the problem, and as we currently do not
really make good use of the feature anyway (we just time out rather than
do any threaded discovery as suggested by the CRS specs), we're better
off just not enabling it.
This should fix a slew of problem reports with random devices (generally
graphics adapters or fairly high-performance networking cards, since it
only affected PCI-E) not getting properly recognized on these AMD systems.
If we really want to use CRS-SV, we may end up eventually needing a
whitelist of systems where this should be enabled, along with some kind
of "pcibios_enable_crs()" query to call the system-specific code.
Suggested-by: Loic Prylli <loic@myri.com>
Tested-by: Kai Ruhnau <kai@tragetaschen.dyndns.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The xcryptecb instruction always processes an even number of blocks so
we need to ensure th existence of an extra block if we have to process
an odd number of blocks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Move veth.h from net/ to linux/ since it is a user api, and add it to
user header processing Kbuild.
[ Use header-y as suggested by Sam Ravnborg. -DaveM ]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a trivial fix of debug message.
When a persist flag is set, the message should say "enabled".
Signed-off-by: Toyo Abe <tabe@miraclelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 528a572dae ("ide: add ->chipset field
to ide_pci_device_t") broke hwif->chipset setup (it is now set to ide_cmd646
for CMD648 instead of CMD646). It seems that the breakage happend while
I was moving patches around (cmd64x_chipsets[] entries for CMD646 and CMD648
are identical except for 'name' field). Fix it and bump driver version.
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Mask 'ireason' variable so only the valid interrupt reason bits
will be reported on "drive appears confused" error.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Mask 'ireason' variable with 0x3 so the valid interrupt reason value
is passed to cdrom_write_check_ireason() for checking.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Use ide_cd_release() to do the cleanup if ide_cdrom_setup() fails.
It fixes:
- the default drive->dsc_overlap value not being restored
- the default drive->queue's prep_rq_fn not being restored
- struct gendisk 'g' not being freed
- wrong function name being reported on unregister_cdrom() error
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
cdi->mask is cleared by ide_cdrom_register() which is called after the quirk.
Fix it by adding new ->no_speed_select flag to struct ide_cd_config_flags
and using it in ide_cdrom_register() to set CDC_SELECT_SPEED flag.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: New device ID for the CP2101 driver
USB: VID/PID update for sierra
USB: Unbreak fsl_usb2_udc
Commit 5a52bd4a2d introduced a subtle logic
change in tty_wait_until_sent(). The original version would only error out
of the 'do { ... } while (timeout)' loop if signal_pending() evaluated to
true; a timeout or break due to an empty buffer would fall out of the loop
and into the tty->driver->wait_until_sent handling. The current
implementation will error out on either a pending signal or an empty
buffer, falling through to the tty->driver->wait_until_sent handling only
on a timeout.
The ->wait_until_sent() will not be reached if the buffer empties before
timeout jiffies have elapsed. This behavior differs from that prior to commit
5a52bd4a2d.
I turned this up while using a little serial download utility to bootstrap an
ARM-based eval board. The util worked fine on 2.6.22.x, but consistently
failed on 2.6.23.x. Once I'd determined that, I narrowed things down with git
bisect, and found the above difference in logic in tty_wait_until_sent() by
inspection.
This change reverts the logic flow in tty_wait_until_sent() to match that
prior to the aforementioned commit.
Signed-off-by: Cory T. Tusar <ctusar@videon-central.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Init section confusion. There will likely be some other similar
issues, introduced by I'm-not-sure-what-patch.
Signed-off-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>
This stray down would cause a permanent sleep which doesn't seem correct.
The other uses of this semaphore appear fairly mutex like it's even
initialized with init_MUTEX() .. So here a patch for removing this one
down().
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
attached please find a new device ID for CP2101 driver. This device is a
usb stick from Dynastream to communicate with ANT wireless devices which
I suppose is fairly similar to the ANT dev board having product id 0x1003.
From: Martin Kusserow <kusserow@ife.ee.ethz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adds VID/PID for the MC8775 found internally in the Thinkpad X61s laptop
(and likely others). For commercial reasons the driver maintainer cannot
add VID/PIDs for laptop OEM devices himself.
Signed-off-by: Kevin R Page <linux-kernel@krp.org.uk>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initially transmit buffer pointers were only reset. But buffer
descriptors were possibly still set as ready, and buffer in upper
layer was not freed. This caused driver hang under big load. Now
reset clean properly the buffer descriptor and freed upper layer.
Signed-off-by: Gregory CLEMENT <gclement00@gmail.com>
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Same story as with olympic - htons(readw()) when swab16(readw()) is needed,
missing conversions to le32 when dealing with shared descriptors, etc.
Olympic got those fixes in 2.4.0-test2, 3c359 didn't.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
If you need to find a difference between addresses of two
struct members, subtract offsetof() or cast addresses to
char * and subtract those if you prefer it that way. Doing
that same with s/char */u32/, OTOH...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Both store MAC address in CIS; there's no decoder for that
type (0x88) so the drivers work with raw data. It is
byteswapped, so ntohs() works for little-endian, but for
big-endian it's wrong. ntohs(le16_to_cpu()) does the
right thing on both (and always expands to swab16()).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* shift before cpu_to_le64(), not after it
* writel() converts to l-e itself
* misc missing conversions
* in set_multicast() hash_table[] is host-endian; we feed it to card
via writel() and populate it as host-endian, so we'd better put the
first element into it also in host-endian
* pci_unmap_single() et.al. expect host-endian, not little-endian
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
pci_unmap_single() and friends getting a little-endian address...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* usb_control_message() to/from stack (breaks on e.g. arm); some
places did kmalloc() for buffer, some just worked from stack.
Added kmalloc()/memcpy()/kfree() in asix_read_cmd()/asix_write_cmd(),
removed that crap from callers.
* Fixed a leak in ax88172_bind() - on success it forgot to kfree() the
buffer.
* Endianness bug in ax88178_bind() - we read a word from eeprom and work with
it without converting to host-endian
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
txlo_dma_addr should be host-endian; we pass it to typhoon_tso_fill(),
which does arithmetics on it, converts to l-e and passes it to card.
Unfortunately, we forgot le32_to_cpu() when initializing it from
face->txLoAddr, which sits in shared memory and is little-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
rxBuffCleared is little-endian; we miss le32_to_cpu() in checks for
rx ring overruns.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
One cpu_to_le16() too many when passing argument for TYPHOON_CMD_XCVR_SELECT;
we end up passing host-endian while the hardware expects little-endian. The
other place doing that (typhoon_start_runtime()) does the right thing, so the
card will recover at the next ifconfig up/tx timeout/resume, which limits the
amount of mess, but still, WTF?
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
in typhoon_get_drvinfo() .parm2 is little-endian; not critical
since we just get the firmware id flipped in get_drvinfo output
on big-endian boxen, but...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
txBytes and rxBytesGood are both 64bit; using le32_to_cpu() won't work
on big-endian for obvious reasons.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Fix possible max_phys_segments violation in cloned dm-crypt bio.
In write operation dm-crypt needs to allocate new bio request
and run crypto operation on this clone. Cloned request has always
the same size, but number of physical segments can be increased
and violate max_phys_segments restriction.
This can lead to data corruption and serious hardware malfunction.
This was observed when using XFS over dm-crypt and at least
two HBA controller drivers (arcmsr, cciss) recently.
Fix it by using bio_add_page() call (which tests for other
restrictions too) instead of constructing own biovec.
All versions of dm-crypt are affected by this bug.
Cc: stable@kernel.org
Cc: dm-crypt@saout.de
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Make sure dm honours max_hw_sectors of underlying devices
We still have no firm testing evidence in support of this patch but
believe it may help to resolve some bug reports. - agk
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Insert a missing KOBJ_CHANGE notification when a device is renamed.
Cc: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Fix BIO_UPTODATE test for write io.
Cc: stable@kernel.org
Cc: dm-crypt@saout.de
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
With CONFIG_SCSI=n __scsi_print_sense() is never linked in.
drivers/built-in.o: In function `hp_sw_end_io':
dm-mpath-hp-sw.c:(.text+0x914f8): undefined reference to `__scsi_print_sense'
Caught with a randconfig on current git.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
This patch fixes a panic on shrinking a DM device if there is
outstanding I/O to the part of the device that is being removed.
(Normally this doesn't happen - a filesystem would be resized first,
for example.)
The bug is that __clone_and_map() assumes dm_table_find_target()
always returns a valid pointer. It may fail if a bio arrives from the
block layer but its target sector is no longer included in the DM
btree.
This patch appends an empty entry to table->targets[] which will
be returned by a lookup beyond the end of the device.
After calling dm_table_find_target(), __clone_and_map() and target_message()
check for this condition using
dm_target_is_valid().
Sample test script to trigger oops:
if log_len is larger than 4K then we are killing the stack.
allocate on heap instead and limit size to what practically can
be used (PAGE_SIZE)
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch moves _cancel_deferred_work out of mutex protection and removes
unnecessary mutex in pci_suspend and pci_resume.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some people would like to know what p54 is.
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thanks to Matthias Mueller for reporting this device.
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
tg3_nvram_write_block_unbuffered() is reading data from nvram into
allocated buffer before overwriting a part of it with user-supplied
data. Then it feeds the entire page back to nvram. It should be
storing the words it had read as little-endian, not as host-endian.
Note that tg3_set_eeprom() does exactly that for padding the same
data to full words before it gets passed down to tg3_nvram_write_block()
and then to tg3_nvram_write_block_unbuffered().
Moreover, when we get to sending the entire thing back to nvram, we
go through it word-by-word, doing essentially
writel(swab32(le32_to_cpu(word)), ...)
so if we want them to reach the card in host-independent endianness,
we'd better really have all that buffer filled with fixed-endian.
For user-supplied part we obviously do have that (it's an array of
octets memcpy'd in), ditto for padding of user-supplied part to word
boundaries (taken care of in tg3_set_eeprom()). The rest of the
buffer gets filled by tg3_nvram_write_block_unbuffered() and it would
damn better be consistent with that (and with tg3_get_eeprom(), while
we are at it - there we also convert the words read from nvram to
little-endian before returning the buffer to user).
The bug should get triggered on big-endian boxen when set_eeprom is done
for less than entire page. Then the words that should've been unaffected
at all will actually get byteswapped in place in nvram.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixed misannotations, introduced a new helper - tg3_nvram_read_le().
It gets __le32 * instead of u32 * and puts there the value converted
to little-endian. A lot of callers of tg3_nvram_read() were doing
that; converted them to tg3_nvram_read_le().
At that point the driver is practically endian-clean; the only remaining
place is an actual bug, AFAICS; will be dealt with in the next patch.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
The dev_id arg passed to free_irq() must match that passed to
request_irq().
Fixes this PS3 error message:
Trying to free already-free IRQ 44
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ps3fb: Update for firmware 2.10
As of PS3 firmware version 2.10, the GPU command buffer size must be at least 2
MiB large. Since we use only a small part of the GPU command buffer and don't
want to waste precious XDR memory, move the GPU command buffer back to the
start of the XDR memory reserved for ps3fb and let the unused part overlap with
the actual frame buffer.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
patch: [SCSI] initio: convert to use the data buffer accessors had a
small but fatal bug in that it didn't increment the pointer into the
initio scatterlist descriptors as it looped over the block generated
ones. Fixed here.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This is caused by a missing scatterlist initialisation (it only shows
up when sg list handling debugging is turned on).
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Kai Makisara <Kai.Makisara@kolumbus.fi>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> I have a scanner connected to a Initio INI-950 SCSI card and I recently
> upgraded from SuSE 10.2 to 10.3. The new kernel doesn't see any of my
> devices. I get the following in /var/log/messages:
>
> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 16
> initio: I/O port range 0x0 is busy.
> ACPI: PCI interrupt for device 0000:00:0a.0 disabled
Humm not a collision - thats a bug in the driver updating. Looks like the
changes I made and combined with Christoph's lost a line somewhere when I
was merging it all.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The patch described by the following excerpt from ChangeLog-2.6.24-rc1
eventually causes a "irq X: nobody cared" error after a while:
commit 99c9e0a1d6
Author: Matthew Wilcox <matthew@wil.cx>
Date: Fri Oct 5 15:55:12 2007 -0400
[SCSI] sym53c8xx: Make interrupt handler capable of returning IRQ_NONE
After this happens, the kernel disables the IRQ, causing the SCSI card
to stop working until the next reboot. The problem is caused by the
interrupt handler returning IRQ_NONE instead of IRQ_HANDLED after
handling an interrupt-on-the-fly (INTF) condition. The following patch
fixes the problem.
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Acked-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This fixes a potential corruption bug where the truncation would cause
reading or writing to the wrong memory area on machines with >4GB of
main memory.
Cc: Stable Kernel Tree <stable@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The following commit changed the pointer passed to request_irq(), but
failed to change the pointer passed to free_irq():
commit 99c9e0a1d6
Author: Matthew Wilcox <matthew@wil.cx>
Date: Fri Oct 5 15:55:12 2007 -0400
[SCSI] sym53c8xx: Make interrupt handler capable of returning IRQ_NONE
...
The result is that free_irq() doesn't actually take any action. This
patch fixes it.
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Acked-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
Cleanup umem driver: fix most checkpatch warnings, conform to kernel
block: let elv_register() return void
as-iosched: fix write batch start point
as-iosched: fix incorrect comments
block: use jiffies conversion functions in scsi_ioctl.c
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
mmc: remove unused 'mode' from the mmc_host structure
sdhci: support JMicron JMB38x chips
sdhci: use PIO when DMA can't satisfy the request
sdhci: don't warn about sdhci 2.0 controllers
sdhci: describe quirks
coding style.
linux-2.6.24-rc5-git3> checkpatch.pl-next patches/block-umem-ckpatch.patch
total: 0 errors, 5 warnings, 530 lines checked
All of these are line-length warnings.
Only change in generated object file is due to not initializing a
static global variable to 0.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata: fix ATAPI draining
libata: update atapi_eh_request_sense() such that lbam/lbah contains buffer size
libata-acpi: implement _GTF command filtering
libata-acpi: improve _GTF execution error handling and reporting
libata-acpi: improve ACPI disabling
libata-acpi: implement dev->gtf_cache and evaluate _GTF right after _STM during resume
libata-acpi: implement and use ata_acpi_init_gtm()
libata-acpi: add new hooks ata_acpi_dissociate() and ata_acpi_on_disable()
libata: ata_dev_disable() should be called from EH context
libata: add more opcodes to ata.h
libata: update ata_*_printk() macros such that level can be a variable
libata-acpi: adjust constness in ata_acpi_gtm/stm() parameters
sata_mv: improve warnings about Highpoint RocketRAID 23xx cards
libata: add ST3160023AS / 3.42 to NCQ blacklist
libata: clear link->eh_info.serror from ata_std_postreset()
sata_sil: fix spurious IRQ handling
We can't use the device in a dev_err() after a kzalloc failure or after the
kfree, so simplify it to the pdev that was originally passed in.
Cc: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A few fixups from Andrew's code comments.
- removed "static inline" forward-declares
- changed use of min() to min_t()
- removed some unnecessary NULL initializations
- removed a couple of BUG() calls
Fixes this:
drivers/dma/ioat_dma.c: In function `ioat1_tx_submit':
drivers/dma/ioat_dma.c:177: sorry, unimplemented: inlining failed in call to '__ioat1_dma_memcpy_issue_pending': function body not available
drivers/dma/ioat_dma.c:268: sorry, unimplemented: called from here
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Cc: "Williams, Dan J" <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cpufreq_stats_free_table() mustn't be __cpuexit since it's called by the
__cpuinit cpufreq_stat_cpu_callback().
This patch fixes the following section mismatch reported by
Chris Clayton:
WARNING: vmlinux.o(.init.text+0x143dd): Section mismatch: reference to .exit.text:cpufreq_stats_free_table (between 'cpufreq_stat_cpu_callback' and 'cpufreq_stats_init')
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Cc: Chris Clayton <chris2553@googlemail.com>
Acked-by: Dave Jones <davej@codemonkey.org.uk>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The error handling code should undo the ioremap as well.
The problem was detected using the following semantic match
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
type T,T1,T2;
identifier E;
statement S;
expression x1,x2;
constant C;
int ret;
@@
T E;
...
* E = ioremap(...);
if (E == NULL) S
... when != iounmap(E)
when != if (E != NULL) { ... iounmap(E); ...}
when != x1 = (T1)E
if (...) {
... when != iounmap(E)
when != if (E != NULL) { ... iounmap(E); ...}
when != x2 = (T2)E
(
* return;
|
* return C;
|
* return ret;
)
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Olaf Hering <olaf@aepfle.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In kobject_register, the kobject reference is get in kobject_init, and then
kobject_add. If kobject_add fail, it will only cleanup the reference got
by itself.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Greg KH <greg@kroah.com>
Cc: Peter Osterlund <petero2@telia.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ingo hit some BUG_ONs that were probably caused by these missing unlocks
causing an unbalance. He couldn't reproduce the bug reliably, so it's
unknown that it's definitly fixing the problem he hit, but it's a fairly
good chance, and this fixes an obvious bug.
[ Dave: "Ingo followed up that he hit some lockdep related output with
this applied, so it may not be right. I'll look at it after
xmas if no-one has it figured out before then."
Akpm: "It looks pretty correct to me though." ]
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While auditing proc_doulongvec_ms_jiffies_minmax() usage in kernel, I found
a bug in drivers/parport/procfs.c, incorrectly using sizeof(int) instead of
sizeof(unsigned long)
Only 64bit arches are affected by this old bug.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reorder at32_rtc_probe() so that it's safe (no oopsing) to fire the
IRQ handler the instant that it's registered. (Bug noted via "Debug
shared IRQ handlers" kernel debug option.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <hcegtvedt@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With ATAPI transfer chunk size properly programmed, libata PIO HSM
should be able to handle full spurious data chunks. Also, it's a good
idea to suppress trailing data warning for misc ATAPI commands as
there can be many of them per command - for example, if the chunk size
is 16 and the drive tries to transfer 510 bytes, there can be 31
trailing data messages.
This patch makes the following updates to libata ATAPI PIO HSM
implementation.
* Make it drain full spurious chunks.
* Suppress trailing data warning message for misc commands.
* Put limit on how many bytes can be drained.
* If odd, round up consumed bytes and the number of bytes to be
drained. This gets the number of bytes to drain right for drivers
which do 16bit PIO.
This patch is partial backport of improve-ATAPI-data-xfer patchset
pending for #upstream.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
While updating lbam/h for ATAPI commands, atapi_eh_request_sense() was
left out. Update it.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Implement _GTF command filtering which can be controlled by
libata.acpi_filter kernel parameter. Currently SETXFER and LOCK
commands are filtered.
libata configures transfer mode by itself and _GTF SETXFER commands
can potentially disrupt device configuration. _GTM/_STM mechanism
can't handle hotplugging too well and when _GTF is executed,
controller is in PIO0 rather than the mode _STM configured.
Note that detecting SET MAX LOCK requires looking at the previous
command. This adds a bit to code complexity.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
As _GTF commands can't transfer data, device error never signals
transfer error. It indicates that the device vetoed the operation, so
it's meaningless to retry.
This patch makes libata-acpi to report and continue on device errors
when executing _GTF commands. Also commands rejected by device don't
contribute to the number of _GTF commands executed.
While at it, update _GTF execution reporting such that all successful
commands are logged at KERN_DEBUG and rename taskfile_load_raw() to
ata_acpi_run_tf() for consistency.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* If _GTF evalution fails, it's pointless to retry. If nothing else
is wrong, just ignore the error.
* After disabling ACPI, return success iff the number of executed _GTF
command equals zero. Otherwise, tell EH to retry. This change
fixes bogus 1 return bug where ata_acpi_on_devcfg() expects the
caller to reload IDENTIFY data and continue but the caller
interprets it as an error.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
On certain implementations, _GTF evaluation depends on preceding _STM
and both can be pretty picky about the configuration. Using _GTM
result cached during controller initialization satisfies the most
neurotic _STM implementation. However, libata evaluates _GTF after
reset during device configuration and the hardware state can be
different from what _GTF expects and can cause evaluation failure.
This patch adds dev->gtf_cache and updates ata_dev_get_GTF() such that
it uses the cached value if available. Cache is cleared with a call
to ata_acpi_clear_gtf().
Because for SATA ACPI nodes _GTF must be evaluated after _SDD which
can't be done till IDENTIFY is complete, _GTF caching from
ata_acpi_on_resume() is used only for IDE ACPI nodes.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
_GTM fetches currently configured transfer mode while _STM configures
controller according to _GTM parameter and prepares transfer mode
configuration TFs for _GTF. In many cases _GTM and _STM
implementations are quite brittle and can't cope with configuration
changed by libata.
libata does not depend on ATA ACPI to configure devices. The only
reason libata performs _GTM and _STM are to make _GTF evaluation
succeed and libata also doesn't care about how _GTF TFs configure
transfer mode. It overrides that configuration anyway, so from
libata's POV, it doesn't matter what value is feeded to _STM as long
as evaluation succeeds for _STM and following _GTF.
This patch adds dev->__acpi_init_gtm and store initial _GTM values on
host initialization before modified by reset and mode configuration.
If the field is valid, ata_acpi_init_gtm() returns pointer to the
saved _GTM structure; otherwise, NULL.
This saved value is used for _STM during resume and peek at
BIOS/firmware programmed initial timing for later use. The accessor
is there to make building w/o ACPI easy as dev->__acpi_init doesn't
exist if ACPI is not enabled.
On driver detach, the initial BIOS configuration is restored by
executing _STM with the initial _GTM values such that the next driver
can also use the initial BIOS configured values.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Add two hooks - ata_acpi_dissociate() which is called during driver
detach after the whole host is shutdown and ata_acpi_on_disable()
which is called when a device is disabled.
Signed-off-by: Tejun heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
ata_port_detach() calls ata_dev_disable() with host lock held but
ata_dev_disable() should be called from EH context. ata_port_detach()
steals EH context by setting ATA_PFLAG_UNLOADAING and flushing EH.
Drop locking around ata_dev_disable() and note that ata_port_detach()
owns EH context at that point.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* No internal function uses const ata_port. Drop const from @ap.
* Make ata_acpi_stm() copy @stm before using it and change @stm to
const.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Improve the existing boot/load time warnings from sata_mv
for Highpoint RocketRAID 23xx cards, based on new knowledge
about where the BIOS likes to overwrite sectors with metadata.
Harmless to us, but very useful for end users.
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Like ST380817AS / 3.42, ST3160023AS / 3.42 times out commands if NCQ
is used. Blacklist it. This is reported by Matheus Izvekov in the
following thread.
http://thread.gmane.org/gmane.linux.ide/24202
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Matheus Izvekov <mizvekov@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
link->eh_info.serror is used to cache SError for controllers which
need it cleared from interrupt handler to clear IRQ. It also should
be cleared after reset just like SError itself.
Make ata_std_postreset() clear link->eh_info.serror too and update
sata_sil such that it doesn't care about bookkeeping the value.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Interestingly, sata_sil raises spurious interrupts if it's coupled
with Sil SATA_PATA bridge. Currently, sata_sil interrupt handler is
strict about spurious interrupts and freezes the port when it occurs.
This patch makes it more forgiving.
* On SATA PHY event interrupt, serror value is checked to see whether
it really is PHYRDY CHG event. If not, SATA PHY event interrupt is
ignored.
* If ATA interrupt occurs while no command is in progress, it's
cleared and ignored.
This fixes bugzilla bug 9505.
http://bugzilla.kernel.org/show_bug.cgi?id=9505
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The patch fixes the STATUS_RF_KILL_HW state is not cleared problem if the
device goes to suspend when the rf_kill switch is enabled. The bug causes
the driver always thinks the rf_kill switch is enabled (although it is
disabled) after resume.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes Bug #9414
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked for several reasons:
(1) Essential data in the rfkill structure were missing.
(2) The rfkill structure was initialized after the LED initialization.
(3) There was a minor memory leak if the radio LED structure was inited.
Once the above problems were fixed, additional difficulties were noted:
(4) The radio LED was in the wrong state at startup.
(5) The radio switch had to be manipulated twice for each state change.
(6) A circular mutex locking situation existed.
(7) If rfkill-input is built as a module, it is not automatically loaded.
This patch fixes all of the above.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ia64:
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c: In function `tsf_write_file':
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:237: warning: long long int format, u64 arg (arg 3)
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:237: warning: long long int format, u64 arg (arg 3)
We do not know what type was used to implement u64 and we can never use u64 in
printk(), sscanf(), etc.
Cc: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ensure that libertas selects WIRELESS_EXT, since selecting other stuff that
should depend on WEXT, like IEEE80211, doesn't seem to drag that in for us.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix rate control algo reference leak in case if network device has been
failed to register. In this case special flag priv->mac80211_registered is
not set and the rate algo reference is not freeing on module unload. That
leads to OOPs in further ieee80211 rate register/unregister procedure (by
any callee).
It should fix the bug #9470http://bugzilla.kernel.org/show_bug.cgi?id=9470
[akpm@linux-foundation.org: build fix]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
