MIPS: Remove file missed when removing rm9k support a while ago.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
drm/i915: Add parsing support for new MIPI blocks in VBT

The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.

v2: Address review comments by Jani
    - adjust code for the structure changes for bdb_mipi_config
    - add boundry and buffer overflow checks as suggested
    - use kmemdup instead of kmalloc and memcpy

v3: More strict check while parsing VBT
    - Ensure that at anytime we do not go beyond sequence block
      while parsing
    - On unknown element fail the whole parsing

v4: Style changes and spell check mostly as suggested by Jani

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
xfs: kill buffers over failed write ranges properly

When a write fails, if we don't clear the delalloc flags from the
buffers over the failed range, they can persist beyond EOF and cause
problems. writeback will see the pages in the page cache, see they
are dirty and continually retry the write, assuming that the page
beyond EOF is just racing with a truncate. The page will eventually
be released due to some other operation (e.g. direct IO), and it
will not pass through invalidation because it is dirty. Hence it
will be released with buffer_delay set on it, and trigger warnings
in xfs_vm_releasepage() and assert fail in xfs_file_aio_write_direct
because invalidation failed and we didn't write the corect amount.

This causes failures on block size < page size filesystems in fsx
and fsstress workloads run by xfstests.

Fix it by completely trashing any state on the buffer that could be
used to imply that it contains valid data when the delalloc range
over the buffer is punched out during the failed write handling.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs: write failure beyond EOF truncates too much data

If we fail a write beyond EOF and have to handle it in
xfs_vm_write_begin(), we truncate the inode back to the current inode
size. This doesn't take into account the fact that we may have
already made successful writes to the same page (in the case of block
size < page size) and hence we can truncate the page cache away from
blocks with valid data in them. If these blocks are delayed
allocation blocks, we now have a mismatch between the page cache and
the extent tree, and this will trigger - at minimum - a delayed
block count mismatch assert when the inode is evicted from the cache.
We can also trip over it when block mapping for direct IO - this is
the most common symptom seen from fsx and fsstress when run from
xfstests.

Fix it by only truncating away the exact range we are updating state
for in this write_begin call.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs: xfs_vm_write_end truncates too much on failure

Similar to the write_begin problem, xfs-vm_write_end will truncate
back to the old EOF, potentially removing page cache from over the
top of delalloc blocks with valid data in them. Fix this by
truncating back to just the start of the failed write.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs: zeroing space needs to punch delalloc blocks

When we are zeroing space andit is covered by a delalloc range, we
need to punch the delalloc range out before we truncate the page
cache. Failing to do so leaves and inconsistency between the page
cache and the extent tree, which we later trip over when doing
direct IO over the same range.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
gpio: set data first, then chip and handler

During irq mapping, in irq_set_chip_and_handler() the process
of setting this up may incur calls to lock the irqchip, which
in turn may need to dereference and use the chip data. So set
the data first, then set the chip and handler.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio / ACPI: Don't crash on NULL chip->dev

Commit aa92b6f689ac (gpio / ACPI: Allocate ACPI specific data directly in
acpi_gpiochip_add()) moved ACPI handle checking to acpi_gpiochip_add() but
forgot to check whether chip->dev is NULL before dereferencing it.

Since chip->dev pointer is optional we can end up with crash like following:

 BUG: unable to handle kernel NULL pointer dereference at 00000138
 IP: [<c126c2b3>] acpi_gpiochip_add+0x13/0x190
 *pde = 00000000
 Oops: 0000 [#1] PREEMPT SMP
 Modules linked in: ssb(+) ...
 CPU: 0 PID: 512 Comm: modprobe Tainted: G        W     3.14.0-rc7-next-20140324-t1 #24
 Hardware name: Dell Inc. Latitude D830                   /0UY141, BIOS A02 06/07/2007
 task: f5799900 ti: f543e000 task.ti: f543e000
 EIP: 0060:[<c126c2b3>] EFLAGS: 00010282 CPU: 0
 EIP is at acpi_gpiochip_add+0x13/0x190
 EAX: 00000000 EBX: f57824c4 ECX: 00000000 EDX: 00000000
 ESI: f57824c4 EDI: 00000010 EBP: f543fc54 ESP: f543fc40
  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 CR0: 8005003b CR2: 00000138 CR3: 355f8000 CR4: 000007d0
 Stack:
  f543fc5c fd1f7790 f57824c4 000000be 00000010 f543fc84 c1269f4e f543fc74
  fd1f78bd 00008002 f57822b0 f5782090 fd1f8400 00000286 fd1f9994 00000000
  f5782000 f543fc8c fd1f7e39 f543fcc8 fd1f0bd8 000000c0 00000000 00000000
 Call Trace:
  [<fd1f7790>] ? ssb_pcie_mdio_write+0xa0/0xd0 [ssb]
  [<c1269f4e>] gpiochip_add+0xee/0x300
  [<fd1f78bd>] ? ssb_pcicore_serdes_workaround+0xfd/0x140 [ssb]
  [<fd1f7e39>] ssb_gpio_init+0x89/0xa0 [ssb]
  [<fd1f0bd8>] ssb_attach_queued_buses+0xc8/0x2d0 [ssb]
  [<fd1f0f65>] ssb_bus_register+0x185/0x1f0 [ssb]
  [<fd1f3120>] ? ssb_pci_xtal+0x220/0x220 [ssb]
  [<fd1f106c>] ssb_bus_pcibus_register+0x2c/0x80 [ssb]
  [<fd1f40dc>] ssb_pcihost_probe+0x9c/0x110 [ssb]
  [<c1276c8f>] pci_device_probe+0x6f/0xc0
  [<c11bdb55>] ? sysfs_create_link+0x25/0x40
  [<c131d8b9>] driver_probe_device+0x79/0x360
  [<c1276512>] ? pci_match_device+0xb2/0xc0
  [<c131dc51>] __driver_attach+0x71/0x80
  [<c131dbe0>] ? __device_attach+0x40/0x40
  [<c131bd87>] bus_for_each_dev+0x47/0x80
  [<c131d3ae>] driver_attach+0x1e/0x20
  [<c131dbe0>] ? __device_attach+0x40/0x40
  [<c131d007>] bus_add_driver+0x157/0x230
  [<c131e219>] driver_register+0x59/0xe0
  ...

Fix this by checking chip->dev pointer against NULL first. Also we can now
remove redundant check in acpi_gpiochip_request/free_interrupts().

Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio / ACPI: Prevent potential wrap of GPIO value on OpRegion read

Dan Carpenter's static code checker reports:

 The patch 473ed7be0da0: "gpio / ACPI: Add support for ACPI GPIO
 operation regions" from Mar 14, 2014, leads to the following static
 checker warning:

  drivers/gpio/gpiolib-acpi.c:454 acpi_gpio_adr_space_handler()
  warn: should 'gpiod_get_raw_value(desc) << i' be a 64 bit type?

This is due the fact that *value is of type u64 and gpiod_get_raw_value()
returns int. Since i can be larger than 31, it is possible that the value
returned gets wrapped.

Fix this by casting the return of gpiod_get_raw_value() to u64 first before
shift.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: set data first, then chip and handler

During irq mapping, in irq_set_chip_and_handler() the process
of setting this up may incur calls to lock the irqchip, which
in turn may need to dereference and use the chip data. So set
the data first, then set the chip and handler.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: support threaded interrupts in irqchip helpers

Some off-chip GPIO expanders need to be communicated by I2C or
SPI traffic, but may still support IRQs. By the sleeping nature
of such buses, such IRQ handlers need to be threaded. Support
such handlers in the gpiochip irqchip helpers by flagging IRQs
as threaded if the .can_sleep property of the gpiochip is
true.

Helpfully deny registration of chained IRQ handlers if the
.can_sleep property is set, as such chips will invariably need
a nested handler rather than a chained handler.

Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: tc3589x: use managed resources

Grab state container and irq using the devm_* functions and save
some lines of hairy clean-up code.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: tc3589x: get rid of static IRQ base

The static IRQ base is not used on any platforms with this chip
(only Ux500). Get rid of it forever, and rely on dynamic IRQ
descriptor allocation.

Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: tc3589x: use gpiolib irqchip helpers

Now that the gpiolib irqchip helpers can support nested, threaded
IRQ handlers, switch the TC3589x driver over to using this new
infrastructure. Tested on the Ux500.

Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: document gpio irqchips a bit more, describe helpers

This adds some documentation about the GPIO irqchips, what types
exist etc.

Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: timberdale: simplify dependencies

GPIO_TIMBERDALE doesn't need an explicit dependency on HAS_IOMEM,
because it depends on MFD_TIMBERDALE which itself depends on
HAS_IOMEM already.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: omap: convert to use irq_domain_add_simple()

The GPIO OMAP driver supports different OMAP SoC families and
not all of them have the needed support to use the linear IRQ
domain mapping like OMAP1 that use the legacy domain mapping.

But this special check is not necessary since the simple IRQ
domain mapping is able to handle both cases. Having a zero
IRQ offset will be interpreted as a linear domain case while
a non-zero value will be interpreted as a legacy domain case.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: omap: check gpiochip_add() return value

The gpiochip_add() function can fail if the chip cannot
be registered so the return value has to be checked and
the error propagated in case it happens.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP

The ARCH_OMAP config option was used to built the GPIO OMAP
driver but this is not consistent with the rest of the GPIO
drivers that have their own Kconfig option.

Also, this make it harder to add dependencies or reverse
dependencies (i.e: select) since that would mean touching the
sub-arch config option.

So is better to add a boolean Kconfig option for this driver
that defaults to true if ARCH_OMAP is enabled.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: omap: convert driver to use gpiolib irqchip

Converts the GPIO OMAP driver to register its chained irq
handler and irqchip using the helpers in the gpiolib core.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>