lpfc_send_rscn_event() allocates data for sizeof(struct
lpfc_rscn_event_header) + payload_len, but claims that the data has size
of sizeof(struct lpfc_els_event_header) + payload_len. That leads to
buffer overruns.
Signed-off-by: NAles Novak <alnovak@suse.cz>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NSebastian Herbszt <herbszt@gmx.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Remove set but not used variables.
Signed-off-by: NSebastian Herbszt <herbszt@gmx.de>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

lpfc:Make the function lpfc_sli4_mbox_completions_pending static in order to comply with function prototype

This makes the function lpfc_sli4_mbox_completion's definition
static now in order to comply with its prototype being also
declared as static too.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Reviewed-by: NSebastian Herbszt <herbszt@gmx.de>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

This patch allows the LPFC to start up without a fatal kernel bug based
on an exceeded KMALLOC_MAX_SIZE and a too large NR_CPU-based maskbits
field. The bug was based on the number of CPU cores in a system.
Using the get_cpu_mask() function declared in kernel/cpu.c allows the
driver to load on the community kernel 4.2 RC1.

Below is the kernel bug reproduced:

8<--------------------------------------------------------------------
2199382.828437 (    0.005216)| lpfc 0003:02:00.0: enabling device (0140 -> 0142)
2199382.999272 (    0.170835)| ------------[ cut here ]------------
2199382.999337 (    0.000065)| WARNING: CPU: 84 PID: 404 at mm/slab_common.c:653 kmalloc_slab+0x2f/0x89()
2199383.004534 (    0.005197)| Modules linked in: lpfc(+) usbcore(+) mptctl scsi_transport_fc sg lpc_ich i2c_i801 usb_common tpm_tis mfd_core tpm acpi_cpufreq button scsi_dh_alua scsi_dh_rdacusbcore: registered new device driver usb
2199383.020568 (    0.016034)|
2199383.020581 (    0.000013)|  scsi_dh_hp_sw scsi_dh_emc scsi_dh gru thermal sata_nv processor piix fan thermal_sysehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
2199383.035288 (    0.014707)|
2199383.035306 (    0.000018)|  hwmon ata_piix
2199383.035336 (    0.000030)| CPU: 84 PID: 404 Comm: kworker/84:0 Not tainted 3.18.0-rc2-gat-00106-ga7ca10f2-dirty #178
2199383.047077 (    0.011741)| ehci-pci: EHCI PCI platform driver
2199383.047134 (    0.000057)| Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
2199383.056245 (    0.009111)| Workqueue: events work_for_cpu_fn
2199383.066174 (    0.009929)|  000000000000028d ffff88eef827bbe8 ffffffff815a542f 000000000000028d
2199383.069545 (    0.003371)|  ffffffff810ea142 ffff88eef827bc28 ffffffff8104365c ffff88eefe4006c8
2199383.076214 (    0.006669)|  0000000000000000 00000000000080d0 0000000000000000 0000000000000004
2199383.079213 (    0.002999)| Call Trace:
2199383.084084 (    0.004871)|  [<ffffffff815a542f>] dump_stack+0x49/0x62
2199383.087283 (    0.003199)|  [<ffffffff810ea142>] ? kmalloc_slab+0x2f/0x89
2199383.091415 (    0.004132)|  [<ffffffff8104365c>] warn_slowpath_common+0x77/0x92
2199383.095197 (    0.003782)|  [<ffffffff8104368c>] warn_slowpath_null+0x15/0x17
2199383.103336 (    0.008139)|  [<ffffffff810ea142>] kmalloc_slab+0x2f/0x89
2199383.107082 (    0.003746)|  [<ffffffff8110fd9e>] __kmalloc+0x13/0x16a
2199383.112531 (    0.005449)|  [<ffffffffa01a8ed9>] lpfc_pci_probe_one_s4+0x105b/0x1644 [lpfc]
2199383.115316 (    0.002785)|  [<ffffffff81302b92>] ? pci_bus_read_config_dword+0x75/0x87
2199383.123431 (    0.008115)|  [<ffffffffa01a951f>] lpfc_pci_probe_one+0x5d/0xcb5 [lpfc]
2199383.127364 (    0.003933)|  [<ffffffff81497119>] ? dbs_check_cpu+0x168/0x177
2199383.136438 (    0.009074)|  [<ffffffff81496fa5>] ? gov_queue_work+0xb4/0xc0
2199383.140407 (    0.003969)|  [<ffffffff8130b2a1>] local_pci_probe+0x1e/0x52
2199383.143105 (    0.002698)|  [<ffffffff81052c47>] work_for_cpu_fn+0x13/0x1b
2199383.147315 (    0.004210)|  [<ffffffff81054965>] process_one_work+0x222/0x35e
2199383.151379 (    0.004064)|  [<ffffffff81054e76>] worker_thread+0x3d5/0x46e
2199383.159402 (    0.008023)|  [<ffffffff81054aa1>] ? process_one_work+0x35e/0x35e
2199383.163097 (    0.003695)|  [<ffffffff810599c6>] kthread+0xc8/0xd2
2199383.167476 (    0.004379)|  [<ffffffff810598fe>] ? kthread_freezable_should_stop+0x5b/0x5b
2199383.176434 (    0.008958)|  [<ffffffff815a8cac>] ret_from_fork+0x7c/0xb0
2199383.180086 (    0.003652)|  [<ffffffff810598fe>] ? kthread_freezable_should_stop+0x5b/0x5b
2199383.192333 (    0.012247)| ehci-pci 0000:00:1a.0: EHCI Host Controller
-------------------------------------------------------------------->8

The proposed solution was approved by James Smart at Emulex and tested
on a UV2 machine with 6144 cores. With the fix, the LPFC module loads
with no unwanted effects on the system.
Signed-off-by: NIan Mitchell <imitchell@sgi.com>
Signed-off-by: NAlex Thorlton <athorlton@sgi.com>
Suggested-by: NRobert Elliot <elliott@hp.com>
[james.smart: resolve unused variable warning]
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Destroy lpfc_hba_index IDR on module exit, reclaiming the allocated memory.

This was detected by the following semantic patch (written by Luis Rodriguez
<mcgrof@suse.com>)
<SmPL>
@ defines_module_init @
declarer name module_init, module_exit;
declarer name DEFINE_IDR;
identifier init;
@@

module_init(init);

@ defines_module_exit @
identifier exit;
@@

module_exit(exit);

@ declares_idr depends on defines_module_init && defines_module_exit @
identifier idr;
@@

DEFINE_IDR(idr);

@ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 idr_destroy(&idr);
 ...
}

@ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 +idr_destroy(&idr);
}
</SmPL>
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Currently the module parameter lpfc_sg_seg_count does not have effect
for sli3 devices.

In lpfc_sli_driver_resource_setup(), which is used for sli3, the code
writes the configured sg_seg_cnt into lpfc_template.sg_tablesize.
But lpfc_template is the template used for sli4 only. Thus the value should
correctly be written to lpfc_template_s3->sg_tablesize.

This patch is for kernel 4.1-rc5, but is tested with lpfc 10.2.405.26 only.
Signed-off-by: NBodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Reviewed-by: NSebastian Herbszt <herbszt@gmx.de>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

kzalloc() returns a void pointer - no need to cast it in
drivers/scsi/lpfc/lpfc_init.c::lpfc_sli_driver_resource_setup()
Signed-off-by: NFiro Yang <firogm@gmail.com>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Remove trailing space from model description.
Signed-off-by: NSebastian Herbszt <herbszt@gmx.de>
Signed-off-by: NJames Smart <james.smart@avagotech.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

3w controller don't dma map small single SGL entry commands but instead
bounce buffer them.  Add a helper to identify these commands and don't
call scsi_dma_unmap for them.

Based on an earlier patch from James Bottomley.

Fixes: 118c85 ("3w-9xxx: fix command completion race")
Reported-by: NTóth Attila <atoth@atoth.sote.hu>
Tested-by: NTóth Attila <atoth@atoth.sote.hu>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

This fixes a bug in recent kernels which results in failure to boot
on systems that have multipath SCSI disks.  I observed this failure
on a POWER8 server where all the disks are multipath SCSI disks.
The symptoms are several messages like this on the console:

[    3.018700] device-mapper: table: 253:0: multipath: error attaching hardware handler
[    3.018828] device-mapper: ioctl: error adding target to table

and the system does not find its disks, and therefore fails to boot.

Bisection revealed that the bug was introduced in commit 566079c8,
"dm-mpath, scsi_dh: request scsi_dh modules in scsi_dh, not dm-mpath".
The specific reason for the failure is that where we previously loaded
the "scsi_dh_alua" module, we are now trying to load the "alua" module,
which doesn't exist.

To fix this, we change the request_module call in scsi_dh_lookup()
to prepend "scsi_dh_" to the name, just like the old code in
drivers/md/dm-mpath.c:parse_hw_handler() used to do.

[jejb: also fixes issue spotted by Sasha Levin that formatting
characters could be passed in via sysfs and cause issues with
request_module()]

Fixes: 566079c8Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Connection last_ping is not being updated when iscsi_send_nopout fails.
Not updating the last_ping will cause firing a timer to a past time
(last_ping + ping_tmo < current_time) which triggers an infinite loop of
iscsi_check_transport_timeouts() and hogs the cpu.

Fix this issue by checking the return value of iscsi_send_nopout.
If it fails set the next_timeout to one second later.
Signed-off-by: NAriel Nahum <arieln@mellanox.com>
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

I didn't notice this when merging the thermal code from Zhang, but his
merge (commit 5a924a07: "Merge branches 'thermal-core' and
'thermal-intel' of .git into next") of the thermal-core and
thermal-intel branches was wrong.

In thermal-core, commit 17e8351a ("thermal: consistently use int for
temperatures") converted the thermal layer to use "int" for
temperatures.

But in parallel, in the thermal-intel branch commit d0a12625
("thermal: Add Intel PCH thermal driver") added support for the intel
PCH thermal sensor using the old interfaces that used "unsigned long"
pointers.

This resulted in warnings like this:

  drivers/thermal/intel_pch_thermal.c:184:14: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
    .get_temp = pch_thermal_get_temp,
                ^
  drivers/thermal/intel_pch_thermal.c:184:14: note: (near initialization for ‘tzd_ops.get_temp’)
  drivers/thermal/intel_pch_thermal.c:186:19: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
    .get_trip_temp = pch_get_trip_temp,
                     ^
  drivers/thermal/intel_pch_thermal.c:186:19: note: (near initialization for ‘tzd_ops.get_trip_temp’)

This fixes it.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The seq_<foo> function return values were frequently misused.

See: commit 1f33c41c ("seq_file: Rename seq_overflow() to
     seq_has_overflowed() and make public")

All uses of these return values have been removed, so convert the
return types to void.

Miscellanea:

o Move seq_put_decimal_<type> and seq_escape prototypes closer the
  other seq_vprintf prototypes
o Reorder seq_putc and seq_puts to return early on overflow
o Add argument names to seq_vprintf and seq_printf
o Update the seq_escape kernel-doc
o Convert a couple of leading spaces to tabs in seq_escape
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Joerg Roedel <jroedel@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It looks like the Kconfig check that was meant to fix this (commit
fe9233fb [SCSI] scsi_dh: fix kconfig related
build errors) was actually reversed, but no-one noticed until the new set of
patches which separated DM and SCSI_DH).

Fixes: fe9233fbSigned-off-by: NChristoph Hellwig <hch@lst.de>
Tested-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
Acked-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Calling transport_generic_request_failure() from here causes list
corruption. We should be using target_complete_cmd() instead.

Which we do in all other cases, so the UNKNOWN_OP case can become just
another member of the big else/if chain in tcmu_handle_completion().
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This does nothing, and there are many other places where
transport_cmd_check_stop_to_fabric()'s retval is not checked>, If we
wanted to check it here, we should probably do it those other places too.
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

We don't use it any more.
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Current for-next iscsi target is broken:

commit 109e2381
Author: Roland Dreier <roland@purestorage.com>
Date:   Thu Jul 23 14:53:32 2015 -0700

    target: Drop iSCSI use of mutex around max_cmd_sn increment

This patch fixes incorrect pr_debug() + atomic_inc_return() usage
within iscsit_increment_maxcmdsn() code.

Also fix funny iscsit_determine_maxcmdsn() usage and update
iscsi_target_do_tx_login_io() code.
Reported-by: NSagi Grimberg <sagig@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
Cc: Roland Dreier <roland@purestorage.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch is a >= v4.1 regression bug-fix where control CDB
emulation logic in commit 38b57f82 now expects a se_cmd->se_sess
pointer to exist when determining T10-PI support is to be exposed
for initiator host ports.

To address this bug, go ahead and add locally generated se_cmd
descriptors for copy-offload block-copy to it's own stand-alone
se_session nexus, while the parent EXTENDED_COPY se_cmd descriptor
remains associated with it's originating se_cmd->se_sess nexus.

Note a valid se_cmd->se_sess is also required for future support
of WRITE_INSERT and READ_STRIP software emulation when submitting
backend I/O to se_device that exposes T10-PI suport.
Reported-by: NAlex Gorbachev <ag@iss-integration.com>
Tested-by: NAlex Gorbachev <ag@iss-integration.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Gilbert <dgilbert@interlog.com>
Cc: <stable@vger.kernel.org> # v4.1+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds an optional fabric driver provided SGL limit
that target-core will honor as it's own internal I/O maximum
transfer length limit, as exposed by EVPD=0xb0 block limits
parameters.

This is required for handling cases when host I/O transfer
length exceeds the requested EVPD block limits maximum
transfer length. The initial user of this logic is qla2xxx,
so that we can avoid having to reject I/Os from some legacy
FC hosts where EVPD=0xb0 parameters are not honored.

When se_cmd payload length exceeds the provided limit in
target_check_max_data_sg_nents() code, se_cmd->data_length +
se_cmd->prot_length are reset with se_cmd->residual_count
plus underflow bit for outgoing TFO response callbacks.
It also checks for existing CDB level underflow + overflow
and recalculates final residual_count as necessary.

Note this patch currently assumes 1:1 mapping of PAGE_SIZE
per struct scatterlist entry.
Reported-by: NCraig Watson <craig.watson@vanguard-rugged.com>
Cc: Craig Watson <craig.watson@vanguard-rugged.com>
Tested-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Arun Easi <arun.easi@qlogic.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Typo that snuck in with commit 6979c630Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Reported-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Broken since "gr: convert user classes to new-style nvkm_object"

Tested on a PPC64 G5 + NV34
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Due to some recent changes in
drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
were not being pruned properly. In current kernels,
drm_mode_validate_basic() is called to sanity-check each mode in the
list. If the sanity-check passes, the mode's status gets set to to
MODE_OK. In older kernels this check was not done, so old custom modes
would still have a status of MODE_UNVERIFIED at this point, and would
therefore be pruned later in the function.

As a result of this new behavior, the list of modes for a device always
includes every custom mode ever configured for the device, with the
largest one listed first. Since desktop environments usually choose the
first preferred mode when a hotplug event is emitted, this had the
result of making it very difficult for the user to reduce the size of
the display.

The qxl driver did implement the mode_valid connector function, but it
was empty. In order to restore the old behavior where old custom modes
are pruned, we implement a proper mode_valid function for the qxl
driver. This function now checks each mode against the last configured
custom mode and the list of standard modes. If the mode doesn't match
any of these, its status is set to MODE_BAD so that it will be pruned as
expected.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since 2009 we have a nice asm-generic header implementing lots of DMA API
functions for architectures using struct dma_map_ops, but unfortunately
it's still missing a lot of APIs that all architectures still have to
duplicate.

This series consolidates the remaining functions, although we still need
arch opt outs for two of them as a few architectures have very
non-standard implementations.

This patch (of 5):

The coherent DMA allocator works the same over all architectures supporting
dma_map operations.

This patch consolidates them and converges the minor differences:

 - the debug_dma helpers are now called from all architectures, including
   those that were previously missing them
 - dma_alloc_from_coherent and dma_release_from_coherent are now always
   called from the generic alloc/free routines instead of the ops
   dma-mapping-common.h always includes dma-coherent.h to get the defintions
   for them, or the stubs if the architecture doesn't support this feature
 - checks for ->alloc / ->free presence are removed.  There is only one
   magic instead of dma_map_ops without them (mic_dma_ops) and that one
   is x86 only anyway.

Besides that only x86 needs special treatment to replace a default devices
if none is passed and tweak the gfp_flags.  An optional arch hook is provided
for that.

[linux@roeck-us.net: fix build]
[jcmvbkbc@gmail.com: fix xtensa]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With two exceptions (drm/qxl and drm/radeon) all vm_operations_struct
structs should be constant.
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: NOleg Nesterov <oleg@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are two kexec load syscalls, kexec_load another and kexec_file_load.
 kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
split kexec_load syscall code to kernel/kexec.c.

And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
use kexec_file_load only, or vice verse.

The original requirement is from Ted Ts'o, he want kexec kernel signature
being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
kexec_load syscall can bypass the checking.

Vivek Goyal proposed to create a common kconfig option so user can compile
in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
KEXEC_CORE so that old config files still work.

Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
kexec_load syscall.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NDave Young <dyoung@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Petr Tesarik <ptesarik@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Instead of custom approach let's use recently introduced seq_hex_dump()
helper.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Joe Perches <joe@perches.com>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Instead of custom approach let's use recently introduced seq_hex_dump()
helper.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NIngo Tuchscherer <ingo.tuchscherer@de.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Joe Perches <joe@perches.com>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Instead of custom approach let's use recently introduced seq_hex_dump()
helper.

In one case it changes the output from
	1111111122222222333333334444444455555555666666667777777788888888
to
	11111111 22222222 33333333 44444444 55555555 66666666 77777777 88888888

though it seems it prints same data (by meaning) in both cases.  I decide
to choose to use the space divided one.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NHelge Deller <deller@gmx.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Joe Perches <joe@perches.com>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Instead of custom approach let's use recently introduced seq_hex_dump()
helper.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NTadeusz Struk <tadeusz.struk@intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Joe Perches <joe@perches.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Originally that parameter was always reset to num_online_cpus during
module initialisation, which renders it useless.

The fix is to only set max_queues to num_online_cpus when user has not
provided a value.
Signed-off-by: NWei Liu <wei.liu2@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
Tested-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Originally that parameter was always reset to num_online_cpus during
module initialisation, which renders it useless.

The fix is to only set max_queues to num_online_cpus when user has not
provided a value.
Reported-by: NJohnny Strom <johnny.strom@linuxsolutions.fi>
Signed-off-by: NWei Liu <wei.liu2@citrix.com>
Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104031
Fixes: 6e85d5ad

Based on the discussion starting at
http://www.spinics.net/lists/netdev/msg342193.html

Tested locally on RTL8168evl/8111evl with various concurrent processes
accessing /proc/net/dev while changing the link state as well as
removing/reloading the r8169 module.
Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
Tested-by: Npoma <pomidorabelisima@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Just like single link MIPI panels, similarly for dual link panels, pipe
to be configured is based on the DVO port from VBT Block 2. In hardware,
Port A is mapped with Pipe A and Port C is mapped with Pipe B.

This issue got introduced in -

commit 7e9804fd
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Jan 16 14:27:23 2015 +0200

    drm/i915/dsi: add drm mipi dsi host support

Cc: stable@vger.kernel.org # v4.0
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If one disables DDR DVFS in the BIOS, Punit will apparently ignores
all DDR DVFS request. Currently we assume that DDR DVFS is always
operational, which leads to errors in dmesg when the DDR DVFS requests
time out.

Fix the problem by gently prodding Punit during driver load to find out
whether it will respond to DDR DVFS requests. If the request times out,
we assume that DDR DVFS has been permanenly disabled in the BIOS and
no longer perster the Punit about it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91629Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Tested-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Fix a wrong logical AND (&&) used for the range check of CSR MMIO.

Spotted nicely by gcc -Wlogical-op flag:
  drivers/gpu/drm/i915/intel_csr.c: In function ‘finish_csr_load’:
  drivers/gpu/drm/i915/intel_csr.c:353:41: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]

Fixes: eb805623 ('drm/i915/skl: Add support to load SKL CSR firmware.')
Cc: <stable@vger.kernel.org> # v4.2
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Incorporate fw_ldst_cmd structure change for new firmware and also
update version string for the same
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There exist one issue by below case that case system hang:
ifconfig eth0 down
ifconfig eth0 hw ether 00:10:19:19:81:19

After eth0 down, all fec clocks are gated off. In the .fec_set_mac_address()
function, it will set new MAC address to registers, which causes system hang.

So it needs to add netif status check to avoid registers access when clocks are
gated off. Until eth0 up the new MAC address are wrote into related registers.

V2:
As Lucas Stach's suggestion, add a comment in the code to explain why it needed.

CC: Lucas Stach <l.stach@pengutronix.de>
CC: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NFugang Duan <B38611@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>