aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-09mmc: sdhci_am654: Fix module autoloadFaiz Abbas1-0/+1
Add a MODULE_DEVICE_TABLE() entry so that the driver is autoloaded when built as a module. Signed-off-by: Faiz Abbas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-10-09Merge branch 'fixes' into nextUlf Hansson1-1/+1
2020-10-09Merge branch 'lkmm' of ↵Ingo Molnar6-134/+1410
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into locking/core Pull LKMM changes for v5.10 from Paul E. McKenney. Various documentation updates. Signed-off-by: Ingo Molnar <[email protected]>
2020-10-09Merge branch 'kcsan' of ↵Ingo Molnar16-347/+677
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into locking/core Pull KCSAN updates for v5.10 from Paul E. McKenney: - Improve kernel messages. - Be more permissive with bitops races under KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=y. - Optimize debugfs stat counters. - Introduce the instrument_*read_write() annotations, to provide a finer description of certain ops - using KCSAN's compound instrumentation. Use them for atomic RNW and bitops, where appropriate. Doing this might find new races. (Depends on the compiler having tsan-compound-read-before-write=1 support.) - Support atomic built-ins, which will help certain architectures, such as s390. - Misc enhancements and smaller fixes. Signed-off-by: Ingo Molnar <[email protected]>
2020-10-09Merge branch 'locking/urgent' into locking/core, to pick up fixesIngo Molnar2487-11305/+19532
Signed-off-by: Ingo Molnar <[email protected]>
2020-10-09lockdep: Revert "lockdep: Use raw_cpu_*() for per-cpu variables"Peter Zijlstra1-17/+9
The thinking in commit: fddf9055a60d ("lockdep: Use raw_cpu_*() for per-cpu variables") is flawed. While it is true that when we're migratable both CPUs will have a 0 value, it doesn't hold that when we do get migrated in the middle of a raw_cpu_op(), the old CPU will still have 0 by the time we get around to reading it on the new CPU. Luckily, the reason for that commit (s390 using preempt_disable() instead of preempt_disable_notrace() in their percpu code), has since been fixed by commit: 1196f12a2c96 ("s390: don't trace preemption in percpu macros") An audit of arch/*/include/asm/percpu*.h shows there are no other architectures affected by this particular issue. Fixes: fddf9055a60d ("lockdep: Use raw_cpu_*() for per-cpu variables") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-10-09lockdep: Fix lockdep recursionPeter Zijlstra2-45/+67
Steve reported that lockdep_assert*irq*(), when nested inside lockdep itself, will trigger a false-positive. One example is the stack-trace code, as called from inside lockdep, triggering tracing, which in turn calls RCU, which then uses lockdep_assert_irqs_disabled(). Fixes: a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu variables") Reported-by: Steven Rostedt <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-10-09lockdep: Fix usage_traceoverflowPeter Zijlstra3-21/+26
Basically print_lock_class_header()'s for loop is out of sync with the the size of of ->usage_traces[]. Also clean things up a bit while at it, to avoid such mishaps in the future. Fixes: 23870f122768 ("locking/lockdep: Fix "USED" <- "IN-NMI" inversions") Reported-by: Qian Cai <[email protected]> Debugged-by: Boqun Feng <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Qian Cai <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-10-09mmc: core: don't set limits.discard_granularity as 0Coly Li1-1/+1
In mmc_queue_setup_discard() the mmc driver queue's discard_granularity might be set as 0 (when card->pref_erase > max_discard) while the mmc device still declares to support discard operation. This is buggy and triggered the following kernel warning message, WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 Hardware name: Google Kevin (DT) pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) pc : __blkdev_issue_discard+0x200/0x294 lr : __blkdev_issue_discard+0x54/0x294 sp : ffff800011dd3b10 x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: __blkdev_issue_discard+0x200/0x294 __submit_discard_cmd+0x128/0x374 __issue_discard_cmd_orderly+0x188/0x244 __issue_discard_cmd+0x2e8/0x33c issue_discard_thread+0xe8/0x2f0 kthread+0x11c/0x120 ret_from_fork+0x10/0x1c ---[ end trace e4c8023d33dfe77a ]--- This patch fixes the issue by setting discard_granularity as SECTOR_SIZE instead of 0 when (card->pref_erase > max_discard) is true. Now no more complain from __blkdev_issue_discard() for the improper value of discard granularity. This issue is exposed after commit b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag is also added for the commit to make sure people won't miss this patch after applying the change of __blkdev_issue_discard(). Fixes: e056a1b5b67b ("mmc: queue: let host controllers specify maximum discard timeout") Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()"). Reported-and-tested-by: Vicente Bergas <[email protected]> Signed-off-by: Coly Li <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: Ulf Hansson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-10-09perf: Fix task_function_call() error handlingKajol Jain1-2/+3
The error handling introduced by commit: 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()") looses any return value from smp_call_function_single() that is not {0, -EINVAL}. This is a problem because it will return -EXNIO when the target CPU is offline. Worse, in that case it'll turn into an infinite loop. Fixes: 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()") Reported-by: Srikar Dronamraju <[email protected]> Signed-off-by: Kajol Jain <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Barret Rhoden <[email protected]> Tested-by: Srikar Dronamraju <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-10-08md/raid5: fix oops during stripe resizingSong Liu1-2/+2
KoWei reported crash during raid5 reshape: [ 1032.252932] Oops: 0002 [#1] SMP PTI [...] [ 1032.252943] RIP: 0010:memcpy_erms+0x6/0x10 [...] [ 1032.252947] RSP: 0018:ffffba1ac0c03b78 EFLAGS: 00010286 [ 1032.252949] RAX: 0000784ac0000000 RBX: ffff91bec3d09740 RCX: 0000000000001000 [ 1032.252951] RDX: 0000000000001000 RSI: ffff91be6781c000 RDI: 0000784ac0000000 [ 1032.252953] RBP: ffffba1ac0c03bd8 R08: 0000000000001000 R09: ffffba1ac0c03bf8 [ 1032.252954] R10: 0000000000000000 R11: 0000000000000000 R12: ffffba1ac0c03bf8 [ 1032.252955] R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000000000 [ 1032.252958] FS: 0000000000000000(0000) GS:ffff91becf500000(0000) knlGS:0000000000000000 [ 1032.252959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1032.252961] CR2: 0000784ac0000000 CR3: 000000031780a002 CR4: 00000000001606e0 [ 1032.252962] Call Trace: [ 1032.252969] ? async_memcpy+0x179/0x1000 [async_memcpy] [ 1032.252977] ? raid5_release_stripe+0x8e/0x110 [raid456] [ 1032.252982] handle_stripe_expansion+0x15a/0x1f0 [raid456] [ 1032.252988] handle_stripe+0x592/0x1270 [raid456] [ 1032.252993] handle_active_stripes.isra.0+0x3cb/0x5a0 [raid456] [ 1032.252999] raid5d+0x35c/0x550 [raid456] [ 1032.253002] ? schedule+0x42/0xb0 [ 1032.253006] ? schedule_timeout+0x10e/0x160 [ 1032.253011] md_thread+0x97/0x160 [ 1032.253015] ? wait_woken+0x80/0x80 [ 1032.253019] kthread+0x104/0x140 [ 1032.253022] ? md_start_sync+0x60/0x60 [ 1032.253024] ? kthread_park+0x90/0x90 [ 1032.253027] ret_from_fork+0x35/0x40 This is because cache_size_mutex was unlocked too early in resize_stripes, which races with grow_one_stripe() that grow_one_stripe() allocates a stripe with wrong pool_size. Fix this issue by unlocking cache_size_mutex after updating pool_size. Cc: <[email protected]> # v4.4+ Reported-by: KoWei Sung <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/bitmap: fix memory leak of temporary bitmapZhao Heming2-1/+3
Callers of get_bitmap_from_slot() are responsible to free the bitmap. Suggested-by: Guoqing Jiang <[email protected]> Signed-off-by: Zhao Heming <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md: fix the checking of wrong work queueGuoqing Jiang1-1/+1
It should check md_rdev_misc_wq instead of md_misc_wq. Fixes: cc1ffe61c026 ("md: add new workqueue for delete rdev") Cc: <[email protected]> # v5.8+ Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/bitmap: md_bitmap_get_counter returns wrong blocksZhao Heming1-1/+1
md_bitmap_get_counter() has code: ``` if (bitmap->bp[page].hijacked || bitmap->bp[page].map == NULL) csize = ((sector_t)1) << (bitmap->chunkshift + PAGE_COUNTER_SHIFT - 1); ``` The minus 1 is wrong, this branch should report 2048 bits of space. With "-1" action, this only report 1024 bit of space. This bug code returns wrong blocks, but it doesn't inflence bitmap logic: 1. Most callers focus this function return value (the counter of offset), not the parameter blocks. 2. The bug is only triggered when hijacked is true or map is NULL. the hijacked true condition is very rare. the "map == null" only true when array is creating or resizing. 3. Even the caller gets wrong blocks, current code makes caller just to call md_bitmap_get_counter() one more time. Signed-off-by: Zhao Heming <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/bitmap: md_bitmap_read_sb uses wrong bitmap blocksZhao Heming1-2/+2
The patched code is used to get chunks number, should use round-up div to replace current sector_div. The same code is in md_bitmap_resize(): ``` chunks = DIV_ROUND_UP_SECTOR_T(blocks, 1 << chunkshift); ``` Signed-off-by: Zhao Heming <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/raid0: remove unused function is_io_in_chunk_boundary()Jason Yan1-17/+0
This function is no longger needed after commit 20d0189b1012 ("block: Introduce new bio_split()"). Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-09Merge tag 'amd-drm-fixes-5.9-2020-10-08' of ↵Dave Airlie6-15/+48
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.9-2020-10-08: amdgpu: - Fix a crash on renoir if you override the IP discovery parameter - Fix the build on ARC platforms - Display fix for Sienna Cichlid Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-08io_uring: fix break condition for __io_uring_register() waitingJens Axboe1-3/+3
Colin reports that there's unreachable code, since we only ever break if ret == 0. This is correct, and is due to a reversed logic condition in when to break or not. Break out of the loop if we don't process any task work, in that case we do want to return -EINTR. Fixes: af9c1a44f8de ("io_uring: process task work in io_uring_register()") Reported-by: Colin Ian King <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-09erofs: remove unnecessary enum entriesChengguang Xu1-2/+0
Opt_nouser_xattr and Opt_noacl are useless, so just remove them. Signed-off-by: Chengguang Xu <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Reviewed-by: Chao Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Gao Xiang <[email protected]>
2020-10-08Merge tag 'block5.9-2020-10-08' of git://git.kernel.dk/linux-blockLinus Torvalds3-5/+7
Pull block fixes from Jens Axboe: "A few fixes that should go into this release: - NVMe controller error path reference fix (Chaitanya) - Fix regression with IBM partitions on non-dasd devices (Christoph) - Fix a missing clear in the compat CDROM packet structure (Peilin)" * tag 'block5.9-2020-10-08' of git://git.kernel.dk/linux-block: partitions/ibm: fix non-DASD devices nvme-core: put ctrl ref when module ref get fail block/scsi-ioctl: Fix kernel-infoleak in scsi_put_cdrom_generic_arg()
2020-10-09power: supply: sbs-battery: chromebook workaround for PECSebastian Reichel1-0/+6
Looks like the I2C tunnel implementation from Chromebook's embedded controller does not handle PEC correctly. Fix this by disabling PEC for batteries behind those I2C tunnels as a workaround. Note, that some Chromebooks actually have been reported to have working PEC support (with I2C tunnel). Since the problem has not yet been fully understood this simply reverts all Chromebooks to not use PEC for now. Reported-by: "Milan P. Stanić" <[email protected]> Reported-by: Vicente Bergas <[email protected]> CC: Enric Balletbo i Serra <[email protected]> Fixes: 7222bd603dd2 ("power: supply: sbs-battery: add PEC support") Tested-by: Vicente Bergas <[email protected]> Tested-by: "Milan P. Stanić" <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2020-10-08spi: dw: Add Baikal-T1 SPI Controller bindingsSerge Semin1-2/+31
These controllers are based on the DW APB SSI IP-core and embedded into the SoC, so two of them are equipped with IRQ, DMA, 64 words FIFOs and 4 native CS, while another one as being utilized by the Baikal-T1 System Boot Controller has got a very limited resources: no IRQ, no DMA, only a single native chip-select and just 8 bytes Tx/Rx FIFOs available. That's why we have to mark the IRQ to be optional for the later interface. The SPI controller embedded into the Baikal-T1 System Boot Controller can be also used to directly access an external SPI flash by means of a dedicated FSM. The corresponding MMIO region availability is switchable by the embedded multiplexor, which phandle can be specified in the dts node. * We added a new example to test out the non-standard Baikal-T1 System Boot SPI Controller DT binding. Co-developed-by: Ramil Zaripov <[email protected]> Signed-off-by: Ramil Zaripov <[email protected]> Signed-off-by: Serge Semin <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add Baikal-T1 SPI Controller glue driverSerge Semin3-0/+368
Baikal-T1 is equipped with three DW APB SSI-based MMIO SPI controllers. Two of them are pretty much normal: with IRQ, DMA, FIFOs of 64 words depth, 4x CSs, but the third one as being a part of the Baikal-T1 System Boot Controller has got a very limited resources: no IRQ, no DMA, only a single native chip-select and Tx/Rx FIFO with just 8 words depth available. In order to provide a transparent initial boot code execution the Boot SPI controller is also utilized by an vendor-specific IP-block, which exposes an SPI flash direct mapping interface. Since both direct mapping and SPI controller normal utilization are mutual exclusive only one of these interfaces can be used to access an external SPI slave device. That's why a dedicated mux is embedded into the System Boot Controller. All of that is taken into account in the Baikal-T1-specific DW APB SSI glue driver implemented by means of the DW SPI core module. Co-developed-by: Ramil Zaripov <[email protected]> Signed-off-by: Ramil Zaripov <[email protected]> Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add poll-based SPI transfers supportSerge Semin1-1/+39
A functionality of the poll-based transfer has been removed by commit 1ceb09717e98 ("spi: dw: remove cs_control and poll_mode members from chip_data") with a justification that "there is no user of one anymore". It turns out one of our DW APB SSI core is synthesized with no IRQ line attached and the only possible way of using it is to implement a poll-based SPI transfer procedure. So we have to get the removed functionality back, but with some alterations described below. First of all the poll-based transfer is activated only if the DW SPI controller doesn't have an IRQ line attached and the Linux IRQ number is initialized with the IRQ_NOTCONNECTED value. Secondly the transfer procedure is now executed with a delay performed between writer and reader methods. The delay value is calculated based on the number of data words expected to be received on the current iteration. Finally the errors status is checked on each iteration. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Introduce max mem-ops SPI bus frequency settingSerge Semin2-1/+4
In some circumstances the current implementation of the SPI memory operations may occasionally fail even though they are executed in the atomic context. This may happen if the system bus is relatively slow in comparison to the SPI bus frequency, or there is a concurrent access to it, which makes the MMIO-operations occasionally stalling before push-pulling data from the DW APB SPI FIFOs. These two problems we've discovered on the Baikal-T1 SoC. In order to fix them we have no choice but to set an artificial limitation on the SPI bus speed. Note currently this limitation will be only applicable for the memory operations, since the standard SPI core interface is implemented with an assumption that there is no problem with the automatic CS toggling. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add memory operations supportSerge Semin3-0/+315
Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <[email protected]> Signed-off-by: Ramil Zaripov <[email protected]> Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add generic DW SSI status-check methodSerge Semin3-18/+37
The DW SSI errors handling method can be generically implemented for all types of the transfers: IRQ, DMA and poll-based ones. It will be a function which checks the overflow/underflow error flags and resets the controller if any of them is set. In the framework of this commit we make use of the new method to detect the errors in the IRQ- and DMA-based SPI transfer execution procedures. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Move num-of retries parameter to the header fileSerge Semin2-3/+4
The parameter will be needed for another wait-done method being added in the framework of the SPI memory operation modification in a further commit. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Explicitly de-assert CS on SPI transfer completionSerge Semin1-1/+1
By design of the currently available native set_cs callback, the CS de-assertion will be done only if it's required by the corresponding controller capability. But in order to pre-fill the Tx FIFO buffer with data during the SPI memory ops execution the SER register needs to be left cleared before that. We'll also need a way to explicitly set and clear the corresponding CS bit at a certain moment of the operation. Let's alter the set_cs function then to also de-activate the CS, when it's required. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: De-assert chip-select on resetSerge Semin1-3/+4
SPI memory operations implementation will require to have the CS register cleared before executing the operation in order not to have the transmission automatically started prior the Tx FIFO is pre-initialized. Let's clear the register then on explicit controller reset to fulfil the requirements in case of an error or having the CS left set by a bootloader or another software. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Discard chip enabling on DMA setup errorSerge Semin1-3/+1
It's pointless to enable the chip back if the DMA setup procedure fails, since we'll disable it on the next transfer anyway. For the same reason We don't do that in case of a failure detected in any other methods called from the transfer_one() method. While at it consider any non-zero value returned from the dma_setup callback to be erroneous as it's supposed to be in the kernel. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Unmask IRQs after enabling the chipSerge Semin1-2/+2
It's theoretically erroneous to enable IRQ before the chip is turned on. If IRQ handler gets executed before the chip is enabled, then any data written to the Tx FIFO will be just ignored. I say "theoretically" because we haven't noticed any problem with that, but let's fix it anyway just in case... Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Perform IRQ setup in a dedicated functionSerge Semin1-18/+23
In order to make the transfer_one() callback method more readable and for unification with the DMA-based transfer, let's detach the IRQ setup procedure into a dedicated function. While at it rename the IRQ-based transfer handler function to be dw_spi-prefixe and looking more like the DMA-related one. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Refactor IRQ-based SPI transfer procedureSerge Semin1-9/+24
Current IRQ-based SPI transfer execution procedure doesn't work well at the final stage of the execution. If all the Tx data is sent out (written to the Tx FIFO) but there is some data left to receive, the Tx FIFO Empty IRQ will constantly happen until all of the requested inbound data is received. Though for a short period of time, but it will make the system less responsive. In order to fix that let's refactor the SPI transfer execution procedure by taking the Rx FIFO Full IRQ into account. We'll read and write SPI transfer data each time the IRQ happens as before. If all the outbound data is sent out, we'll disable the Tx FIFO Empty IRQ. If there is still some data to receive, we'll adjust the Rx FIFO Threshold level, so the next IRQ would be raised at the moment of all incoming data being available in the Rx FIFO. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Refactor data IO procedureSerge Semin2-23/+19
The Tx and Rx data write/read procedure can be significantly simplified by using Tx/Rx transfer lengths instead of the end pointers. By having the Tx/Rx data leftover lengths (in the number of transfer words) we can get rid of all subtraction and division operations utilized here and there in the tx_max(), rx_max(), dw_writer() and dw_reader() methods. Such modification will not only give us the more optimized IO procedures, but will make the data IO methods much more readable than before. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add DW SPI controller config structureSerge Semin2-12/+27
DW APB SSI controller can be used by the two SPI core interfaces: traditional SPI transfers and SPI memory operations. The controller needs to be accordingly configured at runtime when the corresponding operations are executed. In order to do that for the both interfaces from a single function we introduce a new data wrapper for the transfer mode, data width, number of data frames (for the automatic data transfer) and the bus frequency. It will be used by the update_config() method to tune the DW APB SSI up. The update_config() method is made exported to be used not only by the DW SPI core driver, but by the glue layer drivers too. This will be required in a coming further commit. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Update Rx sample delay in the config functionSerge Semin1-7/+6
Rx sample delay can be SPI device specific, and should be synchronously initialized with the rest of the communication and peripheral device related controller setups. So let's move the Rx-sample delay setup into the DW APB SSI configuration update method. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Simplify the SPI bus speed config procedureSerge Semin1-13/+10
The code currently responsible for the SPI communication speed setting up is a bit messy. Most likely for some historical reason the bus frequency is saved in the peripheral chip private data. It's pointless now since the custom communication speed is a SPI-transfer-specific thing and only if there is no SPI transfer data specified (like during the SPI memory operations) it can be taken from the SPI device structure. But even in the later case there is no point in having the clock divider and the SPI bus frequency saved in the chip data, because the controller can be used for both SPI-transfer-based and SPI-transfer-less communications. From software point of view keeping the current clock divider in an SPI-device specific storage may give a small performance gain (to avoid sometimes a round-up division), but in comparison to the total SPI transfer time it just doesn't worth saving a few CPU cycles in comparison to the total SPI transfer time while having the harder to read code. The only optimization, which could worth preserving in the code is to avoid unnecessary DW SPI controller registers update if it's possible. So to speak let's simplify the SPI communication speed update procedure by removing the clock-related fields from the peripheral chip data and update the DW SPI clock divider only if it's really changed. The later change is reached by keeping the effective SPI bus speed in the internal DW SPI private data. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Update SPI bus speed in a config functionSerge Semin1-14/+14
The SPI bus speed update functionality will be useful in another parts of the driver too (like to implement the SPI memory operations and from the DW SPI glue layers). Let's move it to the update_cr0() method then and since the later is now updating not only the CTRLR0 register alter its prototype to have a generic function name not related to CR0. Leave the too long line with the chip->clk_div setting as is for now, since it's going to be changed later anyway. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Detach SPI device specific CR0 config methodSerge Semin1-13/+30
Indeed there is no point in detecting the SPI peripheral device parameters and initializing the CR0 register fields each time an SPI transfer is executed. Instead let's define a dedicated CR0 chip-data member, which will be initialized in accordance with the SPI device settings at the moment of setting it up. By doing so we'll finally make the SPI device chip_data serving as it's supposed to - to preserve the SPI device specific DW SPI configuration. See spi-fsl-dspi.c, spi-pl022.c, spi-pxa2xx.c drivers for example of the way the chip data is utilized. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add DWC SSI capabilitySerge Semin4-75/+40
Currently DWC SSI core is supported by means of setting up the core-specific update_cr0() callback. It isn't suitable for multiple reasons. First of all having exported several methods doing the same thing but for different chips makes the code harder to maintain. Secondly the spi-dw-core driver exports the methods, then the spi-dw-mmio driver sets the private data callback with one of them so to be called by the core driver again. That makes the code logic too complicated. Thirdly using callbacks for just updating the CR0 register is problematic, since in case if the register needed to be updated from different parts of the code, we'd have to create another callback (for instance the SPI device-specific parameters don't need to be calculated each time the SPI transfer is submitted, so it's better to pre-calculate the CR0 data at the SPI-device setup stage). So keeping all the above in mind let's discard the update_cr0() callbacks, define a generic and static dw_spi_update_cr0() method and create the DW_SPI_CAP_DWC_SSI capability, which when enabled would activate the alternative CR0 register layout. While at it add the comments to the code path of the normal DW APB SSI controller setup to make the dw_spi_update_cr0() method looking coherent. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Use an explicit set_cs assignmentSerge Semin1-4/+4
Simplify the dw_spi_add_host() method a bit by replacing the currently implemented default set_cs callback setting up and later having it overwritten by a custom function with direct if-else-based callback assignment. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds4-68/+115
Pull vhost fixes from Michael Tsirkin: "Some last minute vhost,vdpa fixes. The last two of them haven't been in next but they do seem kind of obvious, very small and safe, fix bugs reported in the field, and they are both in a new mlx5 vdpa driver, so it's not like we can introduce regressions" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vdpa/mlx5: Fix dependency on MLX5_CORE vdpa/mlx5: should keep avail_index despite device status vhost-vdpa: fix page pinning leakage in error path vhost-vdpa: fix vhost_vdpa_map() on error condition vhost: Don't call log_access_ok() when using IOTLB vhost: Use vhost_get_used_size() in vhost_vring_set_addr() vhost: Don't call access_ok() when using IOTLB vhost vdpa: fix vhost_vdpa_open error handling
2020-10-08drm/amd/display: Change ABM config init interfaceYongqiang Sun3-6/+19
[Why & How] change abm config init interface to support multiple ABMs. Signed-off-by: Yongqiang Sun <[email protected]> Reviewed-by: Chris Park <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds26-350/+212
Pull networking fixes from Jakub Kicinski: "One more set of fixes from the networking tree: - add missing input validation in nl80211_del_key(), preventing out-of-bounds access - last minute fix / improvement of a MRP netlink (uAPI) interface introduced in 5.9 (current) release - fix "unresolved symbol" build error under CONFIG_NET w/o CONFIG_INET due to missing tcp_timewait_sock and inet_timewait_sock BTF. - fix 32 bit sub-register bounds tracking in the bpf verifier for OR case - tcp: fix receive window update in tcp_add_backlog() - openvswitch: handle DNAT tuple collision in conntrack-related code - r8169: wait for potential PHY reset to finish after applying a FW file, avoiding unexpected PHY behaviour and failures later on - mscc: fix tail dropping watermarks for Ocelot switches - avoid use-after-free in macsec code after a call to the GRO layer - avoid use-after-free in sctp error paths - add a device id for Cellient MPL200 WWAN card - rxrpc fixes: - fix the xdr encoding of the contents read from an rxrpc key - fix a BUG() for a unsupported encoding type. - fix missing _bh lock annotations. - fix acceptance handling for an incoming call where the incoming call is encrypted. - the server token keyring isn't network namespaced - it belongs to the server, so there's no need. Namespacing it means that request_key() fails to find it. - fix a leak of the server keyring" * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (21 commits) net: usb: qmi_wwan: add Cellient MPL200 card macsec: avoid use-after-free in macsec_handle_frame() r8169: consider that PHY reset may still be in progress after applying firmware openvswitch: handle DNAT tuple collision sctp: fix sctp_auth_init_hmacs() error path bridge: Netlink interface fix. net: wireless: nl80211: fix out-of-bounds access in nl80211_del_key() bpf: Fix scalar32_min_max_or bounds tracking tcp: fix receive window update in tcp_add_backlog() net: usb: rtl8150: set random MAC address when set_ethernet_addr() fails mptcp: more DATA FIN fixes net: mscc: ocelot: warn when encoding an out-of-bounds watermark value net: mscc: ocelot: divide watermark value by 60 when writing to SYS_ATOP net: qrtr: ns: Fix the incorrect usage of rcu_read_lock() rxrpc: Fix server keyring leak rxrpc: The server keyring isn't network-namespaced rxrpc: Fix accept on a connection that need securing rxrpc: Fix some missing _bh annotations on locking conn->state_lock rxrpc: Downgrade the BUG() for unsupported token type in rxrpc_read() rxrpc: Fix rxkad token xdr encoding ...
2020-10-08gpiolib: Update header block in gpiolib-cdev.hAndy Shevchenko1-1/+3
The dev_t is defined in types.h while struct gpio_device forward declaration is missed. Take into account above and update header block in gpiolib-cdev.h. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-10-08gpiolib: cdev: switch from kstrdup() to kstrndup()Kent Gibson1-14/+13
Use kstrndup() to copy line labels from the userspace provided char array, rather than ensuring the char array contains a null terminator and using kstrdup(). Note that the length provided to kstrndup() still assumes that the char array does contain a null terminator, so the maximum string length is one less than the array. This is consistent with the previous behaviour. Suggested-by: Andy Shevchenko <[email protected]> Signed-off-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-10-08docs: gpio: add a new document to its index.rstMauro Carvalho Chehab1-0/+1
There's now a new ReST file. Add it to the index.rst file. Fixes: ce7a2f77f976 ("docs: gpio: Add GPIO Aggregator documentation") Fixes: 2fd1abe99e5f ("Documentation: gpio: add documentation for gpio-mockup") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/bad4d85c218d59c1bf69157df8e1012577680d88.1601616399.git.mchehab+huawei@kernel.org Signed-off-by: Linus Walleij <[email protected]>
2020-10-08vdpa/mlx5: Fix dependency on MLX5_COREEli Cohen1-4/+3
Remove propmt for selecting MLX5_VDPA by the user and modify MLX5_VDPA_NET to select MLX5_VDPA. Also modify MLX5_VDPA_NET to depend on mlx5_core. This fixes an issue where configuration sets 'y' for MLX5_VDPA_NET while MLX5_CORE is compiled as a module causing link errors. Reported-by: kernel test robot <[email protected]> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 device")s Signed-off-by: Eli Cohen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael S. Tsirkin <[email protected]>
2020-10-08vdpa/mlx5: should keep avail_index despite device statusSi-Wei Liu1-6/+14
A VM with mlx5 vDPA has below warnings while being reset: vhost VQ 0 ring restore failed: -1: Resource temporarily unavailable (11) vhost VQ 1 ring restore failed: -1: Resource temporarily unavailable (11) We should allow userspace emulating the virtio device be able to get to vq's avail_index, regardless of vDPA device status. Save the index that was last seen when virtq was stopped, so that userspace doesn't complain. Signed-off-by: Si-Wei Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Eli Cohen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.