There should be an 's' on "dump_message" so it matches the module_param.

Fixes: 84e0c4e5 ('spi: add loopback test driver to allow for spi_master regression tests')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The SPI core calls set_cs before a transfer, but the SUN4I_CTL_CS_MANUAL
flag is only set in transfer_one. This leads to the following pattern on
the chip-select line (with runtime power-management on every transfer,
without it only on the first one):

activate, deactivate, activate, transfer, deactivate

Moving the configuration of the SUN4I_CTL_CS_MANUAL flag from transfer_one
to set_cs removes the double activation.
Signed-off-by: NMarcus Weseloh <mweseloh42@gmail.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The spi_check_rx_ranges can always get executed independent of
if we have a real loopback situation.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Rename method spi_test_fill_tx to spi_test_fill_pattern
to better describe what it does.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently the rx_buf does not get set with the
SPI_TEST_PATTERN_UNWRITTEN when tx_buf == NULL in the transfer.

Reorder code so that it gets done also under this specific condition.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The fsl-espi hardware can trasfer at most 64K data so report teh
limitation.

Based on patch by Heiner Kallweit <hkallweit1@gmail.com>

CC: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Use to_platform_device() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Reviewed-by: NMoritz Fischer <moritz.fischer@ettus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Use to_platform_device() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Reviewed-by: NMoritz Fischer <moritz.fischer@ettus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds spi support for mt2701 IC.
Signed-off-by: NLeilk Liu <leilk.liu@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch merge all identical compat into on mtk_common_compat
and used for all compatible soc.
Signed-off-by: NLeilk Liu <leilk.liu@mediatek.com>
Reviewed-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In the case where transfer length is not a multiple of 4, KASAN
reports 2 out-of-bounds memory accesses:
 - mtk_spi_interrupt: ioread32_rep writes past the end of
   trans->rx_buf.
 - mtk_spi_fifo_transfer: iowrite32_rep reads past the end of
   xfer->tx_buf.

Fix this by using memcpy on the remainder of the bytes.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

s5pv210 and exynos4 are now DT only platforms hence these
entries can now be safely removed from the match table.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The total delay of HDMI hotplug detecting with 30ms is sometimes not
enoughtfor HDMI live status up with specific HDMI monitors in BSW platform.

After doing experiments for following monitors, it needs 80ms at least
for those worst cases.

Lenovo L246 1xwA (4 failed, necessary hot-plug delay: 58/40/60/40ms)
Philips HH2AP (9 failed, necessary hot-plug delay: 80/50/50/60/46/40/58/58/39ms)
BENQ ET-0035-N (6 failed, necessary hot-plug delay: 60/50/50/80/80/40ms)
DELL U2713HM (2 failed, necessary hot-plug delay: 58/59ms)
HP HP-LP2475w (5 failed, necessary hot-plug delay: 70/50/40/60/40ms)

It looks like 70-80 ms is BSW platform needs in some bad cases of the
monitors at this end (8 times delay at most). Keep less than 100ms for
HDCP pulse HPD low (with at least 100ms) to respond a plug out.
Reviewed-by: NCooper Chiou <cooper.chiou@intel.com>
Tested-by: NGary Wang <gary.c.wang@intel.com>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NGary Wang <gary.c.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450858295-12804-1-git-send-email-gary.c.wang@intel.comTested-by: NShobhit Kumar <shobhit.kumar@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 237ed86c ("drm/i915: Check live status before reading edid")
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit f8d03ea0)
[Jani: undo the file mode change of the original commit]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Propagate the return value of platform_get_irq on failure.

A simplified version of the semantic match that finds the two cases where
no error code is returned at all is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

dev->nr_luns reports the total number of luns available in a device
while dev->luns_per_chnl is the number of luns per channel.

When multiple channels are available, the offset is calculated from a
channel and lun id into a linear array. As it multiplies with
the total number of luns, we go out of bound when channel id > 0 and
causes the kernel to panic when we read a protected kernel memory area.
Signed-off-by: NMatias Bjørling <m@bjorling.me>
Signed-off-by: NJens Axboe <axboe@fb.com>

If null_blk is run in NULL_IRQ_TIMER mode and with queue_mode NULL_Q_RQ,
we need to restart the queue from the hrtimer interrupt. We can't
directly invoke the request_fn from that context, so punt the queue run
to async kblockd context.
Tested-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJens Axboe <axboe@fb.com>

Recently Dough Ledford reported a deadlock happening
between ocrdma-load sequence and NetworkManager service
issueing "open" on be2net interface.

The deadlock happens when any be2net hook (e.g. open/close) is called
in parallel to insmod ocrdma.ko.

A. be2net is sending administrative open/close event to ocrdma holding
   device_list_mutex. It does this from ndo_open/ndo_stop hooks of be2net.
   So sequence of locks is rtnl_lock---> device_list lock

B.  When new ocrdma roce device gets registered, infiniband stack now
    takes rtnl_lock in ib_register_device() in GID initialization routines.
    So sequence of locks in this path is device_list lock ---> rtnl_lock.

This improper locking sequence causes deadlock.

In order to resolve the above deadlock condition, ocrdma intorduced a
patch to stop listening to administrative open/close events generated from
be2net driver. It now depends on link-state-change async-event generated from
CNA. This change leaves behind dead code which used to generate administrative
open/close events. This patch cleans-up all that dead code from be2net.
Reported-by: NDoug Ledford <dledford@redhat.com>
CC: Sathya Perla <sathya.perla@avagotech.com>
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
Signed-off-by: NSelvin Xavier <selvin.xavier@avagotech.com>
Signed-off-by: NDevesh Sharma <devesh.sharma@avagotech.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Recently Dough Ledford reported a deadlock happening
between ocrdma-load sequence and NetworkManager service
issuing "open" on be2net interface.

The deadlock happens when any be2net hook (e.g. open/close) is called
in parallel to insmod ocrdma.ko.

A. be2net is sending administrative open/close event to ocrdma holding
   device_list_mutex. It does this from ndo_open/ndo_stop hooks of be2net.
   So sequence of locks is rtnl_lock---> device_list lock

B.  When new ocrdma roce device gets registered, infiniband stack now
    takes rtnl_lock in ib_register_device() in GID initialization routines.
    So sequence of locks in this path is device_list lock ---> rtnl_lock.

This improper locking sequence causes deadlock.

With this patch we stop using administrative open and close events
injected by be2net driver. These events were used to dispatch PORT_ACTIVE
and PORT_ERROR events to the IB-stack. This patch implements a logic
to receive async-link-events generated from CNA whenever link-state-change
is detected. Now on, these async-events will be used to dispatch
PORT_ACTIVE and PORT_ERROR events to IB-stack.

Depending on async-events from CNA removes the need to hold device-list-mutex
and thus breaks the busy-wait scenario.
Reported-by: NDoug Ledford <dledford@redhat.com>
CC: Sathya Perla <sathya.perla@avagotech.com>
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
Signed-off-by: NSelvin Xavier <selvin.xavier@avagotech.com>
Signed-off-by: NDevesh Sharma <devesh.sharma@avagotech.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Dispatch only port event to IB stack when port state changes.
Don't explicitly modify qps to error. Let application listen to
port events on async event queue or let QP fail with retry-exceeded
completion error.
Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@avagotech.com>
Signed-off-by: NDevesh Sharma <devesh.sharma@avagotech.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

vlan-id is wrongly getting as 0 when PFC is enabled.
Set vlan-id configured by user in QP parameters.
In case vlan interface is not used, flash a warning to
user to configure vlan and assign vlan-id as 0 in qp params.

Fixes: dbf727de ('IB/core: Use GID table in AH creation and dmac resolution')
Cc: Matan Barak <matanb@mellanox.com>
Signed-off-by: NDevesh Sharma <devesh.sharma@avagotech.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

When sysrq is triggered from console, serial driver for SUN hypervisor
console receives a console break and enables the sysrq. It expects a valid
sysrq char following with break. Meanwhile if driver receives 'NULL'
ASCII char then it disables sysrq and sysrq handler will never be invoked.

This fix skips calling uart sysrq handler when 'NULL' is received while
sysrq is enabled.
Signed-off-by: NVijay Kumar <vijay.ac.kumar@oracle.com>
Acked-by: NKarl Volz <karl.volz@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Constifies sunhv_ops structures in tty's serial
driver since they are not modified after their
initialization.

Detected and found using Coccinelle.
Suggested-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NAya Mahfouz <mahfouz.saif.elyazal@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the original code, if we succeeded on the last iteration through the
loop then we still returned failure.

Fixes: 389e4e04 ('qlcnic: fix a timeout loop')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

NCM buffer sizes are negotiated with the device independently of
the network device MTU.  The RX buffers are allocated by the
usbnet framework based on the rx_urb_size value set by cdc_ncm. A
single RX buffer can hold a number of MTU sized packets.

The default usbnet change_mtu ndo only modifies rx_urb_size if it
is equal to hard_mtu.  And the cdc_ncm driver will set rx_urb_size
and hard_mtu independently of each other, based on dwNtbInMaxSize
and dwNtbOutMaxSize respectively. It was therefore assumed that
usbnet_change_mtu() would never touch rx_urb_size.  This failed to
consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens
to be equal.

Fix by implementing an NCM specific change_mtu ndo, modifying the
netdev MTU without touching the buffer size settings.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently the needed_headroom field for the geneve device is left
to the default value.

This patch set it to space required for basic geneve encapsulation,
so that we can avoid the skb head re-allocation on xmit.

This give a 6% speedup for unsegment traffic on geneve tunnel.

v1 -> v2:
  - add ETH_HLEN for the lower device to the needed headroom
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The "domain" variable needs to be signed for the error handling to work.

Fixes: 8def3103 (cpufreq: arm_big_little: add SCPI interface driver)
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use to_spi_device() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The TMODE available value is well defined and documented in the header
file. Use it and remove the comment.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Atomic changes broke check_digital_port_conflicts(). It needs to look
at the global situation instead of just trying to find a conflict
within the current atomic state.

This bug made my HSW explode spectacularly after I had split the DDI
encoders into separate DP and HDMI encoders. With the fix, things
seem much more solid.

I hope holding the connection_mutex is enough protection that we can
actually walk the connectors even if they're not part of the current
atomic state...

v2: Regenerate the patch so that it actually applies (Jani)

Cc: stable@vger.kernel.org
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Fixes: 5448a00d ("drm/i915: Don't use staged config in check_digital_port_conflicts()")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449764551-12466-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 0bff4858)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Commit 0ef2f05c uses vmalloc for WR buffers
when needed and uses kvfree to free the buffers. It missed changing kfree
to kvfree in mlx4_ib_destroy_srq().
Reported-by: NMatthew Finaly <matt@Mellanox.com>
Signed-off-by: NWengang Wang <wen.gang.wang@oracle.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Previously, cma_match_net_dev called cma_protocol_roce which
tried to verify that the IB device uses RoCE protocol. However,
if rdma_id wasn't bound to a port, then the check would occur
against the first port of the device without regard to whether
that port was even of the same type as the type of port the
incoming packet was received on.

Fix this by passing the port of the request and only checking
against the same port of the device.
Reported-by: NOr Gerlitz <gerlitz.or@gmail.com>
Fixes: b8cab5da ('IB/cma: Accept connection without a valid netdev on RoCE')
Signed-off-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Commit 1299653a ("sh_eth: fix descriptor access endianness") only
addressed the 32-bit buffer address field byte-swapping  but the driver
still accesses 16-bit frame/buffer length descriptor fields without the
necessary byte-swapping -- which should affect the big-endian kernels.
In order to be able to use {cpu|edmac}_to_{edmac|cpu}(), we need to declare
the RX/TX descriptor word 1 as a 32-bit field and use shifts/masking to
access the 16-bit subfields (which gets rid of the ugly #ifdef'ery too)...
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Packets that arrive from real hardware devices have ip_summed ==
CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
current version of veth will replace CHECKSUM_NONE with
CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
a veth device to be delivered to the application. This caused applications
at Twitter to receive corrupt data when network hardware was corrupting
packets.

We believe this was added as an optimization to skip computing and
verifying checksums for communication between containers. However, locally
generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
written does nothing for them. As far as we can tell, after removing this
code, these packets are transmitted from one stack to another unmodified
(tcpdump shows invalid checksums on both sides, as expected), and they are
delivered correctly to applications. We didn’t test every possible network
configuration, but we tried a few common ones such as bridging containers,
using NAT between the host and a container, and routing from hardware
devices to containers. We have effectively deployed this in production at
Twitter (by disabling RX checksum offloading on veth devices).

This code dates back to the first version of the driver, commit
<e314dbdc> ("[NET]: Virtual ethernet device driver"), so I
suspect this bug occurred mostly because the driver API has evolved
significantly since then. Commit <0b796750> ("net/veth: Fix
packet checksumming") (in December 2010) fixed this for packets that get
created locally and sent to hardware devices, by not changing
CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
in from hardware devices.
Co-authored-by: NEvan Jones <ej@evanjones.ca>
Signed-off-by: NEvan Jones <ej@evanjones.ca>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Phil Sutter <phil@nwl.cc>
Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NVijay Pandurangan <vijayp@vijayp.ca>
Acked-by: NCong Wang <cwang@twopensource.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

0x4e is the runtime address normally associated with perihperal ICs.
0x45 is not a valid runtime address.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The primary PMICs use 0x3a3 as their hardware address, not 0x3e3.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

blk_end_request_all may free request, so we need to save
request_queue pointer before blk_end_request_all call.

The problem was introduced in commit cf8ecc5a
("null_blk: guarantee device restart in all irq modes")
and causes general protection fault with slab poisoning
enabled.

Fixes: cf8ecc5a ("null_blk: guarantee device
       restart in all irq modes")
Signed-off-by: NMike Krinkin <krinkin.m.u@gmail.com>
Reviewed-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

This patch fixes a lost request discovered during IO + hot removal.

The driver's pci removal deletes gendisks prior to shutting down the
controller to allow dirty data to sync. Dirty data can not be synced on
a surprise removal, though, and would potentially block indefinitely.

The driver previously had marked the queue as dying in this scenario
to prevent new requests from attempting, however it will still block
for requests that already entered the queue. This patch fixes this by
quiescing IO first, then aborting the requeued requests before deleting
disks.
Reported-by: NSujith Pandel <sujith_pandel@dell.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Tested-by: NSujith Pandel <sujith_pandel@dell.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms delay.

v2:
- straight up to loop execution for more clear in code readability
- mdelay will replace with msleep by Daniel's new patch

	drm/i915: mdelay(10) considered harmful

- suggest to re-evaluate try times for being compatible to old HDMI monitor
Reviewed-by: NCooper Chiou <cooper.chiou@intel.com>
Tested-by: NGary Wang <gary.c.wang@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NGary Wang <gary.c.wang@intel.com>
[danvet: fixup conflict with s/mdelay/msleep/ patch.]
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 61fb3980)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

I missed this myself when reviewing

commit 237ed86c
Author: Sonika Jindal <sonika.jindal@intel.com>
Date:   Tue Sep 15 09:44:20 2015 +0530

    drm/i915: Check live status before reading edid

Long sleeps like this really shouldn't waste cpu cycles spinning.

Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: "Wang, Gary C" <gary.c.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 71a199ba)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other uses thanks to universal plane support.

Chris pointed out that cursor updates are currently too slow
via universal planes that micro optimizations like these wouldn't
even help.

v2: Add a note about futility of micro optimizations (Chris)

Cc: drm-intel-fixes@lists.freedesktop.org
References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 1264859d)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>