Some spi device drivers use the same tx_buf and rx_buf repeatly for better
performance such as driver/input/touchsreen/ads7846.c, but spi core grab tx_buf
/rx_buf of transfer and set them as dummy_tx/dummy_rx once they are NULL. Thus,
in the second time the tx_buf/rx_buf will be replaced by dummy_tx/dummy_rx and
the data which produced by the last tx or rx may be wrongly sent to the device
or handled by the upper level protocol. This patch just keep the orignal value
of tx_buf/rx_buf if they are NULL after this transfer processed.
Signed-off-by: NRobin Gong <b38343@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Merge remote-tracking branches 'spi/topic/qup', 'spi/topic/rockchip', 'spi/topic/rspi', 'spi/topic/s3c64xx' and 'spi/topic/sc18is602' into spi-next

Merge remote-tracking branches 'spi/topic/omap-100k', 'spi/topic/omap-uwire', 'spi/topic/pl022', 'spi/topic/pm' and 'spi/topic/pxa2xx' into spi-next

Merge remote-tracking branches 'spi/topic/fsl-cspi', 'spi/topic/fsl-dspi', 'spi/topic/imx' and 'spi/topic/of-id' into spi-next

Merge remote-tracking branches 'spi/topic/blackfin', 'spi/topic/cadence', 'spi/topic/dw' and 'spi/topic/err' into spi-next

Merge remote-tracking branches 'spi/topic/atmel', 'spi/topic/bcm2385', 'spi/topic/bcm2835', 'spi/topic/bcm53xx' and 'spi/topic/bitbang' into spi-next

Merge remote-tracking branches 'spi/fix/fsl-dspi', 'spi/fix/imx' and 'spi/fix/rockchip' into spi-linus

In cases of short transfer times the CPU is spending lots of time
in the interrupt handler and scheduler to reschedule the worker thread.

Measurements show that we have times where it takes 29.32us to between
the last clock change and the time that the worker-thread is running again
returning from wait_for_completion_timeout().

During this time the interrupt-handler is running calling complete()
and then also the scheduler is rescheduling the worker thread.

This time can vary depending on how much of the code is still in
CPU-caches, when there is a burst of spi transfers the subsequent delays
are in the order of 25us, so the value of 30us seems reasonable.

With polling the whole transfer of 4 bytes at 10MHz finishes after 6.16us
(CS down to up) with the real transfer (clock running) taking 3.56us.
So the efficiency has much improved and is also freeing CPU cycles,
reducing interrupts and context switches.

Because of the above 30us seems to be a reasonable limit for polling.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Transforms the bcm-2835 native SPI-chip select to their gpio-cs equivalent.

This allows for some support of some optimizations that are not
possible due to HW-gliches on the CS line - especially filling
the FIFO before enabling SPI interrupts (by writing to CS register)
while the transfer is already in progress (See commit: e3a2be30)

This patch also works arround some issues in bcm2835-pinctrl which does not
set the value when setting the GPIO as output - it just sets up output and
(typically) leaves the GPIO as low.  When a fix for this is merged then this
gpio_set_value can get removed from bcm2835_spi_setup.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

When the CONTINUE bit is set, the interrupt status we are polling to
identify if a transaction has finished can be sporadic.  Even though
the transfer has finished, the interrupt status may erroneously
indicate that there is still data in the FIFO.  This behaviour causes
random timeouts in large PIO transfers.

Instead of using the CONTINUE bit to control the CS lines, use the SPI
core's CS GPIO handling.  Also, now that the CONTINUE bit is not being
used, we can poll for the ALLDONE interrupt to indicate transfer
completion.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Merge branch 'fix/img-spfi' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-img-spfi

Imagination has recommended that the SPFI controller be reset after
each message, regardless of success or failure.  Do this in an
unprepare_message() callback.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver can be greatly simplified by moving the transfer timeout
handling to a handle_err() callback.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Linux 4.0-rc7

Setting the transfer length in the TRANSACTION register after the
CONTROL register is programmed causes intermittent timeout issues in
SPFI transfers when using the SPI framework to control the CS GPIO
lines.  To avoid this issue, set transfer length before programming
the CONTROL register.
Signed-off-by: NSifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

If a driver doesn't implement the master->handle_err() callback and an
SPI transfer fails, the kernel will crash with a NULL pointer
dereference:

    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c0003000
    [00000000] *pgd=80000040004003, *pmd=00000000
    Internal error: Oops: 80000206 [#1] SMP ARM
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc7-koelsch-05861-g1fc9fdd4add4f783 #1046
    Hardware name: Generic R8A7791 (Flattened Device Tree)
    task: eec359c0 ti: eec54000 task.ti: eec54000
    PC is at 0x0
    LR is at spi_transfer_one_message+0x1cc/0x1f0

Make the master->handle_err() callback optional to avoid the crash.

Also fix a spelling mistake in the callback documentation while we're at
it.

Fixes: b716c4ff ("spi: introduce master->handle_err() callback")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Although the SPFI BITCLK divider supports a value of up to 255, only
values up to 128 are usable.  This results in a maximum possible bit
clock rate of 1/4th the input clock rate.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for switching to using the SPI core's CS GPIO handling,
move setup of the PORT_STATE register, which must be configured before
CS is asserted, to a prepare_message() callback.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Merge branch 'fix/fsl-dspi' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-fsl-dspi

Conflicts:
	drivers/spi/spi-fsl-dspi.c

Pull networking fixes from David Miller:

 1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
    previously SACK'd, from Neal Cardwell.

 2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
    from Cong WANG.

 3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
    from Cong WANG.

 4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.

 5) When we encapsulate for a tunnel device, skb->sk still points to the
    user socket.  So this leads to cases where we retraverse the
    ipv4/ipv6 output path with skb->sk being of some other address
    family (f.e. AF_PACKET).  This can cause things to crash since the
    ipv4 output path is dereferencing an AF_PACKET socket as if it were
    an ipv4 one.

    The short term fix for 'net' and -stable is to elide these socket
    checks once we've entered an encapsulation sequence by testing
    xmit_recursion.

    Longer term we have a better solution wherein we pass the tunnel's
    socket down through the output paths, but that is way too invasive
    for 'net' and -stable.

    From Hannes Frederic Sowa.

 6) l2tp_init() failure path forgets to unregister per-net ops, from
    Cong WANG.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
  net: dsa: fix filling routing table from OF description
  l2tp: unregister l2tp_net_ops on failure path
  mvneta: dont call mvneta_adjust_link() manually
  ipv6: protect skb->sk accesses from recursive dereference inside the stack
  netns: don't allocate an id for dead netns
  Revert "netns: don't clear nsid too early on removal"
  ip6mr: call del_timer_sync() in ip6mr_free_table()
  net: move fib_rules_unregister() under rtnl lock
  ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
  tcp: fix FRTO undo on cumulative ACK of SACKed range
  xen-netfront: transmit fully GSO-sized packets

Commit 1daa4303 ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.

Fixes: 1daa4303 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.

However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.

This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.

To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.

This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Signed-off-by: NPavel Nakonechny <pavel.nakonechny@skitlab.ru>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Pull input fixes from Dmitry Torokhov:
 "Updates for the input subsystem - two more tweaks for ALPS driver to
  work out kinks after splitting the touchpad, trackstick, and potential
  external PS/2 mouse into separate input devices.

  Changes to support ALPS SS4 devices (protocol V8) will be coming in
  4.1..."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: alps - document stick behavior for protocol V2
  Input: alps - report V2 Dualpoint Stick events via the right evdev node
  Input: alps - report interleaved bare PS/2 packets via dev3

Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mvneta_adjust_link() is a callback for of_phy_connect() and should
not be called directly. The result of calling it directly is as below:
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add delay between chip select and clock signals, before clock starts and
after clock stops.
Signed-off-by: NAaron Brice <aaron.brice@datasoft.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Adding fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay properties to
support delays before and after starting the clock in a transfer.
Signed-off-by: NAaron Brice <aaron.brice@datasoft.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).

Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR.  The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).

Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: NAaron Brice <aaron.brice@datasoft.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We need "ret" to be unsigned for the error handling to work.  The
signedness of "i" and "n" don't matter but qspi_set_send_trigger()
returns an int so I've changed them to int as well.

Fixes: 4b6fe3ed ('spi: Using Trigger number to transmit/receive data')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Document that protocol V2 uses standard (bare) PS/2 mouse packets for the
DualPoint stick.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-By: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.

Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.

This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.

This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.

This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Pull USB fixes from Greg KH:
 "Here are some small USB fixes and new device ids for 4.0-rc6.  Nothing
  major, some xhci fixes for reported problems, and some usb-serial
  device ids.

  All have been in linux-next for a while"

* tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
  usb: isp1760: fix spin unlock in the error path of isp1760_udc_start
  usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
  usb: xhci: handle Config Error Change (CEC) in xhci driver
  USB: keyspan_pda: add new device id
  USB: ftdi_sio: Added custom PID for Synapse Wireless product

Pull staging driver fixes from Greg KH:
 "Here are some staging driver fixes, well, really all just IIO driver
  fixes, for 4.0-rc6.  They fix issues that have been reported with
  these drivers.

  All of these patches have been in linux-next for a while"

* tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  iio: imu: Use iio_trigger_get for indio_dev->trig assignment
  iio: adc: vf610: use ADC clock within specification
  iio/adc/cc10001_adc.c: Fix !HAS_IOMEM build
  iio: core: Fix double free.
  iio:inv-mpu6050: Fix inconsistency for the scale channel
  staging: iio: dummy: Fix undefined symbol build error
  iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo
  staging: iio: hmc5843: Set iio name property in sysfs
  iio: bmc150: change sampling frequency
  iio: fix drivers that check buffer->scan_mask