Both i2c-pxa.c and irq.c still include pxa2xx-gpio.h although is is not
needed anymore.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds exit and remove handlers to pxafb so that it can be loaded
and unloaded as a module.
Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.
For performance reasons all scatter-gather addresses passed to
pxamci_request should be aligned on 8-byte boundaries, but if
this can't be guaranteed, byte aligned DMA transfers in the
have to be enabled in the controller to get correct behaviour.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit e872154921.
Andrey Borzenkov reports that it resulted in a totally hung machine for
him when loading the OHCI driver. Extensive netconsole capture with
SysRq output shows that modprobe gets stuck in ohci_hub_status_data()
when probing and enabling the OHCI controller, see for example
http://lkml.org/lkml/2008/7/5/236
for an analysis.
The problem appears to be an interrupt flood triggered by the commit
that gets reverted, and Andrey confirmed that the revert makes things
work for him again.
Reported-and-tested-by: Andrey Borzenkov <arvidjaar@mail.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch (as1108) fixes a problem that can occur with certain USB
mass-storage devices: They return invalid data together with a residue
indicating that the data should be ignored. Rather than leave the
invalid data in a transfer buffer, where it can get misinterpreted,
the patch clears the invalid portion of the buffer.
This solves a problem (wrong write-protect setting detected) reported
by Maciej Rutecki and Peter Teoh.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Peter Teoh <htmldeveloper@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86 ACPI: fix resume from suspend to RAM on uniprocessor x86-64
x86 ACPI: normalize segment descriptor register on resume
Commit ea0c62f7cf tried to clear all
bits in irq_stat but it didn't actually achieve that as irq_stat was
anded with port_map right after read. This patch makes ahci driver
always use the unmasked value to clear irq_status.
While at it, add explanation on the peculiarities of ahci IRQ
clearing.
This was spotted by Linus Torvalds.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Holding ide_lock for ide_release_dma_engine() call is unnecessary
and triggers WARN_ON(irqs_disabled()) in dma_free_coherent().
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
class->dev_release is called by device_release() iff dev->release
is not present so ide_port_class_release() is never called and the
last hwif->gendev reference is not dropped.
Fix it by removing ide_port_class_release() and get_device() call
from ide_register_port() (device_create_drvdata() takes a hwif->gendev
reference anyway).
This patch fixes hang on wait_for_completion(&hwif->gendev_rel_comp)
in ide_unregister() reported by Pavel Machek.
Cc: Pavel Machek <pavel@suse.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
This patch removes the statically initialized tables from the i.MX serial
driver and makes the driver fully dependent on the information provided by
the platform_device.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We assumed a 16MHz reference frequency for the UART. While this
is true for i.MX1 most of the time it is not true for MX27/MX31.
Also, add handling for the ONEMS register which is present on
newer versions of the chip and pass a sane minimum baudrate to
uart_get_baud_rate().
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Some Dell laptops enter resume with apparent garbage in the segment
descriptor registers (almost certainly the result of a botched
transition from protected to real mode.) The only way to clean that
up is to enter protected mode ourselves and clean out the descriptor
registers.
This fixes resume on Dell XPS M1210 and Dell D620.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=10927
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: pm list <linux-pm@lists.linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Even the newer ENE controllers have bugs in their DMA engine that make
it too dangerous to use. Disable it until someone has figured out under
which conditions it corrupts data.
This has caused problems at least once, and can be found as bug report
10925 in the kernel bugzilla.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is a bug in the output of /sys/devices/system/node/node[n]/meminfo
where the Active and Inactive values are in pages instead of Kbytes.
Looks like this occurred back in 2.6.20 when the code was changed
over to use node_page_state().
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The CaFe chip has a hardware bug that ends up with us getting a timeout
value that's too small, causing the following sorts of problems:
[ 60.525138] mmcblk0: error -110 transferring data
[ 60.531477] end_request: I/O error, dev mmcblk0, sector 1484353
[ 60.533371] Buffer I/O error on device mmcblk0p2, logical block 181632
[ 60.533371] lost page write due to I/O error on mmcblk0p2
Presumably this is an off-by-one error in the hardware. Incrementing
the timeout count value that we stuff into the TIMEOUT_CONTROL register
gets us a value that works. This bug was originally discovered by
Pierre Ossman, I believe.
[thanks to Robert Millan for proving that this was still a problem]
Signed-off-by: Andres Salomon <dilinger@debian.org>
Cc: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This has been sitting around unloved for way too long..
The Marvell CaFe chip's SD implementation chokes during card insertion
if one attempts to set the voltage and power up in the same
SDHCI_POWER_CONTROL register write. This adds a quirk that does
that particular dance in two steps.
It also adds an entry to pci_ids.h for the CaFe chip's SD device.
Signed-off-by: Andres Salomon <dilinger@debian.org>
Cc: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch changes the way we determine the maximum number of outstanding
commands for each controller.
Most Smart Array controllers can support up to 1024 commands, the notable
exceptions are the E200 and E200i.
The next generation of controllers which were just added support a mode of
operation called Zero Memory Raid (ZMR). In this mode they only support
64 outstanding commands. In Full Function Raid (FFR) mode they support
1024.
We have been setting the queue depth by arbitrarily assigning some value
for each controller. We needed a better way to set the queue depth to
avoid lots of annoying "fifo full" messages. So we made the driver a
little smarter. We now read the config table and subtract 4 from the
returned value. The -4 is to allow some room for ioctl calls which are
not tracked the same way as io commands are tracked.
Please consider this for inclusion.
Signed-off-by: Mike Miller <mike.miller@hp.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This got broken by the recent "fix rmmod $spi_driver while spidev-user is
active". I tested the rmmod & write path but didn't check the read path.
I am sorry. The read logic changed and spidev_sync_read() +
spidev_sync_write() do not return zero on success anymore but the number
of bytes that has been transfered over the bus. This patch changes the
logic and copy_to_user() gets called again.
The write path returns the number of bytes which are written to the
underlying device what may be less than the requested size. This patch
makes the same change to the read path or else we request a read of 20
bytes, get 10, don't call copy to user and report to the user that we read
10 bytes.
[akpm@linux-foundation.org: remove test of known-to-be-zero local]
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.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>
This is needed for HTC Blueangel (w3200). At 96MHz its screen flickers.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Acked-by: Ian Molton <spyro@f2s.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Apart from Sharp SL-Cxx series, there are a few other devices that have
ATI Imageon chips, among them HP iPAQ hx4700.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Acked-by: Ian Molton <spyro@f2s.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Adds R61, T61p, X61s, X61, Z61m, Z61p models to whitelist.
Fixes this:
cullen@lenny:~$ sudo modprobe hdaps
FATAL: Error inserting hdaps (/lib/modules/2.6.22-10-generic/kernel/drivers/hwmon/hdaps.ko): No such device
[25192.888000] hdaps: supported laptop not found!
[25192.888000] hdaps: driver init failed (ret=-19)!
Originally based on an Ubuntu patch that got it wrong, the dmidecode
output of the corresponding laptops shows LENOVO as the manufacturer.
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/133636
tested on X61s:
[ 184.893588] hdaps: inverting axis readings.
[ 184.893588] hdaps: LENOVO ThinkPad X61s detected.
[ 184.893588] input: hdaps as /class/input/input12
[ 184.924326] hdaps: driver successfully loaded.
Cc: Klaus S. Madsen <ubuntu@hjernemadsen.org>
Cc: Chuck Short <zulcss@ubuntu.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: maximilian attems <max@stro.at>
Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix regression in cciss driver that if no logical drives are configured,
no device nodes at all get created.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cca.cpqcorp.net>
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes following build error when CONFIG_PM is set.
CC drivers/video/fsl-diu-fb.o
drivers/video/fsl-diu-fb.c: In function 'fsl_diu_suspend':
drivers/video/fsl-diu-fb.c:1327: error: 'ofdev' undeclared (first use in this function)
drivers/video/fsl-diu-fb.c:1327: error: (Each undeclared identifier is reported only once
drivers/video/fsl-diu-fb.c:1327: error: for each function it appears in.)
drivers/video/fsl-diu-fb.c: In function 'fsl_diu_resume':
drivers/video/fsl-diu-fb.c:1337: error: 'ofdev' undeclared (first use in this function)
While I'm at it, also fix this warning:
drivers/video/fsl-diu-fb.c: In function 'fsl_diu_alloc':
drivers/video/fsl-diu-fb.c:314: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'phys_addr_t'
And these section mismatches:
..from the function fsl_diu_remove() to the function .exit.text:uninstall_fb()
..from the function fsl_diu_remove() to the function .exit.text:uninstall_fb()
..from the function install_fb() to the variable .devinit.data:fsl_diu_mode_db
..from the function install_fb() to the variable .devinit.data:fsl_diu_mode_db
..from the function fsl_diu_probe() to the function .exit.text:uninstall_fb()
..from the function fsl_diu_probe() to the function .exit.text:uninstall_fb()
Also, some sparse fixes: make two functions static, and use NULL where
appropriate. There are still a lot of sparse warnings, mainly wrt absence
of __iomem annotations, but some will require ugly __force stuff. I'll leave
them for now, since proper fix would be not that trivial as few one-liners
below.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Timur Tabi <timur@freescale.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The pca953x driver can handle another 8-bit I/O expander, the max7310.
This patch adds that chip to the list of supported IDs in that driver, and
expands the Kconfig helptext accordingly.
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>
It seems VT3336 can't do msi either as with its bro 3351. Disable it.
Reported in the following SUSE bug.
https://bugzilla.novell.com/show_bug.cgi?id=300001
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When writing /proc/acpi/alarm in adjust mode, e.g.
echo "+0000-00-00 00:00:15" >/proc/acpi/alarm
The "century" field should be read and added to "year" field before
writing, otherwise the CMOS time will go back to 2000 years ago, e.g.
# cat /proc/acpi/alarm
0008-06-21 11:38:46
Then the system time may be reset to the date of manufacture after
rebooting. This patch fixed this issue.
Signed-off-by: Huacai Chen <huacai.chen@intel.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I have discovered that the current version of rtc-x1205.c does not work
correctly when asked to set the alarm time by the RTC_WKALM_SET ioctl()
call. This happens because the alarm registers do not behave like the
current-time registers. They are non-volatile. Two things go wrong:
- the X1205 requires a 10 msec delay after any attempt to write to the
non-volatile registers. The x1205_set_datetime() routine does the write
as 8 single-byte writes without any delay. Only the first write
succeeds. The second is NAKed because the chip is busy.
- the X1205 resets the RWEL bit after any write to the non-volatile
registers. This would lock out any further writes after the first even
with a 10msec delay.
I fix this by doing a single 8-byte write and then waiting 10msec for the
chip to be ready. A side effect of this change is that it will speed up
x1205_rtc_set_time() which uses the same code.
I have also implemented the 'enable' bit in the rtc_wkalm structure, which
the existing driver does not attempt to do. I have modified both
x1205_rtc_set_alarm() to set the AL0E bit, and x1205_rtc_read_alarm() to
return it.
I have tested this patch on a LinkSys NSLU2 under OpenWRT, but on no other
hardware. On the NSLU2 the X1205 correctly asserts its IRQ pin when the
alarm time matches the current time.
[akpm@linux-foundation.org: clean up over-parenthesisation]
Signed-off-by: Michael Hamel <mhamel@adi.co.nz>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As reported by Vipul Gandhi, the current serial_match_port() doesn't work
for tty-devices using dynamic major number allocation. Fix it.
It oopses if you suspend a serial port with _dynamic_ major number. ATM,
I think, there's only the drivers/serial/jsm/jsm_driver.c driver, that
does it in-tree.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Vipul Gandhi <vcgandhi1@aol.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>
While 0e36a9a4a7 ("rtc: fix readback from
/sys/class/rtc/rtc?/wakealarm") made sure that active alarms were never
returned with invalid "wildcard" fields (negative), it can still report
(wrongly) that the alarm triggers in the past.
Example, if it's now 10am, an alarm firing at 5am will be triggered
TOMORROW not today. (Which may also be next month or next year...)
This updates that alarm handling in three ways:
* Handle alarm rollover in the common cases of RTCs that don't
support matching on all date fields.
* Skip the invalid-field logic when it's not needed.
* Minor bugfix ... tm_isdst should be ignored, it's one of the
fields Linux doesn't maintain.
A warning is emitted for some of the unhandled rollover cases, but the
possible combinations are a bit too numerous to handle every bit of
potential hardware and firmware braindamage.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Mark Lord <lkml@rtr.ca>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
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_mv: safer logic for limit_warnings
libata-sff: improve HSM violation reporting
ahci: always clear all bits in irq_stat
sata_sil24: add DID for another adaptec flavor
sata_uli: hardreset is broken
Remove explicit lock_kernel() calls and document why the code is safe.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
There is a miniscule chance that two separate host controllers
might be in sata_mv at the same time and manage to decrement
the static limit_warnings variable below zero.
Fix the comparison to deal with it.
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Improve SFF HSM violation reporting such that each HSM violation can
be distinguished using ehi_desc.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Some AHCI controllers (ICH7 was reported) set pending bit in
HOST_IRQ_STAT for non-existent ports and when it's not cleared falls
into IRQ storm. Always clear full irq_stat instead of only the bits
that are handled. As nothing changes for recognized ports, the risk
of breaking things is pretty low.
Reported and verified by Philipp Thomas in the following suse
bugzilla.
https://bugzilla.novell.com/attachment.cgi?id=215692
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Philipp Thomas <pth@novell.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
There's another DID used for Adaptec card. Add it.
Reported by Travis Read.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Travis Read <ics@dark.net.au>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The restart() function is called when the link state changes and resets
multicast and promiscuous settings. This patch restores those settings at the
end of restart().
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Short packets has to be discarded by the driver. So this patch addresses the
issue of discarding the short packets of size lesser then ethernet header
size.
Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The descriptor pointers were not initialized to NIL values, so it was
poiniting to some random addresses which was completely invalid. This
fix takes care of initializing the descriptor to NIL values and clearing
the valid descriptors on clean ring operation.
Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on pasemi_mac, since
the device only exists as part of a big-endian system-on-chip, but
fixing this gets rid of a sparse warning and avoids having a bad example
in the tree.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on ehea, since ehea
only exists for big-endian platfroms (at the moment at least) but fixing
this gets rid of a sparse warning and avoids having a bad example in the
tree.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When ehea_stop is called the function
cancel_work_sync(&port->reset_task) is used to ensure
that the reset task is not running anymore. We need an
additional flag to ensure that it can not be scheduled
after this call again for a certain time.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
