Filter out modes that are higher than the max pixel
clock.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2.
Signed-off-by: NSteffen Sledz <sledz@dresearch-fe.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

One new offender detected by the recently increased type checking in
platform_get_drvdata():

drivers/rtc/rtc-m41t93.c: In function ‘m41t93_remove’:
drivers/rtc/rtc-m41t93.c:192: warning: passing argument 1 of ‘platform_get_drvdata’ from incompatible pointer type

Use spi_get_drvdata() instead of platform_get_drvdata(), cfr. commit
42fea15d ("spi/rtc-{ds1390,ds3234,m41t94}:
Use spi_get_drvdata() for SPI devices")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The flush_to_ldisc() work entry has special logic to notice when it has
seen the original tail of the data queue, and it avoids continuing the
flush if it sees that _original_ tail rather than the current tail.

This logic can trigger in case somebody is constantly adding new data to
the tty while the flushing is active - and the intent is to avoid
excessive CPU usage while flushing the tty, especially as we used to do
this from a softirq context which made it non-preemptible.

However, since we no longer re-arm the work-queue from within itself
(because that causes other trouble: see commit a5660b41 "tty: fix
endless work loop when the buffer fills up"), this just leads to
possible hung tty's (most easily seen in SMP and with a test-program
that floods a pty with data - nobody seems to have reported this for any
real-life situation yet).

And since the workqueue isn't done from timers and softirq's any more,
it's doubtful whether the CPU useage issue is really relevant any more.
So just remove the logic entirely, and see if anybody ever notices.

Alternatively, we might want to re-introduce the "re-arm the work" for
just this case, but then we'd have to re-introduce the delayed work
model or some explicit timer, which really doesn't seem worth it for
this.
Reported-and-tested-by: NGuillaume Chazarain <guichaz@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current RE'd code causes blank screens and
display problems on a lot of systems.  So disable
it by default for now.  It can still be enabled
by setting the audio parameter to 1.  E.g.:
radeon.audio=1

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38010
https://bugs.freedesktop.org/show_bug.cgi?id=27731
https://bugs.freedesktop.org/show_bug.cgi?id=35970
https://bugs.freedesktop.org/show_bug.cgi?id=26195
and many other reported problems.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On my x86_64 system with >4GB of ram and swiotlb instead of
a hardware iommu (because I have a VIA chipset), the call
to pci_set_dma_mask (see below) with 40bits returns an error.

But it seems that the radeon driver is designed to have
need_dma32 = true exactly if pci_set_dma_mask is called
with 32 bits and false if it is called with 40 bits.

I have read somewhere that the default are 32 bits. So if the
call fails I suppose that need_dma32 should be set to true.

And indeed the patch fixes the problem I have had before
and which I had described here:
http://choon.net/forum/read.php?21,106131,115940Acked-by: NAlex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Wierdly the kms parser never initialised the family, it wasn't really used
much, but the fmt checker patch started using it and it fell over.
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit a559d2c8.

Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc
when the option driver tries to bind to it.

So revert this as it doesn't seem to be needed at all.

Thanks to Michael Tokarev and Paweł Drobek for working on resolving this
issue.

Cc: Paweł Drobek <pawel.drobek@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The loops over connection ID strings in pm_runtime_clk_notify()
should actually iterate over the strings and not over the elements
of the first of them, so make them behave as appropriate.

This fixes a regression introduced by commit 600b776e
(OMAP1 / PM: Use generic clock manipulation routines for runtime PM).
Reported-and-tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The Samsung GPIO drivers are always built-in when the relevant
platform is selected.  Change the Kconfig symbol to def_bool y
dependant on the platform.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

If CONFIG_PM is not set, init_iommu_pm_ops() introduced by commit
134fac3f (PCI / Intel IOMMU: Use
syscore_ops instead of sysdev class and sysdev) is not defined
appropriately.  Fix this issue.
Reported-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The S3C_GPIO_PULL_UP macro value incorrectly maps to a reserved setting of GPIO
pull up/down registers on Exynos4 platform. Fix this incorrect mapping by adding
wrappers to the s3c_gpio_setpull_updown and s3c_gpio_getpull_updown functions.
Signed-off-by: NThomas Abraham <thomas.ab@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Add a label before the call to clk_put and jump to that in the error
handling code that occurs after the call to clk_get has succeeded.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
expression e1,e2;
statement S;
@@

e1 = clk_get@p1(...);
... when != e1 = e2
    when != clk_put(e1)
    when any
if (...) { ... when != clk_put(e1)
               when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
 } else S
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1468) changes the Kconfig definition for
USB_GADGET_DUALSPEED.  This option is determined entirely by which
device controller drivers are to be built, through Select statements;
it does not need to be (and should not be) configurable by the user.

Also, the "default n" line is superfluous -- everything defaults to N.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Like with other host controllers capable of operating at both high
speed and full speed, we need to indicate that the emulated controller
presented by dummy-hcd has this ability.  Otherwise usbcore will not
accept full-speed gadgets under dummy-hcd.  This patch (as1469) sets
the appropriate has_tt flag.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some USB mass-storage devices have bugs that cause them not to handle
the first READ(10) command they receive correctly.  The Corsair
Padlock v2 returns completely bogus data for its first read (possibly
it returns the data in encrypted form even though the device is
supposed to be unlocked).  The Feiya SD/SDHC card reader fails to
complete the first READ(10) command after it is plugged in or after a
new card is inserted, returning a status code that indicates it thinks
the command was invalid, which prevents the kernel from retrying the
read.

Since the first read of a new device or a new medium is for the
partition sector, the kernel is unable to retrieve the device's
partition table.  Users have to manually issue an "hdparm -z" or
"blockdev --rereadpt" command before they can access the device.

This patch (as1470) works around the problem.  It adds a new quirk
flag, US_FL_INVALID_READ10, indicating that the first READ(10) should
always be retried immediately, as should any failing READ(10) commands
(provided the preceding READ(10) command succeeded, to avoid getting
stuck in a loop).  The patch also adds appropriate unusual_devs
entries containing the new flag.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NSven Geggus <sven-usbst@geggus.net>
Tested-by: NPaul Hartman <paul.hartman+linux@gmail.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Can't find evidence that this is actually done.

Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I doubt the clock is optional. In case it is it should not return with
an error code because we leak everything.

Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

this is more backwords than it has to be.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

|drivers/usb/gadget/mv_udc_core.c:2108: error: label `error' used but not defined

This seems to be broken since the initial commit. I changed this to a
simple return. The other user is the probe code which lets ->probe()
fail on error here.

|drivers/usb/gadget/mv_udc_core.c:2107: warning: passing argument 1 of `dev_err' from incompatible pointer type
|drivers/usb/gadget/mv_udc_core.c:2118: warning: initialization from incompatible pointer type
|drivers/usb/gadget/mv_udc_core.c:2119: warning: initialization from incompatible pointer type
|drivers/usb/gadget/mv_udc_core.c:2130: error: initializer element is not constant
|drivers/usb/gadget/mv_udc_core.c:2130: error: (near initialization for `udc_driver.driver.pm')

Cc: Chao Xie <chao.xie@marvell.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

drivers/usb/gadget/at91_udc.c: In function 'write_fifo':
drivers/usb/gadget/at91_udc.c:421:2: error: implicit declaration of function 'prefetch'
make[3]: *** [drivers/usb/gadget/at91_udc.o] Error 1
make[2]: *** [drivers/usb/gadget] Error 2
make[2]: *** Waiting for unfinished jobs....
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently the s3c-hsotg driver is extremely chatty, producing voluminous
with large register dumps even in default operation. Tone this down so
we're not chatty unless DEBUG is defined.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Commit 64252c75 (vfs: remove dget() from dentry_unhash()) removed the
useless dget from dentry_unhash but didn't fix up this caller in the usb
code.  There used to be exactly one dput per dentry_unhash call; now
there are none.
Tested-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NSage Weil <sage@newdream.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

PCI(E)GART isn't quite stable it seems, fall back to old method until I get
the time to sort it out properly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Hopefully the cause of nvc0 "page jumping" issue.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported-by: NMario Bachmann <grafgrimm77@gmx.de>
Tested-by: NGreg Turner <gmturner007@ameritech.net>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes various potential oopses.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Should hopefully get modesetting at least from this, it appears these are
GF119 chipsets.  Accel will come eventually, once I order a board.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

_set_gpio_triggering uses read-modify-write on bank registers,
lock bank->lock around all calls to it to prevent register
corruption if two cpus access gpios in the same bank at the
same time.
Signed-off-by: NColin Cross <ccross@android.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
causing only the last bit set to take effect, resulting in lost
wakeups when the GPIO controller is in idle.

Replace direct writes to IRQWAKEN with MOD_REG_BIT calls to
perform a read-modify-write on the register.
Signed-off-by: NColin Cross <ccross@android.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

WARNING: arch/arm/plat-omap/built-in.o(.devinit.text+0x46c): Section mismatch in reference from the function omap_gpio_probe() to the function .init.text:omap_gpio_chip_init()
The function __devinit omap_gpio_probe() references
a function __init omap_gpio_chip_init().
If omap_gpio_chip_init is only used by omap_gpio_probe then
annotate omap_gpio_chip_init with a matching annotation.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Protocol stall should not be fatal while reading port or hub status as it is
transient state.  Currently hub EP0 STALL during port status read results in
failed device enumeration.  This has been observed with ST-Ericsson (formerly
Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard.
Signed-off-by: NLibor Pechacek <lpechacek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After the prefetch/list.h restructure, drivers need to explicitly include
linux/prefetch.h in order to use the prefetch() function.  Otherwise, the
current driver fails to build:

drivers/usb/musb/musb_core.c: In function 'musb_write_fifo':
drivers/usb/musb/musb_core.c:219: error: implicit declaration of function 'prefetch'
make[3]: *** [drivers/usb/musb/musb_core.o] Error 1
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This adds the Nokia E7 and C7 to the list of devices in cdc-acm, allowing
the secondary ACM channel on the device to be exposed. Without this patch
the ACM driver won't claim this secondary channel as it's marked as
having a vendor-specific protocol.
Signed-off-by: NToby Gray <toby.gray@realvnc.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ep_write() acquires data->lock mutex in get_ready_ep() and releases it
on all paths except for one: when usb_endpoint_xfer_isoc() failed. The
patch adds mutex_unlock(&data->lock) at that path.

It is similar to commit 00cc7a5f ("usb-gadget: unlock data->lock mutex on error path in ep_read()"),
it was not fixed at that time by accident.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The funtion option_send_status times out when sending USB messages
to the interfaces 0, 1, and 2 of this UMTS stick. This results in a
5s timeout in the function causing other tty operations to feel very
sluggish.

This patch adds a blacklist entry for these 3 interfaces on the ZTE
K3765-Z device.

I was also able to reproduce the problem with v2.6.38 and v2.6.39.

This is very similar to a problem fixed in

commit 7a89e4cb
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date:   Wed Mar 9 09:19:48 2011 +0000

    USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626
Signed-off-by: NTorsten Hilbrich <torsten.hilbrich@secunet.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Simple ID addition.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This modem really wants sendsetup blacklisted for interfaces 0 and 1,
otherwise the kernel hardlocks for about 10 seconds while waiting for
the modem's firmware to respond, which it of course doesn't do.

A slight complication here is that TCT (who owns the Alcatel brand) used
the same USB IDs for the X200 as the X060s despite the devices having
completely different firmware and AT command sets, so we end up adding
the X060s to the blacklist at the same time.  PSA to OEMs: don't use the
same USB IDs for different devices.  Really.  It makes your kittens cry.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>