- 25 May, 2021 3 commits
-
-
Zhen Lei authored
Fix some spelling mistakes in comments: aother ==> another Netiher ==> Neither desribe ==> describe intializing ==> initializing funciton ==> function wont ==> won't and move the word 'the' at the end to the next line accross ==> across pathes ==> paths triggerred ==> triggered excute ==> execute ether ==> either conervative ==> conservative convetion ==> convention markes ==> marks interpeter ==> interpreter Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210525025659.8898-2-thunder.leizhen@huawei.com
-
Aditya Srivastava authored
The opening comment mark '/**' is used for highlighting the beginning of kernel-doc comments. The header for samples/bpf/ibumad_kern.c follows this syntax, but the content inside does not comply with kernel-doc. This line was probably not meant for kernel-doc parsing, but is parsed due to the presence of kernel-doc like comment syntax(i.e, '/**'), which causes unexpected warnings from kernel-doc: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * ibumad BPF sample kernel side Provide a simple fix by replacing this occurrence with general comment format, i.e. '/*', to prevent kernel-doc from parsing it. Signed-off-by:
Aditya Srivastava <yashsri421@gmail.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/bpf/20210523151408.22280-1-yashsri421@gmail.com
-
Yonghong Song authored
LLVM patch https://reviews.llvm.org/D102712 narrowed the scope of existing R_BPF_64_64 and R_BPF_64_32 relocations, and added three new relocations, R_BPF_64_ABS64, R_BPF_64_ABS32 and R_BPF_64_NODYLD32. The main motivation is to make relocations linker friendly. This change, unfortunately, breaks libbpf build, and we will see errors like below: libbpf: ELF relo #0 in section #6 has unexpected type 2 in /home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_tcp_nogpl.o Error: failed to link '/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_tcp_nogpl.o': Unknown error -22 (-22) The new relocation R_BPF_64_ABS64 is generated and libbpf linker sanity check doesn't understand it. Relocation section '.rel.struct_ops' at offset 0x1410 contains 1 entries: Offset Info Type Symbol's Value Symbol's Name 0000000000000018 0000000700000002 R_BPF_64_ABS64 0000000000000000 nogpltcp_init Look at the selftests/bpf/bpf_tcp_nogpl.c, void BPF_STRUCT_OPS(nogpltcp_init, struct sock *sk) { } SEC(".struct_ops") struct tcp_congestion_ops bpf_nogpltcp = { .init = (void *)nogpltcp_init, .name = "bpf_nogpltcp", }; The new llvm relocation scheme categorizes 'nogpltcp_init' reference as R_BPF_64_ABS64 instead of R_BPF_64_64 which is used to specify ld_imm64 relocation in the new scheme. Let us fix the linker sanity checking by including R_BPF_64_ABS64 and R_BPF_64_ABS32. There is no need to check R_BPF_64_NODYLD32 which is used for .BTF and .BTF.ext. Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210522162341.3687617-1-yhs@fb.com
-
- 24 May, 2021 13 commits
-
-
Andrii Nakryiko authored
Denis Salopek says: ==================== This patch series extends the existing bpf_map_lookup_and_delete_elem() functionality with 4 more map types: - BPF_MAP_TYPE_HASH, - BPF_MAP_TYPE_PERCPU_HASH, - BPF_MAP_TYPE_LRU_HASH and - BPF_MAP_TYPE_LRU_PERCPU_HASH. Patch 1 adds most of its functionality and logic as well as documentation. As it was previously limited to only stacks and queues which do not support the BPF_F_LOCK flag, patch 2 enables its usage by adding a new libbpf API bpf_map_lookup_and_delete_elem_flags() based on the existing bpf_map_lookup_elem_flags(). Patch 3 adds selftests for lookup_and_delete_elem(). Changes in patch 1: v7: Minor formating nits, add Acked-by. v6: Remove unneeded flag check, minor code/format fixes. v5: Split patch to 3 patches. Extend BPF_MAP_LOOKUP_AND_DELETE_ELEM documentation with this changes. v4: Fix the return value for unsupported map types. v3: Add bpf_map_lookup_and_delete_elem_flags() and enable BPF_F_LOCK flag, change CHECKs to ASSERT_OKs, initialize variables to 0. v2: Add functionality for LRU/per-CPU, add test_progs tests. Changes in patch 2: v7: No change. v6: Add Acked-by. v5: Move to the newest libbpf version (0.4.0). Changes in patch 3: v7: Remove ASSERT_GE macro which is already added in some other commit, change ASSERT_OK to ASSERT_OK_PTR, add Acked-by. v6: Remove PERCPU macros, add ASSERT_GE macro to test_progs.h, remove leftover code. v5: Use more appropriate macros. Better check for changed value. ==================== Signed-off-by: -
Denis Salopek authored
Add bpf selftests and extend existing ones for a new function bpf_lookup_and_delete_elem() for (percpu) hash and (percpu) LRU hash map types. In test_lru_map and test_maps we add an element, lookup_and_delete it, then check whether it's deleted. The newly added lookup_and_delete prog tests practically do the same thing but additionally use a BPF program to change the value of the element for LRU maps. Signed-off-by:
Denis Salopek <denis.salopek@sartura.hr> Signed-off-by:
-
Denis Salopek authored
Add bpf_map_lookup_and_delete_elem_flags() libbpf API in order to use the BPF_F_LOCK flag with the map_lookup_and_delete_elem() function. Signed-off-by:
-
Denis Salopek authored
Extend the existing bpf_map_lookup_and_delete_elem() functionality to hashtab map types, in addition to stacks and queues. Create a new hashtab bpf_map_ops function that does lookup and deletion of the element under the same bucket lock and add the created map_ops to bpf.h. Signed-off-by:
-
Stanislav Fomichev authored
I'm getting the following error when running 'gen skeleton -L' as regular user: libbpf: Error in bpf_object__probe_loading():Operation not permitted(1). Couldn't load trivial BPF program. Make sure your kernel supports BPF (CONFIG_BPF_SYSCALL=y) and/or that RLIMIT_MEMLOCK is set to big enough value. Fixes: 67234743 ("libbpf: Generate loader program out of BPF ELF file.") Signed-off-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by:
-
YueHaibing authored
Issue identified with Coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Use phy_ethtool_nway_reset() since the driver makes use of the PHY library. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: r6040: Non-functional changes These two patches clean up the r6040 driver a little bit in preparation for adding additional features such as dumping MAC counters and properly dealing with DMA-API mapping. ==================== Signed-off-by: -
Florian Fainelli authored
Instead of the open coded constant 4. Signed-off-by:
-
Florian Fainelli authored
This is not a functional change, but we should be using a logical or to assign the bits we will be writing to the MDIO read and write registers. Signed-off-by:
-
YueHaibing authored
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
-
YueHaibing authored
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
-
YueHaibing authored
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
-
- 23 May, 2021 1 commit
-
-
Yang Yingliang authored
The variables will be free on path err_phy_connect, it should return error code, or it will cause double free when calling ftgmac100_remove(). Fixes: bd466c3f ("net/faraday: Support NCSI mode") Fixes: 39bfab88 ("net: ftgmac100: Add support for DT phy-handle property") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
- 21 May, 2021 23 commits
-
-
Vladimir Oltean authored
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 authored
Ioana Ciornei says: ==================== dpaa2-eth: setup the of_node This patch set allows DSA to work with a DPAA2 master device by setting up the of_node to point to the corresponding MAC DTS node, so that of_find_net_device_by_node() can find it. As an added benefit, udev rules can now be used to create a naming scheme based on the physical MAC. The second patch renames the debugfs directory to use the DPNI name instead of the netdev name, since the latter can be changed after probe time. ==================== Signed-off-by: -
Ioana Ciornei authored
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 authored
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:
-
David S. Miller authored
Vladimir Oltean says: ==================== Ethtool statistics counters cleanup for SJA1105 DSA driver This series removes some reported data from ethtool -S which were not counters at all, and reorganizes the code such that counters can be read individually and not just all at once. ==================== Signed-off-by: -
Vladimir Oltean authored
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 ae1804de ("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 authored
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:
-
Colin Ian King authored
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: b5a0b70d ("net: hns3: refactor dump fd tcam of debugfs") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
zuoqilin authored
Change 'contol' to 'control'. Signed-off-by:
zuoqilin <zuoqilin@yulong.com> Signed-off-by:
-
Jiapeng Chong authored
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:
-
Yang Yingliang authored
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: -
Wang Hai authored
s/becase/because/ s/reqeusts/requests/ s/funcions/functions/ s/addreses/addresses/ Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Wang Hai authored
s/patckets/packets/ s/avilable/available/ s/tbe/the/ Signed-off-by:
-
David S. Miller authored
Guangbin Huang says: ==================== net: wan: clean up some code style issues This patchset clean up some code style issues. ==================== Signed-off-by: -
Peng Li authored
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:
-
Peng Li authored
Braces {} should be used on all arms of this statement. Signed-off-by: -
Peng Li authored
This patch removes some redundant blank lines. Signed-off-by:
-
Peng Li authored
Trailing statements should be on next line. Signed-off-by:
-
Peng Li authored
Add space required after that close brace '}'. Add space required before the open parenthesis '('. Signed-off-by: -
Peng Li authored
Fix the checkpatch error as "foo* bar" should be "foo *bar". Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Adapt the sja1105 DSA driver to the SPI controller's transfer limits This series changes the SPI transfer procedure in sja1105 to take into consideration the buffer size limitations that the SPI controller driver might have. Changes in v2: Remove the driver's use of cs_change and send multiple, smaller SPI messages instead of a single large one. ==================== Signed-off-by: -
Vladimir Oltean authored
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 authored
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:
-
