We don't need to init HW before every transfer since we know the HW
state then. HW init at probe time is enough. While here, add setting the
clock register which belongs to init HW. Also, set MDBS bit since not
setting it is prohibited according to the manual.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

When calculating the bus speed, the clock should be on, of course. Most
bootloaders left them on, so this went unnoticed so far.

Move the ioremapping out of this clock-enabled-block and prepare for
adding hw initialization there, too.
Reported-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Cut 'n paste error saw it only process sizeof(t10_wwn.vendor) characters.
Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

target_core_sbc's compare_and_write functionality suffers from taking
data at the wrong memory location when writing a CAW request to disk
when a SGL offset is non-zero.

This can happen with loopback and vhost-scsi fabric drivers when
SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC is used to map existing user-space
SGL memory into COMPARE_AND_WRITE READ/WRITE payload buffers.

Given the following sample LIO subtopology,

% targetcli ls /loopback/
o- loopback ................................. [1 Target]
  o- naa.6001405ebb8df14a ....... [naa.60014059143ed2b3]
    o- luns ................................... [2 LUNs]
      o- lun0 ................ [iblock/ram0 (/dev/ram0)]
      o- lun1 ................ [iblock/ram1 (/dev/ram1)]
% lsscsi -g
[3:0:1:0]    disk    LIO-ORG  IBLOCK           4.0   /dev/sdc   /dev/sg3
[3:0:1:1]    disk    LIO-ORG  IBLOCK           4.0   /dev/sdd   /dev/sg4

the following bug can be observed in Linux 4.3 and 4.4~rc1:

% perl -e 'print chr$_ for 0..255,reverse 0..255' >rand
% perl -e 'print "\0" x 512' >zero
% cat rand >/dev/sdd
% sg_compare_and_write -i rand -D zero --lba 0 /dev/sdd
% sg_compare_and_write -i zero -D rand --lba 0 /dev/sdd
Miscompare reported
% hexdump -Cn 512 /dev/sdd
00000000  0f 0e 0d 0c 0b 0a 09 08  07 06 05 04 03 02 01 00
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
*
00000200

Rather than writing all-zeroes as instructed with the -D file, it
corrupts the data in the sector by splicing some of the original
bytes in. The page of the first entry of cmd->t_data_sg includes the
CDB, and sg->offset is set to a position past the CDB. I presume that
sg->offset is also the right choice to use for subsequent sglist
members.
Signed-off-by: NJan Engelhardt <jengelh@netitwork.de>
Tested-by: NDouglas Gilbert <dgilbert@interlog.com>
Cc: <stable@vger.kernel.org> # v3.12+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

this patch fixes following regression

 # targetcli
 [Errno 13] Permission denied: '/sys/kernel/config/target/qla2xxx/21:00:00:0e:1e:08:c7:20/tpgt_1/enable'

Fixes: 2eafd729 ("target: use per-attribute show and store methods")
Signed-off-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes the following kernel warning because it avoids that
IRQs are disabled while ft_release_cmd() is invoked (fc_seq_set_resp()
invokes spin_unlock_bh()):

WARNING: CPU: 3 PID: 117 at kernel/softirq.c:150 __local_bh_enable_ip+0xaa/0x110()
Call Trace:
 [<ffffffff814f71eb>] dump_stack+0x4f/0x7b
 [<ffffffff8105e56a>] warn_slowpath_common+0x8a/0xc0
 [<ffffffff8105e65a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff81062b2a>] __local_bh_enable_ip+0xaa/0x110
 [<ffffffff814ff229>] _raw_spin_unlock_bh+0x39/0x40
 [<ffffffffa03a7f94>] fc_seq_set_resp+0xe4/0x100 [libfc]
 [<ffffffffa02e604a>] ft_free_cmd+0x4a/0x90 [tcm_fc]
 [<ffffffffa02e6972>] ft_release_cmd+0x12/0x20 [tcm_fc]
 [<ffffffffa042bd66>] target_release_cmd_kref+0x56/0x90 [target_core_mod]
 [<ffffffffa042caf0>] target_put_sess_cmd+0xc0/0x110 [target_core_mod]
 [<ffffffffa042cb81>] transport_release_cmd+0x41/0x70 [target_core_mod]
 [<ffffffffa042d975>] transport_generic_free_cmd+0x35/0x420 [target_core_mod]
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Acked-by: NJoern Engel <joern@logfs.org>
Reviewed-by: NAndy Grover <agrover@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch addresses a race + use after free where the first
stage of COMPARE_AND_WRITE in compare_and_write_callback()
is rescheduled after the backend sends the secondary WRITE,
resulting in second stage compare_and_write_post() callback
completing in target_complete_ok_work() before the first
can return.

Because current code depends on checking se_cmd->se_cmd_flags
after return from se_cmd->transport_complete_callback(),
this results in first stage having SCF_COMPARE_AND_WRITE_POST
set, which incorrectly falls through into second stage CAW
processing code, eventually triggering a NULL pointer
dereference due to use after free.

To address this bug, pass in a new *post_ret parameter into
se_cmd->transport_complete_callback(), and depend upon this
value instead of ->se_cmd_flags to determine when to return
or fall through into ->queue_status() code for CAW.

Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: <stable@vger.kernel.org> # v3.12+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch addresses a case where iscsi_target_do_tx_login_io()
fails sending the last login response PDU, after the RX/TX
threads have already been started.

The case centers around iscsi_target_rx_thread() not invoking
allow_signal(SIGINT) before the send_sig(SIGINT, ...) occurs
from the failure path, resulting in RX thread hanging
indefinately on iscsi_conn->rx_login_comp.

Note this bug is a regression introduced by:

  commit e5419865
  Author: Nicholas Bellinger <nab@linux-iscsi.org>
  Date:   Wed Jul 22 23:14:19 2015 -0700

      iscsi-target: Fix iscsit_start_kthreads failure OOPs

To address this bug, complete ->rx_login_complete for good
measure in the failure path, and immediately return from
RX thread context if connection state did not actually reach
full feature phase (TARG_CONN_STATE_LOGGED_IN).

Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Smatch complains about returning hard coded error codes, silence this
warning.

drivers/target/iscsi/iscsi_target_parameters.c:211
   iscsi_create_default_params() warn: returning -1 instead of -ENOMEM is sloppy
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

TCMU sets TRANSPORT_FLAG_PASSTHROUGH, so INQUIRY commands will not be
emulated by LIO but passed up to userspace. Therefore TCMU should not
set these, just like pscsi doesn't.
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Reversed arguments meant that we were doing nothing for cmds whose deadline
had passed.
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

If more than 1024 event channels are bound to a evtchn device then it
possible (even with well behaved applications) for the ring to
overflow and events to be lost (reported as an -EFBIG error).

Dynamically increase the size of the ring so there is always enough
space for all bound events.  Well behaved applicables that only unmask
events after draining them from the ring can thus no longer lose
events.

However, an application could unmask an event before draining it,
allowing multiple entries per port to accumulate in the ring, and a
overflow could still occur.  So the overflow detection and reporting
is retained.

The ring size is initially only 64 entries so the common use case of
an application only binding a few events will use less memory than
before.  The ring size may grow to 512 KiB (enough for all 2^17
possible channels).  This order 7 kmalloc() may fail due to memory
fragmentation, so we fall back to trying vmalloc().
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Reviewed-by: NAndrew Cooper <andrew.cooper3@citrix.com>

After commit 8c058b0b ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIC does not
exist, which is the case for Xen PV guests.

Therefore we may need to allocate those descriptors ourselves.
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

Doing so will cause the grant to be unmapped and then, during
fault handling, the fault to be mistakenly treated as NUMA hint
fault.

In addition, even if those maps could partcipate in NUMA
balancing, it wouldn't provide any benefit since we are unable
to determine physical page's node (even if/when VNUMA is
implemented).

Marking grant maps' VMAs as VM_IO will exclude them from being
part of NUMA balancing.
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

With the actual code, read_alarm() always returns -EINVAL when called
during the RTC device registration. This prevents from retrieving an
already configured alarm in hardware.

This patch fixes the issue by moving the HAS_ALARM bit configuration
(if supported by the hardware) above the rtc_device_register() call.
Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

If hardware-driven P-state selection (HWP) is enabled, the
"performance" mode of intel_pstate should only allow the processor
to use the highest-performance P-state available.  That is not
the case currently, so make it actually happen.
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
[ rjw: Subject and changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit b3a72384 ("ARM/PCI: Replace pci_sys_data->align_resource with
global function pointer") introduced an ARM-specific align_resource()
function pointer.  This is not portable to other arches and doesn't work
for platforms with two different PCIe host bridge controllers.

Move the function pointer to the pci_host_bridge structure so each host
bridge driver can specify its own align_resource() function.
Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>

"Could not force DPM to low", etc. is usually harmless and
just confuses users.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Since commit 3fffd128 ("i2c: allow specifying
separate wakeup interrupt in device tree") we have
automatic wakeup irq support for i2c devices. That
commit missed the fact that rtc-1307 had its own
wakeup irq handling and ended up introducing a
kernel splat for at least Beagle x15 boards.

Fix that by reverting original commit _and_ passing
correct interrupt names on DTS so i2c-core can
choose correct IRQ as wakeup.

Now that we have automatic wakeirq support, we can
revert the original commit which did it manually.

Fixes the following warning:

[   10.346582] WARNING: CPU: 1 PID: 263 at linux/drivers/base/power/wakeirq.c:43 dev_pm_attach_wake_irq+0xbc/0xd4()
[   10.359244] rtc-ds1307 2-006f: wake irq already initialized

Cc: Tony Lindgren <tony@atomide.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Reported-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NMartin Peres <martin.peres@free.fr>

Regression from "abi16: implement limited interoperability with
usif/nvif".
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Somehow missed these two when removing dodgy void casts during the
rework.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Each GPCCS unit was reading the mask from GPC0, which causes problems on
boards where some GPCs are missing PPCs.

Part of the fix for fdo#92761.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's a few places where we need to access a GPC register from ucode,
but outside of the falcon's io address space.  To do this we need to
calculate the offset based on which GPC we're executing on.

This used to be done manually, but we've since found a "base" offset
that can be added by the hardware.  To use this, an extra bit needs to
be set in the register address, which is what this macro achieves.

There should be no functional change from this commit.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes detection of a failed attempt at fetching the entire ROM image
in one-shot (a violation of the spec, that works a lot of the time).

Tested on a HP Zbook 15 G2.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No locking is required for the traversal of this list, as it only
happens during suspend/resume where nothing else can be executing.

Fixes some of the issues noticed during parallel piglit runs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

fdo#70354 - comment #88.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

this is needed for my gpu
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

When we fail various metadata related operations in nvme_queue_rq we
need to unmap the data SGL.

Cc: stable@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).

The NVMe device driver, though, assumes that the DMA alignment for the
PRP entries will match the device's page size, and that the DMA aligment
matches the kernel's page aligment. On Power, the the IOMMU page size,
as mentioned above, can be 4K, while the device can have a page size of
8K, while the kernel has a page size of 64K. This eventually trips the
BUG_ON in nvme_setup_prps(), as we have a 'dma_len' that is a multiple
of 4K but not 8K (e.g., 0xF000).

In this particular case of page sizes, we clearly want to use the
IOMMU's page size in the driver. And generally, the NVMe driver in this
function should be using the IOMMU's page size for the default device
page size, rather than the kernel's page size. There is not currently an
API to obtain the IOMMU's page size across all architectures and in the
interest of a stop-gap fix to this functional issue, default the NVMe
device page size to 4K, with the intent of adding such an API and
implementation across all architectures in the next merge window.

With the functionally equivalent v3 of this patch, our hardware test
exerciser survives when using 32-bit DMA; without the patch, the kernel
will BUG within a few minutes.

Signed-off-by: Nishanth Aravamudan <nacc at linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

The hisi_pcie_probe() function is incorrectly marked as __init, as Kconfig
tells us:

  WARNING: drivers/pci/host/built-in.o(.data+0x7780): Section mismatch in reference from the variable hisi_pcie_driver to the function .init.text:hisi_pcie_probe()

If the probe for this device gets deferred past the point where __init
functions are removed, or the device is unbound and then reattached to the
driver, we branch into uninitialized memory, which is bad.

Remove the __init annotation from hisi_pcie_probe() and
hisi_add_pcie_port().

Fixes: 500a1d9a ("PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Acked-by: NZhou Wang <wangzhou1@hisilicon.com>

"pp->io" is an I/O resource, e.g., "[io 0x0000-0xffff]"; "pp->io_base" is
the CPU physical address of a region where the host bridge converts CPU
memory accesses into PCI I/O transactions.

Corrupting pp->io_base by assigning pp->io->start to it breaks access to
the PCI I/O space, as reported by Kishon.

Remove the invalid assignment.

[bhelgaas: changelog]
Fixes: 0021d22b ("PCI: designware: Use of_pci_get_host_bridge_resources() to parse DT")
Reported-and-tested-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>

Commit 12669631 ("PCI: Prevent out of bounds access in numa_node
override") missed that the user-provided node could also be negative.
Handle this case as well to avoid out-of-bounds accesses to the
node_states[] array.  However, allow the special value -1, i.e.
NUMA_NO_NODE, to be able to set the 'no specific node' configuration.

Fixes: 12669631 ("PCI: Prevent out of bounds access in numa_node override")
Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Sasha Levin <sasha.levin@oracle.com>
CC: Prarit Bhargava <prarit@redhat.com>
CC: stable@vger.kernel.org	# v3.19+

If enable Mediatek 8173 SoC, it should also enable power domain
driver. Otherwise access clk subsystem register will fail.
Signed-off-by: NEddie Huang <eddie.huang@mediatek.com>
Acked-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

On some cards it takes a relatively long time for the change
to take place.  Make a timeout non-fatal.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76130Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The IMX6Q/IMX6DL SoC's have a 2-bit temperature grade stored in OTP which
is valid for all IMX6 SoC's (despite the fact that the IMXSDLRM and
IMXSXRM do not document this - this has been proven via tests as well as
verified by Freescale FAE).

Instead of assuming a fixed 85C for passive cooling threshold and 105C for
critical use the thermal grade for these configurations.

We will set the critical to maxT - 5C and passive to maxT - 10C.

Cc: Anson Huang <b20788@freescale.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NJon Nettleton <jon@solid-run.com>
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
----
v3:
 - rebase against linux-soc-thermal.git
 - added ack's from Shawn and Jon
v2:
 - remove check for IMX6Q and update comments: The OTP values have been tested
   on IMX6SOLO, IMX6DUALLITE, and IMX6SX and Freescale FAE has shared data with
   me that the OTP settings are the same and that the reference manuals will
   reflect this in their next updates.
 - set critical to max - 5C
 - set passive to max - 10C
 - display max temp in info
 - do not allow passive to be set above critical
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This just caused build errors:

warning: (QCOM_SPMI_TEMP_ALARM) selects REGMAP_SPMI which has unmet direct dependencies (SPMI)
drivers/built-in.o: In function `regmap_spmi_ext_gather_write':
:(.text+0x609b0): undefined reference to `spmi_ext_register_write'
:(.text+0x609f0): undefined reference to `spmi_ext_register_writel'

While it's generally a good idea to allow compile testing, in this
case, it just doesn't work, so reverting the patch that
introduced the compile-test variant seems the most appropriate
solution.

Note that SPMI also has a 'depends on ARCH_QCOM || COMPILE_TEST'
statement, so we should be able to enable SPMI on all architectures
for compile testing already.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: cb7fb4d3 ("thermal: qcom_spmi: allow compile test")
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The SCPI clk driver registers the virtual cpufreq device that kicks off
initialisation of the SCPI cpufreq driver. Also, clk_get() will fail for
the cpufreq driver if the SCPI clk driver is missing.

Fix this by making the SCPI cpufreq driver explicitly depend on the SCPI
clk driver.

Fixes: 8def3103 (cpufreq: arm_big_little: add SCPI interface driver)
Signed-off-by: NPunit Agrawal <punit.agrawal@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

A rounding error was found in the calculation of limits->max_perf
in intel_pstate_set_policy(), which is used to calculate the max and min
pstate values in intel_pstate_get_min_max().  In that code,
limits->max_perf is truncated to 2 hex digits such that, for example,
0x169 was incorrectly calculated to 0x16 instead of 0x17.  This resulted in
the pstate being set one level too low.  This patch rounds the value of
limits->max_perf up instead of down so that the correct max pstate can
be reached.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>