aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-05-21dpaa2-eth: don't print error from dpaa2_mac_connect if that's EPROBE_DEFERVladimir Oltean1-3/+4
When booting a board with DPAA2 interfaces defined statically via DPL (as opposed to creating them dynamically using restool), the driver will print an unspecific error message. This change adds the error code to the message, and avoids printing altogether if the error code is EPROBE_DEFER, because that is not a cause of alarm. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: lantiq: fix memory corruption in RX ringAleksander Jan Bajkowski1-5/+9
In a situation where memory allocation or dma mapping fails, an invalid address is programmed into the descriptor. This can lead to memory corruption. If the memory allocation fails, DMA should reuse the previous skb and mapping and drop the packet. This patch also increments rx drop counter. Fixes: fe1a56420cf2 ("net: lantiq: Add Lantiq / Intel VRX200 Ethernet driver ") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: dsa: bcm_sf2: Fix bcm_sf2_reg_rgmii_cntrl() call for non-RGMII portFlorian Fainelli1-3/+2
We cannot call bcm_sf2_reg_rgmii_cntrl() for a port that is not RGMII, yet we do that in bcm_sf2_sw_mac_link_up() irrespective of the port's interface. Move that read until we have properly qualified the PHY interface mode. This avoids triggering a warning on 7278 platforms that have GMII ports. Fixes: 55cfeb396965 ("net: dsa: bcm_sf2: add function finding RGMII register") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: core: Remove leading spaces in KconfigJuerg Haefliger1-1/+1
Remove leading spaces before tabs in Kconfig file(s) by running the following command: $ find drivers/scsi -name 'Kconfig*' | xargs sed -r -i 's/^[ ]+\t/\t/' Link: https://lore.kernel.org/r/20210517095835.81733-1-juergh@canonical.com Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21scsi: target: tcmu: Fix boolreturn.cocci warningskernel test robot1-1/+1
drivers/target/target_core_user.c:1424:9-10: WARNING: return of 0/1 in function 'tcmu_handle_completions' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci Link: https://lore.kernel.org/r/20210515230358.GA97544@60d1edce16e0 Fixes: 9814b55cde05 ("scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not found") CC: Bodo Stroesser <bostroesser@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Acked-by: Bodo Stroesser <bostroesser@gmail.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21scsi: ufs: Use designated initializers in ufs_pm_lvl_states[]Bart Van Assche2-14/+14
The comments in the enum ufs_pm_level definition are redundant. Remove the comments from the ufs_pm_level enum and use designated initializers in the ufs_pm_lvl_states[] definition instead. Link: https://lore.kernel.org/r/20210519202058.12634-3-bvanassche@acm.org Cc: Stanley Chu <stanley.chu@mediatek.com> Cc: Can Guo <cang@codeaurora.org> Cc: Bean Huo <beanhuo@micron.com> Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Asutosh Das <asutoshd@codeaurora.org> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21dpaa2-eth: name the debugfs directory after the DPNI objectIoana Ciornei1-1/+5
Name the debugfs directory after the DPNI object instead of the netdev name since this can be changed after probe by udev rules. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21dpaa2-eth: setup the of_node field of the deviceIoana Ciornei2-12/+14
When the DPNI object is connected to a DPMAC, setup the of_node to point to the DTS device node of that specific MAC. This enables other drivers, for example the DSA subsystem, to find the net_device by its device node. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: hisi_sas: Propagate errors in interrupt_init_v1_hw()Sergey Shtylyov1-6/+6
After commit 6c11dc060427 ("scsi: hisi_sas: Fix IRQ checks") we have the error codes returned by platform_get_irq() ready for the propagation upsream in interrupt_init_v1_hw() -- that will fix still broken deferred probing. Let's propagate the error codes from devm_request_irq() as well since I don't see the reason to override them with -ENOENT... Link: https://lore.kernel.org/r/49ba93a3-d427-7542-d85a-b74fe1a33a73@omp.ru Acked-by: John Garry <john.garry@huawei.com> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21net: dsa: sja1105: don't use burst SPI reads for port statisticsVladimir Oltean3-467/+597
The current internal sja1105 driver API is optimized for retrieving many statistics counters at once. But the switch does not do atomic snapshotting for them anyway. In case we start reporting the hardware port counters through ndo_get_stats64 as well, not just ethtool, it would be good to be able to read individual port counters and not all of them. Additionally, since Arnd Bergmann's commit ae1804de93f6 ("dsa: sja1105: dynamically allocate stats structure"), sja1105_get_ethtool_stats allocates memory dynamically, since struct sja1105_port_status was deemed to consume too much stack memory. That is not ideal. The large structure is only needed because of the burst read. If we read statistics one by one, we can consume less memory, and we can avoid dynamic allocation. Additionally, latency-sensitive interfaces such as PTP operations (for phc2sys) might suffer if the SPI mutex is being held for too long, which happens in the case of SPI burst reads. By reading counters one by one, we give a chance for higher priority processes to preempt and take the SPI bus mutex for accessing the PTP clock. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: dsa: sja1105: stop reporting the queue levels in ethtool port countersVladimir Oltean3-54/+2
The queue levels are not counters, but instead they represent the occupancy of the MAC TX queues. Having these in ethtool port counters is not helpful, so remove them. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: bfa: Fix inconsistent indentingJiapeng Chong1-1/+1
Eliminate the follow smatch warning: drivers/scsi/bfa/bfa_svc.c:3176 bfa_fcport_send_enable() warn: inconsistent indenting. Link: https://lore.kernel.org/r/1621590368-72041-1-git-send-email-jiapeng.chong@linux.alibaba.com Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21scsi: bfa: Fix typozuoqilin1-1/+1
Change 'chnage' to 'change'. Link: https://lore.kernel.org/r/20210521092153.379-1-zuoqilin1@163.com Signed-off-by: zuoqilin <zuoqilin@yulong.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21scsi: pmcraid: Fix typoszuoqilin1-2/+2
Change "avaibale" and "avaible" to "available". Link: https://lore.kernel.org/r/20210521082808.1925-1-zuoqilin1@163.com Signed-off-by: zuoqilin <zuoqilin@yulong.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21scsi: scsi_transport_fc: Remove double FC_FPORT_DELETED in mask creationDaniel Wagner1-1/+1
Remove the double listed FC_FPORT_DELETING from the mask creation. Commit 260f4aeddb48 ("scsi: scsi_transport_fc: return -EBUSY for deleted vport") added VC_VPORT_DELETING to the flag masks. This is not necessary as FC_FPORT_DEL is defined as VC_FPORT_DELETED | FC_FPORT_DELETING. Link: https://lore.kernel.org/r/20210520073127.132456-1-dwagner@suse.de Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21net: hns3: Fix return of uninitialized variable retColin Ian King1-0/+1
In the unlikely event that rule_cnt is zero the variable ret is not assigned a value and function hclge_dbg_dump_fd_tcam can end up returning an unitialized value in ret. Fix this by explicitly setting ret to zero before the for-loop. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: b5a0b70d77b9 ("net: hns3: refactor dump fd tcam of debugfs") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: arcmsr: Update driver version to v1.50.00.05-20210429ching Huang1-1/+1
Update driver version to v1.50.00.05-20210429. Link: https://lore.kernel.org/r/d0c6dc6431f0e46db6583dc0d04d7983b420d4da.camel@areca.com.tw Signed-off-by: ching Huang <ching2048@areca.com.tw> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21atm: Fix typozuoqilin1-1/+1
Change 'contol' to 'control'. Signed-off-by: zuoqilin <zuoqilin@yulong.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: arcmsr: Fix doorbell status being updated late on ARC-1886ching Huang1-2/+9
It is possible for the IOP to be delayed in updating the doorbell status. The doorbell status should not be 0 so loop until the value changes. Link: https://lore.kernel.org/r/afdfdf7eabecf14632492c4987a6b9ac6312a7ad.camel@areca.com.tw Signed-off-by: ching Huang <ching2048@areca.com.tw> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21net: phy: Fix inconsistent indentingJiapeng Chong1-1/+1
Eliminate the follow smatch warning: drivers/net/phy/phy_device.c:2886 phy_probe() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21sfc: farch: fix compile warning in efx_farch_dimension_resources()Yang Yingliang1-6/+7
Fix the following kernel build warning when CONFIG_SFC_SRIOV is disabled: drivers/net/ethernet/sfc/farch.c: In function ‘efx_farch_dimension_resources’: drivers/net/ethernet/sfc/farch.c:1671:21: warning: variable ‘buftbl_min’ set but not used [-Wunused-but-set-variable] unsigned vi_count, buftbl_min, total_tx_channels; Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: target: iblock: Fix smp_processor_id() BUG messagesMike Christie1-2/+2
This has us use raw_smp_processor_id() in iblock's plug_device callout. smp_processor_id() is not needed here, because we are running from a per CPU work item that is also queued to run on a worker thread that is normally bound to a specific CPU. If the worker thread did end up switching CPUs then it's handled the same way we handle when the work got moved to a different CPU's worker thread, where we will just end up sending I/O from the new CPU. Link: https://lore.kernel.org/r/20210519222640.5153-1-michael.christie@oracle.com Fixes: 415ccd9811da ("scsi: target: iblock: Add backend plug/unplug callouts") Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21scsi: qedf: Use vzalloc() instead of vmalloc()/memset(0)Yang Yingliang1-2/+1
Use vzalloc() instead of vmalloc() and memset(0) to simpify the code. Link: https://lore.kernel.org/r/20210518132018.1312995-1-yangyingliang@huawei.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21net: bonding: bond_alb: Fix some typos in bond_alb.cWang Hai1-4/+4
s/becase/because/ s/reqeusts/requests/ s/funcions/functions/ s/addreses/addresses/ Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21caif_virtio: Fix some typos in caif_virtio.cWang Hai1-3/+3
s/patckets/packets/ s/avilable/available/ s/tbe/the/ Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: libsas: Use _safe() loop in sas_resume_port()Dan Carpenter1-2/+2
If sas_notify_lldd_dev_found() fails then this code calls: sas_unregister_dev(port, dev); which removes "dev", our list iterator, from the list. This could lead to an endless loop. We need to use list_for_each_entry_safe(). Link: https://lore.kernel.org/r/YKUeq6gwfGcvvhty@mwanda Fixes: 303694eeee5e ("[SCSI] libsas: suspend / resume support") Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21net: wan: add necessary () to macro argumentPeng Li1-9/+9
Macro argument 'card' and 'port' may be better as '(card)' and '(port)' to avoid precedence issues. Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: wan: add braces {} to all arms of the statementPeng Li1-1/+2
Braces {} should be used on all arms of this statement. Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: wan: remove redundant blank linesPeng Li1-20/+0
This patch removes some redundant blank lines. Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: wan: fix the code style issue about trailing statementsPeng Li1-10/+28
Trailing statements should be on next line. Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: wan: add some required spacesPeng Li1-3/+3
Add space required after that close brace '}'. Add space required before the open parenthesis '('. Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: wan: fix an code style issue about "foo* bar"Peng Li1-5/+5
Fix the checkpatch error as "foo* bar" should be "foo *bar". Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: dsa: sja1105: adapt to a SPI controller with a limited max transfer sizeVladimir Oltean4-9/+38
The static config of the sja1105 switch is a long stream of bytes which is programmed to the hardware in chunks (portions with the chip select continuously asserted) of max 256 bytes each. Each chunk is a spi_message composed of 2 spi_transfers: the buffer with the data and a preceding buffer with the SPI access header. Only that certain SPI controllers, such as the spi-sc18is602 I2C-to-SPI bridge, cannot keep the chip select asserted for that long. The spi_max_transfer_size() and spi_max_message_size() functions are how the controller can impose its hardware limitations upon the SPI peripheral driver. For the sja1105 driver to work with these controllers, both buffers must be smaller than the transfer limit, and their sum must be smaller than the message limit. Regression-tested on a switch connected to a controller with no limitations (spi-fsl-dspi) as well as with one with caps for both max_transfer_size and max_message_size (spi-sc18is602). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: dsa: sja1105: send multiple spi_messages instead of using cs_changeVladimir Oltean1-40/+12
The sja1105 driver has been described by Mark Brown as "not using the [ SPI ] API at all idiomatically" due to the use of cs_change: https://patchwork.kernel.org/project/netdevbpf/patch/20210520135031.2969183-1-olteanv@gmail.com/ According to include/linux/spi/spi.h, the chip select is supposed to be asserted for the entire length of a SPI message, as long as cs_change is false for all member transfers. The cs_change flag changes the following: (i) When a non-final SPI transfer has cs_change = true, the chip select should temporarily deassert and then reassert starting with the next transfer. (ii) When a final SPI transfer has cs_change = true, the chip select should remain asserted until the following SPI message. The sja1105 driver only uses cs_change for its first property, to form a single SPI message whose layout can be seen below: this is an entire, single spi_message _______________________________________________________________________________________________ / \ +-------------+---------------+-------------+---------------+ ... +-------------+---------------+ | hdr_xfer[0] | chunk_xfer[0] | hdr_xfer[1] | chunk_xfer[1] | | hdr_xfer[n] | chunk_xfer[n] | +-------------+---------------+-------------+---------------+ ... +-------------+---------------+ cs_change false true false true false false ____________________________ _____________________________ _____________________________ CS line __/ \/ \ ... / \__ The fact of the matter is that spi_max_message_size() has an ambiguous meaning if any non-final transfer has cs_change = true. If the SPI master has a limitation in that it cannot keep the chip select asserted for more than, say, 200 bytes (like the spi-sc18is602), the normal thing for it to do is to implement .max_transfer_size and .max_message_size, and limit both to 200: in the "worst case" where cs_change is always false, then the controller can, indeed, not send messages larger than 200 bytes. But the fact that the SPI controller's max_message_size does not necessarily mean that we cannot send messages larger than that. Notably, if the SPI master special-cases the transfers with cs_change and treats every chip select toggling as an entirely new transaction, then a SPI message can easily exceed that limit. So there is a temptation to ignore the controller's reported max_message_size when using cs_change = true in non-final transfers. But that can lead to false conclusions. As Mark points out, the SPI controller might have a different kind of limitation with the max message size, that has nothing at all to do with how long it can keep the chip select asserted. For example, that might be the case if the device is able to offload the chip select changes to the hardware as part of the data stream, and it packs the entire stream of commands+data (corresponding to a SPI message) into a single DMA transfer that is itself limited in size. So the only thing we can do is avoid ambiguity by not using cs_change at all. Instead of sending a single spi_message, we now send multiple SPI messages as follows: spi_message 0 spi_message 1 spi_message n ____________________________ ___________________________ _____________________________ / \ / \ / \ +-------------+---------------+-------------+---------------+ ... +-------------+---------------+ | hdr_xfer[0] | chunk_xfer[0] | hdr_xfer[1] | chunk_xfer[1] | | hdr_xfer[n] | chunk_xfer[n] | +-------------+---------------+-------------+---------------+ ... +-------------+---------------+ cs_change false true false true false false ____________________________ _____________________________ _____________________________ CS line __/ \/ \ ... / \__ which is clearer because the max_message_size limit is now easier to enforce. What is transmitted on the wire stays, of course, the same. Additionally, because we send no more than 2 transfers at a time, we now avoid dynamic memory allocation too, which might be seen as an improvement by some. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: phy: add driver for Motorcomm yt8511 phyPeter Geis3-0/+143
Add a driver for the Motorcomm yt8511 phy that will be used in the production Pine64 rk3566-quartz64 development board. It supports gigabit transfer speeds, rgmii, and 125mhz clk output. Signed-off-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: ethernet: mtk_eth_soc: Fix DIM support for MT7628/88Stefan Roese1-2/+8
When updating to latest mainline for some testing on the GARDENA smart gateway based on the MT7628, I noticed that ethernet does not work any more. Commit e9229ffd550b ("net: ethernet: mtk_eth_soc: implement dynamic interrupt moderation") introduced this problem, as it missed the RX_DIM & TX_DIM configuration for this SoC variant. This patch fixes this by calling mtk_dim_rx() & mtk_dim_tx() in this case as well. Signed-off-by: Stefan Roese <sr@denx.de> Fixes: e9229ffd550b ("net: ethernet: mtk_eth_soc: implement dynamic interrupt moderation") Cc: Felix Fietkau <nbd@nbd.name> Cc: John Crispin <john@phrozen.org> Cc: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Cc: Reto Schneider <code@reto-schneider.ch> Cc: Reto Schneider <reto.schneider@husqvarnagroup.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21net: xilinx_emaclite: Do not print real IOMEM pointerYueHaibing1-3/+2
Printing kernel pointers is discouraged because they might leak kernel memory layout. This fixes smatch warning: drivers/net/ethernet/xilinx/xilinx_emaclite.c:1191 xemaclite_of_probe() warn: argument 4 to %08lX specifier is cast from pointer Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-21scsi: target: tcmu: Fix xarray RCU warningBodo Stroesser1-5/+7
Commit f5ce815f34bc ("scsi: target: tcmu: Support DATA_BLOCK_SIZE = N * PAGE_SIZE") introduced xas_next() calls to iterate xarray elements. These calls triggered the WARNING "suspicious RCU usage" at tcmu device set up [1]. In the call stack of xas_next(), xas_load() was called. According to its comment, this function requires "the xa_lock or the RCU lock". To avoid the warning: - Guard the small loop calling xas_next() in tcmu_get_empty_block with RCU lock. - In the large loop in tcmu_copy_data using RCU lock would possibly disable preemtion for a long time (copy multi MBs). Therefore replace XA_STATE, xas_set and xas_next with a single xa_load. [1] [ 1899.867091] ============================= [ 1899.871199] WARNING: suspicious RCU usage [ 1899.875310] 5.13.0-rc1+ #41 Not tainted [ 1899.879222] ----------------------------- [ 1899.883299] include/linux/xarray.h:1182 suspicious rcu_dereference_check() usage! [ 1899.890940] other info that might help us debug this: [ 1899.899082] rcu_scheduler_active = 2, debug_locks = 1 [ 1899.905719] 3 locks held by kworker/0:1/1368: [ 1899.910161] #0: ffffa1f8c8b98738 ((wq_completion)target_submission){+.+.}-{0:0}, at: process_one_work+0x1ee/0x580 [ 1899.920732] #1: ffffbd7040cd7e78 ((work_completion)(&q->sq.work)){+.+.}-{0:0}, at: process_one_work+0x1ee/0x580 [ 1899.931146] #2: ffffa1f8d1c99768 (&udev->cmdr_lock){+.+.}-{3:3}, at: tcmu_queue_cmd+0xea/0x160 [target_core_user] [ 1899.941678] stack backtrace: [ 1899.946093] CPU: 0 PID: 1368 Comm: kworker/0:1 Not tainted 5.13.0-rc1+ #41 [ 1899.953070] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018 [ 1899.962459] Workqueue: target_submission target_queued_submit_work [target_core_mod] [ 1899.970337] Call Trace: [ 1899.972839] dump_stack+0x6d/0x89 [ 1899.976222] xas_descend+0x10e/0x120 [ 1899.979875] xas_load+0x39/0x50 [ 1899.983077] tcmu_get_empty_blocks+0x115/0x1c0 [target_core_user] [ 1899.989318] queue_cmd_ring+0x1da/0x630 [target_core_user] [ 1899.994897] ? rcu_read_lock_sched_held+0x3f/0x70 [ 1899.999695] ? trace_kmalloc+0xa6/0xd0 [ 1900.003501] ? __kmalloc+0x205/0x380 [ 1900.007167] tcmu_queue_cmd+0x12f/0x160 [target_core_user] [ 1900.012746] __target_execute_cmd+0x23/0xa0 [target_core_mod] [ 1900.018589] transport_generic_new_cmd+0x1f3/0x370 [target_core_mod] [ 1900.025046] transport_handle_cdb_direct+0x34/0x50 [target_core_mod] [ 1900.031517] target_queued_submit_work+0x43/0xe0 [target_core_mod] [ 1900.037837] process_one_work+0x268/0x580 [ 1900.041952] ? process_one_work+0x580/0x580 [ 1900.046195] worker_thread+0x55/0x3b0 [ 1900.049921] ? process_one_work+0x580/0x580 [ 1900.054192] kthread+0x143/0x160 [ 1900.057499] ? kthread_create_worker_on_cpu+0x40/0x40 [ 1900.062661] ret_from_fork+0x1f/0x30 Link: https://lore.kernel.org/r/20210519135440.26773-1-bostroesser@gmail.com Fixes: f5ce815f34bc ("scsi: target: tcmu: Support DATA_BLOCK_SIZE = N * PAGE_SIZE") Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Signed-off-by: Bodo Stroesser <bostroesser@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21misc: xilinx-sdfec: Drop unnecessary NULL check after container_ofGuenter Roeck1-3/+0
container_of() only returns NULL if the passed pointer is NULL _and_ if the embedded element is the first element of the structure. Even if that is the case, testing against it is misleading and possibly dangerous because the position of the embedded element may change. In this case, the check is unnecessary since it is known that file->private_data is never NULL for an open file, and container_of() will therefore also never be NULL. Drop the check. Acked-by: Dragan Cvetic <dragan.cvetic@xilinx.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210521200457.2112041-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21scsi: target: core: Avoid smp_processor_id() in preemptible codeShin'ichiro Kawasaki1-1/+1
The BUG message "BUG: using smp_processor_id() in preemptible [00000000] code" was observed for TCMU devices with kernel config DEBUG_PREEMPT. The message was observed when blktests block/005 was run on TCMU devices with fileio backend or user:zbc backend [1]. The commit 1130b499b4a7 ("scsi: target: tcm_loop: Use LIO wq cmd submission helper") triggered the symptom. The commit modified work queue to handle commands and changed 'current->nr_cpu_allowed' at smp_processor_id() call. The message was also observed at system shutdown when TCMU devices were not cleaned up [2]. The function smp_processor_id() was called in SCSI host work queue for abort handling, and triggered the BUG message. This symptom was observed regardless of the commit 1130b499b4a7 ("scsi: target: tcm_loop: Use LIO wq cmd submission helper"). To avoid the preemptible code check at smp_processor_id(), get CPU ID with raw_smp_processor_id() instead. The CPU ID is used for performance improvement then thread move to other CPU will not affect the code. [1] [ 56.468103] run blktests block/005 at 2021-05-12 14:16:38 [ 57.369473] check_preemption_disabled: 85 callbacks suppressed [ 57.369480] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1511 [ 57.369506] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1510 [ 57.369512] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1506 [ 57.369552] caller is __target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369606] CPU: 4 PID: 1506 Comm: fio Not tainted 5.13.0-rc1+ #34 [ 57.369613] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018 [ 57.369617] Call Trace: [ 57.369621] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1507 [ 57.369628] dump_stack+0x6d/0x89 [ 57.369642] check_preemption_disabled+0xc8/0xd0 [ 57.369628] caller is __target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369655] __target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369695] target_init_cmd+0x76/0x90 [target_core_mod] [ 57.369732] tcm_loop_queuecommand+0x109/0x210 [tcm_loop] [ 57.369744] scsi_queue_rq+0x38e/0xc40 [ 57.369761] __blk_mq_try_issue_directly+0x109/0x1c0 [ 57.369779] blk_mq_try_issue_directly+0x43/0x90 [ 57.369790] blk_mq_submit_bio+0x4e5/0x5d0 [ 57.369812] submit_bio_noacct+0x46e/0x4e0 [ 57.369830] __blkdev_direct_IO_simple+0x1a3/0x2d0 [ 57.369859] ? set_init_blocksize.isra.0+0x60/0x60 [ 57.369880] generic_file_read_iter+0x89/0x160 [ 57.369898] blkdev_read_iter+0x44/0x60 [ 57.369906] new_sync_read+0x102/0x170 [ 57.369929] vfs_read+0xd4/0x160 [ 57.369941] __x64_sys_pread64+0x6e/0xa0 [ 57.369946] ? lockdep_hardirqs_on+0x79/0x100 [ 57.369958] do_syscall_64+0x3a/0x70 [ 57.369965] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 57.369973] RIP: 0033:0x7f7ed4c1399f [ 57.369979] Code: 08 89 3c 24 48 89 4c 24 18 e8 7d f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 04 24 e8 cd f3 ff ff 48 8b [ 57.369983] RSP: 002b:00007ffd7918c580 EFLAGS: 00000293 ORIG_RAX: 0000000000000011 [ 57.369990] RAX: ffffffffffffffda RBX: 00000000015b4540 RCX: 00007f7ed4c1399f [ 57.369993] RDX: 0000000000001000 RSI: 00000000015de000 RDI: 0000000000000009 [ 57.369996] RBP: 00000000015b4540 R08: 0000000000000000 R09: 0000000000000001 [ 57.369999] R10: 0000000000e5c000 R11: 0000000000000293 R12: 00007f7eb5269a70 [ 57.370002] R13: 0000000000000000 R14: 0000000000001000 R15: 00000000015b4568 [ 57.370031] CPU: 7 PID: 1507 Comm: fio Not tainted 5.13.0-rc1+ #34 [ 57.370036] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018 [ 57.370039] Call Trace: [ 57.370045] dump_stack+0x6d/0x89 [ 57.370056] check_preemption_disabled+0xc8/0xd0 [ 57.370068] __target_init_cmd+0x157/0x170 [target_core_mod] [ 57.370121] target_init_cmd+0x76/0x90 [target_core_mod] [ 57.370178] tcm_loop_queuecommand+0x109/0x210 [tcm_loop] [ 57.370197] scsi_queue_rq+0x38e/0xc40 [ 57.370224] __blk_mq_try_issue_directly+0x109/0x1c0 ... [2] [ 117.458597] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u16:8 [ 117.467279] caller is __target_init_cmd+0x157/0x170 [target_core_mod] [ 117.473893] CPU: 1 PID: 418 Comm: kworker/u16:6 Not tainted 5.13.0-rc1+ #34 [ 117.481150] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 8 [ 117.481153] Workqueue: scsi_tmf_7 scmd_eh_abort_handler [ 117.481156] Call Trace: [ 117.481158] dump_stack+0x6d/0x89 [ 117.481162] check_preemption_disabled+0xc8/0xd0 [ 117.512575] target_submit_tmr+0x41/0x150 [target_core_mod] [ 117.519705] tcm_loop_issue_tmr+0xa7/0x100 [tcm_loop] [ 117.524913] tcm_loop_abort_task+0x43/0x60 [tcm_loop] [ 117.530137] scmd_eh_abort_handler+0x7b/0x230 [ 117.534681] process_one_work+0x268/0x580 [ 117.538862] worker_thread+0x55/0x3b0 [ 117.542652] ? process_one_work+0x580/0x580 [ 117.548351] kthread+0x143/0x160 [ 117.551675] ? kthread_create_worker_on_cpu+0x40/0x40 [ 117.556873] ret_from_fork+0x1f/0x30 Link: https://lore.kernel.org/r/20210515070315.215801-1-shinichiro.kawasaki@wdc.com Fixes: 1526d9f10c61 ("scsi: target: Make state_list per CPU") Cc: stable@vger.kernel.org # v5.11+ Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21eeprom: ee1004: Let device core handle attribute eepromHeiner Kallweit1-17/+9
Instead of creating/removing the attribute ourselves, just declare the attribute and let the device core handle it. This allows to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8a6c77f2-f84a-311b-c2b9-21798f690e4d@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21drivers: base: Reduce device link removal code duplicationRafael J. Wysocki1-18/+13
Reduce device link removal code duplication between the cases when SRCU is enabled and when it is disabled by moving the only differing piece of it (which is the removal of the link from the consumer and supplier lists) into a separate wrapper function (defined differently for each of the cases in question). No intentional functional impact. Reviewed-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/4326215.LvFx2qVVIh@kreacher Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21drivers: base: Fix device link removalRafael J. Wysocki1-14/+23
When device_link_free() drops references to the supplier and consumer devices of the device link going away and the reference being dropped turns out to be the last one for any of those device objects, its ->release callback will be invoked and it may sleep which goes against the SRCU callback execution requirements. To address this issue, make the device link removal code carry out the device_link_free() actions preceded by SRCU synchronization from a separate work item (the "long" workqueue is used for that, because it does not matter when the device link memory is released and it may take time to get to that point) instead of using SRCU callbacks. While at it, make the code work analogously when SRCU is not enabled to reduce the differences between the SRCU and non-SRCU cases. Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during device link deletion") Cc: stable <stable@vger.kernel.org> Reported-by: chenxiang (M) <chenxiang66@hisilicon.com> Tested-by: chenxiang (M) <chenxiang66@hisilicon.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/5722787.lOV4Wx5bFT@kreacher Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21scsi: ufs: ufs-exynos: Move definitions from .h to .cBart Van Assche2-27/+26
In the Linux kernel definitions of data structures should occur in .c files. Hence move the exynos7_uic_attr definition from a .h into a .c file. Additionally, declare exynos_ufs_drvs static. This patch fixes the following two sparse warnings: drivers/scsi/ufs/ufs-exynos.h:248:28: warning: symbol 'exynos_ufs_drvs' was not declared. Should it be static? drivers/scsi/ufs/ufs-exynos.h:250:28: warning: symbol 'exynos7_uic_attr' was not declared. Should it be static? Link: https://lore.kernel.org/r/20210509213817.4348-1-bvanassche@acm.org Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Kiwoong Kim <kwmad.kim@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-05-21drivers/base/node.c: make CACHE_ATTR define static DEVICE_ATTR_RORuiqi Gong1-1/+1
Mark DEVICE_ATTR_RO(name) in CACHE_ATTR(name, fmt)'s definition as static to fix the following Sparse tool reports: drivers/base/node.c:239:1: warning: symbol 'dev_attr_line_size' was not declared. Should it be static? drivers/base/node.c:240:1: warning: symbol 'dev_attr_indexing' was not declared. Should it be static? Where dev_attr_{line_size,indexing} are generated by CACHE_ATTR's expansion. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ruiqi Gong <gongruiqi1@huawei.com> Link: https://lore.kernel.org/r/20210514020548.32483-1-gongruiqi1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21misc: bcm-vk: Replace zero-length array with flexible array memberGustavo A. R. Silva2-3/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Also, make use of the struct_size() helper in kzalloc(). [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20210514230801.GA35863@embeddedor Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21regulator: scmi: Fix off-by-one for linear regulators .n_voltages settingAxel Lin1-1/+1
For linear regulators, the .n_voltages is (max_uv - min_uv) / uv_step + 1. Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20210521073020.1944981-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-21scsi: snic: debugfs: remove local storage of debugfs filesGreg Kroah-Hartman2-16/+8
There is no need to keep the dentry around for the debugfs trace files, as we can just look it up when we want to remove it later on. Simplify the structure by removing the dentries and relying on debugfs to find the dentry to remove when we want to. By doing this change, we remove the last in-kernel user that was storing the result of debugfs_create_bool(), so that api can be cleaned up. Cc: Karan Tilak Kumar <kartilak@cisco.com> Cc: Sesidhar Baddela <sebaddel@cisco.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: <linux-scsi@vger.kernel.org> Link: https://lore.kernel.org/r/20210518161625.3696996-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21b43: don't save dentries for debugfsGreg Kroah-Hartman2-32/+5
There is no need to keep around the dentry pointers for the debugfs files as they will all be automatically removed when the subdir is removed. So save the space and logic involved in keeping them around by just getting rid of them entirely. By doing this change, we remove one of the last in-kernel user that was storing the result of debugfs_create_bool(), so that api can be cleaned up. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Chao Yu <chao@kernel.org> Cc: Leon Romanovsky <leon@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: b43-dev@lists.infradead.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210518163304.3702015-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21b43legacy: don't save dentries for debugfsGreg Kroah-Hartman2-27/+5
There is no need to keep around the dentry pointers for the debugfs files as they will all be automatically removed when the subdir is removed. So save the space and logic involved in keeping them around by just getting rid of them entirely. By doing this change, we remove one of the last in-kernel user that was storing the result of debugfs_create_bool(), so that api can be cleaned up. Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: b43-dev@lists.infradead.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210518163309.3702100-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.