be2net gets an async link status notification from the FW when it creates
an MCC queue. There are some cases in which this gratuitous notification
is not received from FW. To cover this explicitly query the link status
in be_open().
Signed-off-by: NVasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NAjit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAjit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

1) fix be_vlan_add/rem_vid to return proper status
2) perform appropriate housekeeping if firmware command succeeds.
Signed-off-by: NAjit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The new iso bandwidth calculation code accidentally has broken support
for bulk mode cameras. This has broken the following drivers:
finepix, jeilinj, ovfx2, ov534, ov534_9, se401, sq905, sq905c, sq930x,
stv0680, vicam.

Thix patch fixes this. Fix tested with: se401, sq905, sq905c, stv0680 & vicam
cams.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Michael S. Tsirkin also noticed that we could run the refill work
multiple CPUs: if we kick off a refill on one CPU and then on another,
they would both manipulate the queue at the same time (they use
napi_disable to avoid racing against the receive handler itself).

Tejun points out that this is what the WQ_NON_REENTRANT flag is for,
and that there is a convenient system kthread we can use.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Michael S. Tsirkin noticed that we could run the refill work after
ndo_close, which can re-enable napi - we don't disable it until
virtnet_remove.  This is clearly wrong, so move the workqueue control
to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close).

One subtle point: virtnet_probe() could simply fail if it couldn't
allocate a receive buffer, but that's less polite in virtnet_open() so
we schedule a refill as we do in the normal receive path if we run out
of memory.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

At the moment VFs can only operate in Eth mode.
In addition we don't want the VF to attempt link sensing,
so we block this option as well.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On extensive NFS boots on a mx6qsabrelite board it was noted that "FEC: MDIO read timeout" were occuring,
which caused failure on loading the FEC driver.

The original FEC_MII_TIMEOUT was set to 1 ms, which is too low when passed to the usecs_to_jiffies macro.

On ARM one jiffy is 10ms, so use a timeout of 30ms, which corresponds to 3 jiffies.

After running extensive NFS boots, the MDIO timeouts do not occur anymore with this change.
Signed-off-by: NRogerio Pimentel <rogerio.pimentel@freescale.com>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

SGI IP32 (O2)'s ethernet driver (meth) lacks a set_rx_mode function, which
prevents IPv6 from working completely because any ICMPv6 neighbor
solicitation requests aren't picked up by the driver.  So the machine can
ping out and connect to other systems, but other systems will have a very
hard time connecting to the O2.
Signed-off-by: NJoshua Kinard <kumba@gentoo.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix allyesconfig build on architectures without IOMEM:

drivers/net/ethernet/calxeda/xgmac.c:1800:2:
  error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

RC6 fails again.

> I found my system freeze mostly during starting up X and KDE. Sometimes it
> works for some minutes, sometimes it freezes immediatly. When the freeze
> happens, everything is dead (even the reset button does not work, I need to
> power cycle).

> I disabled RC6, and my system runs wonderfully.

> The system is a Z68 Pro board with Sandybridge i5-2500K processor, 8
> GB of RAM and UEFI firmware.
Reported-by: NKai Krakow <hurikhan77@gmail.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Semaphores still cause problems on some machines:

> From Udo Steinberg:
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
>
>  I can reproduce it fairly easily with something
>  as simple as:
>
>	  while true; do dmesg; done

This patch turns them off on SNB while leaving them on for IVB.
Reported-by: NUdo Steinberg <udo@hypervisor.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Eugeni Dodonov <eugeni@dodonov.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Include linux/slab.h to fix below build error:

  CC      drivers/net/ethernet/mellanox/mlx4/resource_tracker.o
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_init_resource_tracker':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:233: error: implicit declaration of function 'kzalloc'
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:234: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_free_resource_tracker':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:264: error: implicit declaration of function 'kfree'
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_qp_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:370: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_mtt_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:386: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_mpt_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:402: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_eq_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:417: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_cq_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:431: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_srq_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:446: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'alloc_counter_tr':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:461: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'add_res_range':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:521: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mac_add_to_slave':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:1193: warning: assignment makes pointer from integer without a cast
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'add_mcg_res':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2521: warning: assignment makes pointer from integer without a cast
make[5]: *** [drivers/net/ethernet/mellanox/mlx4/resource_tracker.o] Error 1
make[4]: *** [drivers/net/ethernet/mellanox/mlx4] Error 2
make[3]: *** [drivers/net/ethernet/mellanox] Error 2
make[2]: *** [drivers/net/ethernet] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We recently made loopback a bool type instead of an int, so the bitwise
AND is redundent.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixed the asix_get_wol() routine reported wrong wol status issue.
Signed-off-by: NAllan Chou <allan@asix.com.tw>
Tested-by: NEugene &lt;elubarsky@gmail.com&gt;; Allan Chou <allan@asix.com.tw>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Change details:
	- Add debugfs support to obtain firmware trace, saved firmware trace on
	  an IOC crash, driver info and read/write to registers.

	- debugfs hierarchy:
	  bna/pci_dev:<pci_name>
	  where the pci_name corresponds to the one under /sys/bus/pci/drivers/bna

	- Following are the new debugfs entries added:
	  fwtrc: collect current firmware trace.
	  fwsave: collect last saved fw trace as a result of firmware crash.
	  regwr: write one word to chip register
	  regrd: read one or more words from chip register.
	  drvinfo: collect the driver information.
Signed-off-by: NKrishna Gudipati <kgudipat@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Change details:
	- The patch adds flash sub-module to the bna driver.
	- Added ethtool set_eeprom() and get_eeprom() entry points to
	  support flash partition read/write operations.
Signed-off-by: NKrishna Gudipati <kgudipat@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the following warning raised
when compile:

WARNING: modpost: missing MODULE_LICENSE()
in drivers/net/ethernet/stmicro/stmmac/stmmac.o
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit d0a4bb49 introduced a
regression which is annoying but fairly harmless.

When writing to an array that is undergoing recovery (a spare
in being integrated into the array), writing to the array will
set bits in the bitmap, but they will not be cleared when the
write completes.

For bits covering areas that have not been recovered yet this is not a
problem as the recovery will clear the bits.  However bits set in
already-recovered region will stay set and never be cleared.
This doesn't risk data integrity.  The only negatives are:
 - next time there is a crash, more resyncing than necessary will
   be done.
 - the bitmap doesn't look clean, which is confusing.

While an array is recovering we don't want to update the
'events_cleared' setting in the bitmap but we do still want to clear
bits that have very recently been set - providing they were written to
the recovering device.

So split those two needs - which previously both depended on 'success'
and always clear the bit of the write went to all devices.
Signed-off-by: NNeilBrown <neilb@suse.de>

Before performing a recovery we try to remove any spares that
might not be working, then add any that might have become relevant.

Currently we abort on the first spare that cannot be added.
This is a false optimisation.
It is conceivable that - depending on rules in the personality - a
subsequent spare might be accepted.
Also the loop does other things like count the available spares and
reset the 'recovery_offset' value.

If we abort early these might not happen properly.

So remove the early abort.

In particular if you have an array what is undergoing recovery and
which has extra spares, then the recovery may not restart after as
reboot as the could of 'spares' might end up as zero.
Reported-by: NAnssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: NNeilBrown <neilb@suse.de>

While reshaping a degraded array (as when reshaping a RAID0 by first
converting it to a degraded RAID4) we currently get confused about
which devices are in_sync.  In most cases we get it right, but in the
region that is being reshaped we need to treat non-failed devices as
in-sync when we have the data but haven't actually written it out yet.
Reported-by: NAdam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

commit d70ed2e4
broke hot-add to a linear array.
After that commit, metadata if not written to devices until they
have been fully integrated into the array as determined by
saved_raid_disk.  That patch arranged to clear that field after
a recovery completed.

However for linear arrays, there is no recovery - the integration is
instantaneous.  So we need to explicitly clear the saved_raid_disk
field.
Signed-off-by: NNeilBrown <neilb@suse.de>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Commit e133e737 didn't correctly fix the integer overflow issue.

-	unsigned int required_size;
+	u64 required_size;
	...
	required_size = mode_cmd->pitch * mode_cmd->height;
-	if (unlikely(required_size > dev_priv->vram_size)) {
+	if (unlikely(required_size > (u64) dev_priv->vram_size)) {

Note that both pitch and height are u32.  Their product is still u32 and
would overflow before being assigned to required_size.  A correct way is
to convert pitch and height to u64 before the multiplication.

	required_size = (u64)mode_cmd->pitch * (u64)mode_cmd->height;

This patch calls the existing vmw_kms_validate_mode_vram() for
validation.
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Reviewed-and-tested-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We already do this for cayman, need to also do it for
BTC parts.  The default memory and voltage setup is not
adequate for advanced operation.  Continuing will
result in an unusable display.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This commit:

commit 8f5d6215
Author: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Date:   Mon Oct 10 18:06:54 2011 +0200

    usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF .

    To be able to use the driver on other OF-aware architectures, too.
    And add necessary OF related #includes to fix compilation error.
Signed-off-by: NJoachim Foerster <joachim.foerster@missinglinkelectronics.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

enabled the build on all CONFIG_OF architectures, but it cannot do
this.

This driver depends upon CONFIG_OF_IRQ but not all CONFIG_OF platforms
support that infrastructure, in particular Sparc does not so the
build fails.

Please push a patch like the following to Linus so that this code only
gets built where it actually should.

--------------------
usb/isp1760: Add missing CONFIG_OF_IRQ dependency on OF code.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds the PCI support (as EXPERIMENTAL)
this has been also tested on XLINX XC2V3000 FF1152AMT0221
D1215994A VIRTEX FPGA board.
To support the PCI bus the main part has been reworked
and both the platform and the PCI specific parts have
been moved into different files.
Signed-off-by: NRayagond Kokatanur <rayagond@vayavyalabs.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix ll_temac and emaclite drivers. Only Microblaze and Xilinx PPC
use then and both use NO_IRQ as 0. It will be removed in near future.
Signed-off-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If recovery is triggered in presence of pending asynchronous
deliveries of storage blocks we do a forced cleanup after
the corresponding tasklets are completely stopped and trigger
appropriate notifications for the correspondingerror state.
Signed-off-by: NEinar Lueck <elelueck@de.ibm.com>
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In case there are no system resources to run a recovery we have to clear
recovery bitmasks so a further automatic or manual driven recovery can
fix up the device.
Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The NETIUCV device driver allows to connect a Linux guest on z/VM to
another z/VM guest based on the z/VM communication facility IUCV.
Multiple output paths to different guests are possible, as well as
multiple input paths from different guests.
With this feature, you can configure multiple point-to-point NETIUCV
interfaces between your Linux on System z instance and another z/VM
guest.
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A recovery does not make sense during shutdown and may even cause an
error like this:

qeth 0.0.f503: A recovery process has been started for the device
Badness at drivers/s390/cio/qdio_main.c:1156
Modules linked in: autofs4 sunrpc dm_multipath scsi_dh scsi_mod qeth_l3 ipv6 vmu
r qeth qdio ccwgroup ext3 jbd mbcache dasd_eckd_mod dasd_mod dm_mirror dm_region
_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
CPU: 3 Not tainted 2.6.32-202.el6.s390x #1
Process qeth_recover (pid: 1498, task: 000000003efe2040, ksp: 000000003d5e3b80)
Krnl PSW : 0404200180000000 000003c000be6da8 (qdio_int_handler+0x88/0x43c [qdio]
)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
Krnl GPRS: ffffffffffff3bac 0000000000000005 0000000000000000 fffffffffffffff4
           0000000000000000 000000000000000c 0000000000000000 000000003ca97000
           0000000000000380 fffffffffffffff4 000000003f22d800 000000003f22c478
           000003c000bdf000 000003c000bea270 000000003f447e10 000000003f447db0
Krnl Code: 000003c000be6d9a: c21f00000004       clfi    %r1,4
           000003c000be6da0: a7c40021           brc     12,3c000be6de2
           000003c000be6da4: a7f40001           brc     15,3c000be6da6
          >000003c000be6da8: e320a0080004       lg      %r2,8(%r10)
           000003c000be6dae: a7390003           lghi    %r3,3
           000003c000be6db2: a72b0178           aghi    %r2,376
           000003c000be6db6: a7490001           lghi    %r4,1
           000003c000be6dba: a7590000           lghi    %r5,0
Call Trace:
([<000000000080ee80>] __per_cpu_offset+0x0/0x200)
[<00000000003d90e8>] ccw_device_call_handler+0x70/0xcc
[<00000000003d83a2>] ccw_device_irq+0x82/0x180
[<00000000003cc6a8>] do_IRQ+0x16c/0x1ec
[<0000000000118abe>] io_return+0x0/0x8
[<000003c000d04c74>] qeth_determine_capabilities+0x208/0x5cc [qeth]
([<000003c000d04c4a>] qeth_determine_capabilities+0x1de/0x5cc [qeth])
[<000003c000d0a6e0>] qeth_core_hardsetup_card+0x160/0x1258 [qeth]
[<000003c000f49f56>] __qeth_l3_set_online+0x132/0xb14 [qeth_l3]
[<000003c000f4ac70>] qeth_l3_recover+0x168/0x224 [qeth_l3]
[<000000000016e210>] kthread+0xa4/0xac
[<0000000000109c6e>] kernel_thread_starter+0x6/0xc
[<0000000000109c68>] kernel_thread_starter+0x0/0xc

The patch forbids start of a recovery once qeth shutdown is running.
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

qeth layer3 recovery invokes its set_multicast_list function, which
invokes function __vlan_find_dev_deep requiring rcu_read_lock or
rtnl lock. This causes kernel messages:

kernel: [ INFO: suspicious rcu_dereference_check() usage. ]
kernel: ---------------------------------------------------
kernel: net/8021q/vlan_core.c:70 invoked rcu_dereference_check() without protection!

kernel: stack backtrace:
kernel: CPU: 0 Not tainted 3.1.0 #9
kernel: Process qeth_recover (pid: 2078, task: 000000007e584680, ksp: 000000007e3e3930)
kernel: 000000007e3e3d08 000000007e3e3c88 0000000000000002 0000000000000000
kernel:       000000007e3e3d28 000000007e3e3ca0 000000007e3e3ca0 00000000005e77ce
kernel:       0000000000000000 0000000000000001 ffffffffffffffff 0000000000000001
kernel:       000000000000000d 000000000000000c 000000007e3e3cf0 0000000000000000
kernel:       0000000000000000 0000000000100a18 000000007e3e3c88 000000007e3e3cc8
kernel: Call Trace:
kernel: ([<0000000000100926>] show_trace+0xee/0x144)
kernel: [<00000000005d395c>] __vlan_find_dev_deep+0xb0/0x108
kernel: [<00000000004acd3a>] qeth_l3_set_multicast_list+0x976/0xe38
kernel: [<00000000004ae0f4>] __qeth_l3_set_online+0x75c/0x1498
kernel: [<00000000004aefec>] qeth_l3_recover+0xc4/0x1d0
kernel: [<0000000000185372>] kthread+0xa6/0xb0
kernel: [<00000000005ed4c6>] kernel_thread_starter+0x6/0xc
kernel: [<00000000005ed4c0>] kernel_thread_starter+0x0/0xc

The patch makes sure the rtnl lock is held once qeth recovery invokes
its set_multicast_list function.
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It was reported that the macvtap device selects a
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When UDP RSS is enabled, we use same QPN for TCP and UDP ranges
The bug is that the default_qpn was used base UDP qpn before it
was set.
Fixes bug introduced in commit: 1202d460Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the BMC gets reset, it will return 0x80 response errors.

In less than a week
# grep "Error 80 on cmd 22" /var/log/kernel |wc -l
378681

In this case, it is probably a good idea to restore the IPMI settings.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NArkadiusz Miśkiewicz <a.miskiewicz@gmail.com>
Reported-by: NArkadiusz Miśkiewicz <a.miskiewicz@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Include linux/io.h to fix below build error:

  CC      drivers/mfd/jz4740-adc.o
drivers/mfd/jz4740-adc.c: In function 'jz4740_adc_irq_demux':
drivers/mfd/jz4740-adc.c:73: error: implicit declaration of function 'readb'
drivers/mfd/jz4740-adc.c: In function 'jz4740_adc_set_enabled':
drivers/mfd/jz4740-adc.c:110: error: implicit declaration of function 'writeb'
drivers/mfd/jz4740-adc.c: In function 'jz4740_adc_set_config':
drivers/mfd/jz4740-adc.c:146: error: implicit declaration of function 'readl'
drivers/mfd/jz4740-adc.c:151: error: implicit declaration of function 'writel'
drivers/mfd/jz4740-adc.c: In function 'jz4740_adc_probe':
drivers/mfd/jz4740-adc.c:249: error: implicit declaration of function 'ioremap_nocache'
drivers/mfd/jz4740-adc.c:249: warning: assignment makes pointer from integer without a cast
drivers/mfd/jz4740-adc.c:289: warning: passing argument 3 of 'mfd_add_devices' discards qualifiers from pointer target type
include/linux/mfd/core.h:93: note: expected 'struct mfd_cell *' but argument is of type 'const struct mfd_cell *'
drivers/mfd/jz4740-adc.c:299: error: implicit declaration of function 'iounmap'
make[2]: *** [drivers/mfd/jz4740-adc.o] Error 1
make[1]: *** [drivers/mfd] Error 2
make: *** [drivers] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

irq_set_chained_handler sets 'desc->handle_irq'.
However this irq is called by handle_nested_irq from handle_twl4030_pih,
and that uses action->thread_fn.

So the handled set with irq_set_chained_handler is never called.

So change to use request_threaded_irq instead - that sets the correct field.

Tested on GTA04 Phoenux.
Signed-off-by: NNeilBrown <neilb@suse.de>
Tested-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

As the interrupt source is only cleared by the threaded interrupt
service routine, we need to make the base interrupt IRQF_ONESHOT.
Without this, the first interrupt from the TWL4030 cause the CPU to
enter an infinite loop trying to handle to interrupt but never
clearing it.
Signed-off-by: NNeilBrown <neilb@suse.de>
Tested-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>