summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* net/ipv6: re-do dad when interface has IFF_NOARP flag changeHangbin Liu2019-12-131-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 896585d48e8e9ba44cd1754fbce8537feffcc1a5 ] When we add a new IPv6 address, we should also join corresponding solicited-node multicast address, unless the interface has IFF_NOARP flag, as function addrconf_join_solict() did. But if we remove IFF_NOARP flag later, we do not do dad and add the mcast address. So we will drop corresponding neighbour discovery message that came from other nodes. A typical example is after creating a ipvlan with mode l3, setting up an ipv6 address and changing the mode to l2. Then we will not be able to ping this address as the interface doesn't join related solicited-node mcast address. Fix it by re-doing dad when interface changed IFF_NOARP flag. Then we will add corresponding mcast group and check if there is a duplicate address on the network. Reported-by: Jianlin Shi <jishi@redhat.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ravb: Clean up duplex handlingMagnus Damm2019-12-132-19/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 08b43857804dd0eca48f5c5a84885cf0079586e0 ] Since only full-duplex operation is supported by the hardware, remove duplex handling code and keep the register setting of ECMR.DM fixed at 1. This updates the driver implementation to follow the data sheet text "This bit should always be set to 1." Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iwlwifi: fix cfg structs for 22000 with different RF modulesLuca Coelho2019-12-133-4/+21
| | | | | | | | | | | | | | | | | | | [ Upstream commit b1bbc1a636505ebdd6336ff781e417123226d4f7 ] We have to choose different configuration and different firmwares depending on the external RF module that is installed. Since the external module is not represented in the PCI IDs, we need to change the configuration at runtime, after checking the RF ID of the module installed. We have a bit of a mess in the code that does this, because it applies cfg's according to the RF ID only, ignoring the integrated module that is in use. Fix that for some devices by adding correct configurations for them and not ignoring the integrated module's type when making the decision. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: cec: report Vendor ID after initializationHans Verkuil2019-12-131-0/+7
| | | | | | | | | | | | | [ Upstream commit 7f02ac77c768ba2bcdd0ce719c1fca0870ffe2fb ] The CEC specification requires that the Vendor ID (if any) is reported after a logical address was claimed. This was never done, so add support for this. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: pulse8-cec: return 0 when invalidating the logical addressHans Verkuil2019-12-131-1/+1
| | | | | | | | | | | | | [ Upstream commit 2e84eb9affac43eeaf834992888b72426a8cd442 ] Return 0 when invalidating the logical address. The cec core produces a warning for drivers that do this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reported-by: Torbjorn Jansson <torbjorn.jansson@mbox200.swipnet.se> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: coda: fix memory corruption in case more than 32 instances are openedPhilipp Zabel2019-12-132-17/+12
| | | | | | | | | | | | | | | [ Upstream commit 649cfc2bdfeeb98ff7d8fdff0af3f8fb9c8da50f ] The ffz() return value is undefined if the instance mask does not contain any zeros. If it returned 32, the following set_bit would corrupt the debugfs_root pointer. Switch to IDA for context index allocation. This also removes the artificial 32 instance limit for all except CodaDx6. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: exynos: Use Samsung SoC specific compatible for DWC2 moduleMarek Szyprowski2019-12-131-1/+1
| | | | | | | | | | | | [ Upstream commit 6035cbcceb069f87296b3cd0bc4736ad5618bf47 ] DWC2 hardware module integrated in Samsung SoCs requires some quirks to operate properly, so use Samsung SoC specific compatible to notify driver to apply respective fixes. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: dt-binding: abx80x: fix resistance scaleBaruch Siach2019-12-131-1/+1
| | | | | | | | | | [ Upstream commit 73852e56827f5cb5db9d6e8dd8191fc2f2e8f424 ] The abracon,tc-resistor property value is in kOhm. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: max8997: Fix the returned value in case of error in ↵Christophe JAILLET2019-12-131-1/+1
| | | | | | | | | | | | | | 'max8997_rtc_read_alarm()' [ Upstream commit 41ef3878203cd9218d92eaa07df4b85a2cb128fb ] In case of error, we return 0. This is spurious and not consistent with the other functions of the driver. Propagate the error code instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* nds32: Fix the items of hwcap_str ordering issue.Nylon Chen2019-12-131-1/+2
| | | | | | | | | | | | [ Upstream commit a5234068e6dc18ae5300d678fbf3e129d9b93f78 ] The hwcap_str should be set in a correct order according to HWCAP_xx. We also add the missing "fpu_dp" to it. Signed-off-by: Nylon Chen <nylon7@andestech.com> Acked-by: Greentime Hu <greentime@andestech.com> Signed-off-by: Greentime Hu <greentime@andestech.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* math-emu/soft-fp.h: (_FP_ROUND_ZERO) cast 0 to void to fix warningVincent Chen2019-12-131-1/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 83312f1b7ae205dca647bf52bbe2d51303cdedfb ] _FP_ROUND_ZERO is defined as 0 and used as a statemente in macro _FP_ROUND. This generates "error: statement with no effect [-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to fix it. This modification is quoted from glibc 'commit <In libc/:> (8ed1e7d5894000c155acbd06f)' Signed-off-by: Vincent Chen <vincentc@andestech.com> Acked-by: Greentime Hu <greentime@andestech.com> Signed-off-by: Greentime Hu <greentime@andestech.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* net/smc: use after free fix in smc_wr_tx_put_slot()Ursula Braun2019-12-131-1/+3
| | | | | | | | | | | | | [ Upstream commit e438bae43c1e08e688c09c410407b59fc1c173b4 ] In smc_wr_tx_put_slot() field pend->idx is used after being cleared. That means always idx 0 is cleared in the wr_tx_mask. This results in a broken administration of available WR send payload buffers. Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: OCTEON: octeon-platform: fix typingAaro Koskinen2019-12-131-1/+1
| | | | | | | | | | | | | | [ Upstream commit 2cf1c8933dd93088cfb5f8f58b3bb9bbdf1781b9 ] Use correct type for fdt_property nameoff field. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21204/ Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* iw_cxgb4: only reconnect with MPAv1 if the peer abortsSteve Wise2019-12-131-1/+2
| | | | | | | | | | | | | | [ Upstream commit 9828ca654b52848e7eb7dcc9b0994ff130dd4546 ] Only retry connection setup with MPAv1 if the peer actually aborted the connection upon receiving the MPAv2 start message. This avoids retrying with MPAv1 in the case where the connection was aborted due to retransmit timeouts. Fixes: d2fe99e86bb2 ("RDMA/cxgb4: Add support for MPAv2 Enhanced RDMA Negotiation") Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iomap: readpages doesn't zero page tail beyond EOFDave Chinner2019-12-131-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8c110d43c6bca4b24dd13272a9d4e0ba6f2ec957 ] When we read the EOF page of the file via readpages, we need to zero the region beyond EOF that we either do not read or should not contain data so that mmap does not expose stale data to user applications. However, iomap_adjust_read_range() fails to detect EOF correctly, and so fsx on 1k block size filesystems fails very quickly with mapreads exposing data beyond EOF. There are two problems here. Firstly, when calculating the end block of the EOF byte, we have to round the size by one to avoid a block aligned EOF from reporting a block too large. i.e. a size of 1024 bytes is 1 block, which in index terms is block 0. Therefore we have to calculate the end block from (isize - 1), not isize. The second bug is determining if the current page spans EOF, and so whether we need split it into two half, one for the IO, and the other for zeroing. Unfortunately, the code that checks whether we should split the block doesn't actually check if we span EOF, it just checks if the read spans the /offset in the page/ that EOF sits on. So it splits every read into two if EOF is not page aligned, regardless of whether we are reading the EOF block or not. Hence we need to restrict the "does the read span EOF" check to just the page that spans EOF, not every page we read. This patch results in correct EOF detection through readpages: xfs_vm_readpages: dev 259:0 ino 0x43 nr_pages 24 xfs_iomap_found: dev 259:0 ino 0x43 size 0x66c00 offset 0x4f000 count 98304 type hole startoff 0x13c startblock 1368 blockcount 0x4 iomap_readpage_actor: orig pos 323584 pos 323584, length 4096, poff 0 plen 4096, isize 420864 xfs_iomap_found: dev 259:0 ino 0x43 size 0x66c00 offset 0x50000 count 94208 type hole startoff 0x140 startblock 1497 blockcount 0x5c iomap_readpage_actor: orig pos 327680 pos 327680, length 94208, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 331776 pos 331776, length 90112, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 335872 pos 335872, length 86016, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 339968 pos 339968, length 81920, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 344064 pos 344064, length 77824, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 348160 pos 348160, length 73728, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 352256 pos 352256, length 69632, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 356352 pos 356352, length 65536, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 360448 pos 360448, length 61440, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 364544 pos 364544, length 57344, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 368640 pos 368640, length 53248, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 372736 pos 372736, length 49152, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 376832 pos 376832, length 45056, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 380928 pos 380928, length 40960, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 385024 pos 385024, length 36864, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 389120 pos 389120, length 32768, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 393216 pos 393216, length 28672, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 397312 pos 397312, length 24576, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 401408 pos 401408, length 20480, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 405504 pos 405504, length 16384, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 409600 pos 409600, length 12288, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 413696 pos 413696, length 8192, poff 0 plen 4096, isize 420864 iomap_readpage_actor: orig pos 417792 pos 417792, length 4096, poff 0 plen 3072, isize 420864 iomap_readpage_actor: orig pos 420864 pos 420864, length 1024, poff 3072 plen 1024, isize 420864 As you can see, it now does full page reads until the last one which is split correctly at the block aligned EOF, reading 3072 bytes and zeroing the last 1024 bytes. The original version of the patch got this right, but it got another case wrong. The EOF detection crossing really needs to the the original length as plen, while it starts at the end of the block, will be shortened as up-to-date blocks are found on the page. This means "orig_pos + plen" no longer points to the end of the page, and so will not correctly detect EOF crossing. Hence we have to use the length passed in to detect this partial page case: xfs_filemap_fault: dev 259:1 ino 0x43 write_fault 0 xfs_vm_readpage: dev 259:1 ino 0x43 nr_pages 1 xfs_iomap_found: dev 259:1 ino 0x43 size 0x2cc00 offset 0x2c000 count 4096 type hole startoff 0xb0 startblock 282 blockcount 0x4 iomap_readpage_actor: orig pos 180224 pos 181248, length 4096, poff 1024 plen 2048, isize 183296 xfs_iomap_found: dev 259:1 ino 0x43 size 0x2cc00 offset 0x2cc00 count 1024 type hole startoff 0xb3 startblock 285 blockcount 0x1 iomap_readpage_actor: orig pos 183296 pos 183296, length 1024, poff 3072 plen 1024, isize 183296 Heere we see a trace where the first block on the EOF page is up to date, hence poff = 1024 bytes. The offset into the page of EOF is 3072, so the range we want to read is 1024 - 3071, and the range we want to zero is 3072 - 4095. You can see this is split correctly now. This fixes the stale data beyond EOF problem that fsx quickly uncovers on 1k block size filesystems. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iomap: dio data corruption and spurious errors when pipes fillDave Chinner2019-12-131-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4721a6010990971440b4ffefbdf014976b8eda2f ] When doing direct IO to a pipe for do_splice_direct(), then pipe is trivial to fill up and overflow as it can only hold 16 pages. At this point bio_iov_iter_get_pages() then returns -EFAULT, and we abort the IO submission process. Unfortunately, iomap_dio_rw() propagates the error back up the stack. The error is converted from the EFAULT to EAGAIN in generic_file_splice_read() to tell the splice layers that the pipe is full. do_splice_direct() completely fails to handle EAGAIN errors (it aborts on error) and returns EAGAIN to the caller. copy_file_write() then completely fails to handle EAGAIN as well, and so returns EAGAIN to userspace, having failed to copy the data it was asked to. Avoid this whole steaming pile of fail by having iomap_dio_rw() silently swallow EFAULT errors and so do short reads. To make matters worse, iomap_dio_actor() has a stale data exposure bug bio_iov_iter_get_pages() fails - it does not zero the tail block that it may have been left uncovered by partial IO. Fix the error handling case to drop to the sub-block zeroing rather than immmediately returning the -EFAULT error. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iomap: sub-block dio needs to zeroout beyond EOFDave Chinner2019-12-131-1/+8
| | | | | | | | | | | | | | | | | | | [ Upstream commit b450672fb66b4a991a5b55ee24209ac7ae7690ce ] If we are doing sub-block dio that extends EOF, we need to zero the unused tail of the block to initialise the data in it it. If we do not zero the tail of the block, then an immediate mmap read of the EOF block will expose stale data beyond EOF to userspace. Found with fsx running sub-block DIO sizes vs MAPREAD/MAPWRITE operations. Fix this by detecting if the end of the DIO write is beyond EOF and zeroing the tail if necessary. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iomap: FUA is wrong for DIO O_DSYNC writes into unwritten extentsDave Chinner2019-12-131-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0929d8580071c6a1cec1a7916a8f674c243ceee1 ] When we write into an unwritten extent via direct IO, we dirty metadata on IO completion to convert the unwritten extent to written. However, when we do the FUA optimisation checks, the inode may be clean and so we issue a FUA write into the unwritten extent. This means we then bypass the generic_write_sync() call after unwritten extent conversion has ben done and we don't force the modified metadata to stable storage. This violates O_DSYNC semantics. The window of exposure is a single IO, as the next DIO write will see the inode has dirty metadata and hence will not use the FUA optimisation. Calling generic_write_sync() after completion of the second IO will also sync the first write and it's metadata. Fix this by avoiding the FUA optimisation when writing to unwritten extents. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ice: Fix possible NULL pointer de-referenceBruce Allan2019-12-131-0/+3
| | | | | | | | | | | | | [ Upstream commit f25dad19ba70f7cc135da78ec013325042cd8c52 ] A recent update to smatch is causing it to report the error "we previously assumed 'm_entry->vsi_list_info' could be null". Fix that. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ice: Fix return value from NAPI pollDave Ertman2019-12-131-1/+2
| | | | | | | | | | | | | | | | [ Upstream commit e0c9fd9b77a7334032ec407d9e14d7c3cac1ac4f ] ice_napi_poll is hard-coded to return zero when it's done. It should instead return the work done (if any work was done). The only time it should return zero is if an interrupt or poll is handled and no work is performed. So change the return value to be the minimum of work done or budget-1. Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* net-next/hinic: fix a bug in rx data flowXue Chaojing2019-12-131-1/+1
| | | | | | | | | | | | [ Upstream commit b1a200484143a727ce293e0f200a543cc7584152 ] In rx_alloc_pkts(), there is a loop call of tasklet, which causes 100% cpu utilization, even no packets are being received. This patch fixes this bug. Signed-off-by: Xue Chaojing <xuechaojing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* net-next/hinic:fix a bug in set mac addressXue Chaojing2019-12-131-3/+4
| | | | | | | | | | | | [ Upstream commit 9ea72dc9430306b77c73a8a21beb51437cde1d6d ] In add_mac_addr(), if the MAC address is a muliticast address, it will not be set, which causes the network card fail to receive the multicast packet. This patch fixes this bug. Signed-off-by: Xue Chaojing <xuechaojing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* xfs: extent shifting doesn't fully invalidate page cacheDave Chinner2019-12-131-7/+1
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 7f9f71be84bcab368e58020a42f6d0dd97adf0ce ] The extent shifting code uses a flush and invalidate mechainsm prior to shifting extents around. This is similar to what xfs_free_file_space() does, but it doesn't take into account things like page cache vs block size differences, and it will fail if there is a page that it currently busy. xfs_flush_unmap_range() handles all of these cases, so just convert xfs_prepare_shift() to us that mechanism rather than having it's own special sauce. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* USB: serial: f81534: fix reading old/new IC configJi-Ze Hong (Peter Hong)2019-12-131-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ab60075f2a4eebca1abb04f712569963fb4d9d6c ] The F81532/534 had a internal configuration space to save & control IC state with address F81534_CUSTOM_ADDRESS_START (0x2f00). Layout as following: +00h: to indicate the section is valid +01h~04h: UART Mode & port availability +05h~08h: Output pin control on IC power on +09h~12h: Output pin control on working <-- New added Old driver will use +05~08h as default on working, but newer IC will configed with shutdown mode(7) in 05h~08h and working mode with RS232(1) in 09h~12h. It'll make mainstream driver not working. This patch will make mainstream driver compatible older and newer IC. If using a old IC, the +05h~08h will be 00h~06h, we'll direct apply it. If using a new IC, the +05h~08h will be 07h or larger, we'll read +09h~12h to apply newer configuration. Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: Fix return value of _set_load() stubMark Brown2019-12-131-1/+1
| | | | | | | | | | | | | | | [ Upstream commit f1abf67217de91f5cd3c757ae857632ca565099a ] The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang <cychiang@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* sctp: count sk_wmem_alloc by skb truesize in sctp_packet_transmitXin Long2019-12-131-20/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 02968ccf0125d39b08ecef5946300a8a873c0942 ] Now sctp increases sk_wmem_alloc by 1 when doing set_owner_w for the skb allocked in sctp_packet_transmit and decreases by 1 when freeing this skb. But when this skb goes through networking stack, some subcomponents might change skb->truesize and add the same amount on sk_wmem_alloc. However sctp doesn't know the amount to decrease by, it would cause a leak on sk->sk_wmem_alloc and the sock can never be freed. Xiumei found this issue when it hit esp_output_head() by using sctp over ipsec, where skb->truesize is added and so is sk->sk_wmem_alloc. Since sctp has used sk_wmem_queued to count for writable space since Commit cd305c74b0f8 ("sctp: use sk_wmem_queued to check for writable space"), it's ok to fix it by counting sk_wmem_alloc by skb truesize in sctp_packet_transmit. Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Reported-by: Xiumei Mu <xmu@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: rockchip: fix ID of 8ch clock of I2S1 for rk3328Katsuhiro Suzuki2019-12-131-1/+1
| | | | | | | | | | | [ Upstream commit df7b1f2e0a4ae0fceff261e29cde63dafcf2360f ] This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1 successfully. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: rockchip: fix I2S1 clock gate register for rk3328Katsuhiro Suzuki2019-12-131-1/+1
| | | | | | | | | | | | | [ Upstream commit 5c73ac2f8b70834a603eb2d92eb0bb464634420b ] This patch fixes definition of I2S1 clock gate register for rk3328. Current setting is not related I2S clocks. - bit6 of CRU_CLKGATE_CON0 means clk_ddrmon_en - bit6 of CRU_CLKGATE_CON1 means clk_i2s1_en Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mm/vmstat.c: fix NUMA statistics updatesJanne Huttunen2019-12-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 13c9aaf7fa01cc7600c61981609feadeef3354ec ] Scan through the whole array to see if an update is needed. While we're at it, use sizeof() to be safe against any possible type changes in the future. The bug here is that we wouldn't sync per-cpu counters into global ones if there was an update of numa_stats for higher cpus. Highly theoretical one though because it is much more probable that zone_stats are updated so we would refresh anyway. So I wouldn't bother to mark this for stable, yet something nice to fix. [mhocko@suse.com: changelog enhancement] Link: http://lkml.kernel.org/r/1541601517-17282-1-git-send-email-janne.huttunen@nokia.com Fixes: 1d90ca897cb0 ("mm: update NUMA counter threshold size") Signed-off-by: Janne Huttunen <janne.huttunen@nokia.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: raspberrypi: Fix firmware calls with large buffersJames Hughes2019-12-131-17/+18
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 91c6ada69f396e663acb2b713e8acb8a9463557d ] Commit a1547e0bca51 ("firmware: raspberrypi: Remove VLA usage") moved away from VLA's to a fixed maximum size for mailbox data. However, some mailbox calls use larger data buffers than the maximum allowed in that change. This fix therefor moves from using fixed buffers to kmalloc to ensure all sizes are catered for. There is some documentation, which is somewhat out of date, on the mailbox calls here : https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface Fixes: a1547e0bca51 ("firmware: raspberrypi: Remove VLA usage") Signed-off-by: James Hughes <james.hughes@raspberrypi.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* Staging: iio: adt7316: Fix i2c data reading, set the data fieldShreeya Patel2019-12-131-0/+2
| | | | | | | | | | | | | | | [ Upstream commit 688cd642ba0c393344c802647848da5f0d925d0e ] adt7316_i2c_read function nowhere sets the data field. It is necessary to have an appropriate value for it. Hence, assign the value stored in 'ret' variable to data field. This is an ancient bug, and as no one seems to have noticed, probably no sense in applying it to stable. Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* pinctrl: qcom: ssbi-gpio: fix gpio-hog related boot issuesBrian Masney2019-12-131-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7ed07855773814337b9814f1c3e866df52ebce68 ] When attempting to setup up a gpio hog, device probing will repeatedly fail with -EPROBE_DEFERED errors. It is caused by a circular dependency between the gpio and pinctrl frameworks. If the gpio-ranges property is present in device tree, then the gpio framework will handle the gpio pin registration and eliminate the circular dependency. See Christian Lamparter's commit a86caa9ba5d7 ("pinctrl: msm: fix gpio-hog related boot issues") for a detailed commit message that explains the issue in much more detail. The code comment in this commit came from Christian's commit. I did not test this change against any hardware supported by this particular driver, however I was able to validate this same fix works for pinctrl-spmi-gpio.c using a LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: zynqmp: Fix node names which contain "_"Michal Simek2019-12-136-13/+13
| | | | | | | | | | | | | | | [ Upstream commit d1d4445abffb2b17e841d37b555b6f1364b571c1 ] s/_/-/ for node names. It fixes warnings like this: ... Warning (node_name_chars_strict): /cpu_opp_table: Character '_' not recommended in node name ... Issues reported by make dtbs W=12 Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: bcm - fix normal/non key hash algorithm failureRaveendra Padasalagi2019-12-131-1/+5
| | | | | | | | | | | | [ Upstream commit 4f0129d13e69bad0363fd75553fb22897b32c379 ] Remove setkey() callback handler for normal/non key hash algorithms and keep it for AES-CBC/CMAC which needs key. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: ecc - check for invalid values in the key verification testVitaly Chikunov2019-12-131-16/+26
| | | | | | | | | | | | | [ Upstream commit 2eb4942b6609d35a4e835644a33203b0aef7443d ] Currently used scalar multiplication algorithm (Matthieu Rivain, 2011) have invalid values for scalar == 1, n-1, and for regularized version n-2, which was previously not checked. Verify that they are not used as private keys. Signed-off-by: Vitaly Chikunov <vt@altlinux.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: imx6: RDU2: fix eGalax touchscreen nodeLucas Stach2019-12-131-2/+3
| | | | | | | | | | | | [ Upstream commit 749a5068f2e2453a38777b1d5fc322d503cabf1d ] Use the correct compatible for the new protocol used by the firmware on the touch controller, the GPIO wakeup isn't used in that case. Also eGalax touch needs axis swapping, just as with the RMI4 touch. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* bus: ti-sysc: Fix getting optional clocks in clock_rolesTony Lindgren2019-12-131-2/+7
| | | | | | | | | | | | [ Upstream commit 7b4f8ac2f1acdff3c0cce23d8c3b86434a6e768a ] We can have holes in clock_roles with interface clock missing for example. Currently getting an optional clock will fail if there are only a functional clock and an optional clock. Fixes: 09dfe5810762 ("bus: ti-sysc: Add handling for clkctrl opt clocks") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drivers: soc: Allow building the amlogic drivers without ARCH_MESONMaxime Jourdan2019-12-131-1/+1
| | | | | | | | | | | | | | [ Upstream commit 41bb5769b7f4b7a85e4b92c37429228279b4f569 ] The current condition makes it difficult to compile the amlogic/ drivers with COMPILE_TEST, or without ARCH_MESON in general. Fixes kbuild errors with patch series that depend on drivers in that directory, for instance the meson video decoder. Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scsi: zfcp: drop default switch case which might paper over missing caseSteffen Maier2019-12-131-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0c902936e55cff9335b27ed632fc45e7115ced75 ] This was introduced with v4.18 commit 8c3d20aada70 ("scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED") but would now suppress helpful -Wswitch compiler warnings when building with W=1 such as the following forced example: drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_handle_failed': drivers/s390/scsi/zfcp_erp.c:126:2: warning: enumeration value 'ZFCP_ERP_ACTION_REOPEN_PORT_FORCED' not handled in switch [-Wswitch] switch (want) { ^~~~~~ But then again, only with W=1 we would notice unhandled enum cases. Without the default cases and a missed unhandled enum case, the code might perform unforeseen things we might not want... As of today, we never run through the removed default case, so removing it is no functional change. In the future, we never should run through a default case but introduce the necessary specific case(s) to handle new functionality. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scsi: zfcp: update kernel message for invalid FCP_CMND length, it's not the CDBSteffen Maier2019-12-131-5/+2
| | | | | | | | | | | | [ Upstream commit 724e144387f4d7e7668d3da913d0efc44a9b4664 ] The CDB is just a part inside of FCP_CMND, see zfcp_fc_scsi_to_fcp(). While at it, fix the device driver reaction: adapter not LUN shutdown. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing MII_PHYSID2Andrew Lunn2019-12-131-5/+16
| | | | | | | | | | | | | | | | | | | | [ Upstream commit ddc49acb659a2d8bfc5fdb0de0ef197712c11d75 ] We already have a workaround for a couple of switches whose internal PHYs only have the Marvel OUI, but no model number. We detect such PHYs and give them the 6390 ID as the model number. However the mv88e6161 has two SERDES interfaces in the same address range as its internal PHYs. These suffer from the same problem, the Marvell OUI, but no model number. As a result, these SERDES interfaces were getting the same PHY ID as the mv88e6390, even though they are not PHYs, and the Marvell PHY driver was trying to drive them. Add a special case to stop this from happen. Reported-by: Chris Healy <Chris.Healy@zii.aero> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: SiByte: Enable ZONE_DMA32 for LittleSurMaciej W. Rozycki2019-12-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 756d6d836dbfb04a5a486bc2ec89397aa4533737 ] The LittleSur board is marked for high memory support and therefore clearly must provide a way to have enough memory installed for some to be present outside the low 4GiB physical address range. With the memory map of the BCM1250 SOC it has been built around it means over 1GiB of actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical address range[1]. Complement commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") then and also enable ZONE_DMA32 for LittleSur. References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Patchwork: https://patchwork.linux-mips.org/patch/21107/ Fixes: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* dlm: fix missing idr_destroy for recover_idrDavid Teigland2019-12-131-0/+1
| | | | | | | | | [ Upstream commit 8fc6ed9a3508a0435b9270c313600799d210d319 ] Which would leak memory for the idr internals. Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: rockchip: Fix rk3288-rock2 vcc_flash nameJohn Keeping2019-12-131-1/+1
| | | | | | | | | | | | [ Upstream commit 03d9f8fa2bfdc791865624d3adc29070cf67814e ] There is no functional change from this, but it is confusing to find two copies of vcc_sys and no vcc_flash when looking in /sys/class/regulator/*/name. Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: rockchip: fix rk3188 sclk_mac_lbtest parameter orderingHeiko Stuebner2019-12-131-2/+2
| | | | | | | | | | | [ Upstream commit ac8cb53829a6ba119082e067f5bc8fab3611ce6a ] Similar to commit a9f0c0e56371 ("clk: rockchip: fix rk3188 sclk_smc gate data") there is one other gate clock in the rk3188 clock driver with a similar wrong ordering, the sclk_mac_lbtest. So fix it as well. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: rockchip: fix rk3188 sclk_smc gate dataFinley Xiao2019-12-131-2/+2
| | | | | | | | | | | | [ Upstream commit a9f0c0e563717b9f63b3bb1c4a7c2df436a206d9 ] Fix sclk_smc gate data. Change variable order, flags come before the register address. Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com> Signed-off-by: Johan Jonker <jbx9999@hotmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* virtchnl: Fix off by one errorAlice Michael2019-12-131-2/+2
| | | | | | | | | | | | | | | | [ Upstream commit 843faff87af261bf55eda719a06087af0486a168 ] When calculating the valid length for a VIRTCHNL_OP_ENABLE_CHANNELS message, we accidentally allowed messages with one extra virtchnl_channel_info structure on the end. This happened due to an off by one error, because we forgot that valid_len already accounted for one virtchnl_channel_info structure, so we need to subtract one from the num_tc value. Signed-off-by: Alice Michael <alice.michael@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* i40e: don't restart nway if autoneg not supportedMitch Williams2019-12-131-5/+5
| | | | | | | | | | | | | | | | [ Upstream commit 7c3758f7839377ab67529cc50264a640636c47af ] On link types that do not support autoneg, we cannot attempt to restart nway negotiation. This results in a dead link that requires a power cycle to remedy. Fix this by saving off the autoneg state and checking this value before we try to restart nway. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: max77686: Fix the returned value in case of error in ↵Christophe JAILLET2019-12-131-1/+1
| | | | | | | | | | | | | | | | | | 'max77686_rtc_read_time()' [ Upstream commit b28cc6cec3d814f5184cbebb2d1f987e769f534a ] In case of error, we return 0. This is spurious and not consistent with the other functions of the driver. Commit e115a2bf1426 has modified more than what is said in the commit message. Reverse part of it znd return an error when needed, as it was previously. Fixes: e115a2bf1426 ("rtc: max77686: stop validating rtc_time in .read_time") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: s3c-rtc: Avoid using broken ALMYEAR registerMarek Szyprowski2019-12-131-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 50c8aec4212a966817e868056efc9bfbb73337c0 ] (RTC,ALM)YEAR registers of Exynos built-in RTC device contains 3 BCD characters. s3c-rtc driver uses only 2 lower of them and supports years from 2000..2099 range. The third BCD value is typically set to 0, but it looks that handling of it is broken in the hardware. It sometimes defaults to a random (even non-BCD) value. This is not an issue for handling RTCYEAR register, because bcd2bin() properly handles only 8bit values (2 BCD characters, the third one is skipped). The problem is however with ALMYEAR register and proper RTC alarm operation. When YEAREN bit is set for the configured alarm, RTC hardware triggers alarm only when ALMYEAR and RTCYEAR matches. This usually doesn't happen because of the random noise on the third BCD character. Fix this by simply skipping setting ALMYEAR register in alarm configuration. This workaround fixes broken alarm operation on Exynos built-in rtc device. My tests revealed that the issue happens on the following Exynos series: 3250, 4210, 4412, 5250 and 5410. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-11 19:36:09 +0000