Use the combined irq_set_chip_and_handler() function
instead. Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

irq_desc checking in the interrupt demux routine is totally
pointless. The driver sets those lines up, so that cant go away
magically.

Remove the open coded handler magic and use the proper accessor.

This driver needs to be converted to threaded interrupts and buslock.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

irq_desc checking in a function which is called with that irq
descriptor locked, is pointless. Equally pointless as the irq desc
check in the interrupt service routine. The driver sets those lines
up, so that cant go away magically.

Remove the open coded handler magic and use the proper accessor.

No need to fiddle with irq_desc in the type setting function. The
original value is in irq_data and the core code stores the new setting
when the return value is 0.

This driver needs to be converted to threaded interrupts and buslock.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Remove unused code.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Remove the pointless irq_desc check in set_type. This function is
called with that irq descriptor locked. Also remove the write back of
the flow type as the core code does this already when the return value
is 0.

Also store the flow type in the chip data structure, so there is no
need to fiddle in the irq descriptor.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Replace the open coded handler call with the prober accessor. Retrieve
the handler data from desc. That avoids a redundant lookup in the
sparse irq case.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

There is no point in checking irq_desc here, as it _is_ available. The
driver configured those lines, so they cannot go away.

The home brewn disabled/note_interrupt magic can be removed as well by
adding a irq_disable callback which avoids the lazy disable.

That driver needs to be converted to threaded interrupts.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Remove the open coded access to irq_desc and use the proper wrappers.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The TPS61050/61052 driver uses MFD core code, yet does not specify the
dependency in Kconfig. If it is the only MFD driver configured, compilation
fails with

ERROR: "mfd_add_devices" [drivers/mfd/tps6105x.ko] undefined!
ERROR: "mfd_remove_devices" [drivers/mfd/tps6105x.ko] undefined!

Fix the problem by adding "select MFD_CORE" to the respective Kconfig entry.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The device table is required to load modules based on modaliases.
After adding MODULE_DEVICE_TABLE, below entry will be added to modules.pcimap:
rdc321x-southbridge  0x000017f3 0x00006030 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This patch enables IRQ handling for MAX8997/8966 chips.

Please note that Fuel-Gauge-related IRQs are not implemented in this
initial release. The fuel gauge module in MAX8997 is identical to
MAX17042, which is already in Linux kernel. In order to use the
already-existing MAX17042 driver for fuel gauge module in MAX8997, the
main interrupt handler of MAX8997 should relay related interrupts to
MAX17042 driver. However, in order to do this, we need to modify
MAX17042 driver as well because MAX17042 driver does not have any
interrupt handlers for now. We are not going to implement this in this
initial release as it is not crucial in basic operations of MAX8997.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NHarald Welte <laforge@gnumonks.org>
Cc: Matti Aaltonen <matti.j.aaltonen@nokia.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The cs5535-pms cell doesn't actually need to be cloned, so we can drop that
and simply have the olpc-xo1.c driver use "cs5535-pms" directly.

Also, rename the cs5535-acpi clones to what we actually use for the (currently
out-of-tree) SCI driver.  In the process, that fixes a subtle bug in
olpc-xo1.c which broke powerdown on XO-1s.. olpc-xo1-ac-acpi was a typo, not
something that actually existed.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Replace mfd_shared_platform_driver_register with mfd_clone_cell.  The
former was called by an mfd client, and registered both a platform driver
and device.  The latter is called by an mfd driver, and registers only a
platform device.

The downside of this is that mfd drivers need to be modified whenever
new clients are added that share a cell; the upside is that it fits
Linux's driver model better.  It's also simpler.

This also converts cs5535-mfd/olpc-xo1 from the old API.  cs5535-mfd
now creates the olpc-xo1-{acpi,pms} devices, while olpc-xo1 binds to
them via platform drivers.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Acked-by: NAlex Dubov <oakad@yahoo.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is an off by one because strlen() doesn't count the null
terminator.  We strcpy() these strings into an array of size
MAX_CONFIG_LEN.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

Fix the following compile failure:

  drivers/media/rc/ite-cir.c: In function 'ite_decode_bytes':
  drivers/media/rc/ite-cir.c:190: error: implicit declaration of function 'generic_find_next_le_bit'
  drivers/media/rc/ite-cir.c:199: error: implicit declaration of function 'generic_find_next_zero_le_bit'

Caused by commit 620a32bb ("[media] rc: New rc-based ite-cir driver
for several ITE CIRs") interacting with commit c4945b9e
("asm-generic: rename generic little-endian bitops functions").
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit ddd588b5 ("oom: suppress nodes that are not allowed from
meminfo on oom kill") moved lib/show_mem.o out of lib/lib.a, which
resulted in build warnings on all architectures that implement their own
versions of show_mem():

	lib/lib.a(show_mem.o): In function `show_mem':
	show_mem.c:(.text+0x1f4): multiple definition of `show_mem'
	arch/sparc/mm/built-in.o:(.text+0xd70): first defined here

The fix is to remove __show_mem() and add its argument to show_mem() in
all implementations to prevent this breakage.

Architectures that implement their own show_mem() actually don't do
anything with the argument yet, but they could be made to filter nodes
that aren't allowed in the current context in the future just like the
generic implementation.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NJames Bottomley <James.Bottomley@hansenpartnership.com>
Suggested-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 1765a575 ("net: make dev->master general") introduced a
test of an uninitialized netdev.  Fix the code so the intended netdev
is tested.
Signed-off-by: NRoland Dreier <roland@purestorage.com>

Fix section mismatch warning by renaming the pci_driver variable to a
recognized (whitelisted) name.

WARNING: drivers/net/pch_gbe/pch_gbe.o(.data+0x1f8): Section mismatch in reference from the variable pch_gbe_pcidev to the variable .devinit.rodata:pch_gbe_pcidev_id
The variable pch_gbe_pcidev references
the variable __devinitconst pch_gbe_pcidev_id
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
LKML-Reference: <20110324212509.118888535@linutronix.de>

Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
LKML-Reference: <20110324212509.025730689@linutronix.de>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

gpiolib plus two gpio implementations in arm fiddle in the guts of
irq_desc in a racy and buggy way. Remove the stuff. I already told the
gpio folks that we can provide that information in a proper way if
necessary.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
LKML-Reference: <20110324212508.931638262@linutronix.de>

Avoiding abuse of ethtool_drvinfo.driver field.
HW specific info can be retrieved using lspci.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes a brown-paperbag bug which was introduced by me:
I used incorrect "GFP_KERNEL | GFP_NOFS" allocation flags to make
sure my allocations do not cause write-back. But the correct form
is "GFP_NOFS".
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Implement a merge function in the striped target.

When the striped target's underlying devices provide a merge_bvec_fn
(like all DM devices do via dm_merge_bvec) it is important to call down
to them when building a biovec that doesn't span a stripe boundary.

Without the merge method, a striped DM device stacked on DM devices
causes bios with a single page to be submitted which results
in unnecessary overhead that hurts performance.

This change really helps filesystems (e.g. XFS and now ext4) which take
care to assemble larger bios.  By implementing stripe_merge(), DM and the
stripe target no longer undermine the filesystem's work by only allowing
a single page per bio.  Buffered IO sees the biggest improvement
(particularly uncached reads, buffered writes to a lesser degree).  This
is especially so for more capable "enterprise" storage LUNs.

The performance improvement has been measured to be ~12-35% -- when a
reasonable chunk_size is used (e.g. 64K) in conjunction with a stripe
count that is a power of 2.

In contrast, the performance penalty is ~5-7% for the pathological worst
case stripe configuration (small chunk_size with a stripe count that is
not a power of 2).  The reason for this is that stripe_map_sector() is
now called once for every call to dm_merge_bvec().  stripe_map_sector()
will use slower division if stripe count isn't a power of 2.
Signed-off-by: NMustafa Mesanovic <mume@linux.vnet.ibm.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

This patch adjusts the multipath target to allow a table with both 0
priority groups and 0 for the initial priority group number.

If any mpath device is held open when all paths in the last priority
group have failed, userspace multipathd will attempt to reload the
associated DM table to reflect the fact that the device no longer has
any priority groups.  But the reload attempt always failed because the
multipath target did not allow 0 priority groups.

All multipath target messages related to priority group (enable_group,
disable_group, switch_group) will handle a priority group of 0 (will
cause error).

When reloading a multipath table with 0 priority groups, userspace
multipathd must be updated to specify an initial priority group number
of 0 (rather than 1).
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: Babu Moger <babu.moger@lsi.com>
Acked-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

Fail the reinstate_path and fail_path message ioctl if the specified
path is not valid.

The message ioctl would succeed for the 'reinistate_path' and
'fail_path' messages even if action was not taken because the
specified device was not a valid path of the multipath device.

Before, when /dev/vdb is not a path of mpathb:
$ dmsetup message mpathb 0 reinstate_path /dev/vdb
$ echo $?
0

After:
$ dmsetup message mpathb 0 reinstate_path /dev/vdb
device-mapper: message ioctl failed: Invalid argument
Command failed
$ echo $?
1
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

Add DM_SECURE_DATA_FLAG which userspace can use to ensure
that all buffers allocated for dm-ioctl are wiped
immediately after use.

The user buffer is wiped as well (we do not want to keep
and return sensitive data back to userspace if the flag is set).

Wiping is useful for cryptsetup to ensure that the key
is present in memory only in defined places and only
for the time needed.

(For crypt, key can be present in table during load or table
status, wait and message commands).
Signed-off-by: NMilan Broz <mbroz@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

Prepare code for implementing buffer wipe flag.
No functional change in this patch.
Signed-off-by: NMilan Broz <mbroz@redhat.com>
Acked-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

Always wipe the original copy of the key after processing it
in crypt_set_key().
Signed-off-by: NMilan Broz <mbroz@redhat.com>
Acked-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

This target is the same as the linear target except that it returns I/O
errors periodically.  It's been found useful in simulating failing
devices for testing purposes.

I needed a dm target to do some failure testing on btrfs's raid code, and
Mike pointed me at this.
Signed-off-by: NJosef Bacik <josef@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

If a table is read-only, also open any log and cow devices it uses read-only.

Previously, even read-only devices were opened read-write internally.
After patch 75f1dc0d
  block: check bdev_read_only() from blkdev_get()
was applied, loading such tables began to fail.  The patch
was reverted by e51900f7
  block: revert block_dev read-only check
but this patch fixes this part of the code to work with the original patch.
Signed-off-by: NMilan Broz <mbroz@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>

This makes the interface a bit cleaner by leaving a single gap in the
vblank bit space instead of creating two gaps.

Suggestions from Michel on mailing list/irc.
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Throw an error if someone tries to fill this with
wrong data, instead of simply ignoring the input.
Now you get:

echo hello >/sys/../power_method
-bash: echo: write error: Invalid argument
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: Alexander.Deucher@amd.com
CC: dri-devel@lists.freedesktop.org
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On some servers there is a hardcoded EDID provided
in the vbios so that the driver will always see a
display connected even if something like a KVM
prevents traditional means like DDC or load
detection from working properly.  Also most
server boards with DVI are not actually DVI, but
DVO connected to a virtual KVM service processor.
If we fail to detect a monitor via DDC or load
detection and a hardcoded EDID is available, use
it.

Additionally, when using the hardcoded EDID, use
a copy of it rather than the actual one stored
in the driver as the detect() and get_modes()
functions may free it if DDC is successful.

This fixes the virtual KVM on several internal
servers.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit a7a75c8f.

There are two different variations on how Intel hardware addresses the
"Hardware Status Page". One as a location in physical memory and the
other as an offset into the virtual memory of the GPU, used in more
recent chipsets. (The HWS itself is a cacheable region of memory which
the GPU can write to without requiring CPU synchronisation, used for
updating various details of hardware state, such as the position of
the GPU head in the ringbuffer, the last breadcrumb seqno, etc).

These two types of addresses were updated in different locations of code
- one inline with the ringbuffer initialisation, and the other during
device initialisation. (The HWS page is logically associated with
the rings, and there is one HWS page per ring.) During resume, only the
ringbuffers were being re-initialised along with the virtual HWS page,
leaving the older physical address HWS untouched. This then caused a
hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
to synchronise the GPU as the breadcrumbs were never being updated.
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NJan Niehusmann <jan@gondor.com>
Reported-and-tested-by: NJustin P. Mattock <justinmattock@gmail.com>
Reported-and-tested-by: NMichael "brot" Groh <brot@minad.de>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Commit 0b950d3d (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using mutex_trylock() in tsc2005_esd_work(). If the
mutex is taken, we know we are in the middle of disable or enable and
the watchdog check can be skipped.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>