* Rename shpchp_wq to shpchp_ordered_wq and add non-ordered shpchp_wq
  which is used instead of the system workqueue.  This is to remove
  the use of flush_scheduled_work() which is deprecated and scheduled
  for removal.

* With cmwq in place, there's no point in creating workqueues lazily.
  Create both shpchp_wq and shpchp_ordered_wq upfront.

* Include workqueue.h from shpchp.h.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

* Rename pciehp_wq to pciehp_ordered_wq and add non-ordered pciehp_wq
  which is used instead of the system workqueue.  This is to remove
  the use of flush_scheduled_work() which is deprecated and scheduled
  for removal.

* With cmwq in place, there's no point in creating workqueues lazily.
  Create both pciehp_wq and pciehp_ordered_wq upfront.

* Include workqueue.h from pciehp.h.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

diva doesn't use workqueue and there is no reason to flush the system
workqueue from diva_os_remove_soft_isr().  Remove it.

This is to prepare for the deprecation and removal of
flush_scheduled_work().
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NArmin Schindler <armin@melware.de>

Add WQ_MEM_RECLAIM flag which currently maps to WQ_RESCUER, mark
WQ_RESCUER as internal and replace all external WQ_RESCUER usages to
WQ_MEM_RECLAIM.

This makes the API users express the intent of the workqueue instead
of indicating the internal mechanism used to guarantee forward
progress.  This is also to make it cleaner to add more semantics to
WQ_MEM_RECLAIM.  For example, if deemed necessary, memory reclaim
workqueues can be made highpri.

This patch doesn't introduce any functional change.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>

update_interval is the matching attribute defined in the hwmon sysfs ABI.
Use it.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The attribute reflects an interval, not a rate.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Acked-by: NIra W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

According to the datasheet for Winbond W83627DHG the proper way to exit
the Extended Function Mode is to write 0xaa to the EFER(0x2e or 0x4e).
Signed-off-by: NJonas Jonsson <jonas@ludd.ltu.se>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

It is unnecessary and wrong to call hwmon_device_unregister in error
handling before hwmon_device_register is called.
Signed-off-by: NYong Wang <yong.y.wang@intel.com>
Reviewed-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: stable@kernel.org
Signed-off-by: NJean Delvare <khali@linux-fr.org>

All bits in the values read from registers to be used for the next
write were getting overwritten, avoid doing so to not mess with the
current configuration.
Signed-off-by: NGuillem Jover <guillem@hadrons.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: stable@kernel.org
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The spec notes that fan0 and fan1 control mode bits are located in bits
7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the
bits shift by 5 instead of by 4.
Signed-off-by: NGuillem Jover <guillem@hadrons.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: stable@kernel.org
Signed-off-by: NJean Delvare <khali@linux-fr.org>

If CONFIG_PM was selected and lis3lv02d_platform_data was NULL,
the kernel will be panic when halt command run.
Reported-by: NYusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Sigend-off-by: NJean Delvare <khali@linux-fr.org>

If an array with 1.x metadata is assembled with the last disk missing,
md doesn't properly record the fact that the disk was missing.

This is unlikely to cause a real problem as the event count will be
different to the count on the missing disk so it won't be included in
the array.  However it could still cause confusion.

So make sure we clear all the relevant slots, not just the early ones.
Signed-off-by: NNeilBrown <neilb@suse.de>

Now that we depend on md_update_sb to clear variable bits in
mddev->flags (rather than trying not to set them) it is important to
always call md_update_sb when appropriate.

md_check_recovery has this job but explicitly avoids it for ->external
metadata arrays.  This is not longer appropraite, or needed.

However we do want to avoid taking the mddev lock if only
MD_CHANGE_PENDING is set as that is not cleared by md_update_sb for
external-metadata arrays.
Reported-by: N"Kwolek, Adam" <adam.kwolek@intel.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

drivers/firewire/nosy* is a stand-alone driver that does not depend on
CONFIG_FIREWIRE.  Hence let make descend into drivers/firewire/ also
if that option is off.

The stand-alone driver drivers/ieee1394/init_ohci1394_dma*  will soon be
moved into drivers/firewire/ too and will require the same makefile fix.

Side effect:
As mentioned in https://bugzilla.novell.com/show_bug.cgi?id=586172#c24
this influences the order in which either firewire-ohci or ohci1394 is
going to be bound to an OHCI-1394 controller in case of a modular build
of both drivers if no modprobe blacklist entries are configured.
However, a user of such a setup cannot expect deterministic behavior
anyway.  The Kconfig help and the migration guide at
ieee1394.wiki.kernel.org recommend blacklist entries when a dual
IEEE 1394 stack build is being used.  (The coexistence period of the two
stacks is planned to end soon.)

Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The VIAFB_GET_INFO device ioctl allows unprivileged users to read 246
bytes of uninitialized stack memory, because the "reserved" member of
the viafb_ioctl_info struct declared on the stack is not altered or
zeroed before being copied back to the user.  This patch takes care of
it.
Signed-off-by: NDan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The NXP LPC32XX processor use the same watchdog as the Philips
PNX4008 processor.
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Since it may be already enabled by bootloader or some other utility. This patch
makes sure that the watchdog is disabled before any userspace daemon opens the
device. It is also required by the watchdog API.
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

irq and reboot notifier are acquired in module_init() but never released.
They should be released correctly, otherwise reloading the module or error
during module_init() will cause a problem.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: Andrew Sharp <andy.sharp@lsi.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Some pcnet_cs compatible cards require an exact 16-lines match
of the ioport areas specified in CIS, but set the "iolines"
value in the CIS incorrectly. We can easily work around this
issue -- same as we do in serial_cs -- by first trying setting
iolines to the CIS-specified value, and then trying a 16-line
match.
Reported-and-tested-by: NWolfram Sang <w.sang@pengutronix.de>
Hardware-supplied-by: NJochen Frieling <j.frieling@pengutronix.de>
CC: netdev@vger.kernel.org
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

As the iomem / ioport setup differs per device, it is much better
to print out the device instead of the socket.
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

We shouldn't overwrite pre-set values, and we should also
set the port address to the beginning, and not the end of
the 8-port range.

CC: linux-serial@vger.kernel.org
Reported-by: NKomuro <komurojun-mbn@nifty.com>
Hardware-supplied-by: NJochen Frieling <j.frieling@pengutronix.de>
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

The texture base address registers are in units of 256 bytes.
The original CS checker treated these offsets as bytes, so the
original check was wrong.  I fixed the units in a patch during
the 2.6.36 cycle, but this ended up breaking some existing
userspace (probably due to a bug in either userspace texture allocation
or the drm texture mipmap checker).  So for now, until we come
up with a better fix, just warn if the mipmap size it too large.
This will keep existing userspace working and it should be just
as safe as before when we were checking the wrong units.  These
are GPU MC addresses, so if they fall outside of the VRAM or
GART apertures, they end up at the GPU default page, so this should
be safe from a security perspective.

v2: Just disable the warning.  It just spams the log and there's
nothing the user can do about it.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <glisse@freedesktop.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There has been periodic evidence that LVDS, on at least some
panels, prefers the dividers selected by the legacy pll algo.
This patch forces the use of the legacy pll algo on RV620
LVDS panels.  The old behavior (new pll algo) can be selected
by setting the new_pll module parameter to 1.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30029Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not 100% sure this is due to BKL removal, its most likely a combination
of that + userspace timing changes in udev/plymouth. The drm adds the sysfs
device before the driver has completed internal loading, this causes udev
to make the node and plymouth to open it before we've completed loading.

The proper solution is to delay the sysfs manipulation until later in loading
however this causes knock on issues with sysfs connector nodes, so we can use
the global mutex to serialise loading and userspace opens.

Reported-by: Toni Spets (hifi on #radeon)
Signed-off-by: NDave Airlie <airlied@redhat.com>

v2: Julien Cristau pointed out that @nondestructive results in
double-negatives and confusion when trying to interpret the parameter,
so use @force instead. Much easier to type as well. ;-)

And fix the miscompilation of vmgfx reported by Sedat Dilek.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

My macbook infrared remote control was broken by commit
bd25f4dd ("HID: hiddev: use
usb_find_interface, get rid of BKL").

This device appears in dmesg as:
apple 0003:05AC:8242.0001: hiddev0,hidraw0: USB HID v1.11 Device
[Apple Computer, Inc. IR Receiver] on usb-0000:00:1d.2-1/input0

It stopped working as lircd was getting ENODEV when opening /dev/usb/hiddev0.

AFAICS hiddev_driver is a dummy driver so usb_find_interface(&hiddev_driver)
does not find anything.

The device is associated with the usbhid driver, so let's do
usb_find_interface(&hid_driver) instead.

$ ls -l /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver
lrwxrwxrwx 1 root root 0 2010-09-12 16:28 /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver -> ../../../../../../bus/usb/drivers/usbhid
Signed-off-by: NGuillaume Chazarain <guichaz@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This commit fixes bogus CS rejection if it contains a sequence
of the following operations:

- Set the color buffer 0. track->cb[i].robj becomes non-NULL.
- Render.
- Set a larger zbuffer than the previously-set color buffer.
- Set a larger scissor area as well.
- Set the color channel mask to 0 to do depth-only rendering.
- Render. --> rejected, because track->cb[i].robj remained non-NULL,
  therefore the conditional checking for the color channel mask and
  friends is not performed, and the larger scissor area causes
  the rejection.

This fixes bugs:
- https://bugs.freedesktop.org/show_bug.cgi?id=29762
- https://bugs.freedesktop.org/show_bug.cgi?id=28869
And maybe some others which seem to look the same.

If possible, this commit should go to stable as well.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

One subtest of mesa/demos/gltestperf takes 9 seconds to complete,
so to prevent an unnecessary gpu reset followed by a hardlock, I am
increasing the interval to 10 seconds after which a GPU is considered
in a locked-up state. This is on RV530. However, with a little slower GPU,
we would surpass the interval easily, so this is not a good fix
for gltestperf.

Nevertheless, this commit also fixes hardlocks in the applications which
render at speed of less than 1 frame per second, where the whole frame
consists of only one command stream. The game Tiny & Big is an example.
This bar is now lowered to 0.1 fps.

Now the question comes down to whether we should (often unsuccessfully)
reset the GPU at all? Once we have stable enough drivers, we won't have to.
Has the time come already?

If possible, this commit should go to stable as well.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch fixes rendering errors on some evergreen boards.
Hardcoding the backend map is not an optimal solution, but
a better fix is being worked on.

Similar to the fix for rv740
(6271901d).

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=29986Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Destructive load-detection is very expensive and due to failings
elsewhere can trigger system wide stalls of up to 600ms. A simple
first step to correcting this is not to invoke such an expensive
and destructive load-detection operation automatically.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29536
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16265Reported-by: NBruno Prémont <bonbons@linux-vserver.org>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Noticed while adding evergreen blit support.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Otherwise when disabling the output we switch to the new fb (which is
likely NULL) and skip the call to mode_set -- leaking driver private
state on the old_fb.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

They aren't compatible.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28671Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

caused by d65d65b1

need to update the radeon crtc priv native mode before using it.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30049

v2: integrate v/h copy paste typo
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I broke out my trusty i845 and found a new boot failure, which upon
inspection turned out to be a recursion within:

drm_helper_probe_single_connector_modes() -> drm_helper_hpd_irq_event()
-> intel_crt_detect() -> drm_helper_probe_single_connector_modes()

Calling drm_kms_helper_poll_enable() instead performs the desired
re-initialisation of the polling should the user have toggled the
parameter, without the recursive side-effect.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMark F. Brown <mark.brown314@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch initializes the pages per block field in CONFIG1 for
v2 controllers. It also sets the FP_INT field. This is the last
field not correctly initialized, so we can switch from
read/modify/write the CONFIG1 reg to just write the correct
value.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NJohn Ogness <john.ogness@linutronix.de>
Tested-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When DMA error occurs. it's loop hang since it can't exit the loop.
and it's the right DMA handling code as Spec.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Wrong assumption bufferram can be switched between BufferRAM0 and BufferRAM1
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>