aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-08-06Merge branch 'linux-linaro-lsk-v4.9' into linux-linaro-lsk-v4.9-rtlinux-linux-linaro-lsk-v4.9-testMark Brown
2018-08-06Merge tag 'v4.9.115-rt93' into linux-linaro-lsk-v4.9-rtMark Brown
Linux 4.9.115-rt93
2018-08-03Linux 4.9.115-rt93Julia Cartwright
2018-08-03Merge tag 'v4.9.115' into v4.9-rtJulia Cartwright
This is the 4.9.115 stable release
2018-08-03Linux 4.9.114-rt92Julia Cartwright
2018-08-03Merge tag 'v4.9.114' into v4.9-rtJulia Cartwright
This is the 4.9.114 stable release
2018-08-03Linux 4.9.113-rt91Julia Cartwright
2018-08-03Merge tag 'v4.9.113' into v4.9-rtJulia Cartwright
This is the 4.9.113 stable release
2018-08-03Linux 4.9.112-rt90Julia Cartwright
2018-08-03Merge tag 'v4.9.112' into v4.9-rtJulia Cartwright
This is the 4.9.112 stable release
2018-08-03Linux 4.9.111-rt89Julia Cartwright
2018-08-03Merge tag 'v4.9.111' into v4.9-rtJulia Cartwright
This is the 4.9.111 stable release
2018-08-03Linux 4.9.110-rt88Julia Cartwright
2018-08-03Merge tag 'v4.9.110' into v4.9-rtJulia Cartwright
This is the 4.9.110 stable release
2018-08-03Linux 4.9.109-rt87Julia Cartwright
2018-08-03Merge tag 'v4.9.109' into v4.9-rtJulia Cartwright
This is the 4.9.109 stable release
2018-08-03Linux 4.9.108-rt86Julia Cartwright
2018-08-03Merge tag 'v4.9.108' into v4.9-rtJulia Cartwright
This is the 4.9.108 stable release
2018-08-03Linux 4.9.107-rt85Julia Cartwright
2018-08-03Merge tag 'v4.9.107' into v4.9-rtJulia Cartwright
This is the 4.9.107 stable release
2018-08-03Linux 4.9.106-rt84Julia Cartwright
2018-08-03Merge tag 'v4.9.106' into v4.9-rtJulia Cartwright
This is the 4.9.106 stable release
2018-08-03Linux 4.9.105-rt83Julia Cartwright
2018-08-03Merge tag 'v4.9.105' into v4.9-rtJulia Cartwright
This is the 4.9.105 stable release
2018-08-03Linux 4.9.104-rt82Julia Cartwright
2018-08-03Merge tag 'v4.9.104' into v4.9-rtJulia Cartwright
This is the 4.9.104 stable release
2018-08-03Linux 4.9.103-rt81Julia Cartwright
2018-08-03Merge tag 'v4.9.103' into v4.9-rtJulia Cartwright
This is the 4.9.103 stable release
2018-08-03Linux 4.9.102-rt80Julia Cartwright
2018-08-03Merge tag 'v4.9.102' into v4.9-rtJulia Cartwright
This is the 4.9.102 stable release
2018-08-03Linux 4.9.101-rt79Julia Cartwright
2018-08-03Merge tag 'v4.9.101' into v4.9-rtJulia Cartwright
This is the 4.9.101 stable release
2018-08-03Linux 4.9.100-rt78Julia Cartwright
2018-08-03Merge tag 'v4.9.100' into v4.9-rtJulia Cartwright
This is the 4.9.100 stable release
2018-08-03Linux 4.9.99-rt77Julia Cartwright
2018-08-03Merge tag 'v4.9.99' into v4.9-rtJulia Cartwright
This is the 4.9.99 stable release
2018-08-03Merge tag 'v4.9.117' into linux-linaro-lsk-v4.9Mark Brown
This is the 4.9.117 stable release
2018-08-03Linux 4.9.117Greg Kroah-Hartman
2018-08-03net: dsa: qca8k: Allow overwriting CPU port settingMichal Vokáč
commit 9bb2289f90e671bdb78e306974187424ac19ff8e upstream. Implement adjust_link function that allows to overwrite default CPU port setting using fixed-link device tree subnode. Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03net: dsa: qca8k: Add QCA8334 binding documentationMichal Vokáč
commit 218bbea11a777c156eb7bcbdc72867b32ae10985 upstream. Add support for the four-port variant of the Qualcomm QCA833x switch. The CPU port default link settings can be reconfigured using a fixed-link sub-node. Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03net: dsa: qca8k: Enable RXMAC when bringing up a portMichal Vokáč
commit eee1fe64765c562d8bcaf95e5631a8ea2f760f34 upstream. When a port is brought up/down do not enable/disable only the TXMAC but the RXMAC as well. This is essential for the CPU port to work. Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family") Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03net: dsa: qca8k: Force CPU port to its highest bandwidthMichal Vokáč
commit 79a4ed4f0f93fc65e48a0fc5247ffa5645f7b0cc upstream. By default autonegotiation is enabled to configure MAC on all ports. For the CPU port autonegotiation can not be used so we need to set some sensible defaults manually. This patch forces the default setting of the CPU port to 1000Mbps/full duplex which is the chip maximum capability. Also correct size of the bit field used to configure link speed. Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family") Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03RDMA/uverbs: Protect from attempts to create flows on unsupported QPLeon Romanovsky
commit 940efcc8889f0d15567eb07fc9fd69b06e366aa5 upstream. Flows can be created on UD and RAW_PACKET QP types. Attempts to provide other QP types as an input causes to various unpredictable failures. The reason is that in order to support all various types (e.g. XRC), we are supposed to use real_qp handle and not qp handle and expect to driver/FW to fail such (XRC) flows. The simpler and safer variant is to ban all QP types except UD and RAW_PACKET, instead of relying on driver/FW. Cc: <stable@vger.kernel.org> # 3.11 Fixes: 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow through uverbs") Cc: syzkaller <syzkaller@googlegroups.com> Reported-by: Noa Osherovich <noaos@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03ext4: check for allocation block validity with block group lockedTheodore Ts'o
commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef upstream. With commit 044e6e3d74a3: "ext4: don't update checksum of new initialized bitmaps" the buffer valid bit will get set without actually setting up the checksum for the allocation bitmap, since the checksum will get calculated once we actually allocate an inode or block. If we are doing this, then we need to (re-)check the verified bit after we take the block group lock. Otherwise, we could race with another process reading and verifying the bitmap, which would then complain about the checksum being invalid. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03ext4: fix inline data updates with checksums enabledTheodore Ts'o
commit 362eca70b53389bddf3143fe20f53dcce2cfdf61 upstream. The inline data code was updating the raw inode directly; this is problematic since if metadata checksums are enabled, ext4_mark_inode_dirty() must be called to update the inode's checksum. In addition, the jbd2 layer requires that get_write_access() be called before the metadata buffer is modified. Fix both of these problems. https://bugzilla.kernel.org/show_bug.cgi?id=200443 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03squashfs: be more careful about metadata corruptionLinus Torvalds
commit 01cfb7937a9af2abb1136c7e89fbf3fd92952956 upstream. Anatoly Trosinenko reports that a corrupted squashfs image can cause a kernel oops. It turns out that squashfs can end up being confused about negative fragment lengths. The regular squashfs_read_data() does check for negative lengths, but squashfs_read_metadata() did not, and the fragment size code just blindly trusted the on-disk value. Fix both the fragment parsing and the metadata reading code. Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Phillip Lougher <phillip@squashfs.org.uk> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03random: mix rdrand with entropy sent in from userspaceTheodore Ts'o
commit 81e69df38e2911b642ec121dec319fad2a4782f3 upstream. Fedora has integrated the jitter entropy daemon to work around slow boot problems, especially on VM's that don't support virtio-rng: https://bugzilla.redhat.com/show_bug.cgi?id=1572944 It's understandable why they did this, but the Jitter entropy daemon works fundamentally on the principle: "the CPU microarchitecture is **so** complicated and we can't figure it out, so it *must* be random". Yes, it uses statistical tests to "prove" it is secure, but AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with flying colors. So if RDRAND is available, mix it into entropy submitted from userspace. It can't hurt, and if you believe the NSA has backdoored RDRAND, then they probably have enough details about the Intel microarchitecture that they can reverse engineer how the Jitter entropy daemon affects the microarchitecture, and attack its output stream. And if RDRAND is in fact an honest DRNG, it will immeasurably improve on what the Jitter entropy daemon might produce. This also provides some protection against someone who is able to read or set the entropy seed file. Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03drm: Add DP PSR2 sink enable bitJosé Roberto de Souza
[ Upstream commit 4f212e40468650e220c1770876c7f25b8e0c1ff5 ] To comply with eDP1.4a this bit should be set when enabling PSR2. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-1-jose.souza@intel.com Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03media: si470x: fix __be16 annotationsMauro Carvalho Chehab
[ Upstream commit 90db5c829692a0a7845e977e45719b4699216bd4 ] The annotations there are wrong as warned: drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: warning: incorrect type in assignment (different base types) drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: expected unsigned short [unsigned] [short] <noident> drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: got restricted __be16 [usertype] <noident> drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03scsi: megaraid_sas: Increase timeout by 1 sec for non-RAID fastpath IOsShivasharan S
[ Upstream commit 3239b8cd28fd849a2023483257d35d68c5876c74 ] Hardware could time out Fastpath IOs one second earlier than the timeout provided by the host. For non-RAID devices, driver provides timeout value based on OS provided timeout value. Under certain scenarios, if the OS provides a timeout value of 1 second, due to above behavior hardware will timeout immediately. Increase timeout value for non-RAID fastpath IOs by 1 second. Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>