ISP1760 requires a delay of 90ns between programming the address and
reading the data.  Current driver solves this by a mdelay(1) which is
very heavy weighted and slow.  This patch applies the workaround from
the ISP1760 FAQ by using two different banks for PTD and payload data
and using a common wait for them.  This wait is done by an additional
ISP1760 access (whose timing constraints guarantee the 90ns delay).
This improves speed when reading from an USB stick from:

  $ time dd if=/dev/sda of=/dev/zero bs=65536 count=1638
  real    1m 15.43s
  user    0m 0.44s
  sys     0m 39.46s

to

  $ time dd if=/dev/sda of=/dev/zero bs=65536 count=1638
  real    0m 18.53s
  user    0m 0.16s
  sys     0m 12.97s

[bigeasy@linutronix.de: fixed comment formating, moved define into
   header file, obey 80 char rule]
Signed-off-by: NEnrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: NSebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

if the enqueue function returns -ESHUTDOWN or -ENOMEM then
we return 0 instead of an error. This leads to a timeout and
then to a dequeue request of an not enqueued urb.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Update RX path handling in new serial gadget code to cope better with
RX blockage:  queue every RX packet until its contents can safely be
passed up to the ldisc.  Most of the RX path work is now done in the
RX tasklet, instead of just the final "push to ldisc" step.  This
addresses some cases of data loss:

  - A longstanding serial gadget bug: when tty_insert_flip_string()
    didn't copy the entire buffer, the rest of the characters were
    dropped!  Now that packet stays queued until the rest of its data
    is pushed to the ldisc.

  - Another longstanding issue:  in the unlikely case that an RX
    transfer returns data and also reports a fault, that data is
    no longer discarded.

  - In the recently added RX throttling logic:  it needs to stop
    pushing data into the TTY layer, instead of just not submitting
    new USB read requests.  When the TTY is throttled long enough,
    backpressure will eventually make the OUT endpoint NAK.

Also: an #ifdef is removed (no longer necessary); and start switching
to a better convention for debug messages (prefix them with tty name).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

"#%x" should have been "%#x"
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

add razr v3xx US_FL_FIX_CAPACITY flag to unusual_devs.h in usb-storage

This is another Motorola phone that incorrectly reports the sector count
(off by one).

Problem Description: io errors when mounting phone's sd-card via the
phones usb port

Steps to reproduce: mount Motorola Razr v3xx phones sd-card on Linux Desktop
via usb cable. Phones USB port must be in memory card mode.

DEBUG output:
Jul 9 19:32:41 micky kernel: Buffer I/O error on device sdd, logical block 3970048
Jul 9 19:32:41 micky kernel: sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
Jul 9 19:32:41 micky kernel: sd 11:0:0:0: [sdd] Sense Key : Medium Error [current]
Jul 9 19:32:41 micky kernel: sd 11:0:0:0: [sdd] Add. Sense: No additional sense information
Jul 9 19:32:41 micky kernel: end_request: I/O error, dev sdd, sector 3970048


From: Jost Diederichs <jost@qdusa.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch upgrades the support for the Sierra Wireless TRU-Install
feature (i.e. zeroCD) to allow for future support of Linux enabled
TRU-Install devices.

By default all devices that do not have a Linux enabled TRU-Install
device (i.e. the device does not have a Linux package on the virtual CD
partition) will be switched into "modem mode." Devices that do contain a
Linux package in the TRU-Install virtual CD will be allowed to enumerate
as a CD-Rom so that either (a) a user can install the packaged software
or (b) a user-space application (e.g. udev) can switch it to modem mode.

This patch does allow for manual override by adding a usb-storage module
parameter 'swi_tru_install' which can force the modem into either mode
regardless of what packages it contains.
Signed-off-by: NKevin Lloyd <klloyd@sierrawireless.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Moves responsbility of TRU-Install (i.e. ZeroCD) to the usb-storage
driver. See patch 04/04 of this set.
Signed-off-by: NKevin Lloyd <klloyd@sierrawireless.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch changes the method by which the number of ports per interface is
assigned so that it is more dynamic and calculated on the fly (as opposed to
hard coding it). This will allow for faster and easier addition of products.
Signed-off-by: NKevin Lloyd <klloyd@sierrawireless.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Very minor changes to clean up sierra code. Adds a prefix to debug messages so
that Sierra messages are easily recognized. Removes extraneous code.

This targets kernel 2.6.26-rc9
Signed-off-by: NKevin Lloyd <klloyd@sierrawireless.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB ID 4348:5523 is handled by the ch341 driver.  Remove it from the
pl2023 driver.

Reverts 002e8f2c.
Signed-off-by: NTollef Fog Heen <tfheen@err.no>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE
flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card
reader.  Apparently these devices provide reasonable residue values
for READ and WRITE operations, but not for others like INQUIRY or READ
CAPACITY.

This fixes the iRiver T10 problem reported in Bugzilla #11125.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This makes "USB Monitor" appear under "Miscellaneous USB options"
section instead of in the middle of device specific drivers in the
"USB Imaging devices" section.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1119) will help to reduce the clutter of usb-storage's
unusual_devs file by automatically detecting some devices that need
the IGNORE_RESIDUE flag.  The idea is that devices should never return
a non-zero residue for an INQUIRY or a READ CAPACITY command unless
they failed to transfer all the requested data.  So if one of these
commands transfers a standard amount of data but there is a positive
residue, we know that the residue is bogus and we can set the flag.

This fixes the problems reported in Bugzilla #11125.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1122) fixes a bug: When an interface is unregistered,
its children (sysfs files and endpoint devices) are unregistered after
it instead of before.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NKay Sievers <kay.sievers@vrfy.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1121) fixes a bug in the USB serial core.  When a device
is unregistered, the core will give back its minors -- even if the
device hasn't been assigned any!

The patch reserves the highest minor value (255) to mean that no minor
was assigned.  It also removes some dead code and does a small style
fixup.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Without it, we might have trouble when trying to write
some composite gadget drivers.

Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb-storage: quirk around v1.11 firmware on Nikon D40

https://bugzilla.redhat.com/show_bug.cgi?id=454028
Just as in earlier firmware versions, we need to perform this
quirk for the latest version too.

Speculatively do the entry for the D80 too, as they seem to
have the same firmware problems historically.
Signed-off-by: NDave Jones <davej@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1114) fixes a problem that was revealed by an earlier
patch (as1069b).  Some broken controllers seem never to turn off their
RHCS interrupt status bit, even when told to do so.  As a result they
generate an interrupt storm and hang the system.

The patch avoids enabling RHSC interrupt requests when the RHCS status
bit is already set.  This should have no adverse affects on normal
controllers, since they won't set the status bit until a root-hub
status change actually occurs, in which case we wouldn't enable RHSC
interrupt requests anyway -- we would wait until the status change had
been processed and cleared.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested by: Andrey Borzenkov <arvidjaar@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb/core/driver: fix warning:
drivers/usb/core/driver.c:834: warning: 'do_unbind_rebind' defined but not used
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The Patch adds support for Luminance Stellaris Evaluation/Development
Kits (FTDI 2232C based).
The PIDs were missing.

Successfully tested with a Stellaris LM3S8962 Evaluation kit.
Signed-off-by: NFrederik Kriewitz <frederik@kriewitz.eu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB product id registration for the ELV HS485 USB adapter (www.elv.de) to
their home automation bus system. Applies to 2.6.26.
Signed-off-by: NAndre Schenk <andre@melior.s.bawue.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB: fix USB boot crash, ecm_do_notify(), list_add corruption. prev->next should be next (ffff88003b8f82f8)

This fixes a BUG() turned up by Ingo via randconfig testing, where
CONFIG_LIST_DEBUG turned up list corruption.  The corruption was
caused by the dummy_hcd (single-machine test harness for gadget and
HCD code) trashing the request queue when driven by the new CDC
composite gadget an I/O pattern that was previously uncommon.
Fix suggested by Alan Stern.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Tested-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch removes the auerswald USB driver from the linux kernel
2.6.26.

This driver was included into the kernel mainly to connect to the ISDN
framework. This was done in linux 2.4.x. For 2.6.x, due to the fragile
and moving ISDN support, this connection was never realized, and the
only use of this driver was for device configuration. In the age of DSL,
the demand of ISDN support is getting very low.

Meanwhile, with the advent of libusb, an userspace driver was done for
the device configuration which works fine for linux and mac. (Thanks to
the libusb developers!). The userspace driver is downloadable from the
auerswald web site.

So this driver is obsolete now and has to be removed. Many thanks to all
developers which helped me to bring this driver up and working.
Signed-off-by: NWolfgang Muees <wolfgang@iksw-muees.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:

##################################################################

BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:

Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
       c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
       c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
 [<c03b5b43>] ? schedule+0x285/0x2ff
 [<c0131856>] ? pm_qos_requirement+0x3c/0x53
 [<c0239f54>] ? acpi_processor_idle+0x0/0x434
 [<c01025fe>] ? cpu_idle+0x73/0x7f
 [<c03a4dcd>] ? rest_init+0x61/0x63
 =======================

Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.

Suresh wrote:

These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.

This is the code sequence  that is probably causing this problem:

a) new app is getting exec'd and it is somewhere in between
   start_thread() and flush_old_exec() in the load_xyz_binary()

b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
   cleared.

c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
   routines in the network stack. This generates a math fault (as
   cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
   in the task's xstate.

d) Return to exec code path, which does start_thread() which does
   free_thread_xstate() and sets xstate pointer to NULL while
   the TS_USEDFPU is still set.

e) At the next context switch from the new exec'd task to another task,
   we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
   This can cause an oops during unlazy_fpu() in __switch_to()

Now:

1) This should happen with or with out pre-emption. Viro also encountered
   similar problem with out CONFIG_PREEMPT.

2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
   kernel_fpu_begin() will manually do a clts() and won't run in to the
   situation of setting TS_USEDFPU in step "c" above.

3) This was working before the fpu changes, because its a spurious
   math fault  which doesn't corrupt any fpu/sse registers and the task's
   math state was always in an allocated state.

With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).

This is the failing scenario that existed even before the lazy fpu allocation
changes:

0. CPU's TS flag is set

1. kernel using FPU in some optimized copy  routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()

2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.

3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts

4. We complete the padlock routine

5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.

6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.

This causes the fpu leakage.

Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the  context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.
Reported-and-bisected-by: NWolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Later SEC revision requires the link table (used for scatter/gather)
to have an extra entry to account for the total length in descriptor [4],
which contains cipher Input and ICV.
This only applies to decrypt, not encrypt.
Without this change, on 837x, a gather return/length error results
when a decryption uses a link table to gather the fragments.
This is observed by doing a ping with size of 1447 or larger with AES,
or a ping with size 1455 or larger with 3des.

So, add check for SEC compatible "fsl,3.0" for using extra link table entry.
Signed-off-by: NLee Nipper <lee.nipper@freescale.com>
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Various cleanup the drivers/firmware/memmap (after review by AKPM):

    - fix kdoc to conform to the standard
    - move kdoc from header to implementation files
    - remove superfluous WARN_ON() after kmalloc()
    - WARN_ON(x); if (!x) -> if(!WARN_ON(x))
    - improve some comments
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

My Sun Netra T1 AC200 has one of these... bit harsh not letting me use it
and all :)

==========
alex@woodchuck:~$ lspci -nn
00:01.0 PCI bridge [0604]: Sun Microsystems Computer Corp. Simba Advanced PCI Bridge [108e:5000] (rev 13)
00:01.1 PCI bridge [0604]: Sun Microsystems Computer Corp. Simba Advanced PCI Bridge [108e:5000] (rev 13)
01:03.0 Non-VGA unclassified device [0000]: ALi Corporation M7101 Power Management Controller [PMU] [10b9:7101]
01:05.1 Ethernet controller [0200]: Sun Microsystems Computer Corp. RIO GEM [108e:1101] (rev 01)
01:05.3 USB Controller [0c03]: Sun Microsystems Computer Corp. RIO USB [108e:1103] (rev 01)
01:07.0 ISA bridge [0601]: ALi Corporation M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] [10b9:1533]
01:0c.0 Bridge [0680]: Sun Microsystems Computer Corp. RIO EBUS [108e:1100] (rev 01)
01:0c.1 Ethernet controller [0200]: Sun Microsystems Computer Corp. RIO GEM [108e:1101] (rev 01)
01:0c.3 USB Controller [0c03]: Sun Microsystems Computer Corp. RIO USB [108e:1103] (rev 01)
01:0d.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev c3)
02:08.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic 53C896/897 [1000:000b] (rev 07)
02:08.1 SCSI storage controller [0100]: LSI Logic / Symbios Logic 53C896/897 [1000:000b] (rev 07)
==========
Signed-off-by: NAlexander Clouter <alex@digriz.org.uk>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Adjust and honor the vc_scrl_erase_char for 256 and 512 character fonts.

It fixes the issue with disappearing cursor during scrolling
(http://bugzilla.kernel.org/show_bug.cgi?id=11258).  The issue was
reported and tracked by Peter Hanzel.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Reported-by: NPeter Hanzel <hanzelpeter@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Specify how much physically continuous, DMA capable memory will be
allocated at driver initialization time.  This allow to create framebuffer
device with larger virtual resolution.  Combine with y-panning this can be
used to implement double buffering acceleration method.
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Panning in the y-direction can be done by simply changing the DMA base
address.  This code is already in place, but FBIOPAN_DISPLAY will
currently fail because ypanstep is 0.

Set ypanstep to 1 to indicate that we do support y-panning and also set
the necessary acceleration flags on AT91 (AVR32 already have them.)
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The legacy i2c model is going away soon, so switch to the new model.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Clean up the use of structure templates in i2c-matroxfb. In this case
it's more efficient to initialize the few fields we need individually.
This makes i2c-matroxfb.ko 16% smaller on my system.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I broke an error path with d03c21ec,
sorry about that.

The machine will crash if the i2c_attach_client() or maven_init_client()
calls fail, although nobody has yet reported this happening.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix preprocessor symbol so that sparse sees it and does not generate
errors:

  drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
  drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
  drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
  drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
  drivers/misc/sgi-gru/grutlbpurge.c:185:11: error: undefined identifier 'GRUREGION'
  drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
  drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Jack Steiner <steiner@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some chips appear to have the 2D engine hang during screen redraw,
typically in a sequence of copyarea operations. This appear to be
solved by adding a flush of the engine destination pixel cache
and waiting for the engine to be idle before issuing the accel
operation. The performance impact seems to be fairly small.

Here is a trace on an RV370 (PCI device ID 0x5b64), it records the
RBBM_STATUS register, then the source x/y, destination x/y, and
width/height used for the copy:

----------------------------------------
radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]
radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]
radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]
radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]
radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]
radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]
radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]
radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]
radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]
radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]
radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]
----------------------------------------

When things are going fine the copies complete before the next ROP is
even issued, but all of a sudden the 2D unit becomes active (bit 17 in
RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit
14) are set as well.  The FIFO begins to backup until it becomes full.

What happens next is the radeon_fifo_wait() times out, and we access
the chip illegally leading to a bus error which usually wedges the
box.  None of this makes it to the console screen, of course :-)
radeon_fifo_wait() should be modified to reset the accelerator when
this timeout happens instead of programming the chip anyways.

----------------------------------------
radeonfb: FIFO Timeout !
ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)
ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]
ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248>
ERROR(0): M_SYND(0),  E_SYND(0), Privileged
ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus"
ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\

ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
ERROR(0): E-cache idx[800e40] tag[000000000e049f4c]
ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]
Ker:xnel panic - not syncing: Irrecoverable deferred error trap.
----------------------------------------

Another quirk is that these copyarea calls will not happen until the
first drivers/char/vt.c:redraw_screen() occurs.  This will only happen
if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen.

This seems to happen because until a redraw_screen() the screen scrolling
method used by fbcon is not finalized yet.  I've seen this with other fb
drivers too.

So if all you do is boot straight into X you will never see this bug on
the relevant chips.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NParag Warudkar <parag.warudkar@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

These attributes are really sysdev class attributes.  The incorrect
definition leads to an oops because of recent changes which make sysdev
attributes use a different prototype.

Based on Andi's f718cd4a ("sched: make
scheduler sysfs attributes sysdev class devices")
Reported-by: NEric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Cc: "Li, Shaohua" <shaohua.li@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>