There was a bad typo in commit 43759d4f ("random: use an improved
fast_mix() function") and I didn't notice because it "looked right", so
I saw what I expected to see when I reviewed it.

Only months later did I look and notice it's not the Threefish-inspired
mix function that I had designed and optimized.

Mea Culpa.  Each input bit still has a chance to affect each output bit,
and the fast pool is spilled *long* before it fills, so it's not a total
disaster, but it's definitely not the intended great improvement.

I'm still working on finding better rotation constants.  These are good
enough, but since it's unrolled twice, it's possible to get better
mixing for free by using eight different constants rather than repeating
the same four.
Signed-off-by: NGeorge Spelvin <linux@horizon.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org  # v3.16+
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While commit 7e36ef82 ("IB/core: Temporarily disable
ex_query_device uverb") is correct as it makes the extended
QUERY_DEVICE uverb (which came as part of commit 5a77abf9
("IB/core: Add support for extended query device caps") and commit
860f10a7 ("IB/core: Add flags for on demand paging support")) not
available to userspace, it doesn't address the initial issue regarding
ib_copy_to_udata() [1][2].

Additionally, further discussions around this new uverb seems to
conclude it would require a different data structure than the one
currently described in <rdma/ib_user_verbs.h> [3].

Both of these issues require a revert of the changes, so this patch
partially reverts commit 8cdd312c ("IB/mlx5: Implement the ODP
capability query verb") and commit 860f10a7 ("IB/core: Add flags
for on demand paging support") and fully reverts commit 5a77abf9
("IB/core: Add support for extended query device caps").

[1] "Re: [PATCH v3 06/17] IB/core: Add support for extended query device caps"
    http://mid.gmane.org/1418733236.2779.26.camel@opteya.com

[2] "Re: [PATCH] IB/core: Temporarily disable ex_query_device uverb"
    http://mid.gmane.org/1423067503.3030.83.camel@opteya.com

[3] "RE: [PATCH v1 1/5] IB/uverbs: ex_query_device: answer must not depend on request's comp_mask"
    http://mid.gmane.org/2807E5FD2F6FDA4886F6618EAC48510E0CC12C30@CRSMSX101.amr.corp.intel.com

Cc: Eli Cohen <eli@mellanox.com>
Cc: Haggai Eran <haggaie@mellanox.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Shachar Raindel <raindel@mellanox.com>
Signed-off-by: NYann Droneaud <ydroneaud@opteya.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>

Commit e9de688d ("irqchip: mips-gic: Support local interrupts")
changed the GIC irqchip driver so that all local interrupts were routed
to the same CPU pin used for external interrupts. Unfortunately this
causes a regression when smp-cmp is used. The CPUs are started by the
bootloader and put in a timer based waiting poll loop, but when their
timer interrupts are rerouted to a different IRQ pin which is not
unmasked they never wake up.

Since smp-cmp support is deprecated and everybody who was using it
should be switching to smp-cps which brings up the secondary CPUs
without bootloader assistance, I've gone for the simple fix which can be
easily removed once smp-cmp is removed, rather than a fully generic fix.

In __gic_init() the local GIC_VPE_TIMER_MAP register is read to find the
boot-time routing of the local timer interrupt, and a chained handler is
added to that CPU pin as well as the normal one.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Fixes: e9de688d ("irqchip: mips-gic: Support local interrupts")
Cc: Andrew Bresticker <abrestic@chromium.org>
Cc: Qais Yousef <qais.yousef@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Reviewed-by: NAndrew Bresticker <abrestic@chromium.org>
Patchwork: https://patchwork.linux-mips.org/patch/9081/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

After d75b1ade ("net: less interrupt masking in NAPI")
driver's NAPI poll routine is expected to return
exact budget value if it wants to be re-called.
Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
Fixes: d75b1ade ("net: less interrupt masking in NAPI")
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The RSS support requires enablement based on the features reported by
the hardware. The setting of this flag is missing. Add support to
set the RSS enablement flag based on the reported hardware features.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The number of traffic classes reported by the hardware is zero-based
so increment the value returned to get an actual count.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commit [8975626e: drm/cirrus: allow 32bpp framebuffers for
cirrus drm] broke X modesetting driver because cirrus driver still
provides the full list of modes up to 1280x1024 while the 32bpp can
support only up to 800x600.

We might be able to filter out the invalid modes in mode_valid
callback, but unfortunately the bpp in question can't be referred
there for now (let me know if there is a better way to retrieve the
bpp for the probed fb).

So, instead, this patch adds the bpp module option to specify the
maximal bpp explicitly and limits the resolutions in get_modes
depending on its value.

The default value is set to 24 so that the existing stuff keeps
working.  If you need a new 32bpp feature, specify cirrus.bpp=32
option explicitly.

Fixes: 8975626e ('drm/cirrus: allow 32bpp framebuffers for cirrus drm')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In virtio 1.0 mode, when mergeable buffers are enabled on a big-endian
host, num_buffers wasn't byte-swapped correctly, so large incoming
packets got corrupted.

To fix, fill it in within hdr - this also makes sure it gets
the correct type.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch correct the bad expression while writing the
bit-pattern from software's buffer to hardware registers.
Signed-off-by: NSanjeev Sharma <Sanjeev_Sharma@mentor.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commone register macors (e.g. RSR) is too commont to drivers, it may
be conflict with the architectures (e.g. xtensa, sh).

The related warnings (with allmodconfig under xtensa):

    CC [M]  drivers/net/usb/sr9700.o
  In file included from drivers/net/usb/sr9700.c:24:0:
  drivers/net/usb/sr9700.h:65:0: warning: "RSR" redefined
   #define RSR   0x06
   ^
  In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
                   from include/linux/bitops.h:36,
                   from include/linux/kernel.h:10,
                   from include/linux/list.h:8,
                   from include/linux/module.h:9,
                   from drivers/net/usb/sr9700.c:13:
  ./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of the previous definition
   #define RSR(v,sr) __asm__ __volatile__ ("rsr %0,"__stringify(sr) : "=a"(v));
   ^
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 3d0ad094.

Now that GSO functionality can correctly track if the fragment
id has been selected and select a fragment id if necessary,
we can re-enable UFO on tap/macvap and virtio devices.
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 5188cd44.

Now that GSO layer can track if fragment id has been selected
and can allocate one if necessary, we don't need to do this in
tap and macvtap.  This reverts most of the code and only keeps
the new ipv6 fragment id generation function that is still needed.

Fixes: 3d0ad094 (drivers/net: Disable UFO through virtio)
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e81648 ("PCI: Restore detection of read-only
BARs").  Prior to 36e81648, we filled in res->start; afterwards we
leave it zeroed out.  The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.

Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.

On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e81648,
we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.

[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e81648 ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdfReported-and-tested-by: NNix <nix@esperi.org.uk>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v.2.6.27+

Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
mp102_suspend/tmp102_resume under CONFIG_PM_SLEEP to avoid
build warnings.
Signed-off-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org>
[groeck: Declare tmp102_dev_pm_ops as static variable]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Commit 5a77abf9 ("IB/core: Add support for extended query device caps")
added a new extended verb to query the capabilities of RDMA devices, but the
semantics of this verb are still under debate [1].

Don't expose this verb to userspace until the ABI is nailed down.

[1] [PATCH v1 0/5] IB/core: extended query device caps cleanup for v3.19
    http://www.spinics.net/lists/linux-rdma/msg22904.htmlSigned-off-by: NHaggai Eran <haggaie@mellanox.com>
Reviewed-by: NYann Droneaud <ydroneaud@opteya.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>

Revert commit 6c17ee44 (ACPI / LPSS: introduce a 'proxy' device
to power on LPSS for DMA), as it introduced registration and probe
ordering problems between devices on the LPSS that may lead to full
hard system hang on boot in some cases.

For TKT238285 hardware issue which may cause txfifo store data twice can only
be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.

Fixes: f62caccd (spi: spi-imx: add DMA support)
Signed-off-by: NRobin Gong <b38343@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

After commit e9d8b2c2 (xen-netback:
disable rogue vif in kthread context), a fatal (protocol) error would
leave the guest Rx thread spinning, wasting CPU time.  Commit
ecf08d2d (xen-netback: reintroduce
guest Rx stall detection) made this even worse by removing a
cond_resched() from this path.

Since a fatal error is non-recoverable, just allow the guest Rx thread
to exit.  This requires taking additional refs to the task so the
thread exiting early is handled safely.
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Reported-by: NJulien Grall <julien.grall@linaro.org>
Tested-by: NJulien Grall <julien.grall@linaro.org>
Acked-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit de966c59 (net/mlx4_core: Support more than 64 VFs) was meant to
allow up to 126 VFs.  However, due to leaving MLX4_MFUNC_MAX too low, using
more than 80 VFs resulted in memory corruptions (and Oopses) when more than
80 VFs were requested. In addition, the number of slaves was left too high.

This commit fixes these issues.

Fixes: de966c59 ("net/mlx4_core: Support more than 64 VFs")
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>

The bug here is that we use "Reject" as the index into the cau_t[] array
in the else path.  Since the cau_t[] has 9 elements if Reject == 9 then
we are reading beyond the end of the array.

My understanding of the code is that it's saying that if Reject is 1 or
too high then that's invalid and we should hang up.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes a bug where vnet_skb_shape() didn't set the already-selected
queue mapping when a packet copy was required. This results in using the
wrong queue index for stops/starts, hung tx queues and watchdog timeouts
under heavy load.
Signed-off-by: NDavid L Stevens <david.stevens@oracle.com>
Acked-by: NSowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently qlge_update_hw_vlan_features() will always first put the
interface down, then update features and then bring it up again. But it
is possible to hit this code while the adapter is down and this causes a
non-paired call to napi_disable(), which will get stuck.

This patch fixes it by skipping these down/up actions if the interface
is already down.

Fixes: a45adbe8 ("qlge: Enhance nested VLAN (Q-in-Q) handling.")
Cc: Harish Patil <harish.patil@qlogic.com>
Signed-off-by: NMarcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from vram BO.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464

Cc: stable@vger.kernel.org
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from destination BO.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464

Cc: stable@vger.kernel.org
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Should be the same as cayman.  We don't use VM by default
on NI parts so this isn't critical.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it.  Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.

v2: handle vm_fini as well
v3: handle bo_open/close as well

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

This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.

v2: fix signed/unsigned warning

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=91861
https://bugzilla.kernel.org/show_bug.cgi?id=83461Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The variables diff_input, ext_vref, and vref_mv are only used in the probe
function and therefore don't need to be kept in the device data structure.
Reviewed-and-Tested-by: NRobert Rosengren <robert.rosengren@axis.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Simplify code and reduce code size by using regmap to access i2c registers.
Reviewed-and-Tested-by: NRobert Rosengren <robert.rosengren@axis.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The following patch fixes an issue observed with 4k sector disks
where the max_hw_sectors attribute was getting set too large in
sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units
of SCSI logical blocks and queue_max_hw_sectors is in units of
512 byte blocks, on a 4k sector disk, every time we went through
sd_revalidate_disk, we were taking the current value of
queue_max_hw_sectors and increasing it by a factor of 8. Fix
this by only shifting sdkp->max_xfer_blocks.

Cc: stable@vger.kernel.org
Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

This fixes a regression caused by commit 1d5203 ("scsi: handle more device
handler setup/teardown in common code").

The bug is that the alua detach() callout will try to access the
sddev->scsi_dh_data, but we have already set it to NULL. This patch
moves the clearing of that field to after detach() is called.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

This patch changes a BUG_ON() statement to pr_debug, in case the user tries to
update a non-existing queue.
Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
Reviewed-by: NBen Goz <ben.goz@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

commit 8eb23b9f
    sched: Debug nested sleeps

causes false-positive warnings in RAID5 code.

This annotation removes them and adds a comment
explaining why there is no real problem.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

If a non-page-aligned write is destined for a device which
is missing/faulty, we can deadlock.

As the target device is missing, a read-modify-write cycle
is not possible.
As the write is not for a full-page, a recontruct-write cycle
is not possible.

This should be handled by logic in fetch_block() which notices
there is a non-R5_OVERWRITE write to a missing device, and so
loads all blocks.

However since commit 67f45548, that code requires
STRIPE_PREREAD_ACTIVE before it will active, and those circumstances
never set STRIPE_PREREAD_ACTIVE.

So: in handle_stripe_dirtying, if neither rmw or rcw was possible,
set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set
after a suitable delay.

Fixes: 67f45548
Cc: stable@vger.kernel.org (v3.16+)
Reported-by: NMikulas Patocka <mpatocka@redhat.com>
Tested-by: NHeinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

Add two more Fujitsu LIFEBOOK models that also ship with the Elantech
touchpad and don't work with crc_disabled to the quirk list.
Signed-off-by: NRainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The existing code frees the skb in EAGAIN case, in which the skb will be
retried from upper layer and used again.
Also, the existing code doesn't free send buffer slot in error case, because
there is no completion message for unsent packets.
This patch fixes these problems.

(Please also include this patch for stable trees. Thanks!)
Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the following kernel crash,

	WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_input.c:3079 tcp_clean_rtx_queue+0x658/0x80c()
	Call trace:
	[<fffffe0000096b7c>] dump_backtrace+0x0/0x184
	[<fffffe0000096d10>] show_stack+0x10/0x1c
	[<fffffe0000685ea0>] dump_stack+0x74/0x98
	[<fffffe00000b44e0>] warn_slowpath_common+0x88/0xb0
	[<fffffe00000b461c>] warn_slowpath_null+0x14/0x20
	[<fffffe00005b5c1c>] tcp_clean_rtx_queue+0x654/0x80c
	[<fffffe00005b6228>] tcp_ack+0x454/0x688
	[<fffffe00005b6ca8>] tcp_rcv_established+0x4a4/0x62c
	[<fffffe00005bf4b4>] tcp_v4_do_rcv+0x16c/0x350
	[<fffffe00005c225c>] tcp_v4_rcv+0x8e8/0x904
	[<fffffe000059d470>] ip_local_deliver_finish+0x100/0x26c
	[<fffffe000059dad8>] ip_local_deliver+0xac/0xc4
	[<fffffe000059d6c4>] ip_rcv_finish+0xe8/0x328
	[<fffffe000059dd3c>] ip_rcv+0x24c/0x38c
	[<fffffe0000563950>] __netif_receive_skb_core+0x29c/0x7c8
	[<fffffe0000563ea4>] __netif_receive_skb+0x28/0x7c
	[<fffffe0000563f54>] netif_receive_skb_internal+0x5c/0xe0
	[<fffffe0000564810>] napi_gro_receive+0xb4/0x110
	[<fffffe0000482a2c>] xgene_enet_process_ring+0x144/0x338
	[<fffffe0000482d18>] xgene_enet_napi+0x1c/0x50
	[<fffffe0000565454>] net_rx_action+0x154/0x228
	[<fffffe00000b804c>] __do_softirq+0x110/0x28c
	[<fffffe00000b8424>] irq_exit+0x8c/0xc0
	[<fffffe0000093898>] handle_IRQ+0x44/0xa8
	[<fffffe000009032c>] gic_handle_irq+0x38/0x7c
	[...]

Software writes poison data into the descriptor bytes[15:8] and upon
receiving the interrupt, if those bytes are overwritten by the hardware with
the valid data, software also reads bytes[7:0] and executes receive/tx
completion logic.

If the CPU executes the above two reads in out of order fashion, then the
bytes[7:0] will have older data and causing the kernel panic.  We have to
force the order of the reads and thus this patch introduces read memory
barrier between these reads.
Signed-off-by: NIyappan Subramanian <isubramanian@apm.com>
Signed-off-by: NKeyur Chudgar <kchudgar@apm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When a skb has multiple vlans and it is CHECKSUM_PARTIAL,
ixgbevf_tx_csum() fails to get the network protocol and checksum related
descriptor fields are not configured correctly because skb->protocol
doesn't show the L3 protocol in this case.

Use first->protocol instead of skb->protocol to get the proper network
protocol.
Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>