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: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NHaavard 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: Eric Piel <Eric.Piel@tremplin-utc.net>
Cc: Pavel Machek <pavel@suse.cz>
Tested-by: NPalatis Tseng <palatis@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: NEric Piel <Eric.Piel@tremplin-utc.net>
Cc: Pavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NPavel Machek <pavel@suse.cz>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NEd 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NZlatko Calusic <zlatko.calusic@iskon.hr>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NMiles Lane <miles.lane@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NDavid Woodhouse <David.Woodhouse@intel.com>
Tested-by: NChris Wright <chrisw@sous-sol.org>
Reviewed-by: NBhavesh Davda <bhavesh@vmware.com>
Signed-off-by: NLinus 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=483208Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean 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: NJean Delvare <khali@linux-fr.org>
Acked-by: NHans 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: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro 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: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro 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: NAdam Baker <linux@baker-net.org.uk>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro 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: NMauro 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: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro 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: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As reported by David Engel <david@istwok.net>, ATSC115 doesn't work
fine with mythtv. This software opens both analog and dvb interfaces of
saa7134.

What happens is that some tuner commands are going to the wrong place,
as shown at the logs:

Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01

This happens due to a hack at TUV1236D analog setup, where it replaces
tuner address, at 0x61 for 0x0a, in order to save a few memory bytes.

The code assumes that nobody else would try to access the tuner during
that setup, but the point is that there's no lock to protect such
access. So, this opens the possibility of race conditions to happen.

Instead of hacking tuner address, this patch uses a temporary var with
the proper tuner value to be used during the setup. This should save
the issue, although we should consider to write some analog/digital
lock at saa7134 driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The devices handled by hid-tmff and hid-zpff were added in the
hid_ignore_list[] instead of hid_blacklist[] in hid-core.c, thus
disabling them completely.

hid_ignore_list[] causes hid layer to skip the device, while
hid_blacklist[] indicates there is a specific driver in hid bus.

Re-enable the devices by moving them to the correct list.
Signed-off-by: NAnssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We can't return immediately because lock_kernel() is held.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

For quite some time users with various UPSes from Powercom were forced to play
magic with bind/unbind in /sys in order to be able to see the UPSes.  The
beasts does not work as HID devices, even if claims to do so.  cypress_m8
driver works with the devices instead, creating a normal serial port with which
normal UPS controlling software works.

The manufacturer confirmed the upcoming models with proper HID support will
have different device IDs.  In any way, it's wrong to have two completely
different modules for one device in kernel.

Blacklist the device in HID (add it to hid_ignore_list) to stop this mess,
finally.
Signed-off-By: NMichael Tokarev <mjt@tls.msk.ru>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

WARNING: drivers/mfd/built-in.o(.text+0x1706): Section mismatch in
reference from the function sm501_register_gpio() to the function
.devinit.text:sm501_gpio_register_chip()
The function sm501_register_gpio() references
the function __devinit sm501_gpio_register_chip().
This is often because sm501_register_gpio lacks a __devinit
annotation or the annotation of sm501_gpio_register_chip is wrong.
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

drv => driver renaming is needed otherwise modpost will spit false positives
re pointing to __devinit function from regular data.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

The i2c_device_id list is supposed to be zero-terminated.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Balaji Rao <balajirrao@openmoko.org>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

The IRQs might have been left enabled in hardware, generating spurious
IRQs before the drivers have registered.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Fixes an off-by-one error in the iomem resource mapping.
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Many ARM platforms do not provide a mach/cpu.h so rather than guarding
the use of that header with CONFIG_ARM guard it with the guards used
when testing for the OMAP variants in the body of the code.
Signed-off-by: NMark Brown <broonie@sirena.org.uk>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

With a postfix decrement tries will reach -1 rather than 0,
so the warning will not be issued even upon timeout.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

The code is out of sync with the silicon.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Check the return value of the device I/O functions when reading the
ID registers so we can provide a more useful diagnostic when we're
having trouble talking to the device.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Ensure that the interrupt handling is configured before we do platform
specific init. This allows the platform specific initialisation to
configure things which use interrupts safely.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Since ei is already known to be non-NULL, I assume that what was intended
was to test the result of kzalloc.
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Kernel bz#12176 reports that nf2 hardreset simply doesn't work.  Give
up.  Argh...
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Robert Hancock <hancockr@shaw.ca>
Reported-by: NSaro <saro_v@hotmail.it>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Commit 871af121 (libata: Add 32bit
PIO support) has caused all kinds of errors on the ATAPI devices, so
it has been empirically proven that one shouldn't try to read/write
an extra data word when a device is not expecting it already. "Don't
do it then"; however, still use a chance to do 32-bit read/write one
last time when there are exactly 3 trailing bytes.

Oh, and stop pointlessly swapping the bytes to and fro on big-endian
machines by using io*_rep() accessors which shouldn't byte-swap.

This patch should fix the kernel.org bug #12609.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Always lock whc->lock with spin_lock_irq() or spin_lock_irqsave().
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>

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.

Should resolve:

  https://bugzilla.redhat.com/show_bug.cgi?id=479996
  http://bugzilla.kernel.org/show_bug.cgi?id=12578Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Tested-and-acked-by: NChris Wright <chrisw@sous-sol.org>
Reviewed-by: NBhavesh Davda <bhavesh@vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

bugzilla: #12363
commit 7cd5b08b added a second regression:
some Dell's and Compaq's lockup on boot. So we revert most of the code.
The ICH9 reboot issue remains in place and will need some more fixing... :-(
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Fix pci kernel-doc parameter missing notation, correct
function name, and fix typo:

Warning(linux-2.6.28-git10//drivers/pci/pci.c:1511): No description found for parameter 'exclusive'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Fix struct pci_platform_pm_ops kernel-doc notation.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>