Payload is currently accessed blindly and may exceed valid message
boundaries.
Fixes: 407af3299 ("bridge: Add netlink interface to configure vlans on bridge ports")
Cc: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
affects nothing but ARM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJUddkVAAoJEL/70l94x66D0awIAK+Zy4CnoLdtEpWFZsuoK2YO
TXOUg3z0WNR4sD/dFMlh1jLxiBG5f/JkDHBBecSZTi+L9PcU15mrAeS+k1F4rDkw
0GNwRQas+WDElD9rRnqIeBF8A83BmunsVnCsOmn3w+xeXuB8L0HBy6Pgh/wnfHbQ
+G4gODi0JMDVcvEujN2NNBf60LcM/G3U0VIFXHHGblEIOUtNCUy9mnGRBCg75vwb
CORpMC+8JV7gFF7jVnqurYc2SyN9a6fzun1evIQJWlFN+ohU8XjkVn4JsrsHpv+E
6Eqy1wgEWLW1TQhApsh5EYkIRTvvGLgdKm5KCBu15xUw/i3OTOc1BQ0VrSEPs/Y=
=rEqk
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Last minute KVM/ARM fixes; even the generic change actually affects
nothing but ARM"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm: fix kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()
arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()
arm/arm64: KVM: vgic: Fix error code in kvm_vgic_create()
arm64: KVM: Handle traps of ICC_SRE_EL1 as RAZ/WI
arm64: KVM: fix unmapping with 48-bit VAs
Most of these are fairly standard little fixes, a bmc150 and bmg160 patch
is to make an ABI change to indicated a specific axis in an event rather
than the generic option in the original drivers. As both of these drivers
are new in this cycle it would be ideal to push this minor change through
even though it isn't strictly a fix. A couple of other 'fixes' change
defaults for some settings on these new drivers to more intuitive calues.
Looks like some useful feedback has been coming in for this driver
since it was applied.
* IIO_EVENT_CODE_EXTRACT_DIR bit mask was wrong and has been for a while
0xCF clearly doesn't give a contiguous bitmask.
* kxcjk-1013 range setting was failing to mask out the previous value
in the register and hence was 'enable only'.
* men_z188 device id table wasn't null terminated.
* bmg160 and bmc150 both failed to correctly handling an error in mode
setting.
* bmg160 and bmc150 both had a bug in setting the event direction in the
event spec (leads to an attribute name being incorrect)
* bmg160 defaulted to an open drain output for the interrupt - as a default
this obviously only works with some interrupt chips - hence change the
default to push-pull (note this is a new driver so we aren't going to
cause any regressions with this change).
* bmc150 had an unintuitive default for the rate of change (motion detector)
so change it to 0 (new driver so change of default won't cause any
regressions).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUaRGrAAoJEFSFNJnE9BaIrWgP/jdxYsA7l7gAamjkK6Dm+jmR
FIDaD1eJ0ZMRS43guIwaGJ90OC2Mxc7xIAgbE3xurI0r/73YagTwWtUwzUOGRnE1
kqRKyo8NEu3+BZtasoigEZfm9pHmsmkdD+lQLAnLlDeVFhYpTbsr/j9qeMD7L8CN
b+hTwQBsObnpJ/tN61KLSjlx57D8c47ghCgqEaGqXrfR4r/wMItMN6cB1xbM4yU4
tHJQBBbOv03vZI5oaxJ3+Q4aBGf4TdrL3z/P/vrmMUyyQrmbS6jCBjUlmjcylVSn
Yz2mr5oPyRgRRzH/KcMT/S+i8BELxBuC5nURBAkO35YqHhXvZENgg29edEWX4s4c
KOTC+FgbEEPEu5wcUl5NuFPP3D8NNuOxDl677bLz9I6ufhwFLCNtyN6vGsqAMPA+
s/eviz/W8u2L90/+ryiEV+UESXjqLszWU7xpfdheo4Z6jokpWi9ZT65m11Z+aJ79
QldzeniUxR9ycH6O6z9GxkdhXV79OACjkvoNZgh33MfmuX7jLMIodWfrI/Xn2+Pb
N0hpWzcADcd2KfXoXRvuN8t3Wgz09T7CuodOSBsAOjhvkUiufj+iOhwU96rNnNzl
ZWtYAbRr+DmKks+bzoobyCypaH/0hPuC/YUSBUALlg80P8ozGiIs+E1phiZze+rB
fHyT8lUFg4a0syWOfx8s
=IPMl
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.18c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Third set of IIO fixes for the 3.18 cycle.
Most of these are fairly standard little fixes, a bmc150 and bmg160 patch
is to make an ABI change to indicated a specific axis in an event rather
than the generic option in the original drivers. As both of these drivers
are new in this cycle it would be ideal to push this minor change through
even though it isn't strictly a fix. A couple of other 'fixes' change
defaults for some settings on these new drivers to more intuitive calues.
Looks like some useful feedback has been coming in for this driver
since it was applied.
* IIO_EVENT_CODE_EXTRACT_DIR bit mask was wrong and has been for a while
0xCF clearly doesn't give a contiguous bitmask.
* kxcjk-1013 range setting was failing to mask out the previous value
in the register and hence was 'enable only'.
* men_z188 device id table wasn't null terminated.
* bmg160 and bmc150 both failed to correctly handling an error in mode
setting.
* bmg160 and bmc150 both had a bug in setting the event direction in the
event spec (leads to an attribute name being incorrect)
* bmg160 defaulted to an open drain output for the interrupt - as a default
this obviously only works with some interrupt chips - hence change the
default to push-pull (note this is a new driver so we aren't going to
cause any regressions with this change).
* bmc150 had an unintuitive default for the rate of change (motion detector)
so change it to 0 (new driver so change of default won't cause any
regressions).
The commit 3b57de958e brought the support for a different amount of
the filter bins, but didn't update the platform driver that without
CONFIG_OF.
Fixes: 3b57de958e (net: stmmac: Support devicetree configs for mcast
and ucast filter entries)
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.
Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.
As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.
Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Florian Fainelli says:
====================
net: dsa: bcm_sf2: misc bugfixes
This patch series contains two bug fixes:
- first patch fixes an issue on the error path of the driver where we could
have left some of our registers mapped
- second patch enforces the use of a software reset of the switch to guarantee
the HW is in a consistent state prior to software initialization
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Our boot agent may have left the switch in an certain configuration
state, make sure we issue a software reset prior to configuring the
switch in order to ensure the HW is in a consistent state, in particular
transmit queues and internal buffers.
Fixes: 246d7f773c ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case we fail to ioremap() one of our registers, we would be leaking
existing mappings, unwind those accordingly on errors.
Fixes: 246d7f773c ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 85c8555ff0 ("KVM: check for !is_zero_pfn() in
kvm_is_mmio_pfn()") and renames the function to kvm_is_reserved_pfn.
The problem being addressed by the patch above was that some ARM code
based the memory mapping attributes of a pfn on the return value of
kvm_is_mmio_pfn(), whose name indeed suggests that such pfns should
be mapped as device memory.
However, kvm_is_mmio_pfn() doesn't do quite what it says on the tin,
and the existing non-ARM users were already using it in a way which
suggests that its name should probably have been 'kvm_is_reserved_pfn'
from the beginning, e.g., whether or not to call get_page/put_page on
it etc. This means that returning false for the zero page is a mistake
and the patch above should be reverted.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Instead of using kvm_is_mmio_pfn() to decide whether a host region
should be stage 2 mapped with device attributes, add a new static
function kvm_is_device_pfn() that disregards RAM pages with the
reserved bit set, as those should usually not be mapped as device
memory.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If we detect another vCPU is running we just exit and return 0 as if we
succesfully created the VGIC, but the VGIC wouldn't actual be created.
This shouldn't break in-kernel behavior because the kernel will not
observe the failed the attempt to create the VGIC, but userspace could
be rightfully confused.
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When running on a system with a GICv3, we currenly don't allow the guest
to access the system register interface of the GICv3. We do this by
clearing the ICC_SRE_EL2.Enable, which causes all guest accesses to
ICC_SRE_EL1 to trap to EL2 and causes all guest accesses to other ICC_
registers to cause an undefined exception in the guest.
However, we currently don't handle the trap of guest accesses to
ICC_SRE_EL1 and will spill out a warning. The trap just needs to handle
the access as RAZ/WI, and a guest that tries to prod this register and
set ICC_SRE_EL1.SRE=1, must read back the value (which Linux already
does) to see if it succeeded, and will thus observe that ICC_SRE_EL1.SRE
was not set.
Add the simple trap handler in the sorted table of the system registers.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
[ardb: added cp15 handling]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently we just make sure vdd is off before suspending, but we don't
cancel the vdd off work. The work wil not touch vdd if
want_panel_vdd==false so in theory this is fine.
In the past that was perfectly fine since the vdd off work didn't do
anything when want_panel_vdd==false, so even if the work would have been
run during system resume before i915 has resumed, nothing would happen.
However since pps_lock() will now grab the power domain references before
it can check want_panel_vdd, we may end up toggling the power wells on/off
already before the driver has resumed. That is not really acceptable, so
cancel the vdd off work when suspending the encoder.
The problem appeared when pps_lock() was introduced in:
commit 773538e860
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 4 14:54:56 2014 +0300
drm/i915: Reset power sequencer pipe tracking when disp2d is off
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If no voltage supply regulators are defined for the UFS devices (assumed
they are always-on), ufshcd_config_vreg_load() can be called on
suspend/resume paths with vreg == NULL as hba->vreg_info.vcc* equal to
NULL, and it causes NULL pointer dereference.
This fixes it by making ufshcd_config_vreg_{h,l}pm noop when no regulators
are defined.
Signed-off-by: Akinobu Mita <mita@fixstars.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
When dynamic clk gating feature is enabled, delayed workqueue machanism
is used in order to detect certain period of inactivity. But there is no
guarantee that scheduled gating work is completed before module unloading.
So it can cause kernel crash by accessing memory after it was freed.
Fix it by cancelling clk gating and ungating works and ensure that its
execution is finished before module unloading.
Signed-off-by: Akinobu Mita <mita@fixstars.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Kevin Cernekee <cernekee@gmail.com>
Link: https://lkml.kernel.org/r/20141114221642.GA37468@dtor-ws
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Kevin Cernekee <cernekee@gmail.com>
Link: https://lkml.kernel.org/r/20141114221614.GA37395@dtor-ws
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Pull nfsd bugfixes from Bruce Fields:
"These fix one mishandling of the case when security labels are
configured out, and two races in the 4.1 backchannel code"
* 'for-3.18' of git://linux-nfs.org/~bfields/linux:
nfsd: Fix slot wake up race in the nfsv4.1 callback code
SUNRPC: Fix locking around callback channel reply receive
nfsd: correctly define v4.2 support attributes
Pull aio fix from Ben LaHaise:
"Dirty page accounting fix for aio"
* git://git.kvack.org/~bcrl/aio-fixes:
aio: fix uncorrent dirty pages accouting when truncating AIO ring buffer
Pull powerpc fixes from Ben Herrenschmidt:
"This series fix a nasty issue with radeon adapters on powerpc servers,
it's all CC'ed stable and has the relevant maintainers ack's/reviews.
Basically, some (radeon) adapters have issues with MSI addresses above
1T (only support 40-bits). We had powerpc specific quirk but it only
listed a specific revision of an adapter that we shipped with our
machines and didn't properly handle the audio function which some
distros enable nowadays.
So we made the quirk generic and fixed both the graphic and audio
drivers properly to use it.
Without that, ppc64 server machines will crash at boot with a radeon
adapter.
Note: This has been brewing for a while, it just needed a last respin
which got delayed due to us moving ozlabs to a new location in town
and other such things taking priority"
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/pci: Remove unused force_32bit_msi quirk
powerpc/pseries: Honor the generic "no_64bit_msi" flag
powerpc/powernv: Honor the generic "no_64bit_msi" flag
sound/radeon: Move 64-bit MSI quirk from arch to driver
gpu/radeon: Set flag to indicate broken 64-bit MSI
PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
ALSA: hda - Limit 40bit DMA for AMD HDMI controllers
single fix in one of the basic clock templates. No fixes to the core
this time around. As with most clock driver fixes these run the gamut
from fixing a build warning to fixing wrecked memory timings, with a
little USB tossed in for fun. Please consider pulling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUcrkwAAoJEDqPOy9afJhJzq4P/jT9K+g0ljQrY93t97Wm6s4x
Xi+RrVO/MOUhpIGzqrhPflGALl5Yj96iBUiC2QSVpVjDUdoQL5tc8c3FtQDGA7fA
Q/9e2yUmjQ+nNxizdeIzaNUHO+fIe8FEn3NwyondfaDlI1sqVv/0WAf6MNkuLCwM
/DJ1MmJbwgK255gI3FwUhbNylCCPeUENKRs3xGW3p4+fFIZGyROhBsJClE1nUiT1
EFzWM6Bq29qOLxZ4Dqkfzz1BWLiqcTlRcf8ZaHjME77k09ybwNS9cmXrB9gHhmlL
sMfDa0uwsv/mFWRohP5jK3AUqqtR7EgcPL5euO+d9Q+nBVofgTwxyvA0nlGqX8XQ
hm1OZeolnWHPPHasRkgzSnd/0b/A8s+tr96XSvHjIlrx1ioWQD2K7GU82/3bObTL
isqzW34+Y0dX2GpgwJu2eWrSwHk705wBA0t8/pP+r7aWdUsyX4J1ElGHLElzTLI0
VkQZPwKvjVNd0kQRplZ/KPQoboDuFh8b09+MvG8Kz8t3Ilt0MS7rFrxEQ6xIBfe9
M49vUJw2egmOCgcWp3GeyICIQJCfet2acyZy+vJivpu0//ssD7BT/woR7qmgHic1
kmiVdj1iBSoUK4NIr+DvsNmMMDEW58CSK/j11chitT8WCRGYKW849iUk7LiGhXU0
IgTphTfMdFF1a2gzqaQo
=4O2k
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of https://git.linaro.org/people/mike.turquette/linux
Pull clock fixes from Mike Turquette:
"The fixes for the clock framework are all regressions in drivers, plus
a single fix in one of the basic clock templates. No fixes to the
core this time around.
As with most clock driver fixes these run the gamut from fixing a
build warning to fixing wrecked memory timings, with a little USB
tossed in for fun"
* tag 'clk-fixes-for-linus' of https://git.linaro.org/people/mike.turquette/linux:
clk: pxa: fix pxa27x CCCR bit usage
clk-divider: Fix READ_ONLY when divider > 1
clk: qcom: Fix duplicate rbcpr clock name
clk: at91: usb: fix at91sam9x5 recalc, round and set rate
clk: at91: usb: fix at91rm9200 round and set rate
This reverts commit 2dea53bf57.
Turns out to be broken :(
Cc: Jingchang Lu <jingchang.lu@freescale.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If TX channels are set to 4 and RX channels are set to less than 4,
using ethtool -L, the driver will try to initialize more RX channels
than it has allocated, causing an oops.
This fix only initializes the RX ring if it has been allocated.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit ca777eff51 ("tcp: remove dst refcount false sharing for
prequeue mode") we have to relax check against skb dst in
tcp_v[46]_send_reset() if prequeue dropped the dst.
If a socket is provided, a full lookup was done to find this socket,
so the dst test can be skipped.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88191
Reported-by: Jaša Bartelj <jasa.bartelj@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Daniel Borkmann <dborkman@redhat.com>
Fixes: ca777eff51 ("tcp: remove dst refcount false sharing for prequeue mode")
Signed-off-by: David S. Miller <davem@davemloft.net>
The existing order of steps when starting the PCI devices works for
2.4G devices, but fails to initialize the 5G section of the RTL8821AE
hardware.
This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).
Reported-by: Valerio Passini <valerio.passini@unicam.it>
Tested-by: Valerio Passini <valerio.passini@unicam.it>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Valerio Passini <valerio.passini@unicam.it>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The changes associated with moving this driver from staging to the regular
tree missed one section setting the allowable rates for the 5GHz band.
This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).
Reported-by: Valerio Passini <valerio.passini@unicam.it>
Tested-by: Valerio Passini <valerio.passini@unicam.it>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Valerio Passini <valerio.passini@unicam.it>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit 5195c14c8b.
If the conntrack clashes with an existing one, it is left out of
the unconfirmed list, thus, crashing when dropping the packet and
releasing the conntrack since golden rule is that conntracks are
always placed in any of the existing lists for traceability reasons.
Reported-by: Daniel Borkmann <dborkman@redhat.com>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88841
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck says:
====================
Fix outer UDP checksums for IPv6 VXLAN tunnels
In testing against an older kernel I found a couple issues in the IPv6
VXLAN tunnel checksum logic for the outer UDP checksum.
First the default transitioned from using an outer checksum to not using
one. Second, sometime after that the checksum inputs were changed
resulting the checksum not being correct if it were computed.
These two issues prevented a ping from the newer kernel to the older one.
With these two changes applied I verified I was able to send traffic over
the VXLAN tunnel to a link partner on an older kernel.
The boolean flip fix can be submitted for 3.17 stable as well since the
patch that introduced the issue was included in that kernel.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
In "vxlan: Call udp_sock_create" there was a logic error that resulted in
the default for IPv6 VXLAN tunnels going from using checksums to not using
checksums. Since there is currently no support in iproute2 for setting
these values it means that a kernel after the change cannot talk over a IPv6
VXLAN tunnel to a kernel prior the change.
Fixes: 3ee64f3 ("vxlan: Call udp_sock_create")
Cc: Tom Herbert <therbert@google.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Acked-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The UDP checksum calculation for VXLAN tunnels is currently using the
socket addresses instead of the actual packet source and destination
addresses. As a result the checksum calculated is incorrect in some
cases.
Also uh->check was being set twice, first it was set to 0, and then it is
set again in udp6_set_csum. This change removes the redundant assignment
to 0.
Fixes: acbf74a7 ("vxlan: Refactor vxlan driver to make use of the common UDP tunnel functions.")
Cc: Andy Zhou <azhou@nicira.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
SOF_TIMESTAMPING_OPT_ID puts the id in ee_data, not ee_info.
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The xpad wireless endpoint is not a bulk endpoint on my devices, but
rather an interrupt one, so the USB core complains when it is submitted.
I'm guessing that the author really did mean that this should be an
interrupt urb, but as there are a zillion different xpad devices out
there, let's cover out bases and handle both bulk and interrupt
endpoints just as easily.
Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Only try to parse data as coming from trackpoint if firmware told us that
trackpoint is present.
Fixes commit caeb0d37fa
Reported-and-tested-by: Marcus Overhagen <marcus.overhagen@gmail.com>
Reported-and-tested-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This wireless mouse receiver needs a reset-resume quirk to properly come
out of reset.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
sock will be returned.
the fix is to "continue" the searching, if no matching, return NULL.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Jane Zhou <a17711@motorola.com>
Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af_packet produces lots of these:
net/packet/af_packet.c:384:39: warning: incorrect type in return expression (different modifiers)
net/packet/af_packet.c:384:39: expected struct page [pure] *
net/packet/af_packet.c:384:39: got struct page *
this seems to be because sparse does not realize that _pure
refers to function, not the returned pointer.
Tweak code slightly to avoid the warning.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
xenbus is left in offline mode but netback_probe() reports success.
The patch implements propagation of error code for backend_create_xenvif().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When using GRE redirection in WCCP, it sets the wrong skb->protocol,
that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.
Fixes: c12b395a46 ("gre: Support GRE over IPv6")
Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Yuri Chislov <yuri.chislov@gmail.com>
Tested-by: Yuri Chislov <yuri.chislov@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure that the firmware will know this command before
sending it. This avoids a firmware crash.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUcjt3AAoJEC0Llv5uNjIBfFwP/1c23M0ntEgWBlhSbVEmwQrN
G5JunJzHQ0BCSysWTQkR8AXjthsxyjRSuv5KoYKUDgDMuolN9fIlDwjZdhX5ed4F
RIHZjY7i+QB05UWBdCi5x/h/EYc57+TulANmAMgUHj0xCwOTmjZoVPBgnAOdqq/f
0Vutf1MI09Pz7o4b07/SPihzpbgOLsHgabVxEoEaG0DD4k8RLtKi1xdc7HylrykG
b0+IgtfXigji/vs2+Krvc4nSnlg+RTVeSJtgVZb2NHPx85rEOnK5+Q2ZSooAIJuK
wW+FiTfje/LWn06HrsrjnzIfKrO6sy4axJX6BWqHXOTCgeKlG9SRgh/D3EdeT5tq
s15COT5YBkBWUUB4l8UaMak85XzMntrhUA/GOQXIkHiOaOuj3C3Y+i6ZBXaEsnxa
w5jrw/Y2ZoGAaJfsWAg5wOCBMzlcWpvF7y9yMuSUrkmhZ53X9Ehr9FwGUls+5iTo
rv2lVAm6becBihQe0oxPvYzHgpofc+8/CLJHJ+Q4TFHLsUPnRfXTBwTK321d8Fya
onKOstTxSn0/JJ6ftK2YKeEpcwiZeIQ8ppsXVork/3ICUcec5DRc+gycpZLAtHzB
qeg9uMwG3eEL+3l1az6ZwjzAth7ZBbBwuB4wNFhYnVyrIhtBy/HClS6aULUbdvKC
C6Ep3dLhQ3xIkf6Jz5TD
=Rtbg
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-for-john-2014-11-23' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
Emmanuel Grumbach <egrumbach@gmail.com> says:
"Not all the firmware know how to handle the HOT_SPOT_CMD.
Make sure that the firmware will know this command before
sending it. This avoids a firmware crash."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During a GPU reset we need to get pending page flip cleared out
since the ring contents are gone and flip will never complete
on its own. This used to work until the mmio vs. CS flip race
detection came about. That piece of code is looking for a
specific surface address in the SURFLIVE register, but as
a flip to that address may never happen the check may never
pass. So we should just skip the SURFLIVE and flip counter
checks when the GPU gets reset.
intel_display_handle_reset() tries to effectively complete
the flip anyway by calling .update_primary_plane(). But that
may not satisfy the conditions of the mmio vs. CS race
detection since there's no guarantee that a modeset didn't
sneak in between the GPU reset and intel_display_handle_reset().
Such a modeset will not wait for pending flips due to the ongoing GPU
reset, and then the primary plane updates performed by
intel_display_handle_reset() will already use the new surface
address, and thus the surface address the flip is waiting for
might never appear in SURFLIVE. The result is that the flip
will never complete and attempts to perform further page flips
will fail with -EBUSY.
During the GPU reset intel_crtc_has_pending_flip() will return
false regardless, so the deadlock with a modeset vs. the error
work acquiring crtc->mutex was avoided. And the reset_counter
check in intel_crtc_has_pending_flip() actually made this bug
even less severe since it allowed normal modesets to go through
even though there's a pending flip.
This is a regression introduced by me here:
commit 75f7f3ec60
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Apr 15 21:41:34 2014 +0300
drm/i915: Fix mmio vs. CS flip race on ILK+
Testcase: igt/kms_flip/flip-vs-panning-vs-hang
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In 'early_parse_mem' the data type used for the start
and size of a memory region specified on the command line
is incorrect. If 64-bit addressing is used, the value
gets truncated.
Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8456/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
microMIPS and SmartMIPS can't be used together. This fixes the
following build problem:
Warning: the 32-bit microMIPS architecture does not support the `smartmips' extension
arch/mips/kernel/entry.S:90: Error: unrecognized opcode `mtlhx $24'
[...]
arch/mips/kernel/entry.S:109: Error: unrecognized opcode `mtlhx $24'
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7421/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commits a951440971 ("MIPS: Netlogic: Support for XLP3XX on-chip SATA")
and fedfcb1137 ("MIPS: Netlogic: XLP9XX on-chip SATA support") added
ahci-init and ahci-init-xlp2 as objects to build when CONFIG_SATA_AHCI
is enabled.
If CONFIG_SATA_AHCI is made modular, these two files will also get built
as modules (obj-m), which will result in the following linking failure:
ERROR: "nlm_set_pic_extra_ack" [arch/mips/netlogic/xlp/ahci-init.ko]
undefined!
ERROR: "nlm_io_base" [arch/mips/netlogic/xlp/ahci-init.ko] undefined!
ERROR: "nlm_nodes" [arch/mips/netlogic/xlp/ahci-init-xlp2.ko] undefined!
ERROR: "nlm_set_pic_extra_ack"
[arch/mips/netlogic/xlp/ahci-init-xlp2.ko] undefined!
ERROR: "xlp_socdev_to_node" [arch/mips/netlogic/xlp/ahci-init-xlp2.ko]
undefined!
ERROR: "nlm_io_base" [arch/mips/netlogic/xlp/ahci-init-xlp2.ko]
undefined!
Just check whether CONFIG_SATA_AHCI is defined for this build, and if
that is the case, add these objects to the list of built-in object
files.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: ganesanr@broadcom.com
Cc: jchandra@broadcom.com
Patchwork: https://patchwork.linux-mips.org/patch/7855/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 1004165f34 ("MIPS: Netlogic: USB support for XLP") and then
commit 9eac3591e7 ("MIPS: Netlogic: Add support for USB on XLP2xx")
added usb-init and usb-init-xlp2 as objects to build when CONFIG_USB is
enabled.
If CONFIG_USB is made modular, these two files will also get built as
modules (obj-m), which will result in the following linking failure:
ERROR: "nlm_io_base" [arch/mips/netlogic/xlp/usb-init.ko] undefined!
ERROR: "nlm_nodes" [arch/mips/netlogic/xlp/usb-init-xlp2.ko] undefined!
ERROR: "nlm_set_pic_extra_ack" [arch/mips/netlogic/xlp/usb-init-xlp2.ko]
undefined!
ERROR: "xlp_socdev_to_node" [arch/mips/netlogic/xlp/usb-init-xlp2.ko]
undefined!
ERROR: "nlm_io_base" [arch/mips/netlogic/xlp/usb-init-xlp2.ko]
undefined!
Just check whether CONFIG_USB is defined for this build, and if that is
the case, add these objects to the list of built-in object files.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: ganesanr@broadcom.com
Cc: jchandra@broadcom.com
Patchwork: https://patchwork.linux-mips.org/patch/7854/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
If SERIAL_8250 is compiled as a module, the platform specific setup
for Loongson will be a module too, and it will not work very well.
At least on Loongson 3 it will trigger a build failure,
since loongson_sysconf is not exported to modules.
Fix by making the platform specific serial code always built-in.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reported-by: Ralf Baechle <ralf@linux-mips.org>
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/8533/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
