summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ice: Implement devlink port split operationsAnatolii Gerasymenko2022-08-243-0/+326
| | | | | | | | | | | | | | | | | | | Allow to configure port split options using the devlink port split interface. Support port splitting only for port 0, as the FW has a predefined set of available port split options for the whole device. Add ice_devlink_port_options_print() function to print the table with all available FW port split options. It will be printed after each port split and unsplit command. Add documentation for devlink port split interface usage for the ice driver. Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Anatolii Gerasymenko <anatolii.gerasymenko@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* ice: Add additional flags to ice_nvm_write_activateJacob Keller2022-08-243-5/+16
| | | | | | | | | | | | | | | | The ice_nvm_write_activate function is used to issue AdminQ command 0x0707 which sends a request to firmware to activate a flash bank. For basic operations, this command takes an 8bit flag value which defines the flags to control the activation process. There are some additional flags that are stored in a second 8bit flag field. We can simplify the interface by using a u16 cmd_flags variable. Split this over the two bytes of flag storage in the structure. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Anatolii Gerasymenko <anatolii.gerasymenko@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* ice: Add port option admin queue commandsAnatolii Gerasymenko2022-08-243-0/+178
| | | | | | | | | | | | | | | | Implement support for Get/Set Port Options admin queue commands (0x06EA/0x06EB). These firmware commands allow the driver to change port specific options and will be used in the next patch. Co-developed-by: Lev Faerman <lev.faerman@intel.com> Signed-off-by: Lev Faerman <lev.faerman@intel.com> Co-developed-by: Damian Milosek <damian.milosek@intel.com> Signed-off-by: Damian Milosek <damian.milosek@intel.com> Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Anatolii Gerasymenko <anatolii.gerasymenko@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* ice: Add support for ip TTL & ToS offloadMarcin Szycik2022-08-242-4/+144
| | | | | | | | | | | | | | | Add support for parsing TTL and ToS (Hop Limit and Traffic Class) tc fields and matching on those fields in filters. Incomplete part of implementation was already in place (getting enc_ip and enc_tos from flow_match_ip and writing them to filter header). Note: matching on ipv6 ip_ttl, enc_ttl and enc_tos is currently not supported by the DDP package. Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* Merge branch 'r8169-next'David S. Miller2022-08-243-248/+18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Heiner Kallweit says: ==================== r8169: remove support for few unused chip versions There's a number of chip versions that apparently never made it to the mass market. Detection of these chip versions has been disabled for few kernel versions now and nobody complained. Therefore remove support for these chip versions. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove support for chip version 60Heiner Kallweit2022-08-243-90/+8
| | | | | | | | | | | | | | | | Detection of this chip version has been disabled for few kernel versions now. Nobody complained, so remove support for this chip version. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove support for chip version 50Heiner Kallweit2022-08-243-26/+3
| | | | | | | | | | | | | | | | | | | | | | Detection of this chip version has been disabled for few kernel versions now. Nobody complained, so remove support for this chip version. v3: - rebase patch Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove support for chip version 49Heiner Kallweit2022-08-243-47/+3
| | | | | | | | | | | | | | | | | | | | | | Detection of this chip version has been disabled for few kernel versions now. Nobody complained, so remove support for this chip version. v2: - fix a typo: RTL_GIGA_MAC_VER_40 -> RTL_GIGA_MAC_VER_50 Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove support for chip versions 45 and 47Heiner Kallweit2022-08-243-82/+5
| | | | | | | | | | | | | | | | Detection of these chip versions has been disabled for few kernel versions now. Nobody complained, so remove support for this chip version. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove support for chip version 41Heiner Kallweit2022-08-243-5/+1
|/ | | | | | | | Detection of this chip version has been disabled for few kernel versions now. Nobody complained, so remove support for this chip version. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'mlx5-updates-2022-08-22' of ↵David S. Miller2022-08-2429-765/+1246
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux mlx5-updates-2022-08-22 Roi Dayan Says: =============== Add support for SF tunnel offload Mlx5 driver only supports VF tunnel offload. To add support for SF tunnel offload the driver needs to: 1. Add send-to-vport metadata matching rules like done for VFs. 2. Set an indirect table for SF vport, same as VF vport. info smaller sub functions for better maintainability. rules from esw init phase to representor load phase. SFs could be created after esw initialized and thus the send-to-vport meta rules would not be created for those SFs. By moving the creation of the rules to representor load phase we ensure creating the rules also for SFs created later. =============== Lama Kayal Says: ================ Make flow steering API loosely coupled from mlx5e_priv, in a manner to introduce more readable and maintainable modules. Make TC's private, let mlx5e_flow_steering struct be dynamically allocated, and introduce its API to maintain the code via setters and getters instead of publicly exposing it. Introduce flow steering debug macros to provide an elegant finish to the decoupled flow steering API, where errors related to flow steering shall be reported via them. All flow steering related files will drop any coupling to mlx5e_priv, instead they will get the relevant members as input. Among these, fs_tt_redirect, fs_tc, and arfs. ================
| * net/mlx5: TC, Add support for SF tunnel offloadRoi Dayan2022-08-232-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | VF tunnel flow already exists and SF tunnel is the same flow. Support offloading of tunneling over SF device by allow to attach an encap route over SF and set to use indirect flow table on SF. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5: E-Switch, Move send to vport meta rule creationRoi Dayan2022-08-236-94/+90
| | | | | | | | | | | | | | | | | | | | | | | | Move the creation of the rules from offloads fdb table init to per rep vport init. This way the driver will creating the send to vport meta rule on any representor, e.g. SF representors. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5: E-Switch, Split creating fdb tables into smaller chunksRoi Dayan2022-08-231-124/+206
| | | | | | | | | | | | | | | | | | | | Split esw_create_offloads_fdb_tables() into smaller functions. This will help maintenance. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5: E-Switch, Add default drop rule for unmatched packetsJianbo Liu2022-08-232-3/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ft_offloads table serves to steer packets, which are from the eswitch, to the representor associated with the packets' source vport. Previously, if a packet's source vport or metadata was not associated with any representor, it was forwarded to the uplink representor. The representor got packets it shouldn't have as they weren't coming from the uplink vport. One such effect of this breakage can be observed if the uplink representor is attached to a bridge, where such illegal packets will be broadcast to the remaining ports, flooding the switch with illegal packets. In the case where IB loopback (e.g, SNAP) is enabled, all transmitted packets would be looped back, and received by the uplink representor, and result in an infinite feedback loop. Therefore, block this hole by adding a default drop rule to the ft_offloads table, so that all unmatched packets with no associated representor are dropped. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Gavi Teitz <gavi@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Completely eliminate priv from fs.hLama Kayal2022-08-234-94/+100
| | | | | | | | | | | | | | | | Complete the decoupling process of flow steering from en.h. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Make all ttc functions of en_fs get fs struct as argumentLama Kayal2022-08-234-36/+43
| | | | | | | | | | | | | | | | | | Let all ttc creation be independent of priv, and pass relevant members of priv only. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Make flow steering arfs independent of privLama Kayal2022-08-236-62/+74
| | | | | | | | | | | | | | | | | | | | | | Decouple arfs flow steering functionality from priv. Make all arfs functions defined under fs.h get flow_steering struct as an argument, thus helping with the process of decoupling the whole flow steering API from en.h. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Introduce flow steering debug macrosLama Kayal2022-08-234-76/+76
| | | | | | | | | | | | | | | | | | | | | | Introduce flow steering debug macros family, fs_*. These macros bring clean finish to the decoupling of flow steering process such that all flow steering flows can report warnings and provide debug information via these exclusive macros. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Separate ethtool_steering from fs.h and make privateLama Kayal2022-08-238-38/+65
| | | | | | | | | | | | | | | | | | | | Create a new fs_ethtool.h header file, where ethtool steering init and cleanup functions are declared in it. Make mlx5e_ethtool_steering struct private and declare at en_fs_ethtool.c. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Directly get flow_steering struct as input when init/cleanup ↵Lama Kayal2022-08-235-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | ethtool steering Let both mlx5e_ethtool_init_steering and mlx5e_ethtool_cleanup_steering get ethtool steering struct as input instead of priv, as passing priv is obsolete. Also modify other function through the flow similarly. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Convert ethtool_steering member of flow_steering struct to pointerLama Kayal2022-08-231-8/+33
| | | | | | | | | | | | | | | | | | | | Convert mlx5e_ethtool_steering member of mlx5e_flow_steering to a pointer, and allocate dynamically for each profile at flow_steering init. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Drop priv argument of ptp function in en_fsLama Kayal2022-08-233-16/+18
| | | | | | | | | | | | | | | | | | | | Both mlx5e_ptp_alloc_rx_fs and mlx5e_ptp_free_rx_fs only make use of two priv member, pass them directly instead. This will help dropping priv from all en_fs file. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Decouple fs_tcp from en.hLama Kayal2022-08-234-59/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | Make flow steering files fs_tcp.c/h independent of en.h such that they go through the flow steering API only. Make error reports be via mlx5_core API instead of netdev_err API, this to ensure a safe decoupling from en.h, and prevent redundant argument passing. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Decouple fs_tt_redirect from en.hLama Kayal2022-08-235-99/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | Make flow steering files fs_tt_redirect.c/h independent of en.h such that it goes through the flow steering API only. Make error reports be via mlx5_core API instead of netdev_err API, this to ensure a safe decoupling from en.h, and prevent redundant argument passing. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * net/mlx5e: Introduce flow steering APILama Kayal2022-08-2314-193/+415
| | | | | | | | | | | | | | | | | | Move mlx5e_flow_steering struct to fs_en.c to make it private. Introduce flow_steering API and let other files go through it. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
* | micrel: ksz8851: fixes struct pointer issueJerry Ray2022-08-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue found during code review. This bug has no impact as long as the ks8851_net structure is the first element of the ks8851_net_spi structure. As long as the offset to the ks8851_net struct is zero, the container_of() macro is subtracting 0 and therefore no damage done. But if the ks8851_net_spi struct is ever modified such that the ks8851_net struct within it is no longer the first element of the struct, then the bug would manifest itself and cause problems. struct ks8851_net is contained within ks8851_net_spi. ks is contained within kss. kss is the priv_data of the netdev structure. Signed-off-by: Jerry Ray <jerry.ray@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tcp: annotate data-race around tcp_md5sig_pool_populatedEric Dumazet2022-08-241-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tcp_md5sig_pool_populated can be read while another thread changes its value. The race has no consequence because allocations are protected with tcp_md5sig_mutex. This patch adds READ_ONCE() and WRITE_ONCE() to document the race and silence KCSAN. Reported-by: Abhishek Shah <abhishek.shah@columbia.edu> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: marvell: prestera: implement br_port_locked flag offloadingOleksandr Mazur2022-08-245-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | Both <port> br_port_locked and <lag> interfaces's flag offloading is supported. No new ABI is being added, rather existing (port_param_set) API call gets extended. Signed-off-by: Oleksandr Mazur <oleksandr.mazur@plvision.eu> V2: add missing receipents (linux-kernel, netdev) Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'j7200-support'David S. Miller2022-08-243-9/+55
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Siddharth Vadapalli says: ==================== J7200: CPSW5G: Add support for QSGMII mode to am65-cpsw driver Add support for QSGMII mode to am65-cpsw driver. Change log: v4-> v5: 1. Move ti,j7200-cpswxg-nuss compatible to the line above the ti,j721e-cpsw-nuss compatible. 2. Add allOf and move if-then statements within it to allow future if-then statements to be added easily. v3 -> v4: 1. Update bindings to disallow ports based on compatible, instead of adding a new if/then statement for the new compatible. 2. Add Else-If condition for RMII mode in the set of supported interfaces. Support for RMII mode is already present in the driver and I had missed out adding a condition for RMII mode in the previous patches. v2 -> v3: 1. In ti,k3-am654-cpsw-nuss.yaml, restrict if/then statement to port nodes. v1 -> v2: 1. Add new compatible for CPSW5G in ti,k3-am654-cpsw-nuss.yaml and extend properties for new compatible. 2. Add extra_modes member to struct am65_cpsw_pdata to be used for QSGMII mode by new compatible. 3. Add check for phylink supported modes to ensure that only one phy mode is advertised as supported. 4. Check if extra_modes supports QSGMII mode in am65_cpsw_nuss_mac_config() for register write. 5. Add check for assigning port->sgmii_base only when extra_modes is valid. v4: https://lore.kernel.org/r/20220816060139.111934-1-s-vadapalli@ti.com/ v3: https://lore.kernel.org/r/20220606110443.30362-1-s-vadapalli@ti.com/ v2: https://lore.kernel.org/r/20220602114558.6204-1-s-vadapalli@ti.com/ v1: https://lore.kernel.org/r/20220531113058.23708-1-s-vadapalli@ti.com/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: ethernet: ti: am65-cpsw: Move phy_set_mode_ext() to correct locationSiddharth Vadapalli2022-08-241-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In TI's J7200 SoC CPSW5G ports, each of the 4 ports can be configured as a QSGMII main or QSGMII-SUB port. This configuration is performed by phy-gmii-sel driver on invoking the phy_set_mode_ext() function. It is necessary for the QSGMII main port to be configured before any of the QSGMII-SUB interfaces are brought up. Currently, the QSGMII-SUB interfaces come up before the QSGMII main port is configured. Fix this by moving the call to phy_set_mode_ext() from am65_cpsw_nuss_ndo_slave_open() to am65_cpsw_nuss_init_slave_ports(), thereby ensuring that the QSGMII main port is configured before any of the QSGMII-SUB ports are brought up. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: ethernet: ti: am65-cpsw: Add support for J7200 CPSW5GSiddharth Vadapalli2022-08-242-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | CPSW5G in J7200 supports additional modes like QSGMII and SGMII. Add new compatible for J7200 and enable QSGMII mode in am65-cpsw driver. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | dt-bindings: net: ti: k3-am654-cpsw-nuss: Update bindings for J7200 CPSW5GSiddharth Vadapalli2022-08-241-2/+16
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | Update bindings for TI K3 J7200 SoC which contains 5 ports (4 external ports) CPSW5G module and add compatible for it. Changes made: - Add new compatible ti,j7200-cpswxg-nuss for CPSW5G. - Extend pattern properties for new compatible. - Change maximum number of CPSW ports to 4 for new compatible. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: skb: prevent the split of kfree_skb_reason() by gccMenglong Dong2022-08-243-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, gcc will optimize the function by spliting it to two or more functions. In this case, kfree_skb_reason() is splited to kfree_skb_reason and kfree_skb_reason.part.0. However, the function/tracepoint trace_kfree_skb() in it needs the return address of kfree_skb_reason(). This split makes the call chains becomes: kfree_skb_reason() -> kfree_skb_reason.part.0 -> trace_kfree_skb() which makes the return address that passed to trace_kfree_skb() be kfree_skb(). Therefore, introduce '__fix_address', which is the combination of '__noclone' and 'noinline', and apply it to kfree_skb_reason() to prevent to from being splited or made inline. (Is it better to simply apply '__noclone oninline' to kfree_skb_reason? I'm thinking maybe other functions have the same problems) Meanwhile, wrap 'skb_unref()' with 'unlikely()', as the compiler thinks it is likely return true and splits kfree_skb_reason(). Signed-off-by: Menglong Dong <imagedong@tencent.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'add-interface-mode-select-and-rmii'Jakub Kicinski2022-08-242-5/+95
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wei Fang says: ==================== add interface mode select and RMII From: Wei Fang <wei.fang@nxp.com> The patches add the below feature support for both TJA1100 and TJA1101 PHYs cards: - Add MII and RMII mode support. - Add REF_CLK input/output support for RMII mode. ==================== Link: https://lore.kernel.org/r/20220822015949.1569969-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net: phy: tja11xx: add interface mode and RMII REF_CLK supportWei Fang2022-08-241-5/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add below features support for both TJA1100 and TJA1101 cards: - Add MII and RMII mode support. - Add REF_CLK input/output support for RMII mode. Signed-off-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | dt-bindings: net: tja11xx: add nxp,refclk_in propertyWei Fang2022-08-241-0/+17
|/ / | | | | | | | | | | | | | | | | | | TJA110x REF_CLK can be configured as interface reference clock intput or output when the RMII mode enabled. This patch add the property to make the REF_CLK can be configurable. Signed-off-by: Wei Fang <wei.fang@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge branch 'mlxsw-introduce-modular-system-support-by-minimal-driver'Jakub Kicinski2022-08-245-86/+546
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Petr Machata says: ==================== mlxsw: Introduce modular system support by minimal driver Vadim Pasternak writes: This patchset adds line cards support in mlxsw_minimal, which is used for monitoring purposes on BMC systems. The BMC is connected to the ASIC over I2C bus, unlike the host CPU that is connected to the ASIC via PCI bus. The BMC system needs to be notified whenever line cards become active or inactive, so that, for example, netdevs will be registered / unregistered by mlxsw_minimal. However, traps cannot be generated towards the BMC over the I2C bus. To overcome that, the I2C bus driver (i.e., mlxsw_i2c) registers an handler for an IRQ that is fired upon specific system wide changes, like line card activation and deactivation. The generated event is handled by mlxsw_core, which checks whether anything changed in the state of available line cards. If a line card becomes active or inactive, interested parties such as mlxsw_minimal are notified via their registered line card event callback. Patch set overview: Patches #1 is preparations. Patches #2-#3 extend mlxsw_core with an infrastructure to handle the previously mentioned system events. Patch #4 extends the I2C bus driver to register an handler for the IRQ fired upon specific system wide changes. Patches #5-#8 gradually add line cards support in mlxsw_minimal by dynamically registering / unregistering netdevs for ports found on line cards, whenever a line card becomes active / inactive. ==================== Link: https://lore.kernel.org/r/cover.1661093502.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: minimal: Extend to support line card dynamic operationsVadim Pasternak2022-08-241-1/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement line card operation callbacks got_active() / got_inactive(). The purpose of these callback to create / remove line card ports after line card is getting active / inactive. Implement line ports_remove_selected() callback to support line card un-provisioning flow through 'devlink'. Add line card operation registration and de-registration APIs. Add module offset for line card. Offset for main board iz zero. For line card in slot #n offset is calculated as (#n - 1) multiplied by maximum modules number. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: minimal: Extend module to port mapping with slot indexVadim Pasternak2022-08-241-52/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The interfaces for ports found on line card are created and removed dynamically after line card is getting active or inactive. Introduce per line card array with module to port mapping. For each port get 'slot_index' through PMLP register and set port mapping for the relevant [slot_index][module] entry. Split module and port allocation into separate routines. Split per line card port creation and removing into separate routines. Motivation to re-use these routines for line card operations. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: minimal: Move ports allocation to separate routineVadim Pasternak2022-08-241-8/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Perform ports allocation in a separate routine. Motivation is to re-use this routine for ports found on line cards. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: minimal: Extend APIs with slot index for modular system supportVadim Pasternak2022-08-241-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 'slot_index' field to port structure. Replace zero slot_index argument with 'slot_index' in 'ethtool' related APIs. Add 'slot_index' argument to port initialization and de-initialization related APIs. Motivation is to prepare minimal driver for modular system support. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: i2c: Add support for system interrupt handlingVadim Pasternak2022-08-241-1/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend i2c bus driver with interrupt handler to support system specific hotplug events, related to line card state change. Provide system IRQ line for interrupt handler. IRQ line Id could be provided through the platform data if available, or could be set to the default value. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: core_linecards: Register a system event handlerVadim Pasternak2022-08-241-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add line card system event handler. Register it with core. It is triggered by system interrupts raised from chassis programmable logic devices to CPU. The purpose is to handle line card state changes over I2C bus. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: core: Add registration APIs for system event handlerVadim Pasternak2022-08-242-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of system event handler is to handle system interrupts. Such interrupts are raised to CPU from system programmable logic devices, upon specific system wide changes, like line card activation and deactivation. The purpose is to create an alternative to trap mechanism, which delivers these events to driver over PCI bus, but not available for the driver working over I2C bus. Mechanism is system dependent and applicable only for the systems equipped with programmable devices with custom logic. Add APIs for event handler registration and un-registration and API which should be invoked from the registered callbacks when system interrupt is raised to CPU. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | mlxsw: core_linecards: Separate line card init and fini flowVadim Pasternak2022-08-241-21/+50
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, each line card is initialized using the following steps: 1. Initializing its various fields (e.g., slot index). 2. Creating the corresponding devlink object. 3. Enabling events (i.e., traps) for changes in line card status. 4. Querying and processing line card status. Unlike traps, the IRQ that notifies the CPU about line card status changes cannot be enabled / disabled on a per line card basis. If a handler is registered before the line cards are initialized, the handler risks accessing uninitialized memory. On the other hand, if the handler is registered after initialization, we risk missing events. For example, in step 4, the driver might see that a line card is in ready state and will tell the device to enable it. When enablement is done, the line card will be activated and the IRQ will be triggered. Since a handler was not registered, the event will be missed. Solve this by splitting the initialization sequence into two steps (1-2 and 3-4). In a subsequent patch, the handler will be registered between both steps. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | docs: netlink: basic introduction to NetlinkJakub Kicinski2022-08-243-0/+656
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide a bit of a brain dump of netlink related information as documentation. Hopefully this will be useful to people trying to navigate implementing YAML based parsing in languages we won't be able to help with. I started writing this doc while trying to figure out what it'd take to widen the applicability of YAML to good old rtnl, but the doc grew beyond that as it usually happens. In all honesty a lot of this information is new to me as I usually follow the "copy an existing example, drink to forget" process of writing netlink user space, so reviews will be much appreciated. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20220819200221.422801-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: improve and fix netlink kdocJakub Kicinski2022-08-241-5/+16
| | | | | | | | | | | | | | | | | | | | | | Subsequent patch will render the kdoc from include/uapi/linux/netlink.h into Documentation. We need to fix the warnings. While at it move the comments on struct nlmsghdr to a proper kdoc comment. Link: https://lore.kernel.org/r/20220819200221.422801-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: ftmac100: set max_mtu to allow DSA overhead settingSergei Antonov2022-08-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case ftmac100 is used with a DSA switch, Linux wants to set MTU to 1504 to accommodate for DSA overhead. With the default max_mtu it leads to the error message: ftmac100 92000000.mac eth0: error -22 setting MTU to 1504 to include DSA overhead ftmac100 supports packet length 1518 (MAX_PKT_SIZE constant), so it is safe to report it in max_mtu. Signed-off-by: Sergei Antonov <saproj@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220821160844.474277-1-saproj@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge branch 'dsa-changes-for-multiple-cpu-ports-part-3'Paolo Abeni2022-08-239-96/+197
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vladimir Oltean says: ==================== DSA changes for multiple CPU ports (part 3) Those who have been following part 1: https://patchwork.kernel.org/project/netdevbpf/cover/20220511095020.562461-1-vladimir.oltean@nxp.com/ and part 2: https://patchwork.kernel.org/project/netdevbpf/cover/20220521213743.2735445-1-vladimir.oltean@nxp.com/ will know that I am trying to enable the second internal port pair from the NXP LS1028A Felix switch for DSA-tagged traffic via "ocelot-8021q". This series represents part 3 of that effort. Covered here are some preparations in DSA for handling multiple DSA masters: - when changing the tagging protocol via sysfs - when the masters go down as well as preparation for monitoring the upper devices of a DSA master (to support DSA masters under a LAG). There are also 2 small preparations for the ocelot driver, for the case where multiple tag_8021q CPU ports are used in a LAG. Both those changes have to do with PGID forwarding domains. Compared to v1, the patches were trimmed down to just another preparation stage, and the UAPI changes were pushed further out to part 4. https://patchwork.kernel.org/project/netdevbpf/cover/20220523104256.3556016-1-olteanv@gmail.com/ Compared to v2, I had to export a symbol I forgot to (ocelot_port_teardown_dsa_8021q_cpu), to avoid a build breakage when the felix and seville drivers are built as modules. ==================== Link: https://lore.kernel.org/r/20220819174820.3585002-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-18 22:15:59 +0100