aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
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-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>
2021-05-21Merge 50f09a3dd587 ("Merge tag 'char-misc-5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc") into char-misc-nextGreg Kroah-Hartman16-128/+123
We want the char/misc driver fixes in here as well Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-20net: cdc_ncm: use DEVICE_ATTR_RW macroYueHaibing1-12/+24
Use DEVICE_ATTR_RW helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: usb: hso: use DEVICE_ATTR_RO macroYueHaibing1-4/+3
Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: stmmac: fix system hang if change mac address after interface ifdownJoakim Zhang1-1/+10
Fix system hang with below sequences: ~# ifconfig ethx down ~# ifconfig ethx hw ether xx:xx:xx:xx:xx:xx After ethx down, stmmac all clocks gated off and then register access causes system hang. Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver") Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: stmmac: correct clocks enabled in stmmac_vlan_rx_kill_vid()Joakim Zhang1-6/+6
This should be a mistake to fix conflicts when removing RFC tag to repost the patch. Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver") Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net/qla3xxx: fix schedule while atomic in ql_sem_spinlockZheyu Ma1-1/+1
When calling the 'ql_sem_spinlock', the driver has already acquired the spin lock, so the driver should not call 'ssleep' in atomic context. This bug can be fixed by using 'mdelay' instead of 'ssleep'. The KASAN's log reveals it: [ 3.238124 ] BUG: scheduling while atomic: swapper/0/1/0x00000002 [ 3.238748 ] 2 locks held by swapper/0/1: [ 3.239151 ] #0: ffff88810177b240 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x41/0x60 [ 3.240026 ] #1: ffff888107c60e28 (&qdev->hw_lock){....}-{2:2}, at: ql3xxx_probe+0x2aa/0xea0 [ 3.240873 ] Modules linked in: [ 3.241187 ] irq event stamp: 460854 [ 3.241541 ] hardirqs last enabled at (460853): [<ffffffff843051bf>] _raw_spin_unlock_irqrestore+0x4f/0x70 [ 3.242245 ] hardirqs last disabled at (460854): [<ffffffff843058ca>] _raw_spin_lock_irqsave+0x2a/0x70 [ 3.242245 ] softirqs last enabled at (446076): [<ffffffff846002e4>] __do_softirq+0x2e4/0x4b1 [ 3.242245 ] softirqs last disabled at (446069): [<ffffffff811ba5e0>] irq_exit_rcu+0x100/0x110 [ 3.242245 ] Preemption disabled at: [ 3.242245 ] [<ffffffff828ca5ba>] ql3xxx_probe+0x2aa/0xea0 [ 3.242245 ] Kernel panic - not syncing: scheduling while atomic [ 3.242245 ] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00145 -gee7dc339169-dirty #16 [ 3.242245 ] Call Trace: [ 3.242245 ] dump_stack+0xba/0xf5 [ 3.242245 ] ? ql3xxx_probe+0x1f0/0xea0 [ 3.242245 ] panic+0x15a/0x3f2 [ 3.242245 ] ? vprintk+0x76/0x150 [ 3.242245 ] ? ql3xxx_probe+0x2aa/0xea0 [ 3.242245 ] __schedule_bug+0xae/0xe0 [ 3.242245 ] __schedule+0x72e/0xa00 [ 3.242245 ] schedule+0x43/0xf0 [ 3.242245 ] schedule_timeout+0x28b/0x500 [ 3.242245 ] ? del_timer_sync+0xf0/0xf0 [ 3.242245 ] ? msleep+0x2f/0x70 [ 3.242245 ] msleep+0x59/0x70 [ 3.242245 ] ql3xxx_probe+0x307/0xea0 [ 3.242245 ] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [ 3.242245 ] ? pci_device_remove+0x110/0x110 [ 3.242245 ] local_pci_probe+0x45/0xa0 [ 3.242245 ] pci_device_probe+0x12b/0x1d0 [ 3.242245 ] really_probe+0x2a9/0x610 [ 3.242245 ] driver_probe_device+0x90/0x1d0 [ 3.242245 ] ? mutex_lock_nested+0x1b/0x20 [ 3.242245 ] device_driver_attach+0x68/0x70 [ 3.242245 ] __driver_attach+0x124/0x1b0 [ 3.242245 ] ? device_driver_attach+0x70/0x70 [ 3.242245 ] bus_for_each_dev+0xbb/0x110 [ 3.242245 ] ? rdinit_setup+0x45/0x45 [ 3.242245 ] driver_attach+0x27/0x30 [ 3.242245 ] bus_add_driver+0x1eb/0x2a0 [ 3.242245 ] driver_register+0xa9/0x180 [ 3.242245 ] __pci_register_driver+0x82/0x90 [ 3.242245 ] ? yellowfin_init+0x25/0x25 [ 3.242245 ] ql3xxx_driver_init+0x23/0x25 [ 3.242245 ] do_one_initcall+0x7f/0x3d0 [ 3.242245 ] ? rdinit_setup+0x45/0x45 [ 3.242245 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.242245 ] kernel_init_freeable+0x2aa/0x301 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] kernel_init+0x18/0x190 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] ? rest_init+0x2c0/0x2c0 [ 3.242245 ] ret_from_fork+0x1f/0x30 [ 3.242245 ] Dumping ftrace buffer: [ 3.242245 ] (ftrace buffer empty) [ 3.242245 ] Kernel Offset: disabled [ 3.242245 ] Rebooting in 1 seconds. Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20ibmvnic: remove default label from to_string switchMichal Suchanek1-4/+2
This way the compiler warns when a new value is added to the enum but not to the string translation like: drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string': drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value 'VNIC_FOOBAR' not handled in switch [-Wswitch] switch (state) { ^~~~~~ drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string': drivers/net/ethernet/ibm/ibmvnic.c:1935:2: warning: enumeration value 'VNIC_RESET_FOOBAR' not handled in switch [-Wswitch] switch (reason) { ^~~~~~ Signed-off-by: Michal Suchanek <msuchanek@suse.de> Acked-by: Lijun Pan <lijunp213@gmail.com> Link: https://lore.kernel.org/netdev/CAOhMmr701LecfuNM+EozqbiTxFvDiXjFdY2aYeKJYaXq9kqVDg@mail.gmail.com/ Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: bonding: use tabs instead of space for code indentYufeng Mo1-1/+1
Code indent should use tabs where possible, so use tabs instead of space for code indent. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: bonding: remove unnecessary bracesYufeng Mo2-4/+2
Braces {} are not necessary for single statement blocks, so remove these braces {}. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: bonding: fix code indent for conditional statementsYufeng Mo1-1/+1
Fix incorrect code indent for conditional statements. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: bonding: add some required blank linesYufeng Mo4-0/+13
Add some blank lines after declarations as required. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: encx24j600: fix kernel-doc syntax in file headersAditya Srivastava2-2/+2
The opening comment mark '/**' is used for highlighting the beginning of kernel-doc comments. The header for drivers/net/ethernet/microchip/encx24j600 files 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 warning from kernel-doc. For e.g., running scripts/kernel-doc -none drivers/net/ethernet/microchip/encx24j600_hw.h emits: warning: expecting prototype for h(). Prototype was for _ENCX24J600_HW_H() instead Provide a simple fix by replacing such occurrences with general comment format, i.e. '/*', to prevent kernel-doc from parsing it. Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20ixgbe: fix large MTU request from VFJesse Brandeburg1-9/+7
Check that the MTU value requested by the VF is in the supported range of MTUs before attempting to set the VF large packet enable, otherwise reject the request. This also avoids unnecessary register updates in the case of the 82599 controller. Fixes: 872844ddb9e4 ("ixgbe: Enable jumbo frames support w/ SR-IOV") Co-developed-by: Piotr Skajewski <piotrx.skajewski@intel.com> Signed-off-by: Piotr Skajewski <piotrx.skajewski@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Co-developed-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller5-127/+681
Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-05-20 This series contains updates to igc driver only. Andre Guedes says: This series adds AF_XDP zero-copy feature to igc driver. The initial patches do some code refactoring, preparing the code base to land the AF_XDP zero-copy feature, avoiding code duplications. The last patches of the series are the ones implementing the feature. The last patch which indeed implements AF_XDP zero-copy support was originally way too lengthy so, for the sake of code review, I broke it up into two patches: one adding support for the RX functionality and the other one adding TX support. --- v2: Patch 8/9 - "igc: Enable RX via AF_XDP zero-copy" * In XDP_PASS flow, copy metadata too into the skb. * When HW timestamp is added by the NIC, after copying it into a local variable, update xdp_buff->data_meta so that metadata length when XDP program is called 0. * In igc_xdp_enable_pool(), call xsk_pool_dma_unmap() on failure. Known issues: When an XDP application is running in Tx-Only mode with Zero-Copy enabled, it is not expected to add the frames to the fill-queue. I have noticed the following two issues in this scenario: - If XDP_USE_NEED_WAKEUP flag is not set by application, igc_poll() will go into infinite loop because the buffer allocation resulting in igc_clean_rx_irq_zc() indicating that all work is not done and NAPI should keep polling. This does not occur if XDP_USE_NEED_WAKEUP flag is set. - Since there are no buffers allocated by userspace for the fill queue, there is no memory allocated for the NIC to copy the data to. If the packet received is destined to the hardware queue where XDP application is running, no packets are received even on other queues. Both these issues can be mitigated by adding a few frames to the fill queue. The second issue can also be mitigated by making sure no packets are being received on the hardware queue where Rx is running. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20mii: remove leading spaces before tabsHui Tang1-1/+1
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20ifb: remove leading spaces before tabsHui Tang1-2/+2
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: appletalk: remove leading spaces before tabsHui Tang2-18/+18
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: fddi: skfp: remove leading spaces before tabsHui Tang2-4/+4
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hamradio: remove leading spaces before tabsHui Tang5-17/+17
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: ppp: remove leading spaces before tabsHui Tang1-1/+1
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Tom Parkin <tparkin@katalix.com> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: slip: remove leading spaces before tabsHui Tang1-1/+1
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: usb: remove leading spaces before tabsHui Tang1-1/+1
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: wan: remove leading spaces before tabsHui Tang3-7/+7
There are a few leading spaces before tabs and remove it by running the following commard: $ find . -name '*.[ch]' | xargs sed -r -i 's/^[ ]+\t/\t/' Cc: Xie He <xie.he.0141@gmail.com> Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: remove the useless debugfs file node cmdYufeng Mo5-119/+0
Currently, all debugfs commands have been reconstructed, and the debugfs file node cmd is useless. So remove this debugfs file node. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump serv info of debugfsYufeng Mo4-14/+35
Currently, the debugfs command for serv info is implemented by "echo xxxx > cmd", and record the inforamtion in dmesg. It's unnecessary and heavy. To improve it, create a single file "serv_info" for it, and query it by command "cat serv_info", return the result to userspace, rather than record in dmesg. The display style is below: $ cat service_task_info local_clock: [ 114.203321] delta: 784(ms) last_service_task_processed: 4294918512(jiffies) last_service_task_cnt: 4 Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump mac tnl status of debugfsJiaran Zhang3-12/+24
Currently, the debugfs command for dump mac tnl status is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create a single file "mac_tnl_status" for it, and query it by command "cat mac_tnl_status", return the result to userspace, rather than record in dmesg. The display style is below: $ cat mac_tnl_status Recently generated mac tnl interruption: [0111204.175437] status = 0x30 [0154120.329912] status = 0x30 Signed-off-by: Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump qs shaper of debugfsGuangbin Huang4-86/+76
Currently, user gets qset shaper parameters by implementing debugfs command "echo dump qs shaper > cmd", this command will dump info in dmesg. It's unnecessary and heavy. As there is "tm_qset" file in tm directory for dump qset info, to optimize these command, merge qset shaper parameters to tm_qset file and use cat command to get them. The display style is below: $ cat tm_qset ID MAP_PRI LINK_VLD MODE DWRR IR_B IR_U IR_S BS_B BS_S FLAG 0000 0 1 dwrr 100 150 7 0 5 20 0 0001 0 0 sp 0 150 7 0 5 20 0 Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump qos buf cfg of debugfsGuangbin Huang3-80/+115
Currently, user gets qos buffer config by implementing debugfs command "echo dump qos buf cfg > cmd", this command will dump info in dmesg. It's unnecessary and heavy. To optimize it, create a single file "qos_buf_cfg" in tm directory and use cat command to get info. It will return info to userspace, rather than record in dmesg. The display style is below: $ cat qos_buf_cfg tx_packet_buf_tc_0: 0x120 tx_packet_buf_tc_1: 0x120 tx_packet_buf_tc_2: 0x120 tx_packet_buf_tc_3: 0x120 tx_packet_buf_tc_4: 0x0 tx_packet_buf_tc_5: 0x0 tx_packet_buf_tc_6: 0x0 tx_packet_buf_tc_7: 0x0 ...... Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump qos pri map of debugfsGuangbin Huang3-18/+36
Currently, user gets priority map by implementing debugfs command "echo dump qos pri map > cmd", this command will dump info in dmesg. It's unnecessary and heavy. To optimize it, create a single file "qos_pri_map" in tm directory and use cat command to get info. It will return info to userspace, rather than record in dmesg. The display style is below: $ cat qos_pri_map vlan_to_pri: 0 PRI TC 0 0 1 1 2 2 3 3 4 0 5 1 6 2 Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump qos pause cfg of debugfsGuangbin Huang3-14/+25
Currently, user gets pause config by implementing debugfs command "echo dump qos pause cfg > cmd", this command will dump info in dmesg. It's unnecessary and heavy. To optimize it, create a single file "qos_pause_cfg" in tm directory and use cat command to get info. It will return info to userspace, rather than record in dmesg. The display style is below: $ cat qos_pause_cfg pause_trans_gap: 0x7f pause_trans_time: 0xffff Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump tc of debugfsGuangbin Huang3-27/+37
Currently, user gets tc schedule info by implementing debugfs command "echo dump tc > cmd", this command will dump info in dmesg. It's unnecessary and heavy. To optimize it, create a single file "tc_sch_info" and use cat command to get info. It will return info to userspace, rather than record in dmesg. The display style is below: $ cat tc_sch_info enabled tc number: 4 weight_offset: 14 TC MODE WEIGHT 0 dwrr 25 1 dwrr 25 2 dwrr 25 3 dwrr 25 4 dwrr 0 5 dwrr 0 6 dwrr 0 7 dwrr 0 Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump tm of debugfsGuangbin Huang6-205/+256
Currently, user gets some tm info by implementing debugfs command "echo dump tm > cmd", this command will dump info in dmesg. It's unnecessary and heavy. In addition, the info of this command mixes info of qset, priority, pg and port. Qset and priority have their own command to get info of themself, so can remove info of qset and priority from this command. To optimize it, create two new files "tm_pg", "tm_port" in tm directory and use cat command to separately get info of pg and port. The display style is below: $ cat tm_pg ID PRI_MAP MODE DWRR C_IR_B C_IR_U C_IR_S C_BS_B C_BS_S ... 00 0x1f dwrr 1 75 9 0 31 20 ... $ cat tm_port IR_B IR_U IR_S BS_B BS_S FLAG RATE(Mbps) 75 9 0 31 20 1 200000 Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump tm map of debugfsGuangbin Huang5-95/+145
Currently, the debugfs command for tm map is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create a single file "tm_map" for it, and query it by command "cat tm_map", return the result to userspace, rather than record in dmesg. As user can't specify queue id in cat command, driver will return info of all queue id. The display style is below: $ cat tm_map queue_id qset_id pri_id tc_id 0000 0000 00 00 INDEX | TM BP QSET MAPPING: 0000 | 00000000:00000000:00000000:00000000:00000000:00000000:00000000 0256 | 00000000:00000000:00000000:00000000:00000000:00000002:00000000 0512 | 00000000:00000000:00000000:00000004:00000000:00000000:00000000 0768 | 00000000:00000008:00000000:00000000:00000000:00000000:00000000 Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump fd tcam of debugfsHao Chen5-32/+74
Currently, the debugfs command for fd tcam is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create a single file "fd_tcam" for it, and query it by command "cat fd_tcam", return the result to userspace, rather than record in dmesg. The display style is below: $ cat fd_tcam read result tcam key x(31): 00000000 00000000 00000000 08000000 00000600 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 read result tcam key y(31): 00000000 00000000 00000000 f7ff0000 0000f900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000fff8 Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor queue info of debugfsHao Chen3-91/+186
Currently, the debugfs command for queue info is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create two files "rx_queue_info" and "tx_queue_info" for it, and query it by command "cat rx_queue_info" and "cat tx_queue_info", return the result to userspace, rather than record in dmesg. The display style is below: $ cat rx_queue_info QUEUE_ID BD_NUM BD_LEN TAIL HEAD FBDNUM PKTNUM ... 0 0 0 0 0 0 0 ... 1 0 0 0 0 0 0 ... 2 0 0 0 0 0 0 ... $ cat tx_queue_info QUEUE_ID BD_NUM TC TAIL HEAD FBDNUM OFFSET PKTNUM ... 0 0 0 0 0 0 0 0 ... 1 0 0 0 0 0 0 0 ... 2 0 0 0 0 0 0 0 ... Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor queue map of debugfsHao Chen3-15/+45
Currently, the debugfs command for queue map is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create a single file "queue_map" for it, and query it by command "cat queue_map", return the result to userspace, rather than record in dmesg. The display style is below: $ cat queue_map local_queue_id global_queue_id vector_id 0 0 341 Signed-off-by: Hao Chen <chenhao288@hisilicon.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump reg dcb info of debugfsYufeng Mo3-97/+212
Currently, the debugfs command for reg dcb info is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create a single file "dcb" for it, and query it by command "cat dcb", return the result to userspace, rather than record in dmesg. The display style is below: $ cat dcb qset_id roce_qset_mask nic_qset_mask qset_shaping_pass qset_bp_status 0000 0x1 0x1 0x1 0x0 0001 0x1 0x1 0x1 0x0 0002 0x1 0x1 0x1 0x0 0003 0x1 0x1 0x1 0x0 0004 0x1 0x1 0x1 0x0 0005 0x1 0x1 0x1 0x0 0006 0x1 0x1 0x1 0x0 0007 0x1 0x1 0x1 0x0 pri_id pri_mask pri_cshaping_pass pri_pshaping_pass 000 0x1 0x0 0x1 001 0x1 0x0 0x0 002 0x1 0x0 0x0 003 0x1 0x0 0x0 004 0x1 0x0 0x0 005 0x1 0x0 0x0 006 0x1 0x0 0x0 007 0x1 0x0 0x0 pg_id pg_mask pg_cshaping_pass pg_pshaping_pass 000 0x1 0x0 0x1 Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20net: hns3: refactor dump reg of debugfsYufeng Mo5-134/+321
Currently, the debugfs command for reg is implemented by "echo xxxx > cmd", and record the information in dmesg. It's unnecessary and heavy. To improve it, create some files "bios_common/ssu/igu_egu/rpu/ncsi/rtc/ppp/rcb/tqp/mac" for it, and query it by command "cat xxx", return the result to userspace, rather than record in dmesg. The display style is below: $ cat bios_common BP_CPU_STATE: 0x0 DFX_MSIX_INFO_NIC_0: 0xc000 DFX_MSIX_INFO_NIC_1: 0x0 DFX_MSIX_INFO_NIC_2: 0x0 DFX_MSIX_INFO_NIC_3: 0x0 DFX_MSIX_INFO_ROC_0: 0xc000 DFX_MSIX_INFO_ROC_1: 0x0 DFX_MSIX_INFO_ROC_2: 0x0 DFX_MSIX_INFO_ROC_3: 0x0 Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-20igc: Enable TX via AF_XDP zero-copyAndre Guedes4-8/+129
Add support for transmitting packets via AF_XDP zero-copy mechanism. The packet transmission itself is implemented by igc_xdp_xmit_zc() which is called from igc_clean_tx_irq() when the ring has AF_XDP zero-copy enabled. Likewise i40e and ice drivers, the transmission budget used is the number of descriptors available on the ring. A new tx buffer type is introduced to 'enum igc_tx_buffer_type' to indicate the tx buffer uses memory from xsk pool so it can be properly cleaned after transmission or when the ring is cleaned. The I225 controller has only 4 Tx hardware queues so the main difference between igc and other Intel drivers that support AF_XDP zero-copy is that there is no tx ring dedicated exclusively to XDP. Instead, tx rings are shared between the network stack and XDP, and netdev queue lock is used to ensure mutual exclusion. This is the same approach implemented to support XDP_TX and XDP_REDIRECT actions. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: Vedang Patel <vedang.patel@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-20igc: Enable RX via AF_XDP zero-copyAndre Guedes5-18/+449
Add support for receiving packets via AF_XDP zero-copy mechanism. Add a new flag to 'enum igc_ring_flags_t' to indicate the ring has AF_XDP zero-copy enabled so proper ring setup is carried out during ring configuration in igc_configure_rx_ring(). RX buffers can now be allocated via the shared pages mechanism (default behavior of the driver) or via xsk pool (when AF_XDP zero-copy is enabled) so a union is added to the 'struct igc_rx_buffer' to cover both cases. When AF_XDP zero-copy is enabled, rx buffers are allocated from the xsk pool using the new helper igc_alloc_rx_buffers_zc() which is the counterpart of igc_alloc_rx_buffers(). Likewise other Intel drivers that support AF_XDP zero-copy, in igc we have a dedicated path for cleaning up rx irqs when zero-copy is enabled. This avoids adding too many checks within igc_clean_rx_irq(), resulting in a more readable and efficient code since this function is called from the hot-path of the driver. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: Vedang Patel <vedang.patel@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-20igc: Replace IGC_TX_FLAGS_XDP flag by an enumAndre Guedes2-7/+26
Up to this point, Tx buffers are associated with either a skb or a xdpf, and the IGC_TX_FLAGS_XDP flag was enough to distinguish between these two case. However, with upcoming patches that will add AF_XDP zero-copy support, a third case will be introduced so this flag-based approach won't fit well. In preparation to land AF_XDP zero-copy support, replace the IGC_TX_FLAGS_XDP flag by an enum which will be extended once zero-copy support is introduced to the driver. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: Vedang Patel <vedang.patel@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.