summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-07-22spi: lantiq: Add support to Lightning Mountain SoCDilip Kota
Add support to SPI controller on Intel Atom based Lightning Mountain SoC which reuses Lantiq SPI controller IP. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/4d61a75381aca9479f9fc15d07a7b05534da6bb3.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lantiq: Move interrupt configuration to SoC specific data structureDilip Kota
Moving interrupt configuration to SoC specific data structure helps to add support for newer SoCs on which SPI controller with lesser interrupt lines compared to existing chipsets. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/7eb6d863515245fedfa0296c72082df107367d07.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lantiq: Add fifo size bit mask in SoC specific data structureDilip Kota
On newer chipsets, SPI controller has fifos of larger size. So add the fifo size bit mask entry in SoC specific data structure. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/a0889abf17a9fbc7077f10be0f0342b7ebdf9361.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lantiq: Add support to acknowledge interruptDilip Kota
On newer chipsets interrupt need to be acknowledged as they use different interrupt controller which does not acknowledge the interrupts automatically. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/608923b484d9ef239b44bb545c0b79b27030a6ae.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lantiq: Move interrupt control register offesets to SoC specific data ↵Dilip Kota
structure Address of Interrupt control registers are different on new chipsets. So move them to SoC specific data structure. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/f0f9723a30ea9c2ee48d2199f7512af9e15803b0.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lantiq: Add SMP supportDilip Kota
Existing driver supports only single core SoC. New multicore platforms uses the same driver/IP so SMP support is required. This patch adds multicore support in the driver. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/d6663296b41f102c582fda08e71f62b72ca05d5d.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lantiq: fix: Rx overflow error in full duplex modeDilip Kota
In full duplex mode, rx overflow error is observed. To overcome the error, wait until the complete data got received and proceed further. Fixes: 17f84b793c01 ("spi: lantiq-ssc: add support for Lantiq SSC SPI controller") Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Link: https://lore.kernel.org/r/efb650b0faa49a00788c4e0ca8ef7196bdba851d.1594957019.git.eswara.kota@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: spi-topcliff-pch: use generic power managementVaibhav Gupta
Drivers using legacy PM have to manage PCI states and device's PM states themselves. They also need to take care of configuration registers. With improved and powerful support of generic PM, PCI Core takes care of above mentioned, device-independent, jobs. This driver makes use of PCI helper functions like pci_save/restore_state(), pci_enable/disable_device(), pci_enable_wake() and pci_set_power_state() to do required operations. In generic mode, they are no longer needed. Change function parameter in both .suspend() and .resume() to "struct device*" type. Use dev_get_drvdata() to get drv data. Compile-tested only. Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Link: https://lore.kernel.org/r/20200720155714.714114-1-vaibhavgupta40@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: ppc4xx: Convert to use GPIO descriptorsLinus Walleij
This converts the PPC4xx SPI driver to use GPIO descriptors. The driver is already just picking some GPIOs from the device tree so the conversion is pretty straight forward. However this driver is looking form a pure "gpios" property rather than the standard binding "cs-gpios" so we need to add a new exception to the gpiolib OF parser to allow this for this driver's compatibles. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20200714072226.26071-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: spi-cadence: add support for chip select highShreyas Joshi
The spi cadence driver should support spi-cs-high in mode bits so that the peripherals that needs the chip select to be high active can use it. Add the SPI-CS-HIGH flag in the supported mode bits. Signed-off-by: Shreyas Joshi <shreyas.joshi@biamp.com> Link: https://lore.kernel.org/r/20200710211655.1564-1-shreyas.joshi@biamp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22spi: lpspi: fix the imbalance of runtime pm function callClark Wang
Call the put function after probe successfully. Otherwise, the lpspi module will keep active status until the first spi transfer called. Disable runtime pm when probe fails. There is no need to active runtime pm after probe failed. Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Link: https://lore.kernel.org/r/20200714075251.12777-2-xiaoning.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22ipvs: fix the connection sync failed in some casesguodeqing
The sync_thread_backup only checks sk_receive_queue is empty or not, there is a situation which cannot sync the connection entries when sk_receive_queue is empty and sk_rmem_alloc is larger than sk_rcvbuf, the sync packets are dropped in __udp_enqueue_schedule_skb, this is because the packets in reader_queue is not read, so the rmem is not reclaimed. Here I add the check of whether the reader_queue of the udp sock is empty or not to solve this problem. Fixes: 2276f58ac589 ("udp: use a separate rx queue for packet reception") Reported-by: zhouxudong <zhouxudong8@huawei.com> Signed-off-by: guodeqing <geffrey.guo@huawei.com> Acked-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-07-21selftest: txtimestamp: fix net ns entry logicPaolo Pisati
According to 'man 8 ip-netns', if `ip netns identify` returns an empty string, there's no net namespace associated with current PID: fix the net ns entrance logic. Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21xtensa: fix access check in csum_and_copy_from_userMax Filippov
Commit d341659f470b ("xtensa: switch to providing csum_and_copy_from_user()") introduced access check, but incorrectly tested dst instead of src. Fix access_ok argument in csum_and_copy_from_user. Cc: Al Viro <viro@zeniv.linux.org.uk> Fixes: d341659f470b ("xtensa: switch to providing csum_and_copy_from_user()") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-07-21Merge branch 'qed-suppress-irrelevant-error-messages-on-HW-init'David S. Miller
Alexander Lobakin says: ==================== qed: suppress irrelevant error messages on HW init This raises the verbosity level of several error/warning messages on driver/module initialization, most of which are false-positives, and the one actively spamming the log for no reason. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21qed: suppress false-positives interrupt error messages on HW initAlexander Lobakin
It was found that qed_pglueb_rbc_attn_handler() can produce a lot of false-positive error detections on driver load/reload (especially after crashes/recoveries) and spam the kernel log: [ 4.958275] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d00ff0 [ 2079.146764] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0 [ 2116.374631] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0 [ 2135.250564] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0 [...] Reduce the logging level of two false-positive prone error messages from notice to verbose on initialization (only) to not mix it with real error attentions while debugging. Fixes: 666db4862f2d ("qed: Revise load sequence to avoid PCI errors") Signed-off-by: Alexander Lobakin <alobakin@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21qed: suppress "don't support RoCE & iWARP" flooding on HW initAlexander Lobakin
Change the verbosity of the "don't support RoCE & iWARP simultaneously" warning to debug level to stop flooding on driver/hardware initialization: [ 4.783230] qede 01:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth0] [ 4.810020] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 4.861186] qede 01:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth1] [ 4.893311] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 5.181713] qede a1:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth2] [ 5.224740] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 5.276449] qede a1:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth3] [ 5.318671] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 5.369548] qede a1:00.02: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth4] [ 5.411645] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only Fixes: e0a8f9de16fc ("qed: Add iWARP enablement support") Signed-off-by: Alexander Lobakin <alobakin@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21fs-verity: use smp_load_acquire() for ->i_verity_infoEric Biggers
Normally smp_store_release() or cmpxchg_release() is paired with smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with the more lightweight READ_ONCE(). However, for this to be safe, all the published memory must only be accessed in a way that involves the pointer itself. This may not be the case if allocating the object also involves initializing a static or global variable, for example. fsverity_info::tree_params.hash_alg->tfm is a crypto_ahash object that's internal to and is allocated by the crypto subsystem. So by using READ_ONCE() for ->i_verity_info, we're relying on internal implementation details of the crypto subsystem. Remove this fragile assumption by using smp_load_acquire() instead. Also fix the cmpxchg logic to correctly execute an ACQUIRE barrier when losing the cmpxchg race, since cmpxchg doesn't guarantee a memory barrier on failure. (Note: I haven't seen any real-world problems here. This change is just fixing the code to be guaranteed correct and less fragile.) Fixes: fd2d1acfcadf ("fs-verity: add the hook for file ->open()") Link: https://lore.kernel.org/r/20200721225920.114347-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-07-21fscrypt: use smp_load_acquire() for ->i_crypt_infoEric Biggers
Normally smp_store_release() or cmpxchg_release() is paired with smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with the more lightweight READ_ONCE(). However, for this to be safe, all the published memory must only be accessed in a way that involves the pointer itself. This may not be the case if allocating the object also involves initializing a static or global variable, for example. fscrypt_info includes various sub-objects which are internal to and are allocated by other kernel subsystems such as keyrings and crypto. So by using READ_ONCE() for ->i_crypt_info, we're relying on internal implementation details of these other kernel subsystems. Remove this fragile assumption by using smp_load_acquire() instead. (Note: I haven't seen any real-world problems here. This change is just fixing the code to be guaranteed correct and less fragile.) Fixes: e37a784d8b6a ("fscrypt: use READ_ONCE() to access ->i_crypt_info") Link: https://lore.kernel.org/r/20200721225920.114347-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-07-21fscrypt: use smp_load_acquire() for ->s_master_keysEric Biggers
Normally smp_store_release() or cmpxchg_release() is paired with smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with the more lightweight READ_ONCE(). However, for this to be safe, all the published memory must only be accessed in a way that involves the pointer itself. This may not be the case if allocating the object also involves initializing a static or global variable, for example. super_block::s_master_keys is a keyring, which is internal to and is allocated by the keyrings subsystem. By using READ_ONCE() for it, we're relying on internal implementation details of the keyrings subsystem. Remove this fragile assumption by using smp_load_acquire() instead. (Note: I haven't seen any real-world problems here. This change is just fixing the code to be guaranteed correct and less fragile.) Fixes: 22d94f493bfb ("fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl") Link: https://lore.kernel.org/r/20200721225920.114347-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-07-21fscrypt: use smp_load_acquire() for fscrypt_prepared_keyEric Biggers
Normally smp_store_release() or cmpxchg_release() is paired with smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with the more lightweight READ_ONCE(). However, for this to be safe, all the published memory must only be accessed in a way that involves the pointer itself. This may not be the case if allocating the object also involves initializing a static or global variable, for example. fscrypt_prepared_key includes a pointer to a crypto_skcipher object, which is internal to and is allocated by the crypto subsystem. By using READ_ONCE() for it, we're relying on internal implementation details of the crypto subsystem. Remove this fragile assumption by using smp_load_acquire() instead. (Note: I haven't seen any real-world problems here. This change is just fixing the code to be guaranteed correct and less fragile.) Fixes: 5fee36095cda ("fscrypt: add inline encryption support") Cc: Satya Tangirala <satyat@google.com> Link: https://lore.kernel.org/r/20200721225920.114347-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-07-21fscrypt: switch fscrypt_do_sha256() to use the SHA-256 libraryEric Biggers
fscrypt_do_sha256() is only used for hashing encrypted filenames to create no-key tokens, which isn't performance-critical. Therefore a C implementation of SHA-256 is sufficient. Also, the logic to create no-key tokens is always potentially needed. This differs from fscrypt's other dependencies on crypto API algorithms, which are conditionally needed depending on what encryption policies userspace is using. Therefore, for fscrypt there isn't much benefit to allowing SHA-256 to be a loadable module. So, make fscrypt_do_sha256() use the SHA-256 library instead of the crypto_shash API. This is much simpler, since it avoids having to implement one-time-init (which is hard to do correctly, and in fact was implemented incorrectly) and handle failures to allocate the crypto_shash object. Fixes: edc440e3d27f ("fscrypt: improve format of no-key names") Cc: Daniel Rosenberg <drosen@google.com> Link: https://lore.kernel.org/r/20200721225920.114347-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-07-21netdevsim: fix unbalaced locking in nsim_create()Taehee Yoo
In the nsim_create(), rtnl_lock() is called before nsim_bpf_init(). If nsim_bpf_init() is failed, rtnl_unlock() should be called, but it isn't called. So, unbalanced locking would occur. Fixes: e05b2d141fef ("netdevsim: move netdev creation/destruction to dev probe") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: dsa: microchip: call phy_remove_link_mode during probeHelmut Grohne
When doing "ip link set dev ... up" for a ksz9477 backed link, ksz9477_phy_setup is called and it calls phy_remove_link_mode to remove 1000baseT HDX. During phy_remove_link_mode, phy_advertise_supported is called. Doing so reverts any previous change to advertised link modes e.g. using a udevd .link file. phy_remove_link_mode is not meant to be used while opening a link and should be called during phy probe when the link is not yet available to userspace. Therefore move the phy_remove_link_mode calls into ksz9477_switch_register. It indirectly calls dsa_register_switch, which creates the relevant struct phy_devices and we update the link modes right after that. At that time dev->features is already initialized by ksz9477_switch_detect. Remove phy_setup from ksz_dev_ops as no users remain. Link: https://lore.kernel.org/netdev/20200715192722.GD1256692@lunn.ch/ Fixes: 42fc6a4c613019 ("net: dsa: microchip: prepare PHY for proper advertisement") Signed-off-by: Helmut Grohne <helmut.grohne@intenta.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21Merge branch 'hns3-fixes'David S. Miller
Huazhong Tan says: ==================== net: hns3: fixes for -net There are some bugfixes for the HNS3 ethernet driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix return value error when query MAC link status failJian Shen
Currently, PF queries the MAC link status per second by calling function hclge_get_mac_link_status(). It return the error code when failed to send cmdq command to firmware. It's incorrect, because this return value is used as the MAC link status, which 0 means link down, and none-zero means link up. So fixes it. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix error handling for desc fillingYunsheng Lin
The content of the TX desc is automatically cleared by the HW when the HW has sent out the packet to the wire. When desc filling fails in hns3_nic_net_xmit(), it will call hns3_clear_desc() to do the error handling, which miss zeroing of the TX desc and the checking if a unmapping is needed. So add the zeroing and checking in hns3_clear_desc() to avoid the above problem. Also add DESC_TYPE_UNKNOWN to indicate the info in desc_cb is not valid, because hns3_nic_reclaim_desc() may treat the desc_cb->type of zero as packet and add to the sent pkt statistics accordingly. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix for not calculating TX BD send size correctlyYunsheng Lin
With GRO and fraglist support, the SKB can be aggregated to a total size of 65535, and when that SKB is forwarded through a bridge, the size of the SKB may be pushed to exceed the size of 65535 when br_dev_queue_push_xmit() is called. The max send size of BD supported by the HW is 65535, when a SKB with a headlen of over 65535 is sent to the driver, the driver needs to use multi BD to send the linear data, and the send size of the last BD is calculated incorrectly by the driver who is using '&' operation, which causes a TX error. Use '%' operation to fix this problem. Fixes: 3fe13ed95dd3 ("net: hns3: avoid mult + div op in critical data path") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix for not unmapping TX buffer correctlyYunsheng Lin
When a big TX buffer is sent using multi BD, the driver maps the whole TX buffer, and unmaps it using info in desc_cb corresponding to each BD, but only the info in the desc_cb of first BD is correct, other info in desc_cb is wrong, which causes TX unmapping problem when SMMU is on. Only set the mapping and freeing info in the desc_cb of first BD to fix this problem, because the TX buffer only need to be unmapped and freed once. Fixes: 1e8a7977d09f("net: hns3: add handling for big TX fragment") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huzhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21spi: dw-dma: Fix Tx DMA channel working too fastSerge Semin
It turns out having a Rx DMA channel serviced with higher priority than a Tx DMA channel is not enough to provide a well balanced DMA-based SPI transfer interface. There might still be moments when the Tx DMA channel is occasionally handled faster than the Rx DMA channel. That in its turn will eventually cause the SPI Rx FIFO overflow if SPI bus speed is high enough to fill the SPI Rx FIFO in before it's cleared by the Rx DMA channel. That's why having the DMA-based SPI Tx interface too optimized is the errors prone, so the commit 0b2b66514fc9 ("spi: dw: Use DMA max burst to set the request thresholds") though being perfectly normal from the standard functionality point of view implicitly introduced the problem described above. In order to fix that the Tx DMA activity is intentionally slowed down by limiting the SPI Tx FIFO depth with a value twice bigger than the Tx burst length calculated earlier by the dw_spi_dma_maxburst_init() method. Fixes: 0b2b66514fc9 ("spi: dw: Use DMA max burst to set the request thresholds") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Feng Tang <feng.tang@intel.com> Link: https://lore.kernel.org/r/20200721203951.2159-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-21net: udp: Fix wrong clean up for IS_UDPLITE macroMiaohe Lin
We can't use IS_UDPLITE to replace udp_sk->pcflag when UDPLITE_RECV_CC is checked. Fixes: b2bf1e2659b1 ("[UDP]: Clean up for IS_UDPLITE macro") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net-sysfs: add a newline when printing 'tx_timeout' by sysfsXiongfeng Wang
When I cat 'tx_timeout' by sysfs, it displays as follows. It's better to add a newline for easy reading. root@syzkaller:~# cat /sys/devices/virtual/net/lo/queues/tx-0/tx_timeout 0root@syzkaller:~# Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: ethernet: ravb: exit if re-initialization fails in tx timeoutYoshihiro Shimoda
According to the report of [1], this driver is possible to cause the following error in ravb_tx_timeout_work(). ravb e6800000.ethernet ethernet: failed to switch device to config mode This error means that the hardware could not change the state from "Operation" to "Configuration" while some tx and/or rx queue are operating. After that, ravb_config() in ravb_dmac_init() will fail, and then any descriptors will be not allocaled anymore so that NULL pointer dereference happens after that on ravb_start_xmit(). To fix the issue, the ravb_tx_timeout_work() should check the return values of ravb_stop_dma() and ravb_dmac_init(). If ravb_stop_dma() fails, ravb_tx_timeout_work() re-enables TX and RX and just exits. If ravb_dmac_init() fails, just exits. [1] https://lore.kernel.org/linux-renesas-soc/20200518045452.2390-1-dirk.behme@de.bosch.com/ Reported-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21Merge branch 'udp-Fix-reuseport-selection-with-connected-sockets'David S. Miller
Kuniyuki Iwashima says: ==================== udp: Fix reuseport selection with connected sockets. This patch set addresses two issues which happen when both connected and unconnected sockets are in the same UDP reuseport group. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21udp: Improve load balancing for SO_REUSEPORT.Kuniyuki Iwashima
Currently, SO_REUSEPORT does not work well if connected sockets are in a UDP reuseport group. Then reuseport_has_conns() returns true and the result of reuseport_select_sock() is discarded. Also, unconnected sockets have the same score, hence only does the first unconnected socket in udp_hslot always receive all packets sent to unconnected sockets. So, the result of reuseport_select_sock() should be used for load balancing. The noteworthy point is that the unconnected sockets placed after connected sockets in sock_reuseport.socks will receive more packets than others because of the algorithm in reuseport_select_sock(). index | connected | reciprocal_scale | result --------------------------------------------- 0 | no | 20% | 40% 1 | no | 20% | 20% 2 | yes | 20% | 0% 3 | no | 20% | 40% 4 | yes | 20% | 0% If most of the sockets are connected, this can be a problem, but it still works better than now. Fixes: acdcecc61285 ("udp: correct reuseport selection with connected sockets") CC: Willem de Bruijn <willemb@google.com> Reviewed-by: Benjamin Herrenschmidt <benh@amazon.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21udp: Copy has_conns in reuseport_grow().Kuniyuki Iwashima
If an unconnected socket in a UDP reuseport group connect()s, has_conns is set to 1. Then, when a packet is received, udp[46]_lib_lookup2() scans all sockets in udp_hslot looking for the connected socket with the highest score. However, when the number of sockets bound to the port exceeds max_socks, reuseport_grow() resets has_conns to 0. It can cause udp[46]_lib_lookup2() to return without scanning all sockets, resulting in that packets sent to connected sockets may be distributed to unconnected sockets. Therefore, reuseport_grow() should copy has_conns. Fixes: acdcecc61285 ("udp: correct reuseport selection with connected sockets") CC: Willem de Bruijn <willemb@google.com> Reviewed-by: Benjamin Herrenschmidt <benh@amazon.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21arm64: dts: amlogic: meson-g12: add the Mali OPP table and use DVFSMartin Blumenstingl
Add the OPP table for the Mali Bifrost GPU and drop the hardcoded initial clock configuration. This enables GPU DVFS and thus saves power when the GPU is not in use while still being able switch to a higher clock on demand. Set the GP0_PLL clock to 744MHz (which is the only frequency which cannot be derived from the FCLK dividers) as the clock driver avoids setting the parent clock rates so the HIFI PLL clock isn't changed (as that's reserved for audio). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200719173213.639540-4-martin.blumenstingl@googlemail.com
2020-07-21arm64: dts: amlogic: meson-gxm: add the Mali OPP table and use DVFSMartin Blumenstingl
Add the OPP table for the Mali-T820 GPU and drop the hardcoded initial clock configuration. This enables GPU DVFS and thus saves power when the GPU is not in use while still being able switch to a higher clock on demand. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200719173213.639540-3-martin.blumenstingl@googlemail.com
2020-07-21arm64: dts: amlogic: meson-gx: add the Mali-450 OPP table and use DVFSMartin Blumenstingl
Add the OPP table for the Mali-450 GPU and drop the hardcoded initial clock configuration. This enables GPU DVFS and thus saves power when the GPU is not in use while still being able switch to a higher clock on demand. Set the GP0_PLL clock to 744MHz (which is the only frequency which cannot be derived from the FCLK dividers) as the clock driver avoids setting the parent clock rates so the MPLL clocks aren't changed (as these are reserved for audio). The only exception to this is the GXL S805X package because the 744MHz OPP isn't working correctly there. While here, make most of meson-gxl-mali re-usable to reduce the amount of duplicate code between GXBB and GXL. This is more important now as we don't want to duplicate the GPU OPP table. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200719173213.639540-2-martin.blumenstingl@googlemail.com
2020-07-21Merge tag 'amlogic-fixes' into v5.9/dt64Kevin Hilman
Amlogic fixes for v5.8-rc - misc DT fixes, and SoC ID fixes
2020-07-21regulator: convert QCOM SMD-RPM regulator document to YAML schemaKathiravan T
Convert qcom,smd-rpm-regulator.txt document to YAML schema Signed-off-by: Kathiravan T <kathirav@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1595225543-12127-5-git-send-email-kathirav@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-21arm64: dts: meson: add support for the WeTek Core 2Christian Hewitt
The WeTek Core2 is a commercial device based on the Amlogic Q200 reference design but with the following differences: - 3GB RAM, 32GB eMMC - Blue and Red LEDs used to signal on/off status - uart_AO can be accessed after opening the case; soldering required - USB OTG is not accessible (inside the case) - Realtek RTL8152 Ethernet (internal USB connection) Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200719021421.7959-3-christianshewitt@gmail.com
2020-07-21dt-bindings: arm: amlogic: add support for the WeTek Core 2Christian Hewitt
The WeTek Core 2 is a commercial Android device based on the Amlogic Q200 reference design using the S912-H chipset. Specs: 3GB DDR3 RAM 32GB eMMC storage 10/100 Ethernet using Realtek RTL8152 (internal USB) 802.11 a/b/g/n/ac + BT 4.1 sdio wireless module (AP6356S) 2x single colour LEDs to indicate power 1x power button 1x reset button on the underside of the box HDMI 2.0 (4k@60p) video Composite video + 2-channel audio output on 3.5mm jack S/PDIF audio output 2x USB 2.0 ports 1x USB OTG port (internal) 1x micro SD card slot UART pins (internal) IR Sensor Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200719021421.7959-2-christianshewitt@gmail.com
2020-07-21arm64: dts: meson: add audio playback to khadas-vim3lChristian Hewitt
Add initial audio support limited to HDMI i2s, copying the config from the existing VIM3 device-tree. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200718072532.8427-3-christianshewitt@gmail.com
2020-07-21arm64: dts: meson: add audio playback to odroid-c4Christian Hewitt
Add initial audio support limited to HDMI i2s. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200718072532.8427-2-christianshewitt@gmail.com
2020-07-21btrfs: fix mount failure caused by race with umountBoris Burkov
It is possible to cause a btrfs mount to fail by racing it with a slow umount. The crux of the sequence is generic_shutdown_super not yet calling sop->put_super before btrfs_mount_root calls btrfs_open_devices. If that occurs, btrfs_open_devices will decide the opened counter is non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to 0. From here, mount will call sget which will result in grab_super trying to take the super block umount semaphore. That semaphore will be held by the slow umount, so mount will block. Before up-ing the semaphore, umount will delete the super block, resulting in mount's sget reliably allocating a new one, which causes the mount path to dutifully fill it out, and increment total_rw_bytes a second time, which causes the mount to fail, as we see double the expected bytes. Here is the sequence laid out in greater detail: CPU0 CPU1 down_write sb->s_umount btrfs_kill_super kill_anon_super(sb) generic_shutdown_super(sb); shrink_dcache_for_umount(sb); sync_filesystem(sb); evict_inodes(sb); // SLOW btrfs_mount_root btrfs_scan_one_device fs_devices = device->fs_devices fs_info->fs_devices = fs_devices // fs_devices-opened makes this a no-op btrfs_open_devices(fs_devices, mode, fs_type) s = sget(fs_type, test, set, flags, fs_info); find sb in s_instances grab_super(sb); down_write(&s->s_umount); // blocks sop->put_super(sb) // sb->fs_devices->opened == 2; no-op spin_lock(&sb_lock); hlist_del_init(&sb->s_instances); spin_unlock(&sb_lock); up_write(&sb->s_umount); return 0; retry lookup don't find sb in s_instances (deleted by CPU0) s = alloc_super return s; btrfs_fill_super(s, fs_devices, data) open_ctree // fs_devices total_rw_bytes improperly set! btrfs_read_chunk_tree read_one_dev // increment total_rw_bytes again!! super_total_bytes < fs_devices->total_rw_bytes // ERROR!!! To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree before the calls to read_one_dev, while holding the sb umount semaphore and the uuid mutex. To reproduce, it is sufficient to dirty a decent number of inodes, then quickly umount and mount. for i in $(seq 0 500) do dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1 done umount /mnt/foo& mount /mnt/foo does the trick for me. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2020-07-21btrfs: fix page leaks after failure to lock page for delallocRobbie Ko
When locking pages for delalloc, we check if it's dirty and mapping still matches. If it does not match, we need to return -EAGAIN and release all pages. Only the current page was put though, iterate over all the remaining pages too. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Robbie Ko <robbieko@synology.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2020-07-21btrfs: qgroup: fix data leak caused by race between writeback and truncateQu Wenruo
[BUG] When running tests like generic/013 on test device with btrfs quota enabled, it can normally lead to data leak, detected at unmount time: BTRFS warning (device dm-3): qgroup 0/5 has unreleased space, type 0 rsv 4096 ------------[ cut here ]------------ WARNING: CPU: 11 PID: 16386 at fs/btrfs/disk-io.c:4142 close_ctree+0x1dc/0x323 [btrfs] RIP: 0010:close_ctree+0x1dc/0x323 [btrfs] Call Trace: btrfs_put_super+0x15/0x17 [btrfs] generic_shutdown_super+0x72/0x110 kill_anon_super+0x18/0x30 btrfs_kill_super+0x17/0x30 [btrfs] deactivate_locked_super+0x3b/0xa0 deactivate_super+0x40/0x50 cleanup_mnt+0x135/0x190 __cleanup_mnt+0x12/0x20 task_work_run+0x64/0xb0 __prepare_exit_to_usermode+0x1bc/0x1c0 __syscall_return_slowpath+0x47/0x230 do_syscall_64+0x64/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ---[ end trace caf08beafeca2392 ]--- BTRFS error (device dm-3): qgroup reserved space leaked [CAUSE] In the offending case, the offending operations are: 2/6: writev f2X[269 1 0 0 0 0] [1006997,67,288] 0 2/7: truncate f2X[269 1 0 0 48 1026293] 18388 0 The following sequence of events could happen after the writev(): CPU1 (writeback) | CPU2 (truncate) ----------------------------------------------------------------- btrfs_writepages() | |- extent_write_cache_pages() | |- Got page for 1003520 | | 1003520 is Dirty, no writeback | | So (!clear_page_dirty_for_io()) | | gets called for it | |- Now page 1003520 is Clean. | | | btrfs_setattr() | | |- btrfs_setsize() | | |- truncate_setsize() | | New i_size is 18388 |- __extent_writepage() | | |- page_offset() > i_size | |- btrfs_invalidatepage() | |- Page is clean, so no qgroup | callback executed This means, the qgroup reserved data space is not properly released in btrfs_invalidatepage() as the page is Clean. [FIX] Instead of checking the dirty bit of a page, call btrfs_qgroup_free_data() unconditionally in btrfs_invalidatepage(). As qgroup rsv are completely bound to the QGROUP_RESERVED bit of io_tree, not bound to page status, thus we won't cause double freeing anyway. Fixes: 0b34c261e235 ("btrfs: qgroup: Prevent qgroup->reserved from going subzero") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2020-07-21drm/amdgpu: Fix NULL dereference in dpm sysfs handlersPaweł Gronowski
NULL dereference occurs when string that is not ended with space or newline is written to some dpm sysfs interface (for example pp_dpm_sclk). This happens because strsep replaces the tmp with NULL if the delimiter is not present in string, which is then dereferenced by tmp[0]. Reproduction example: sudo sh -c 'echo -n 1 > /sys/class/drm/card0/device/pp_dpm_sclk' Signed-off-by: Paweł Gronowski <me@woland.xyz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-07-21drm/amd/powerplay: fix a crash when overclocking Vega MQiu Wenbo
Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and vddci_voltage_table is empty. It has been tested on Intel Hades Canyon (i7-8809G). Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208489 Fixes: ac7822b0026f ("drm/amd/powerplay: add smumgr support for VEGAM (v2)") Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Qiu Wenbo <qiuwenbo@phytium.com.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-09-19 08:35:30 +0000