The new MACsec driver uses the AES crypto algorithm, but can be configured
even if CONFIG_CRYPTO is disabled, leading to a build error:
warning: (MAC80211 && MACSEC) selects CRYPTO_GCM which has unmet direct dependencies (CRYPTO)
warning: (BT && CEPH_LIB && INET && MAC802154 && MAC80211 && BLK_DEV_RBD && MACSEC && AIRO_CS && LIBIPW && HOSTAP && USB_WUSB && RTLLIB_CRYPTO_CCMP && FS_ENCRYPTION && EXT4_ENCRYPTION && CEPH_FS && BIG_KEYS && ENCRYPTED_KEYS) selects CRYPTO_AES which has unmet direct dependencies (CRYPTO)
crypto/built-in.o: In function `gcm_enc_copy_hash':
aes_generic.c:(.text+0x2b8): undefined reference to `crypto_xor'
aes_generic.c:(.text+0x2dc): undefined reference to `scatterwalk_map_and_copy'
This adds an explicit 'select CRYPTO' statement the way that other
drivers handle it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: c09440f7dc ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 9567366fef ("dm cache metadata: fix READ_LOCK macros and
cleanup WRITE_LOCK macros") uses down_write() instead of down_read() in
cmd_read_lock(), yet up_read() is used to release the lock in
READ_UNLOCK(). Fix it.
Fixes: 9567366fef ("dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Samy <f.fallen45@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
The trigger delay algorithm that converts from microseconds to
the register value looks incorrect. According to most of the PMIC
documentation, the equation is
delay (Seconds) = (1 / 1024) * 2 ^ (x + 4)
except for one case where the documentation looks to have a
formatting issue and the equation looks like
delay (Seconds) = (1 / 1024) * 2 x + 4
Most likely this driver was written with the improper
documentation to begin with. According to the downstream sources
the valid delays are from 2 seconds to 1/64 second, and the
latter equation just doesn't make sense for that. Let's fix the
algorithm and the range check to match the documentation and the
downstream sources.
Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: 92d57a73e4 ("input: Add support for Qualcomm PMIC8XXX power key")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We shouldn't assign the parent device of the input_dev to be the
parent MFD device, because this will be used for devres which causes
input_unregister_device to run after the haptics device has been
removed, since it is itself a child of the MFD device. The default
of using the haptics device itself as the parent is correct.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We've got a regression report that the recording on Mac with a cirrus
codec doesn't work any longer. This turned out to be the missing
power up to D0 by power_save_node enablement.
After analyzing the traces, we found out that the culprit is that the
codec advertises the "actual" power state of a few nodes to be D0
while the "target" power state is D3. This inconsistency is usually
OK, as it implies the power transition. But in the case of cirrus
codec, this seems to be stuck to D3 while it's not actually D0.
This patch addresses the issue by checking the power state difference
more strictly. It sends the power-state change verb unless both the
target and the actual power states show the given value.
We may introduce yet another flag indicating the possible broken
hardware power state, but it's anyway safer to set the proper power
state even in a transition (at least it's harmless as long as the
target state is same). So this simpler change was applied now.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Here are some small char/misc driver fixes for 4.6-rc4. Full details
are in the shortlog, nothing major here.
These have all been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlcS4DQACgkQMUfUDdst+ylBIwCgtag4UtH2i+NwFiErDmmnokSz
h5oAn1488h1FTiXolyA9MnmRkWlf0ZPI
=aYD7
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc fixes from Greg KH:
"Here are some small char/misc driver fixes for 4.6-rc4. Full details
are in the shortlog, nothing major here.
These have all been in linux-next for a while with no reported issues"
* tag 'char-misc-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
lkdtm: do not leak free page on kmalloc failure
lkdtm: fix memory leak of base
lkdtm: fix memory leak of val
extcon: palmas: Drop stray IRQF_EARLY_RESUME flag
Here are 3 small fixes 4.6-rc4. Two fix up some lz4 issues with big
endian systems, and the remaining one resolves a minor debugfs issue
that was reported.
All have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlcS3ucACgkQMUfUDdst+ynw1QCbBGgbY7Xt08whNFcAP81z1Q5X
fmsAn1fyrhfsxe+JnybzswsTOjFw99Xd
=YX6h
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull misc fixes from Greg KH:
"Here are three small fixes for 4.6-rc4.
Two fix up some lz4 issues with big endian systems, and the remaining
one resolves a minor debugfs issue that was reported.
All have been in linux-next with no reported issues"
* tag 'driver-core-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
lib: lz4: cleanup unaligned access efficiency detection
lib: lz4: fixed zram with lz4 on big endian machines
debugfs: Make automount point inodes permanently empty
Here are some small USB fixes for 4.6-rc4.
Mostly xhci fixes for reported issues, a UAS bug that has hit a number
of people, including stable tree users, and a few other minor things.
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlcS3ngACgkQMUfUDdst+ykPlgCeJ2UJu7dYz3ICVnxQ4zLkNG6A
yI0AoKa37VYqNkqRadj97g9E5S6KcsXi
=KmX3
-----END PGP SIGNATURE-----
Merge tag 'usb-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB driver fixes from Greg KH:
"Here are some small USB fixes for 4.6-rc4.
Mostly xhci fixes for reported issues, a UAS bug that has hit a number
of people, including stable tree users, and a few other minor things.
All have been in linux-next for a while with no reported issues"
* tag 'usb-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: hcd: out of bounds access in for_each_companion
USB: uas: Add a new NO_REPORT_LUNS quirk
USB: uas: Limit qdepth at the scsi-host level
doc: usb: Fix typo in gadget_multi documentation
usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value
xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers
usb: xhci: fix wild pointers in xhci_mem_cleanup
usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys
usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT
xhci: resume USB 3 roothub first
usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host
cdc-acm: fix crash if flushed with nothing buffered
On 64bit kernels, device stats are 64bit wide, not 32bit.
Fixes: 1c1008c793 ("net: bcmgenet: add main driver file")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vivien Didelot says:
====================
net: dsa: mv88e6xxx: fix hardware cross-chip bridging
In order to accelerate cross-chip switching of frames with the hardware,
the DSA Tag ports, used to interconnect switch devices, must learn SA
and DA addresses, and share the same FDB with the user ports.
The two first patches restore address learning on DSA links. This fixes
hardware cross-chip bridging in a VLAN filtering enabled system, which
implements a bridge group as a 802.1Q VLAN and thus share an isolated
address database between DSA and user ports.
The third patch changes the distinct default databases used for each
port, to the same address database. This fixes the hardware cross-chip
bridging in a VLAN filtering disabled system, where a bridge group gets
implemented only as a port-based VLAN.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
For hardware cross-chip bridging to work, user ports *and* DSA ports
need to share a common address database, in order to switch a frame to
the correct interconnected device.
This is currently working for VLAN filtering aware systems, since Linux
will implement a bridge group as a 802.1Q VLAN, which has its own FDB,
including DSA and CPU links as members.
However when the system doesn't support VLAN filtering, Linux only
relies on the port-based VLAN to implement a bridge group.
To fix hardware cross-chip bridging for such systems, set the same
default address database 0 for user and DSA ports, instead of giving
them all a different default database.
Note that the bridging code prevents frames to egress between unbridged
ports, and flushes FDB entries of a port when changing its STP state.
Also note that the FID 0 is special and means "all" for ATU operations,
but it's OK since it is used as a default forwarding address database.
Fixes: 2db9ce1fd9 ("net: dsa: mv88e6xxx: assign default FDB to ports")
Fixes: 466dfa0770 ("net: dsa: mv88e6xxx: assign dynamic FDB to bridges")
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In multi-chip systems, DSA Tag ports must learn SA addresses in order to
correctly switch frames between interconnected chips.
This fixes cross-chip hardware bridging in a VLAN filtering aware
system, because a bridge group gets implemented as an hardware 802.1Q
VLAN and thus DSA and user ports share the same FDB.
Fixes: 4c7ea3c079 ("net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports")
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Locking a port generates an hardware interrupt when a new SA address is
received. This enables CPU directed learning, which is needed for 802.1X
MAC authentication.
To disable automatic learning on a port, the only configuration needed
is to set its Port Association Vector to all zero.
Clear PAV when SA learning should be disabled instead of locking a port.
Fixes: 4c7ea3c079 ("net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports")
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Two different threads with different rds sockets may be in
rds_recv_rcvbuf_delta() via receive path. If their ports
both map to the same word in the congestion map, then
using non-atomic ops to update it could cause the map to
be incorrect. Lets use atomics to avoid such an issue.
Full credit to Wengang <wen.gang.wang@oracle.com> for
finding the issue, analysing it and also pointing out
to offending code with spin lock based fix.
Reviewed-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dp->dp_ack_seq is used in big endian format. We need to do the
big endianness conversion when we assign a value in host format
to it.
Signed-off-by: Qing Huang <qing.huang@oracle.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Okay we some driver fixes piled up, so time to get them up.
This time we have some odd fixes in hsu, edma, omap and xilinx.
Usual fixes and nothing special
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXEnqKAAoJEHwUBw8lI4NH3ScP/RaxUP64cn4ttUM/G/13jWxs
xpCtb25fRB7DcpqZpsAV84+NOGSJgJNOGKzWtfzu9aerUGcFiePwsv0V23ocC6oK
OxLDHQdjR5WXXchTxMqugWzNb0NdaMXDA5hfM1CnStMj4ifZY5r9/l/0ndlrSgOf
A1rZhg4TlbM1G1xnMYeDPwXRoHDs7k3eHM1XC9y5B50IPqMCsDwX4SODHX2vMu0H
6MbcturjfNN3hjr/ciTCMRYcab5q3Sv7UP31KSLA8LGzNojntj3shy2jLU6olQdn
IT0nUA+K7eYk/4Q2HGIo9LhM33XLBuCSLKca2H6/xt8R6J0J6ASwbQqa1k4A1aSv
n/jeQzlvgkGZA0Spat5Qms24NjtSbEllPcMkkoXXQsZctk4Hm2PRAOxVDFdXPt3C
0DMXHPnVhkOvamXqZYsvy/bqqUKDrHQvxW5kqtpn6W+B7bx5PPmPFRHtFWcbatsY
5y+D+3n0RNZqtKQ80M/3pRqpDh6MtrdfO9kuakS0BqpZZEFzZ5F0c2MzO93K2+3e
lVzj1iwTXcYJTF/DTuPOKmu/g6BC3oqaLNXDlsUEODiczzZwcbEvDxa4Z1otzQn3
JJ0diVqQRAbIdvVSpSUPMwaqLn+s5r0Uz9tLRNdARNI22a6YgnOK3MEyq+9+OMxl
rEA4ntRPxD2YzN7KfRY1
=bSYQ
-----END PGP SIGNATURE-----
Merge tag 'dmaengine-fix-4.6-rc4' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fixes from Vinod Koul:
"This time we have some odd fixes in hsu, edma, omap and xilinx.
Usual fixes and nothing special"
* tag 'dmaengine-fix-4.6-rc4' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: dw: fix master selection
dmaengine: edma: special case slot limit workaround
dmaengine: edma: Remove dynamic TPTC power management feature
dmaengine: vdma: don't crash when bad channel is requested
dmaengine: omap-dma: Do not suppress interrupts for memcpy
dmaengine: omap-dma: Fix polled channel completion detection and handling
dmaengine: hsu: correct use of channel status register
dmaengine: hsu: correct residue calculation of active descriptor
dmaengine: hsu: set HSU_CH_MTSR to memory width
Pull locking fixlet from Ingo Molnar:
"Fixes a build warning on certain Kconfig combinations"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/lockdep: Fix print_collision() unused warning
Generation2 instances don't support reporting the NMI status on port 0x61,
read from there returns 'ff' and we end up reporting nonsensical PCI
error (as there is no PCI bus in these instances) on all NMIs:
NMI: PCI system error (SERR) for reason ff on CPU 0.
Dazed and confused, but trying to continue
Fix the issue by overriding x86_platform.get_nmi_reason. Use 'booted on
EFI' flag to detect Gen2 instances.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Cathy Avery <cavery@redhat.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: devel@linuxdriverproject.org
Link: http://lkml.kernel.org/r/1460728232-31433-1-git-send-email-vkuznets@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There are several cases in compiled C code where a function may not
return at the end, and may instead fall through to the next function.
That may indicate a bug in the code, or a gcc bug, or even an objtool
bug. But in each case, objtool reports an unhelpful warning, something
like:
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_fc_host_stats()+0x0: duplicate frame pointer save
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_fc_host_stats()+0x0: frame pointer state mismatch
Detect this situation and print a more useful error message:
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_host_fabric_name() falls through to next function qla2x00_get_starget_node_name()
Also add some information about this warning and its potential causes to
the documentation.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/caa4ec6c687931db805e692d4e4bf06cd87d33e6.1460729697.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When __vlan_insert_tag() fails from skb_vlan_push() path due to the
skb_cow_head(), we need to undo the __skb_push() in the error path
as well that was done earlier to move skb->data pointer to mac header.
Moreover, I noticed that when in the non-error path the __skb_pull()
is done and the original offset to mac header was non-zero, we fixup
from a wrong skb->data offset in the checksum complete processing.
So the skb_postpush_rcsum() really needs to be done before __skb_pull()
where skb->data still points to the mac header start and thus operates
under the same conditions as in __vlan_insert_tag().
Fixes: 93515d53b1 ("net: move vlan pop/push functions into common code")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull block fixes from Jens Axboe:
"A few fixes for the current series. This contains:
- Two fixes for NVMe:
One fixes a reset race that can be triggered by repeated
insert/removal of the module.
The other fixes an issue on some platforms, where we get probe
timeouts since legacy interrupts isn't working. This used not to
be a problem since we had the worker thread poll for completions,
but since that was killed off, it means those poor souls can't
successfully probe their NVMe device. Use a proper IRQ check and
probe (msi-x -> msi ->legacy), like most other drivers to work
around this. Both from Keith.
- A loop corruption issue with offset in iters, from Ming Lei.
- A fix for not having the partition stat per cpu ref count
initialized before sending out the KOBJ_ADD, which could cause user
space to access the counter prior to initialization. Also from
Ming Lei.
- A fix for using the wrong congestion state, from Kaixu Xia"
* 'for-linus' of git://git.kernel.dk/linux-block:
block: loop: fix filesystem corruption in case of aio/dio
NVMe: Always use MSI/MSI-x interrupts
NVMe: Fix reset/remove race
writeback: fix the wrong congested state variable definition
block: partition: initialize percpuref before sending out KOBJ_ADD
Pull libnvdimm fixes from Ross Zwisler:
"Two fixes:
- Fix memcpy_from_pmem() to fallback to memcpy() for architectures
where CONFIG_ARCH_HAS_PMEM_API=n.
- Add a comment explaining why we write data twice when clearing
poison in pmem_do_bvec().
This has passed a boot test on an X86_32 config, which was the
architecture where issue #1 above was first noticed"
Dan Williams adds:
"We're giving this multi-maintainer setup a shot, so expect libnvdimm
pull requests from either Ross or I going forward"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
libnvdimm, pmem: clarify the write+clear_poison+write flow
pmem: fix BUG() error in pmem.h:48 on X86_32
In the v4.4 cycle, we relaxed the requirement for assigning mtd->owner, but we
didn't remove this error case. It's hit only by drivers that are both:
(a) using nand_scan() directly and
(b) built as modules
We haven't seen explicit complaints about this (most use cases don't fit one or
both of the above), but we should definitely not be BUG()'ing here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXEWZUAAoJEFySrpd9RFgtuaYQAIjfmoefoDJuIw3QQE5tLNMc
xTj07f+V/Nzhats69zvjx4LNFF6R339IBFNq7WK+q7l7VbW6/XSa8XaQkgpO+wMI
Sqzkty4YIxQGucITVvauv82JW0K421XVUBAzeNt+4oT72RvMnXhOPka1LQXf3Ezh
vGb7ZGea7ZYuu060OQAGxJlrlDA5x7yhsvs3hpOT9hjx0jXr0JZXmohvFRqSiXqz
Rx60rmhpl37WJg46OX/LYRAF34StF8btDZsQVdpY75T9QtxD3vWvvlMHfJ4cQXRI
L3qUIGGj03tD0/4nf6/p+WMjxgctDqROVxWzLHOvTa+xIFR7iU8yra09fTbylOGL
C3I0B6kW05YJrY3TegL8EhNbotciC9SeCtbeRwbndyO1Jox88xGHovwWFN5++3Q+
4ahiP57cV/py1L2BgeYdPmHES6T4GLH/4y2MaMZr4hfGVxHbKN1/JkLp9cNqCSzZ
MtnEevbHYq4eN1rYULQCzLRxawhYjeY77cMYip6Ynu24UWUJmfdaroJncfmmBOhP
7NvWjtxpsjonrCVOdb4aq9UPTc3PxlyR4kZyzg7+Vx4eOByK8hFkfjckehJ64DCs
ac+r5d2LmaLqAMIvQt4ApwwzRzj4ST6CEWBEyKrvwwF4B4nHhkbf9Pf4IrzGmaao
W4dws70o9WUwGIv0Rw3D
=wxaC
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd
Pull MTD fix from Brian Norris:
"One MTD fix for v4.6-rc4:
In the v4.4 cycle, we relaxed the requirement for assigning
mtd->owner, but we didn't remove this error case. It's hit only
by drivers that are both:
(a) using nand_scan() directly
and
(b) built as modules
We haven't seen explicit complaints about this (most use cases don't
fit one or both of the above), but we should definitely not be
BUG()'ing here"
* tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd:
mtd: nand: Drop mtd.owner requirement in nand_scan
- Restore similar old behaviour when assigning mmcblk device indexes
MMC host:
- tegra: Disable UHS-I modes for Tegra124 to fix regression
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXELVaAAoJEP4mhCVzWIwpvCQP/i1P0tPTLKvHmuKMnCbrIVN/
GWbUNjcui4YnOBufJDFZ3QnHVWpnSDpa+dGmzsO0Vpi7OSRWmvgWwwqwspSZUcp/
2c//US3R7iiVQ2ww2Kf7IErmi2CqHxL+ItWtZO3MaabiC0fCPPtjBRnfbftTFBJ5
5zcHeXJTkBF8rXtaz6URwACvlGsPluvVutxLRsEoHDQU0rsTgysbzTr2fu+M7IDI
jE3Q0U5xdIlT8YqmsQTUwdWF12STlBJfHwsGxOSxZTOnLOiNwoSoDftXvA+qH27V
C/gJUP8Di6sgYKPY7zqdN9eF0DAnK6n4QSpyzFEG9U2zNvW6enXiv8RBWRhfGjVp
VW/1XE8DE//l+WCxEQhjiFcBDAJ8ahfcdbsp7Ngd5t8WJVydL0dGpHLolCWwABMl
YMuRaH2eJznxazn0CRrIxRO9OIISandj3G5COkOOaar+2YzIWUotrk+q+swyq2x/
5hgSyaxYm27J7RUTx31YtQxCZownrNvyQAwj3omoe2ffWTENJeAobkBiLrzbSuaL
2TxhRJig75vOcFN6cZI0dhHR47j6uYVYJ62aWi3OzwpGR5Wz7h4zkVN5GRmNYBdE
JB5neGiEeCDnvbZ5tGHR3+ZNnDjFthAK88NagqknZFlnm6VOIsj4dCa2gBvwc1xu
wOobQCSH7JuQqS7JHjuy
=nnxN
-----END PGP SIGNATURE-----
Merge tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc
Pull MMC fixes from Ulf Hansson:
"Here are a couple of mmc fixes intended for v4.6 rc4.
Regarding the fix for the regression about mmcblk device indexes. The
approach taken to solve the problem seems to be good enough. There
were some discussions around the solution, but it seems like people
were happy about it in the end.
MMC core:
- Restore similar old behaviour when assigning mmcblk device indexes
MMC host:
- tegra: Disable UHS-I modes for Tegra124 to fix regression"
* tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc:
mmc: tegra: Disable UHS-I modes for Tegra124
mmc: block: Use the mmc host device index as the mmcblk device index
Pull drm fixes from Dave Airlie:
"This contains fixes for exynos, amdgpu, radeon, i915 and qxl.
It also contains some fixes to the core drm edid parser.
qxl:
- fix for a cursor hotspot issue
radeon:
- some MST fixes that I've been running locally and make my monitor a
bit happier
exynos:
- fix some regressions and build fixes
amdgpu:
- a couple of small fixes
i915:
- two DP MST fixes and a couple of other regression fixes
Nothing too out of the ordinary or surprising at this point"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
drm/exynos: fix a warning message
drm/exynos: mic: fix an error code
drm/exynos: fimd: fix broken dp_clock control
drm/exynos: build fbdev code conditionally
drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
drm/exynos: fix error handling in exynos_drm_subdrv_open
drm/amd/amdgpu: fix irq domain remove for tonga ih
drm/i915: fix deadlock on lid open
drm/radeon: use helper for mst connector dpms.
drm/radeon/mst: port some MST setup code from DAL.
drm/amdgpu: add invisible pin size statistic
drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings
drm/i915: Exit cherryview_irq_handler() after one pass
drm/i915: Call intel_dp_mst_resume() before resuming displays
drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor
drm/edid: Fix EDID Established Timings I and II
drm/qxl: fix cursor position with non-zero hotspot
Pull parisc ftrace fixes from Helge Deller:
"This is (most likely) the last pull request for v4.6 for the parisc
architecture.
It fixes the FTRACE feature for parisc, which is horribly broken since
quite some time and doesn't even compile. This patch just fixes the
bare minimum (it actually removes more lines than it adds), so that
the function tracer works again on 32- and 64bit kernels.
I've queued up additional patches on top of this patch which e.g. add
the syscall tracer, but those have to wait for the merge window for
v4.7."
* 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Fix ftrace function tracer
The ACPI specification does not specify the state of data after a clear
poison operation. Potential future libnvdimm bus implementations for
other architectures also might not specify or disagree on the state of
data after clear poison. Clarify why we write twice.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Reported-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Chelsio adapters have two VPD structures stored in the VPD:
- offset 0x000: an abbreviated VPD, and
- offset 0x400: the complete VPD.
After 104daa71b3 ("PCI: Determine actual VPD size on first access"), the
PCI core computes the valid VPD size by parsing the VPD starting at offset
0x0. That size only includes the abbreviated VPD structure, so reads of
the complete VPD at 0x400 fail.
Explicitly set the VPD size with pci_set_vpd_size() so the driver can read
both VPD structures.
[bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and
return int (not ssize_t)]
Fixes: 104daa71b3 ("PCI: Determine actual VPD size on first access")
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
After 104daa71b3 ("PCI: Determine actual VPD size on first access"), the
PCI core computes the valid VPD size by parsing the VPD starting at offset
0x0. We don't attempt to read past that valid size because that causes
some devices to crash.
However, some devices do have data past that valid size. For example,
Chelsio adapters contain two VPD structures, and the driver needs both of
them.
Add pci_set_vpd_size(). If a driver knows it is safe to read past the end
of the VPD data structure at offset 0, it can use pci_set_vpd_size() to
allow access to as much data as it needs.
[bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and
return int (not ssize_t)]
Fixes: 104daa71b3 ("PCI: Determine actual VPD size on first access")
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Make sure that s390 appears to be a big endian machine by defining
this config option.
Without this s390 appears to be little endian as seen by e.g. the
recordmount script: "perl ./scripts/recordmcount.pl "s390" "little"
"64""
This has no practical impact within the script since the endian
variable is only evaluated for mips. However there are already a
couple of common code places which evaluate this config option. None
of them is relevant for s390 currently though.
To avoid any issues in the future (and fix the recordmcount oddity)
add the new config option.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
arch_spin_lock_wait_flags() checks if a spinlock is not held before
trying a compare and swap instruction. If the lock is unlocked it
tries the compare and swap instruction, however if a different cpu
grabbed the lock in the meantime the instruction will fail as
expected.
Subsequently the arch_spin_lock_wait_flags() incorrectly tries to
figure out if the cpu that holds the lock is running. However it is
using the wrong cpu number for this (-1) and then will also yield the
current cpu to the wrong cpu.
Fix this by adding a missing continue statement.
Fixes: 470ada6b1a ("s390/spinlock: refactor arch_spin_lock_wait[_flags]")
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
dcssblk_remove_store() holds the dcssblk_devices_sem semaphore while
calling device_unregister(), which in turn tries to acquire the kernfs
kn->dev_map rwsem for the device sysfs subtree. The same rwsem is also
acquired when using the per-device sysfs attributes in the device sub-tree,
and the attribute handlers then also acquire the dcssblk_devices_sem.
This can lead to a deadlock when removing a DCSS while concurrently
reading from / writing to one of its sysfs attributes. The following
lockdep warning hinted towards the issue (CPU0 = dcssblk_remove_store,
CPU1 = dcssblk_shared_store):
[ 76.496047] Possible unsafe locking scenario:
[ 76.496054] CPU0 CPU1
[ 76.496059] ---- ----
[ 76.496087] lock(&dcssblk_devices_sem);
[ 76.496090] lock(s_active#175);
[ 76.496106] lock(&dcssblk_devices_sem);
[ 76.496110] lock(s_active#175);
[ 76.496115]
*** DEADLOCK ***
Fix this by releasing the dcssblk_devices_sem semaphore, which only
protects internal DCSS data, before calling device_unregister().
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
If fan_get_status() fails then "s" is not initialized. Tweak the error
handling a bit to silence this warning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Presumably "pss_period" and "ioss_period" can't both be zero, but this
function is never called so we can't infer that using static analysis
alone.
Silence the warning by setting "ret" to zero.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
If acpi_evaluate_integer() fails then "lret" isn't initialized. I've
tweaked the error handling to avoid this issue.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Starting from commit e36f620428(block: split bios to max possible length),
block core starts to split bio in the middle of bvec.
Unfortunately loop dio/aio doesn't consider this situation, and
always treat 'iter.iov_offset' as zero. Then filesystem corruption
is observed.
This patch figures out the offset of the base bvevc via
'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
to iov iterator.
Fixes: e36f620428 (block: split bios to max possible length)
Cc: Keith Busch <keith.busch@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org (4.5)
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Prevent information from leaking to userspace by doing a memset to 0 of
the export state structure before setting the structure values and copying
it. This prevents un-initialized padding areas from being copied into the
export area.
Cc: <stable@vger.kernel.org> # 3.14.x-
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used
when check and complete other jobs. If the memory of first completed req
is freed, while still completing other jobs in the func, kernel will
crash since NULL pointer is assigned to RIP.
Cc: <stable@vger.kernel.org>
Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com>
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The output buffer length has to be at least as big as the key_size.
It is then updated to the actual output size by the implementation.
Cc: <stable@vger.kernel.org>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
GCC has a rare quirk, currently only seen in three driver functions in
the kernel, and only with certain obscure non-distro configs, which can
cause objtool to produce "unreachable instruction" false positive
warnings.
As part of an optimization, GCC makes a copy of an existing switch jump
table, modifies it, and then hard-codes the jump (albeit with an
indirect jump) to use a single entry in the table. The rest of the jump
table and some of its jump targets remain as dead code.
In such a case we can just crudely ignore all unreachable instruction
warnings for the entire object file. Ideally we would just ignore them
for the function, but that would require redesigning the code quite a
bit. And honestly that's just not worth doing: unreachable instruction
warnings are of questionable value anyway, and this is a very rare
issue.
kbuild reports:
https://lkml.kernel.org/r/201603231906.LWcVUpxm%25fengguang.wu@intel.comhttps://lkml.kernel.org/r/201603271114.K9i45biy%25fengguang.wu@intel.comhttps://lkml.kernel.org/r/201603291058.zuJ6ben1%25fengguang.wu@intel.com
GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70604
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/700fa029bbb0feff34f03ffc69d666a3c3b57a61.1460663532.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
ranging from 1 to MAX. This leads to a corner case where we try to request
the pin number = MAX and fails.
bit_pos value is being calculted using ffs. pin_num_from_lsb uses
bit_pos value. pins array is populated with:
pin + pin_num_from_lsb.
The above is 1 more than usual bit indices as bit_pos uses ffs to compute
first set bit. Hence the last of the pins array is populated with the MAX
value and not MAX - 1 which causes error when we call pin_request.
mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
Consequently val_pos and submask are correct.
Hence use __ffs which gives (ffs(x) - 1) as the first bit set.
fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 19e6e5e539 ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself. This can trigger the following
safeguard in the slab/slub allocator:
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
pr_emerg("gfp: %un", flags & GFP_SLAB_BUG_MASK);
BUG();
}
Fix this by filtering the flags that make the slab allocator unhappy.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The debounce time unit for gpio_chip.set_debounce is us but
mtk_gpio_set_debounce regard it as ms.
Fix this by correct debounce time array dbnc_arr so it can find correct
debounce setting. Debounce time for first debounce setting is 500us,
correct this as well.
While I'm at it, also change the debounce time array name to
"debounce_time" for readability.
Cc: stable@vger.kernel.org
Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
