summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-03-18s390/qeth: allow configuration of TX queues for IQD devicesJulian Wiedmann
Similar to the support for z/VM NICs, but we need to take extra care about the dedicated mcast queue: 1. netdev_pick_tx() is unaware of this limitation and might select the mcast txq. Catch this. 2. require at least _two_ TX queues - one for ucast, one for mcast. 3. when reducing the number of TX queues, there's a potential race where netdev_cap_txqueue() over-rules the selected txq index and falls back to index 0. This would place ucast traffic on the mcast queue, and result in TX errors. So for IQD, reject a reduction while the interface is running. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-18s390/qeth: allow configuration of TX queues for z/VM NICsJulian Wiedmann
Add support for ETHTOOL_SCHANNELS to change the count of active TX queues. Since all TX queue structs are pre-allocated and -registered, we just need to trivially adjust dev->real_num_tx_queues. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-18s390/qeth: remove prio-queueing support for z/VM NICsJulian Wiedmann
z/VM NICs don't offer HW QoS for TX rings. So just use netdev_pick_tx() to distribute the connections equally over all enabled TX queues. We start with just 1 enabled TX queue (this matches the typical configuration without prio-queueing). A follow-on patch will allow users to enable additional TX queues. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-18s390/qeth: use memory reserves in TX slow pathJulian Wiedmann
When falling back to an allocation from the HW header cache, check if the skb is eligible for using memory reserves. This only makes a difference if the cache is empty and needs to be refilled. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-18s390/qeth: use memory reserves to back RX buffersJulian Wiedmann
Use dev_alloc_page() for backing the RX buffers with pages. This way we pick up __GFP_MEMALLOC. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-18spi: spi-fsl-dspi: Add support for LS1028AVladimir Oltean
This is similar to the DSPI instantiation on LS1028A, except that: - The A-011218 erratum has been fixed, so DMA works - The endianness is different, which has implications on XSPI mode Some benchmarking with the following command: spidev_test --device /dev/spidev2.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 shows that in DMA mode, it can achieve around 2400 kbps, and in XSPI mode, the same command goes up to 4700 kbps. This is somewhat to be expected, since the DMA buffer size is extremely small at 8 bytes, the winner becomes whomever can prepare the buffers for transmission quicker, and DMA mode has higher overhead there. So XSPI FIFO mode has been chosen as the operating mode for this chip. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-11-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_messageVladimir Oltean
The operating mode (DMA, XSPI, EOQ) is not going to change across the lifetime of the device. So it makes no sense to keep writing to SPI_RSER on each message. Move this configuration to dspi_init instead. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-10-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code pathVladimir Oltean
Interrupts are not necessary for DMA functionality, since the completion event is provided by the DMA driver. But if the driver fails to request the IRQ defined in the device tree, it will call dspi_poll which would make the driver hang waiting for data to become available in the RX FIFO. Fixes: c55be3059159 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-9-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA modeVladimir Oltean
The driver does not create the dspi->dma structure unless operating in DSPI_DMA_MODE, so it makes sense to check for that. Fixes: f4b323905d8b ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-8-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completionVladimir Oltean
Currently the driver puts the process in interruptible sleep waiting for the interrupt train to finish transfer to/from the tx_buf and rx_buf. But exiting the process with ctrl-c may make the kernel panic: the wait_event_interruptible call will return -ERESTARTSYS, which a proper driver implementation is perhaps supposed to handle, but nonetheless this one doesn't, and aborts the transfer altogether. Actually when the task is interrupted, there is still a high chance that the dspi_interrupt is still triggering. And if dspi_transfer_one_message returns execution all the way to the spi_device driver, that can free the spi_message and spi_transfer structures, leaving the interrupts to access a freed tx_buf and rx_buf. hexdump -C /dev/mtd0 00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff |.uhu............| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * ^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed! [ 38.503097] spi_master spi2: failed to transfer one message from queue [ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377 [ 38.517676] Mem abort info: [ 38.520474] ESR = 0x96000045 [ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits [ 38.528861] SET = 0, FnV = 0 [ 38.531921] EA = 0, S1PTW = 0 [ 38.535067] Data abort info: [ 38.537952] ISV = 0, ISS = 0x00000045 [ 38.541797] CM = 0, WnR = 1 [ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000 [ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000 [ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 38.565819] Modules linked in: [ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193 [ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO) [ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110 [ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90 [ 38.601203] sp : ffff800010003d90 [ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000 [ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400 [ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0 [ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377 [ 38.625841] x21: 000000000000146e x20: ffff8000120c3000 [ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948 [ 38.636498] x17: 0000000000000000 x16: 0000000000000000 [ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720 [ 38.647155] x13: 0720072007200765 x12: 0775076507750771 [ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040 [ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8 [ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60 [ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377 [ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0 [ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026 [ 38.684454] Call trace: [ 38.686905] ktime_get_real_ts64+0x3c/0x110 [ 38.691100] spi_take_timestamp_pre+0x40/0x90 [ 38.695470] dspi_fifo_write+0x58/0x2c0 [ 38.699315] dspi_interrupt+0xbc/0xd0 [ 38.702987] __handle_irq_event_percpu+0x78/0x2c0 [ 38.707706] handle_irq_event_percpu+0x3c/0x90 [ 38.712161] handle_irq_event+0x4c/0xd0 [ 38.716008] handle_fasteoi_irq+0xbc/0x170 [ 38.720115] generic_handle_irq+0x2c/0x40 [ 38.724135] __handle_domain_irq+0x68/0xc0 [ 38.728243] gic_handle_irq+0xc8/0x160 [ 38.732000] el1_irq+0xb8/0x180 [ 38.735149] spi_nor_spimem_read_data+0xe0/0x140 [ 38.739779] spi_nor_read+0xc4/0x120 [ 38.743364] mtd_read_oob+0xa8/0xc0 [ 38.746860] mtd_read+0x4c/0x80 [ 38.750007] mtdchar_read+0x108/0x2a0 [ 38.753679] __vfs_read+0x20/0x50 [ 38.757002] vfs_read+0xa4/0x190 [ 38.760237] ksys_read+0x6c/0xf0 [ 38.763471] __arm64_sys_read+0x20/0x30 [ 38.767319] el0_svc_common.constprop.3+0x90/0x160 [ 38.772125] do_el0_svc+0x28/0x90 [ 38.775449] el0_sync_handler+0x118/0x190 [ 38.779468] el0_sync+0x140/0x180 [ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0) [ 38.788910] ---[ end trace 55da560db4d6bef7 ]--- [ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt [ 38.799914] SMP: stopping secondary CPUs [ 38.803849] Kernel Offset: disabled [ 38.807344] CPU features: 0x10002,20006008 [ 38.811451] Memory Limit: none [ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- So it is clear that the "interruptible" part isn't handled correctly. When the process receives a signal, one could either attempt a clean abort (which appears to be difficult with this hardware) or just keep restarting the sleep until the wait queue really completes. But checking in a loop for -ERESTARTSYS is a bit too complicated for this driver, so just make the sleep uninterruptible, to avoid all that nonsense. The wait queue was actually restructured as a completion, after polling other drivers for the most "popular" approach. Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Protect against races on dspi->words_in_flightVladimir Oltean
dspi->words_in_flight is a variable populated in the *_write functions and used in the dspi_fifo_read function. It is also used in dspi_fifo_write, immediately after transmission, to update the message->actual_length variable used by higher layers such as spi-mem for integrity checking. But it may happen that the IRQ which calls dspi_fifo_read to be triggered before the updating of message->actual_length takes place. In that case, dspi_fifo_read will decrement dspi->words_in_flight to -1, and that will cause an invalid modification of message->actual_length. For that, we make the simplest fix possible: to not decrement the actual shared variable in dspi->words_in_flight from dspi_fifo_read, but actually a copy of it which is on stack. But even if dspi_fifo_read from the next IRQ does not interfere with the dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still can. So we must assume that everything after the last write to the TX FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write function must be safe against that. This means refactoring the 2 flavours of FIFO writes (for EOQ and XSPI) such that the calculation of the number of words to be written is common and happens a priori. This way, the code for updating the message->actual_length variable works with a copy and not with the volatile dspi->words_in_flight. After some interior debate, the dspi->progress variable used for software timestamping was *not* backed up against preemption in a copy on stack. Because if preemption does occur between spi_take_timestamp_pre and spi_take_timestamp_post, there's really no point in trying to save anything. The first-in-time spi_take_timestamp_post call with a dspi->progress higher than the requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true anyway and will close the deal. To understand the above a bit better, consider a transfer with xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI controller timestamps in chunks of 4 bytes at a time, and preemption occurs in the middle of timestamping the first chunk: spi_take_timestamp_pre(0) . . (preemption) . . spi_take_timestamp_pre(4) . . spi_take_timestamp_post(7) . spi_take_timestamp_post(3) So the reason I'm not bothering to back up dspi->progress for that spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going to (a) be more honest, (b) provide better accuracy and (c) already render the spi_take_timestamp_post(3) into a noop by setting xfer->timestamped = true anyway. Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Avoid reading more data than written in EOQ modeVladimir Oltean
If dspi->words_in_flight is populated with the hardware FIFO size, then in dspi_fifo_read it will attempt to read more data at the end of a buffer that is not a multiple of 16 bytes in length. It will probably time out attempting to do so. So limit the num_fifo_entries variable to the actual number of FIFO entries that is going to be used. Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-5-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA modeVladimir Oltean
In DMA mode, dspi_setup_accel does not get called, which results in the dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be initialized properly. Because oper_word_size is zero, a few calculations end up being incorrect, and the DMA transfer eventually times out instead of sending anything on the wire. Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel for DMA mode too. Also take the opportunity and simplify the DMA buffer handling a little bit. Fixes: 6c1c26ecd9a3 ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-4-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATAVladimir Oltean
In XSPI mode, the 32-bit PUSHR register can be written to separately: the higher 16 bits are for commands and the lower 16 bits are for data. This has nicely been hacked around, by defining a second regmap with a width of 16 bits, and effectively splitting a 32-bit register into 2 16-bit ones, from the perspective of this regmap_pushr. The problem is the assumption about the controller's endianness. If the controller is little endian (such as anything post-LS1046A), then the first 2 bytes, in the order imposed by memory layout, will actually hold the TXDATA, and the last 2 bytes will hold the CMD. So take the controller's endianness into account when performing split writes to PUSHR. The obvious and simple solution would have been to call regmap_get_val_endian(), but that is an internal regmap function and we don't want to change regmap just for this. Therefore, we just re-read the "big-endian" device tree property. Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCRVladimir Oltean
The SPI_MCR_PCSIS macro assumes that the controller has a number of chip select signals equal to 6. That is not always the case, but actually is described through the driver-specific "spi-num-chipselects" device tree binding. LS1028A for example only has 4 chip selects. Don't write to the upper bits of the PCSIS field, which are reserved in the reference manual. Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18drm/amdgpu: fix typo for vcn2.5/jpeg2.5 idle checkJames Zhu
fix typo for vcn2.5/jpeg2.5 idle check Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-18drm/amdgpu: fix typo for vcn2/jpeg2 idle checkJames Zhu
fix typo for vcn2/jpeg2 idle check Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-18drm/amdgpu: fix typo for vcn1 idle checkJames Zhu
fix typo for vcn1 idle check Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-18scsi: Convert to use set_capacity_revalidate_and_notifyBalbir Singh
block/genhd provides set_capacity_revalidate_and_notify() for sending RESIZE notifications via uevents. This notification is newly added to scsi sd. Signed-off-by: Balbir Singh <sblbir@amazon.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-18nvme: Convert to use set_capacity_revalidate_and_notifyBalbir Singh
block/genhd provides set_capacity_revalidate_and_notify() for sending RESIZE notifications via uevents. This notification is newly added to NVME devices Signed-off-by: Balbir Singh <sblbir@amazon.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-18xen-blkfront.c: Convert to use set_capacity_revalidate_and_notifyBalbir Singh
block/genhd provides set_capacity_revalidate_and_notify() for sending RESIZE notifications via uevents. Signed-off-by: Balbir Singh <sblbir@amazon.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-18virtio_blk.c: Convert to use set_capacity_revalidate_and_notifyBalbir Singh
block/genhd provides set_capacity_revalidate_and_notify() for sending RESIZE notifications via uevents. Signed-off-by: Balbir Singh <sblbir@amazon.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-18regulator: da9063: fix suspendMartin Fuzzey
The .set_suspend_enable() and .set_suspend_disable() methods are not supposed to immediately change the regulator state but just indicated if the regulator should be enabled or disabled when standby mode is entered (by a hardware signal). However currently they set control the SEL bits in the DVC registers, which causes the voltage to change to immediately between the "A" (normal) and "B" (standby) values as programmed and does nothing for the enable state... This means that "regulator-on-in-suspend" does not work (the regulator is switched off when the PMIC enters standby mode on the hardware signal) and, potentially, depending on the A and B voltage configurations the voltage could be incorrectly changed *before* actually entering suspend. The right bit to use for the functionality is the "CONF" bit in the "CONT" register. The detailed register description says "Sequencer target state" for this bit which is not very clear but the functional description is clearer. >From 5.1.5 System Enable: De-asserting SYS_EN (changing from active to passive state) clears control SYSTEM_EN which triggers a power down sequence into hibernate/standby mode ... With the exception of supplies that have the xxxx_CONF control bit asserted, all regulators in power domains POWER1, POWER, and SYSTEM are sequentially disabled in reverse order. Regulators with the <x>_CONF bit set remain on but change the active voltage controlregisters from V<x>_A to V<x>_B (if V<x>_B is notalready selected). Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/1584461691-14344-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18drm/lease: fix WARNING in idr_destroyQiujun Huang
drm_lease_create takes ownership of leases. And leases will be released by drm_master_put. drm_master_put ->drm_master_destroy ->idr_destroy So we needn't call idr_destroy again. Reported-and-tested-by: syzbot+05835159fe322770fe3d@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjagain@gmail.com
2020-03-18drivers: base: power: wakeup.c: Use built-in RCU list checkingMadhuparna Bhowmik
Pass cond argument to list_for_each_entry_rcu() to fix the following false positive lockdep warning and other uses of list_for_each_entry_rcu() in wakeup.c. [ 331.934648] ============================= [ 331.934650] WARNING: suspicious RCU usage [ 331.934653] 5.6.0-rc1+ #5 Not tainted [ 331.934655] ----------------------------- [ 331.934657] drivers/base/power/wakeup.c:408 RCU-list traversed in non-reader section!! [ 333.025156] ============================= [ 333.025161] WARNING: suspicious RCU usage [ 333.025168] 5.6.0-rc1+ #5 Not tainted [ 333.025173] ----------------------------- [ 333.025180] drivers/base/power/wakeup.c:424 RCU-list traversed in non-reader section!! Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Link: https://lore.kernel.org/r/20200228174745.9308-1-madhuparnabhowmik10@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18component: allow missing unbind callbackMarco Felsch
The component framework reuses the devres managed functions. There is no need to specify an unbind() callback if the driver only wants to release the devres managed resources. The bind/unbind is like the probe/remove pair. The bind/probe is necessary and the unbind/remove is optional. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20200227104547.30085-1-m.felsch@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: fix compat TIOCGSERIAL checking wrong function ptrEric Biggers
Commit 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start checking for the presence of the ->set_serial function pointer rather than ->get_serial. This appears to be a copy-and-paste error, since ->get_serial is the function pointer that is called as well as the pointer that is checked by the non-compat version of TIOCGSERIAL. Fix this by checking the correct function pointer. Fixes: 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: fix compat TIOCGSERIAL leaking uninitialized memoryEric Biggers
Commit 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start copying a whole 'serial_struct32' to userspace rather than individual fields, but failed to initialize all padding and fields -- namely the hole after the 'iomem_reg_shift' field, and the 'reserved' field. Fix this by initializing the struct to zero. [v2: use sizeof, and convert the adjacent line for consistency.] Reported-by: syzbot+8da9175e28eadcb203ce@syzkaller.appspotmail.com Fixes: 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-2-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: drop outdated comments about release_tty() lockingEric Biggers
The current version of the TTY code unlocks the tty_struct(s) before release_tty() rather than after. Moreover, tty_unlock_pair() no longer exists. Thus, remove the outdated comments regarding tty_unlock_pair(). Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20200224073359.292795-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18Merge tag 'iwlwifi-next-for-kalle-2020-03-17' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next First set of iwlwifi patches intended for v5.7 * Refactoring of the device selection algorithms;
2020-03-18tty: n_tracesink: Use the correct style for SPDX License IdentifierNishad Kamdar
This patch corrects the SPDX License Identifier style in header file related to Kernel driver API to route trace data. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used). Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Link: https://lore.kernel.org/r/20200302143642.GA3335@nishad Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: hvc: Use the correct style for SPDX License IdentifierNishad Kamdar
This patch corrects the SPDX License Identifier style in header file related to the HVC driver. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used). Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Link: https://lore.kernel.org/r/20200301170419.GA7125@nishad Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: nozomi: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Also rewrite the code in a standard if-form instead of ugly conditional operators. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311092905.24362-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: serial: pch_uart: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311092930.24433-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: nozomi: fix spelling mistake "reserverd" -> "reserved"Alexandre Belloni
The reserved bits should be named reserved. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200214141455.20902-1-alexandre.belloni@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18ath11k: Perform per-msdu rx processingSriram R
As Hash based reo destination selection is configured, the decapped packets reach different reo destintion rings based on the destintaion ring selected for the computed hash (based on the 5-tuple {ip src/ip dst/src port/dst port/protocol}) by hw and as configured by driver. Hence the current implementation of amsdu list based processing after all the subframes of amsdu are received (since all msdu's for a pdev are received in same reo dest ring), is not applicable here and hence is replaced with per msdu based handling as these subframes can be received in different reo dest rings. Also, as some of the rx descriptor fields might be valid only for the first msdu (for ex. received 80211 header, encryption type, etc), it might not be useful now as we cannot sync between different subframes received in different rings. Hence do not rely on those fields and replace them with fieds valid only on per msdu descriptors. Also cache other details such as encryption type for a peer so that it can be reused when a packet is received from it. Co-developed-by: Tamizh Chelvam Raja <tamizhr@codeaurora.org> Signed-off-by: Tamizh Chelvam Raja <tamizhr@codeaurora.org> Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-18ath11k: Configure hash based reo destination ring selectionSriram R
Current implementation of pdev based reo destination ring selection is replaced by hash based ring selection so as to ensure all the available rings are utilized for better performance. The 4 reo destination rings are selected by the HW based on the hash value computed from the received packet based on the 5 tuple {ip src/ip dst/src port/dst port/protocol}. Out of the 32 hash values used by the hw, the driver assigns 8 values per reo destination ring to each of the 4 reo destination rings. Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-18ath11k: Adding proper validation before accessing tx_statsPravas Kumar Panda
Before dumping tx_stats proper validation was not been taken care of. Due to which we were encountering null pointer dereference(kernel panic). This scenario will arise when a station is getting disconnected and we are changing the STA state by ath11k_mac_op_sta_state and assigning tx_stats as NULL and after this the mac80211 will destroy the debugfs entry from where we are trying to read the stats. If anyone tries to dump tx_stats for that STA in between setting tx_stats to NULL and debugfs file removal without checking the NULL value it will run into a NULL pointer exception. Proceeding with the analysis of "ARM Kernel Panic". The APSS crash happened due to OOPS on CPU 3. Crash Signature : Unable to handle kernel NULL pointer dereference at virtual address 00000360 During the crash, PC points to "ath11k_debug_htt_stats_init+0x16ac/0x1acc [ath11k]" LR points to "ath11k_debug_htt_stats_init+0x1688/0x1acc [ath11k]". The Backtrace obtained is as follows: [<ffffffbffcfd8590>] ath11k_debug_htt_stats_init+0x16ac/0x1acc [ath11k] [<ffffffc000156320>] do_loop_readv_writev+0x60/0xa4 [<ffffffc000156a5c>] do_readv_writev+0xd8/0x19c [<ffffffc000156b54>] vfs_readv+0x34/0x48 [<ffffffc00017d6f4>] default_file_splice_read+0x1a8/0x2e4 [<ffffffc00017c56c>] do_splice_to+0x78/0x98 [<ffffffc00017c63c>] splice_direct_to_actor+0xb0/0x1a4 [<ffffffc00017c7b4>] do_splice_direct+0x84/0xa8 [<ffffffc000156f40>] do_sendfile+0x160/0x2a4 [<ffffffc000157980>] SyS_sendfile64+0xb4/0xc8 Signed-off-by: Pravas Kumar Panda <kumarpan@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-18ath11k: dump SRNG stats during FW assertManikanta Pubbisetty
Dumping the SRNG stats during FW assert, this would help in debugging ring stuck issues. Co-developed-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-18ath11k: fill channel info from rx channelVenkateswara Naralasetty
Fill the channel information from rx channel for the packet which has invalid channel info from meta data. Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-18ath11k: Supporting RX ring backpressure HTT event and stats handlingSriram R
The Firmware sends HTT event to host whenever there is a backpressure on RX rings, Handling such event and dumping info on the console under the "ATH11K_DBG_DP_HTT" debug level. Fetching RX ring backpressure histogram from FW via htt_stats debugfs. #echo "24" > /sys/kernel/debug/ath11k/ipq8074/macX/htt_stats_type #cat /sys/kernel/debug/ath11k/ipq8074/macX/htt_stats Signed-off-by: Vikas Patel <vikpatel@codeaurora.org> Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-18firmware: fix a double abort case with fw_load_sysfs_fallbackJunyong Sun
fw_sysfs_wait_timeout may return err with -ENOENT at fw_load_sysfs_fallback and firmware is already in abort status, no need to abort again, so skip it. This issue is caused by concurrent situation like below: when thread 1# wait firmware loading, thread 2# may write -1 to abort loading and wakeup thread 1# before it timeout. so wait_for_completion_killable_timeout of thread 1# would return remaining time which is != 0 with fw_st->status FW_STATUS_ABORTED.And the results would be converted into err -ENOENT in __fw_state_wait_common and transfered to fw_load_sysfs_fallback in thread 1#. The -ENOENT means firmware status is already at ABORTED, so fw_load_sysfs_fallback no need to get mutex to abort again. ----------------------------- thread 1#,wait for loading fw_load_sysfs_fallback ->fw_sysfs_wait_timeout ->__fw_state_wait_common ->wait_for_completion_killable_timeout in __fw_state_wait_common, ... 93 ret = wait_for_completion_killable_timeout(&fw_st->completion, timeout); 94 if (ret != 0 && fw_st->status == FW_STATUS_ABORTED) 95 return -ENOENT; 96 if (!ret) 97 return -ETIMEDOUT; 98 99 return ret < 0 ? ret : 0; ----------------------------- thread 2#, write -1 to abort loading firmware_loading_store ->fw_load_abort ->__fw_load_abort ->fw_state_aborted ->__fw_state_set ->complete_all in __fw_state_set, ... 111 if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED) 112 complete_all(&fw_st->completion); ------------------------------------------- BTW,the double abort issue would not cause kernel panic or create an issue, but slow down it sometimes.The change is just a minor optimization. Signed-off-by: Junyong Sun <sunjunyong@xiaomi.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/1583202968-28792-1-git-send-email-sunjunyong@xiaomi.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18serial: sprd: remove redundant sprd_port cleanupChunyan Zhang
We don't need to cleanup sprd_port anymore, since we've dropped the way of using the sprd_port[] array to get port index. Reviewed-by: Baolin Wang <baolin.wang7@gmail.com> Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lore.kernel.org/r/20200318105049.19623-3-zhang.lyra@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18serial: sprd: getting port index via serial aliases onlyChunyan Zhang
This patch simplifies the process of getting serial port number, with this patch, serial devices must have aliases configured in devicetree. The serial port searched out via sprd_port array maybe wrong if we don't have serial alias defined in devicetree, and specify console with command line, we would get the wrong port number if other serial ports probe failed before console's. So using aliases is mandatory. Reviewed-by: Baolin Wang <baolin.wang7@gmail.com> Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lore.kernel.org/r/20200318105049.19623-2-zhang.lyra@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18mmc: rtsx_pci: Fix support for speed-modes that relies on tuningRicky Wu
The TX/RX register should not be treated the same way to allow for better support of tuning. Fix this by using a default initial value for TX. Signed-off-by: Ricky Wu <ricky_wu@realtek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com [Ulf: Updated changelog] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18USB: serial: f81232: add control driver for F81534AJi-Ze Hong (Peter Hong)
The Fintek F81534A series contains 1 HUB, 1 GPIO device and n UARTs. The UARTs are disabled by default and need to be enabled by the GPIO device (2c42:16F8). When F81534A plug to host, we can only see 1 HUB and 1 GPIO device and we write 0x8fff to GPIO device register F81534A_CTRL_CMD_ENABLE_PORT (116h) to enable all available serial ports. Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com> [johan: reword commit message and an error message slightly] Signed-off-by: Johan Hovold <johan@kernel.org>
2020-03-18arch_topology: Fix putting invalid cpu clkJeffy Chen
Add a sanity check before putting the cpu clk. Fixes: b8fe128dad8f (“arch_topology: Adjust initial CPU capacities with current freq") Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Link: https://lore.kernel.org/r/20200317063308.23209-1-jeffy.chen@rock-chips.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18Merge tag 'iio-5.7a' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: First set of new IIO device support, fatures and cleanups for the 5.7 cycle Includes changes for the counter subsystem Core Feature * Explicitly handle sysfs values in dB, including correctly handling the needed postfix dB. * Add a TODO to suggest suitable activities for new contributors to IIO now the vast majority of drivers are out of staging (and the remaining ones there are 'hard'). Also update the TODO in staging to remove stale entries. Staging graduations * ad7192 ADC. New device support * ad5770r - New driver for this 6 channel DAC including DT bindings. * ad8366 - Add supprot for the hmc1119 attenuator. * al3010 - New driver supporting this Dyna-image light sensors. - Power management and DT bindings added in additional patches. * atlas-sensor - Add support for atlas DO-SM device. Reads disolved oxygen in a solution. * gpap002x00f - New driver and bindings to support the GP2AP002A00F and GP2AP002S00F light and proximity sensors. There is some limited existing support in input. The intent is to drop this driver once IIO driver is in place. * hmc425a - New driver for this attenuator. * icp10100 - New driver for this presure sensor. * ltc2632 - Add support for the ltc2636 8 channel DAC. Includes bindings and some tidying up of the driver. * inv_mpu6050 - Support IAM20680, ICM20609, ICM20689 and ICM20690. Includes related tidy up and rework of low pass filter bandwidth handling to give suitable values for all chips. Binding conversions to yaml or missing bindings docs. * atlas-sensor, including consolidation of previous 3 separate docs into 1. * ad7923, previously no doc. * max1363, split into max1238 and max1363 to simplify yaml. * stm32-adc Features * (counter) 104-quad-8 - Support a filter clock prescaler. - Support reporting of encoder cable status. * ad7124 - Low pass filter support. - Debugfs interface to access registers directly. * ad8366 - Support control of hardware gain. * inv_mpu6050 - Runtime pm with autosuspend. * npcm adc - Add reset support. This is a breaking change if DT is not in sync, however this device is a BMC so the ecosystem is closed enought that this should not be a problem. * srf04 - Add power management with DT bindings for the GPIO. * stm32-timer-trigger - Power management. * (counter) stm32-timer-cnt - Power management. * vcnl4000 - Enable runtime PM for devices that don't use on demand measurement. Cleanups and minor fixes * core - Avoid double read when using debugfs. Whilst we provide no guarantees on lack of side effects using the debugfs interfaces, this one is generate unexpected results so let us tidy it up. * dac/Kconfig - Alphabetic order. * ad5755 - Grammar and minor other fixes. * ad7124 - Fail probe if get_voltage fails as no meaningful readings can be had without knowing the external reference. - Switch to selection between different channel attributes rather than building the arrays at runtime. - Remove the spi_device_id table as the driver cannot be probled without more information that can be provided without dt. - Update sysfs docs to provide more inormation and bring remaining docs for this part out of staging. * ad9292 - Use new SPI transfer delay structure. * adis library - Add unlocked version of adis_initial_startup and refactor the function. - Add a product ID santiy check. - Add support for different self test registers. - Use new SPI delay structure. - Add new docs and tidy up existing. * adis16136 - Initialize adis_data statically. * adis16400 - Initialize adis_data statically. * adis16460 - Use core __adis_initial_Startup now it supports everything needed. * adis16480 - Initialize adis_data statically. - Use core __adis_initial_startup now it supports everything needed. * al3320a - Add missing DT binding docs. - Tidy up code formatting. - Simplify error paths using devm_add_action_or_reset. - Ensure autoloading works by adding the of_match_table. * atlas-sensor - Drop false requirement for interrupt line, the value can be polled using a sysfs or hrtimer type trigger. * exynos-adc - Silence warning message on deferring probe. * gp2ap002 - Greatly simplify the Lux LUT. - Reorder actions around buffer setup and tear down as part of a sub-system wide standardization of these. * inv_mpu6050 - Various lttle tidyups. - Simpliy I2C aux MUX handling by enabling it only at startup. It never needs to be disabled. - Simplify polling rate when magnetometer enabled by putting only under control of userspace. - Always execute full reset on devices supporting spi. It does no harm when using i2c and makes for simpler code. - Reduce over the top sleep times for vddio regulator power up. - Greatly simplify power and engine management. - Fix some delays in polled reads (only visible due to other changes) - Stop preventing sampling rate changes whilst running as there is no adverse consequence of doing so. - Prevent attempting to read the temperature if neither accel nor gyro is enabled. * lmp9100 - Reorder actions around buffer setup and tear down as part of a sub-system wide standardization of these. * max1118 - Use new SPI transfer delay structure. * mcp320x - Use new SPI transfer delay structure. * si1133 - Read full 24 bit signed integer instead o dropping last 8 bits of value. Not a critical fix as just adds precision. * st_sensors - Use st_sensors_dev_name_probe instead of open coded version in st_accel - Handle potential memory allocation failure. * st_lsm6dsx - Fix some wrong structure element naming in documentation. - Add missing return value check. * stm32_timer_cnt - Drop some unused left over IIO headers from this count subsystem driver. - Ensure the clock is enabled in master mode. Theoretical issue rather than one known to happen in the wild. * tlc4541 - Use new SPI delay structure. * tag 'iio-5.7a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (98 commits) iio: dac: Kconfig: sort symbols alphabetically iio: light: gp2ap020a00f: fix iio_triggered_buffer_{predisable,postenable} positions iio: potentiostat: lmp9100: fix iio_triggered_buffer_{predisable,postenable} positions iio: trigger: stm32-timer: add power management support iio: trigger: stm32-timer: rename enabled flag iio: add a TODO counter: 104-quad-8: Support Differential Encoder Cable Status counter: 104-quad-8: Support Filter Clock Prescaler iio: pressure: icp10100: add driver for InvenSense ICP-101xx iio: industrialio-core: Fix debugfs read iio: imu: adis: add a note better explaining state_lock iio: imu: adis: update 'adis_data' struct doc-string iio: imu: adis: add doc-string for 'adis' struct iio: imu: adis_buffer: Use new structure for SPI transfer delays iio: adc: ti-tlc4541: Use new structure for SPI transfer delays iio: adc: mcp320x: Use new structure for SPI transfer delays iio: adc: max1118: Use new structure for SPI transfer delays iio: adc: ad9292: Use new structure for SPI transfer delays iio: adc: exynos: Silence warning about regulators during deferred probe staging: iio: update TODO ...
2020-03-18intel_th: pci: Add Elkhart Lake CPU supportAlexander Shishkin
This adds support for the Trace Hub in Elkhart Lake CPU. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200317062215.15598-7-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18intel_th: Fix user-visible error codesAlexander Shishkin
There are a few places in the driver that end up returning ENOTSUPP to the user, replace those with EINVAL. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: ba82664c134ef ("intel_th: Add Memory Storage Unit driver") Cc: stable@vger.kernel.org # v4.4+ Link: https://lore.kernel.org/r/20200317062215.15598-6-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-16 01:06:35 +0000