acpi_osi=Linux helps the mute button work properly by sending Linux
a mute key press.

http://bugzilla.kernel.org/show_bug.cgi?id=13934Signed-off-by: NJerone Young <jerone.young@canonical.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Added missing mach/i2c.h and linux/io.h header file includes
Signed-off-by: NKevin Wells <kevin.wells@nxp.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Limit minimum jiffie timeout to 2 to prevent early timeout on systems
with low tick rates
Signed-off-by: NKevin Wells <kevin.wells@nxp.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

As this struct is exposed to user space and the API was added for this
release it's a bit of a pain for the C++ world and we still have time to
fix it. Rename the fields before we end up with that pain in an actual
release.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Reported-by: Olivier Goffart
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 86cf898e ("intel-iommu: Check for
'DMAR at zero' BIOS error earlier.") was supposed to work by pretending
not to detect an IOMMU if it was actually being reported by the BIOS at
physical address zero.

However, the intel_iommu_init() function is called unconditionally, as
are the corresponding functions for other IOMMU hardware.

So the patch only worked if you have RAM above the 4GiB boundary. It
caused swiotlb to be initialised when no IOMMU was detected during early
boot, and thus the later IOMMU init would refuse to run.

But if you have less RAM than that, swiotlb wouldn't get set up and the
IOMMU _would_ still end up being initialised, even though we never
claimed to detect it.

This patch also sets the dmar_disabled flag when the error is detected
during the initial detection phase -- so that the later call to
intel_iommu_init() will return without doing anything, regardless of
whether swiotlb is used or not.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We should set this before calling agp_add_bridge() so that it's done
before we map the scratch page too.

This should probably fix the regression reported as k.o. bug #14627.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

unmap Rx page only when guaranteed that this page won't be
used anymore to allocate rx page chunks.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The TRT bit shifts were reversed for EMAC4 and non-EMAC4 during the
port from ibm_emac to ibm_newemac. This patch corrects that error.
Signed-off-by: NDave Mitchell <dmitchell@appliedmicro.com>
Acked-by: NFeng Kan <fkan@appliedmicro.com>
Acked-by: NProdyut Hazarika <phazarika@appliedmicro.com>
Acked-by: NStefan Roese <sr@denx.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Dave,

Attached is an update of my patch against the cpufreq fixes branch.

Before applying the patch I compiled and booted the tree to see if the panic
was still there -- to my surprise it was not.  This is because of the conversion
of cpufreq_cpu_governor to a char[].

While the panic is kaput, the problem of stale data continues and my patch is
still valid.  It is possible to end up with the wrong governor after hotplug
events because CPUFREQ_DEFAULT_GOVERNOR is statically linked to a default,
while the cpu siblings may have had a different governor assigned by a user.

ie) the patch is still needed in order to keep the governors assigned
properly when hotplugging devices
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NDave Jones <davej@redhat.com>

ondemand and conservative governors are messing up time units in the
code path where NO_HZ is not enabled and ignore_nice is set. The walltime
idletime stored is in jiffies and nice time calculation is happening in
microseconds.

The problem was reported and diagnosed by Alexander here.
http://marc.info/?l=linux-kernel&m=125752550404513&w=2

The patch below fixes this thinko.
Reported-by: NAlexander Miller <Miller@fmi.uni-stuttgart.de>
Tested-by: NAlexander Miller <Miller@fmi.uni-stuttgart.de>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Currently on governer backup/restore path we storing governor's pointer.
This is wrong because one may unload governor's module after cpu goes
offline. As result use-after-free will take place on restored cpu.
It is not easy to exploit this bug, but still we have to close this
issue ASAP. Issue was introduced by following commit
084f3493

##TESTCASE##
#!/bin/sh -x
modprobe acpi_cpufreq
# Any non default governor, in may case it is "ondemand"
modprobe cpufreq_ondemand
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
rmmod acpi_cpufreq
rmmod cpufreq_ondemand
modprobe acpi_cpufreq  # << use-after-free here.
Signed-off-by: NDmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: NDave Jones <davej@redhat.com>

The return should be negative on errors
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Return a negative error value instead of a positive
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: dmitry pervushin <dpervushin@embeddedalley.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device
has 4 interfaces, of which 1 is handled by storage and the other 3 by
option driver.

The device appears first as CD-only 05c6:2100 device and must be
switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch.

The MessageContent for usb_modeswitch.conf is:
"55534243e0c26a85000000000000061b000000020000000000000000000000"
Signed-off-by: NZhang Le <r0bertz@gentoo.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1299b) fixes a bug in an error-handling path of usbmon's
binary interface.  The storage area for URB data is divided into
fixed-size blocks.  If an URB's data can't be copied, the area
reserved for it should be decreased to the size of the truncated
information (rounded up to a block boundary).  Rounding up the amount
to be removed and subtracting it from the reserved size is definitely
the wrong thing to do.

Also, when the data for an isochronous URB can't be copied, we can
still copy the isoc packet descriptors.  In fact the current code does
copy the descriptors, but then sets the capture length to 0 so they
remain inaccessible.  The capture length should be reduced to the
length of the descriptors, not set to 0.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NPete Zaitcev <zaitcev@redhat.com>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The scratchpad_free() function uses xhci->page_size to free some memory
with pci_free_consistent().  However, the page_size is set to zero before
the call, causing kernel oopses on driver unload.  Call scratchpad_free()
before setting xhci->page_size to zero.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NJohn Youn <John.Youn@synopsys.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The trb_in_td() function in the xHCI driver is supposed to translate a
physical transfer buffer request (TRB) into a virtual pointer to the ring
segment that TRB is in.

Unfortunately, a mistake in this function may cause endless loops as the
driver searches through the linked list of ring segments over and over
again.  Fix a couple bugs that may lead to loops or bad output:

1. Bail out if we get a NULL pointer when translating the segment's
private structure and the starting DMA address of the segment chunk.  If
this happens, we've been handed a starting TRB pointer from a different
ring.

2. Make sure the function works when there's multiple segments in the
ring.  In the while loop to search through the ring segments, use the
current segment variable (cur_seg), rather than the starting segment
variable (start_seg) that is passed in.

3. Stop searching the ring if we've run through all the segments in the
ring.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the xHCI driver fails during the memory initialization, xhci->ir_set
may not be a valid pointer.  Check that it points to valid DMA'able memory
before writing to that address during the memory freeing process.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Am Donnerstag, 10. September 2009 15:43:53 schrieb Dietmar Hilbrich:
> Hello,
>
> i have the following problem with the cdc-acm - driver:
>
> I'm using the driver with an "Ericsson F3507G" on a Thinkpad T400.
>
> If a disable the device (with the RFKill-Switch) while it is used by a
> programm like ppp, the driver doesn't seem to correctly clean up the tty,
> even after the program has been closed)
>
> The tty is still active (e.g. there still exists an entry in
> /sys/dev/char/166:0 if ttyACM0 was used) and if a reacticate the device,
> this device entry will be skipped and the Device-Nodes ttyACM1, ttyACM2
> and ttyACM3 will be used.
>
> This problem was introduced with the commit
> 10077d4a (before 2.6.31-rc1) and still
> exists in 2.6.31.
>
> I was able the fix this problem with the following patch:
>
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 2bfc41e..0970d2f 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -676,6 +676,7 @@ static void acm_tty_hangup(struct tty_struct *tty)
>         struct acm *acm = tty->driver_data;
>         tty_port_hangup(&acm->port);
>         acm_port_down(acm, 0);
> +       acm_tty_unregister(acm);
>  }

I have the same problem with cdc-acm (I'm using a Samsung SGH-U900): when I
unplug it from the USB port during a PPP connection, the ppp daemon gets the
hangup correctly (and closes the device), but the struct acm corresponding to
the device disconnected is not freed. Hence reconnecting the device results in
creation of /dev/ttyACM(x+1). The same happens when the system is hibernated
during a PPP connection.

This memory leak is due to the fact that when the tty is hung up,
tty_port_close_start() returns always zero, and acm_tty_close() never reaches
the point where acm_tty_unregister() is called.

Here is a fix for this.
Signed-off-by: NFrancesco Lavra <francescolavra@interfree.it>
Acked-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If acm_rx_tasklet() gets called before tty_port_block_til_ready()
returns, then bulk IN urbs may not be sent. This fixes it.
Signed-off-by: NHenry Gebhardt <gebhardt@astro.uni-tuebingen.de>
Acked-by: NOliver Neukum <oliver@neukum.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The following patch in the driver is required to avoid USB 1.1 device
failures that may occur due to requests from USB OHCI controllers may
be overwritten if the latency for any pending request by the USB
controller is very long (in the range of milliseconds).
Signed-off-by: NLibin Yang <libin.yang@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Original discussion:
http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248
or
http://marc.info/?l=linux-usb&m=125553790714133&w=2

9a68e39d broke carrier handling so that a
cp210x setup which needed the carrier lines set up (non CLOCAL) which did
not make a call which set the termios bits left the lines down even if
CLOCAL was not asserted.

Fix this not by reverting but by adding the proper dtr_rts and
carrier_raised methods. This both sets the modem lines properly and also
implements the correct blocking semantics for the port as required by
POSIX.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Reported-by: NKarl Hiramoto <karl@hiramoto.org>
Tested-by: NKarl Hiramoto <karl@hiramoto.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Original discussion:
http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248
or
http://marc.info/?l=linux-usb&m=125553790714133&w=2

The tty_port code inherited a bug common to various drivers it was based
upon. If the tty is opened O_NONBLOCK we do not wait for the carrier to be
raised but we must still raise our modem lines if appropriate.

(There is a second question here about whether we should do so if CLOCAL is
 set but that can wait)
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Reported-by: NKarl Hiramoto <karl@hiramoto.org>
Tested-by: NKarl Hiramoto <karl@hiramoto.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We need to look for the 'shared-pins' property to get
this right.

Based upon a patch by Hermann Lauer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes the following warning:

WARNING: drivers/net/phy/built-in.o(.devexit.text+0x70): Section mismatch in reference from the function .mdio_gpio_bus_destroy() to the function .devinit.text:.mdio_gpio_bus_deinit()
The function __devexit .mdio_gpio_bus_destroy() references
a function __devinit .mdio_gpio_bus_deinit().
This is often seen when error handling in the exit function
uses functionality in the init path.
The fix is often to remove the __devinit annotation of
.mdio_gpio_bus_deinit() so it may be used outside an init section.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

PPP does not correctly call pskb_may_pull() on all necessary receive paths
before reading the PPP protocol, thus causing PPP to report seemingly
random 'unsupported protocols' and eventually trigger BUG_ON(skb->len <
skb->data_len) in skb_pull_rcsum() when receiving multilink protocol in
non-linear skbs.

ppp_receive_nonmp_frame() does not call pskb_may_pull() before reading the
protocol number.  For the non-mp receive path this is not a problem, as
this check is done in ppp_receive_frame().  For the mp receive path,
ppp_mp_reconstruct() usually copies the data into a new linear skb.
However, in the case where the frame is made up of a single mp fragment,
the mp header is pulled and the existing skb used.  This skb was then
passed to ppp_receive_nonmp_frame() without checking if the encapsulated
protocol header could safely be read.
Signed-off-by: NBen McKeegan <ben@netservers.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commmit 4b77b0a2 EEH breaks
after the second error, since it calls pci_restore_state()
but it returns 0, since pci->state_saved is false.

So, this patch just call pci_save_state() after pci_restore_state().
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Panasonic CF-72 uses 6-byte protocol and does not need to be tied
to a particular port.
Signed-off-by: NAbner Holsinger <9zabner@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Commit b7802c5c ("Input: psmouse - use boolean type") caused the
synaptics_hardware variable to be completely useless, as it is
constantly set to 'true' throughout the whole psmouse_extensions().
This was caused by the following hunk in the commit in question

	-       int synaptics_hardware = 0;
	+       bool synaptics_hardware = true;

which is wrong and causes driver to issue extra reset when falling
back to bare PS/2 protocol.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This will fix some small issues with the COH 901 331 RTC driver:
- Interrupt is disabled after alarm so that we don't fire
  multiple interrupts.
- We return 0 from the coh901331_alarm_irq_enable() ridding
  a compile warning.
- We alter the name in the U300 device registry to match that
  of the driver so they sucessfully resolve.
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_probe_subdev':
drivers/mtd/maps/sa1100-flash.c:214: warning: format '%d' expects type 'int', but argument 3 has type 'uint64_t'
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Don't dereference drvdata after it has been freed.

regards,
dan carpenter
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

If there are leds present in the OF tree, but the GPIOs for (some) of
them are unavailable, led_data doesn't get populated with correct
devices. Then, on device unbinding, one can crash the kernel.

Workaround this by setting led->gpio to invalid value early.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

On spitz (& similar) machines, if battery is running low, backlight
needs
to be limited to lower step.  Unfortunately, current code uses &= for
limiting, turning backlight off completely for some backlight settings.
Fix that.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

The adt7475 driver creates pwm#_auto_channel_temp attributes instead
of the standard pwm#_auto_channels_temp. Fix it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>

The comment says that limits are cached for 60 seconds but the code
actually caches them for only 2 seconds. Align the code on the
comment, as 60 seconds makes more sense.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>

The logic of temperature fault flags is wrong, it shows faults when
there are none and vice versa. Fix it.

I can't believe this has been broken since the driver was added, 8
months ago, basically breaking temp1 and temp3, and nobody ever
complained.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>

Avoid registering channels that have zero divider settings in them, as this
will only lead to kernel OOPS from divide-by-zero when the sysfs entry is
read.
Signed-off-by: NBen Dooks <ben@simtec.co.uk>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

If ret is unsigned, the checks for negative wm831x_reg_read() return values
are wrong. The error value should be transmitted to its caller, e.g.
wm831x_gp_ldo_get_status() which tests for a negative return value.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>