aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-10-01lib8390: Use netif_msg_init to initialize msg_enable bitsArmin Wolf1-6/+8
Use netif_msg_init() to process param settings and use only the proper initialized value of ei_local->msg_level for later processing; Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01net: phy: realtek: Modify 2.5G PHY name to RTL8226Willy Liu1-19/+19
Realtek single-chip Ethernet PHY solutions can be separated as below: 10M/100Mbps: RTL8201X 1Gbps: RTL8211X 2.5Gbps: RTL8226/RTL8221X RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY. Since RTL8226 is single port only, realtek changes its name to RTL8221B from the second version. PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840. RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus controller and embedded memory. Signed-off-by: Willy Liu <willy.liu@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01caif_virtio: Remove redundant initialization of variable errJing Xiangfeng1-1/+1
After commit a8c7687bf216 ("caif_virtio: Check that vringh_config is not null"), the variable err is being initialized with '-EINVAL' that is meaningless. So remove it. Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01drivers/net/wan/hdlc_fr: Correctly handle special skb->protocol valuesXie He1-47/+51
The fr_hard_header function is used to prepend the header to skbs before transmission. It is used in 3 situations: 1) When a control packet is generated internally in this driver; 2) When a user sends an skb on an Ethernet-emulating PVC device; 3) When a user sends an skb on a normal PVC device. These 3 situations need to be handled differently by fr_hard_header. Different headers should be prepended to the skb in different situations. Currently fr_hard_header distinguishes these 3 situations using skb->protocol. For situation 1 and 2, a special skb->protocol value will be assigned before calling fr_hard_header, so that it can recognize these 2 situations. All skb->protocol values other than these special ones are treated by fr_hard_header as situation 3. However, it is possible that in situation 3, the user sends an skb with one of the special skb->protocol values. In this case, fr_hard_header would incorrectly treat it as situation 1 or 2. This patch tries to solve this issue by using skb->dev instead of skb->protocol to distinguish between these 3 situations. For situation 1, skb->dev would be NULL; for situation 2, skb->dev->type would be ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI. This way fr_hard_header would be able to distinguish these 3 situations correctly regardless what skb->protocol value the user tries to use in situation 3. Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Xie He <xie.he.0141@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01ravb: Add support for explicit internal clock delay configurationGeert Uytterhoeven2-9/+28
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This caused issues with PHY drivers that implement PHY internal delays properly[1]. Hence a backwards-compatible workaround was added by masking the PHY mode[2]. Add proper support for explicit configuration of the MAC internal clock delays using the new "[rt]x-internal-delay-ps" properties. Fall back to the old handling if none of these properties is present. [1] Commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") [2] Commit 9b23203c32ee02cd ("ravb: Mask PHY mode to avoid inserting delays twice"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01ravb: Split delay handling in parsing and applyingGeert Uytterhoeven2-6/+19
Currently, full delay handling is done in both the probe and resume paths. Split it in two parts, so the resume path doesn't have to redo the parsing part over and over again. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30net/mlx5e: Fix potential null pointer dereferenceGustavo A. R. Silva1-4/+6
Calls to kzalloc() and kvzalloc() should be null-checked in order to avoid any potential failures. In this case, a potential null pointer dereference. Fix this by adding null checks for _parse_attr_ and _flow_ right after allocation. Addresses-Coverity-ID: 1497154 ("Dereference before null check") Fixes: c620b772152b ("net/mlx5: Refactor tc flow attributes structure") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5e: Fix a use after free on error in mlx5_tc_ct_shared_counter_get()Dan Carpenter1-1/+3
This code frees "shared_counter" and then dereferences on the next line to get the error code. Fixes: 1edae2335adf ("net/mlx5e: CT: Use the same counter for both directions") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: Fix dereference on pointer attr after null checkAriel Levkovich1-2/+4
When removing a flow from the slow path fdb, a flow attr struct is allocated for the rule removal process. If the allocation fails the code prints a warning message but continues with the removal flow which include dereferencing a pointer which could be null. Fix this by exiting the function in case the attr allocation failed. Fixes: c620b772152b ("net/mlx5: Refactor tc flow attributes structure") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: Use dma device access helperParav Pandit12-34/+37
Use the PCI device directly for dma accesses as non PCI device unlikely support IOMMU and dma mappings. Introduce and use helper routine to access DMA device. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-Switch, Support flow source for local vportHamdan Igbaria1-2/+5
Set flow source as hint for local vport. Signed-off-by: Hamdan Igbaria <hamdani@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Move devlink eswitch ports closer to eswitchParav Pandit6-92/+154
Currently devlink eswitch ports are registered and unregistered by the representor layer. However it is better to register them at eswitch layer so that in future user initiated command port add and delete commands can also register/unregister devlink ports without depending on representor layer. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Use helper function to load unload representorParav Pandit1-8/+21
To register and unregister devlink ports when loading/unload representors, refactor the code to helper functions. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Add helper to check egress ACL needParav Pandit2-5/+11
Currently only VF vports need egress ACL table. Add a generic helper to check whether a vport need egress ACL table or not. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Use PF num in metadata reg c0sunils1-18/+18
Currently only 256 vports can be supported as only 8 bits are reserved for them and 8 bits are reserved for vhca_ids in metadata reg c0. To support more than 256 vports, replace vhca_id with a unique shorter 4-bit PF number which covers upto 16 PF's. Use remaining 12 bits for vports ranging 1-4095. This will continue to generate unique metadata even if multiple PCI devices have same switch_id. Signed-off-by: sunils <sunils@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Add support for rule creation with flow source hintHamdan Igbaria4-22/+26
Skip the rule according to flow arrival source, in case of RX and the source is local port skip and in case of TX and the source is uplink skip, we get this info according to the flow source hint we get from upper layers when creating the rule. This is needed because for example in case of FDB table which has a TX and RX tables and we are inserting a rule with an encap action which is only a TX action, in this case rule will fail on RX, so we can rely on the flow source hint and skip RX in such case. Until now we relied on metadata regc_0 that upper layer mapped the port in the regc_0, but the problem is that upper layer did not always use regc_0 for port mapping, so now we added support to flow source hint which upper layers will pass to SW steering when creating a rule. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Hamdan Igbaria <hamdani@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Call ste_builder directly with tag pointerYevgeny Kliteynik2-68/+33
Instead of getting the tag in each function, call the builder directly with the tag. This will allow to use the same function for building the tag and the bitmask. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Remove unneeded local variableYevgeny Kliteynik1-3/+1
The misc3 variable is used only once and can be dropped. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Remove unneeded vlan check from L2 builderYevgeny Kliteynik3-30/+13
When we create a matcher we check that all fields are consumed. There is no need for this specific check. This keeps the STE builder functions simple and clean. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Remove unneeded check from source port builderYevgeny Kliteynik3-33/+21
Mask validity for ste builders is checked by mlx5dr_ste_build_pre_check during matcher creation. It already checks the mask value of source_vport, so removing this duplicated check. Also, moving there the check of source_eswitch_owner_vhca_id mask. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Replace the check for valid STE entryYevgeny Kliteynik4-26/+10
Validity check is done by reading the next lu_type from the STE, this check can be replaced by checking the refcount. This will make the check independent on internal STE structure. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30Merge tag 'linux-can-next-for-5.10-20200930' of ↵David S. Miller11-1665/+1741
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2020-09-30 this is a pull request of 13 patches for net-next. The first 10 target the mcp25xxfd driver (which is renamed to mcp251xfd during this series). The first two patches are by Thomas Kopp, which adds reference to the just related errata and updates the documentation and log messages. Dan Carpenter's patch fixes a resource leak during ifdown. A patch by me adds the missing initialization of a variable. Oleksij Rempel updates the DT binding documentation as requested by Rob Herring. The next 5 patches are by Thomas Kopp and me. During review Geert Uytterhoeven suggested to use "microchip,mcp251xfd" instead of "microchip,mcp25xxfd" as the DT autodetection compatible to avoid clashes with future but incompatible devices. We decided not only to rename the compatible but the whole driver from "mcp25xxfd" to "mcp251xfd". This is done in several patches. Joakim Zhang contributes three patches for the flexcan driver. The first one adds support for the ECC feature, which is implemented on some modern IP cores, by initializing the controller's memory during ifup. The next patch adds support for the i.MX8MP (which supports ECC) and the last patch properly disables the runtime PM if device registration fails. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30ionic: prevent early watchdog checkShannon Nelson1-1/+4
In one corner case scenario, the driver device lif setup can get delayed such that the ionic_watchdog_cb() timer goes off before the ionic->lif is set, thus causing a NULL pointer panic. We catch the problem by checking for a NULL lif just a little earlier in the callback. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30ionic: stop watchdog timer earlier on removeShannon Nelson3-8/+3
We need to be better at making sure we don't have a link check watchdog go off while we're shutting things down, so let's stop the timer as soon as we start the remove. Meanwhile, since that was the only thing in ionic_dev_teardown(), simplify and remove that function. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30net: macb: move pdata to private headerAlexandre Belloni3-2/+11
struct macb_platform_data is only used by macb_pci to register the platform device, move its definition to cadence/macb.h and remove platform_data/macb.h Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30can: flexcan: disable runtime PM if register flexcandev failedJoakim Zhang1-0/+2
Disable runtime PM if register flexcandev failed, and balance reference of usage_count. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929211557.14153-4-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: flexcan: add flexcan driver for i.MX8MPJoakim Zhang1-0/+9
Add flexcan driver for i.MX8MP, which supports CAN FD and ECC. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929211557.14153-3-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: flexcan: initialize all flexcan memory for ECC functionJoakim Zhang1-2/+51
One issue was reported at a baremetal environment, which is used for FPGA verification. "The first transfer will fail for extended ID format(for both 2.0B and FD format), following frames can be transmitted and received successfully for extended format, and standard format don't have this issue. This issue occurred randomly with high possiblity, when it occurs, the transmitter will detect a BIT1 error, the receiver a CRC error. According to the spec, a non-correctable error may cause this transfer failure." With FLEXCAN_QUIRK_DISABLE_MECR quirk, it supports correctable errors, disable non-correctable errors interrupt and freeze mode. Platform has ECC hardware support, but select this quirk, this issue may not come to light. Initialize all FlexCAN memory before accessing them, at least it can avoid non-correctable errors detected due to memory uninitialized. The internal region can't be initialized when the hardware doesn't support ECC. According to IMX8MPRM, Rev.C, 04/2020. There is a NOTE at the section 11.8.3.13 Detection and correction of memory errors: "All FlexCAN memory must be initialized before starting its operation in order to have the parity bits in memory properly updated. CTRL2[WRMFRZ] grants write access to all memory positions that require initialization, ranging from 0x080 to 0xADF and from 0xF28 to 0xFFF when the CAN FD feature is enabled. The RXMGMASK, RX14MASK, RX15MASK, and RXFGMASK registers need to be initialized as well. MCR[RFEN] must not be set during memory initialization." Memory range from 0x080 to 0xADF, there are reserved memory (unimplemented by hardware, e.g. only configure 64 MBs), these memory can be initialized or not. In this patch, initialize all flexcan memory which includes reserved memory. In this patch, create FLEXCAN_QUIRK_SUPPORT_ECC for platforms which has ECC feature. If you have a ECC platform in your hand, please select this qurik to initialize all flexcan memory firstly, then you can select FLEXCAN_QUIRK_DISABLE_MECR to only enable correctable errors. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929211557.14153-2-qiangqing.zhang@nxp.com [mkl: wrap long lines] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename all remaining occurrence to mcp251xfdMarc Kleine-Budde4-1277/+1277
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all non user facing occurrence of "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD". [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename all user facing strings to mcp251xfdMarc Kleine-Budde3-12/+12
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all user facing strings from "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD", including: - kconfig symbols - name of kernel module - DT and SPI compatible [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename driver files and subdir to mcp251xfdMarc Kleine-Budde9-13/+13
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes the name of the driver subdir and the individual files accordinly. [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: narrow down wildcards in device tree bindings to ↵Thomas Kopp2-11/+11
"microchip,mcp251xfd" The wildcard should be narrowed down to prevent existing and future devices that are not compatible from matching. It is very unlikely that incompatible devices will be released that do not match the wildcard. Discussion Reference: https://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200930091423.755-1-thomas.kopp@microchip.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_irq(): add missing initialization of variable ↵Marc Kleine-Budde1-1/+1
set_normal mode This patch fixes the following warning: drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c:2155 mcp25xxfd_irq() error: uninitialized symbol 'set_normal_mode'. by adding the missing initialization. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/r/20200923114726.2704426-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_ring_free(): fix memory leak during cleanupDan Carpenter1-1/+1
This loop doesn't free the first element of the array. The "i > 0" has to be changed to "i >= 0". Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200923112752.GA1473821@mwanda Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_probe(): add SPI clk limit related errata informationThomas Kopp1-5/+14
This patch adds a reference to the recent released MCP2517FD and MCP2518FD errata sheets and paste the explanation. The driver already implements the proposed fix. Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200925065606.358-1-thomas.kopp@microchip.com [mkl: split into two patches, adjust subject and commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_handle_eccif(): add ECC related errata and update ↵Thomas Kopp1-7/+14
log messages This patch adds a reference to the recent released MCP2517FD and MCP2518FD errata sheets and paste the explanation. The single error correction does not always work, so always indicate that a single error occurred. If the location of the ECC error is outside of the TX-RAM always use netdev_notice() to log the problem. For ECC errors in the TX-RAM, there is a recovery procedure. Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200925065606.358-1-thomas.kopp@microchip.com [mkl: split into two patches, adjust subject and commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-29net: mscc: ocelot: look up the filters in flower_stats() and flower_destroy()Vladimir Oltean2-13/+18
Currently a new filter is created, containing just enough correct information to be able to call ocelot_vcap_block_find_filter_by_index() on it. This will be limiting us in the future, when we'll have more metadata associated with a filter, which will matter in the stats() and destroy() callbacks, and which we can't make up on the spot. For example, we'll start "offloading" some dummy tc filter entries for the TCAM skeleton, but we won't actually be adding them to the hardware, or to block->rules. So, it makes sense to avoid deleting those rules too. That's the kind of thing which is difficult to determine unless we look up the real filter. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: add a new ocelot_vcap_block_find_filter_by_id functionVladimir Oltean2-7/+21
And rename the existing find to ocelot_vcap_block_find_filter_by_index. The index is the position in the TCAM, and the id is the flow cookie given by tc. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: rename variable 'cnt' in vcap_data_offset_get()Vladimir Oltean1-8/+12
The 'cnt' variable is actually used for 2 purposes, to hold the number of sub-words per VCAP entry, and the number of sub-words per VCAP action. In fact, I'm pretty sure these 2 numbers can never be different from one another. By hardware definition, the entry (key) TCAM rows are divided into the same number of sub-words as its associated action RAM rows. But nonetheless, let's at least rename the variables such that observations like this one are easier to make in the future. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: rename variable 'count' in vcap_data_offset_get()Vladimir Oltean1-8/+8
This gets rid of one of the 2 variables named, very generically, "count". Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: calculate vcap offsets correctly for full and quarter entriesXiaoliang Yang1-2/+15
When calculating the offsets for the current entry within the row and placing them inside struct vcap_data, the function assumes half key entry (2 keys per row). This patch modifies the vcap_data_offset_get() function to calculate a correct data offset when the setting VCAP Type-Group of a key to VCAP_TG_FULL or VCAP_TG_QUARTER. This is needed because, for example, VCAP ES0 only supports full keys. Also rename the 'count' variable to 'num_entries_per_row' to make the function just one tiny bit easier to follow. Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: parse flower action before keyVladimir Oltean1-3/+16
When we'll make the switch to multiple chain offloading, we'll want to know first what VCAP block the rule is offloaded to. This impacts what keys are available. Since the VCAP block is determined by what actions are used, parse the action first. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: remove unneeded VCAP parameters for IS2Vladimir Oltean3-38/+0
Now that we are deriving these from the constants exposed by the hardware, we can delete the static info we're keeping in the driver. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: automatically detect VCAP constantsVladimir Oltean7-6/+116
The numbers in struct vcap_props are not intuitive to derive, because they are not a straightforward copy-and-paste from the reference manual but instead rely on a fairly detailed level of understanding of the layout of an entry in the TCAM and in the action RAM. For this reason, bugs are very easy to introduce here. Ease the work of hardware porters and read from hardware the constants that were exported for this particular purpose. Note that this implies that struct vcap_props can no longer be const. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: add definitions for VCAP ES0 keys, actions and targetVladimir Oltean3-0/+145
As a preparation step for the offloading to ES0, let's create the infrastructure for talking with this hardware block. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: add definitions for VCAP IS1 keys, actions and targetVladimir Oltean3-0/+272
As a preparation step for the offloading to IS1, let's create the infrastructure for talking with this hardware block. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: generalize existing code for VCAPVladimir Oltean7-290/+253
In the Ocelot switches there are 3 TCAMs: VCAP ES0, IS1 and IS2, which have the same configuration interface, but different sets of keys and actions. The driver currently only supports VCAP IS2. In preparation of VCAP IS1 and ES0 support, the existing code must be generalized to work with any VCAP. In that direction, we should move the structures that depend upon VCAP instantiation, like vcap_is2_keys and vcap_is2_actions, out of struct ocelot and into struct vcap_props .keys and .actions, a structure that is replicated 3 times, once per VCAP. We'll pass that structure as an argument to each function that does the key and action packing - only the control logic needs to distinguish between ocelot->vcap[VCAP_IS2] or IS1 or ES0. Another change is to make use of the newly introduced ocelot_target_read and ocelot_target_write API, since the 3 VCAPs have the same registers but put at different addresses. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: return error if VCAP filter is not foundXiaoliang Yang1-4/+12
Although it doesn't look like it is possible to hit these conditions from user space, there are 2 separate, but related, issues. First, the ocelot_vcap_block_get_filter_index function, née ocelot_ace_rule_get_index_id prior to the aae4e500e106 ("net: mscc: ocelot: generalize the "ACE/ACL" names") rename, does not do what the author probably intended. If the desired filter entry is not present in the ACL block, this function returns an index equal to the total number of filters, instead of -1, which is maybe what was intended, judging from the curious initialization with -1, and the "++index" idioms. Either way, none of the callers seems to expect this behavior. Second issue, the callers don't actually check the return value at all. So in case the filter is not found in the rule list, propagate the return code. So update the callers and also take the opportunity to get rid of the odd coding idioms that appear to work but don't. Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mscc: ocelot: introduce a new ocelot_target_{read,write} APIVladimir Oltean1-0/+17
There are some targets (register blocks) in the Ocelot switch that are instantiated more than once. For example, the VCAP IS1, IS2 and ES0 blocks all share the same register layout for interacting with the cache for the TCAM and the action RAM. For the VCAPs, the procedure for servicing them is actually common. We just need an API specifying which VCAP we are talking to, and we do that via these raw ocelot_target_read and ocelot_target_write accessors. In plain ocelot_read, the target is encoded into the register enum itself: u16 target = reg >> TARGET_OFFSET; For the VCAPs, the registers are currently defined like this: enum ocelot_reg { [...] S2_CORE_UPDATE_CTRL = S2 << TARGET_OFFSET, S2_CORE_MV_CFG, S2_CACHE_ENTRY_DAT, S2_CACHE_MASK_DAT, S2_CACHE_ACTION_DAT, S2_CACHE_CNT_DAT, S2_CACHE_TG_DAT, [...] }; which is precisely what we want to avoid, because we'd have to duplicate the same register map for S1 and for S0, and then figure out how to pass VCAP instance-specific registers to the ocelot_read calls (basically another lookup table that undoes the effect of shifting with TARGET_OFFSET). So for some targets, propose a more raw API, similar to what is currently done with ocelot_port_readl and ocelot_port_writel. Those targets can only be accessed with ocelot_target_{read,write} and not with ocelot_{read,write} after the conversion, which is fine. The VCAP registers are not actually modified to use this new API as of this patch. They will be modified in the next one. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-29net: mvneta: avoid possible cache misses in mvneta_rx_swbmLorenzo Bianconi1-6/+6
Do not use rx_desc pointers if possible since rx descriptors are stored in uncached memory and dereferencing rx_desc pointers generate extra loads. This patch improves XDP_DROP performance of ~ 110Kpps (700Kpps vs 590Kpps) on Marvell Espressobin Analyzed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Powered by cgit, Gruvboxed by Blaster4385.