- 29 Jun, 2022 7 commits
-
-
Jakub Kicinski authored
Based on a request from Geert: Revert "ARM: dts: r9a06g032-rzn1d400-db: add switch description" This reverts commit 9aab31d6. Revert "ARM: dts: r9a06g032: describe switch" This reverts commit cf9695d8. Revert "ARM: dts: r9a06g032: describe GMAC2" This reverts commit 3f5261f1. Revert "ARM: dts: r9a06g032: describe MII converter" This reverts commit 066c3bd3. to let these changes flow thru the platform and SoC trees. Link: https://lore.kernel.org/r/CAMuHMdUvSLFU56gsp1a9isOiP9otdCJ2-BqhbrffcoHuA6JNig@mail.gmail.com/ Link: https://lore.kernel.org/r/20220627173900.3136386-1-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Russell King says: ==================== net: phylink: cleanup pcs code These two patches were part of the larger series for the mv88e6xxx phylink pcs conversion. As this is delayed, I've decided to send these two patches now. ==================== Link: https://lore.kernel.org/r/YrmYEC2N9mVpg9g6@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
While we are performing a major configuration, there is no point having the PCS polling timer running. Stop it before we begin preparing for the configuration change, and restart it only once we've successfully completed the change. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King (Oracle) authored
Remove the pcs_ops member from struct phylink, using the one stored in struct phylink_pcs instead. Reviewed-by:
-
Eric Dumazet authored
Currently, "ss -K -ta ..." does not support TIME_WAIT sockets. Issue has been raised at least two times in the past [1] [2] it is time to fix it. [1] https://lore.kernel.org/netdev/ba65f579-4e69-ae0d-4770-bc6234beb428@gmail.com/ [2] https://lore.kernel.org/netdev/CANn89i+R9RgmD=AQ4vX1Vb_SQAj4c3fi7-ZtQz-inYY4Sq4CMQ@mail.gmail.com/T/ While we are at it, use inet_sk_state_load() while tcp_abort() does not hold a lock on the socket. Signed-off-by:
Eric Dumazet <edumazet@google.com> Tested-by:
Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/r/20220627121038.226500-1-edumazet@google.comSigned-off-by:
-
Dimitris Michailidis authored
Add the FW command for reading port module memory pages and implement ethtool's get_module_eeprom_by_page operation. Signed-off-by:
Dimitris Michailidis <dmichail@fungible.com> Link: https://lore.kernel.org/r/20220627182000.8198-1-dmichail@fungible.comSigned-off-by:
-
Kuniyuki Iwashima authored
While setting up init_net's sysctl table, we need not duplicate the global table and can use it directly as ipv4_sysctl_init_net() does. Unlike IPv4, AF_UNIX does not have a huge sysctl table for now, so it cannot be a problem, but this patch makes code consistent. Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20220627233627.51646-1-kuniyu@amazon.comSigned-off-by:
-
- 28 Jun, 2022 23 commits
-
-
Paolo Abeni authored
Ido Schimmel says: ==================== mlxsw: Unified bridge conversion - part 4/6 This is the fourth part of the conversion of mlxsw to the unified bridge model. Unlike previous parts that prepared mlxsw for the conversion, this part actually starts the conversion. It focuses on flooding configuration and converts mlxsw to the more "raw" APIs of the unified bridge model. The patches configure the different stages of the flooding pipeline in Spectrum that looks as follows (at a high-level): +------------+ +----------+ +-------+ {FID, | | {Packet type, | | | | MID DMAC} | FDB lookup | Bridge type} | SFGC | MID base | | Index +--------> (miss) +----------------> register +-----------> Adder +-------> | | | | | | | | | | | | +------------+ +----+-----+ +---^---+ | | Table | | type | | Offset | +-------+ | | | | | | | | | +----->+ Mux +------+ | | | | +-^---^-+ | | FID| |FID | |offset + + The multicast identifier (MID) index is used as an index to the port group table (PGT) that contains a bitmap of ports via which a packet needs to be replicated. From the PGT table, the packet continues to the multicast port egress (MPE) table that determines the packet's egress VLAN. This is a two-dimensional table that is indexed by port and switch multicast port to egress (SMPE) index. The latter can be thought of as a FID. Without it, all the packets replicated via a certain port would get the same VLAN, regardless of the bridge domain (FID). Logically, these two steps look as follows: PGT table MPE table +-----------------------+ +---------------+ | | {Local port, | | Egress MID index | Local ports bitmap #1 | SMPE index} | | VID +------------> ... +---------------> +--------> | Local ports bitmap #N | | | | | SMPE | | +-----------------------+ +---------------+ Local port Patchset overview: Patch #1 adds a variable to guard against mixed model configuration. Will be removed in part 6 when mlxsw is fully converted to the unified model. Patches #2-#5 introduce two new FID attributes required for flooding configuration in the new model: 1. 'flood_rsp': Instructs the firmware to handle flooding configuration for this FID. Only set for router FIDs (rFIDs) which are used to connect a {Port, VLAN} to the router block. 2. 'bridge_type': Allows the device to determine the flood table (i.e., base index to the PGT table) for the FID. The first type will be used for FIDs in a VLAN-aware bridge and the second for FIDs representing VLAN-unaware bridges. Patch #6 configures the MPE table that determines the egress VLAN of a packet that is forwarded according to L2 multicast / flood. Patches #7-#11 add the PGT table and related APIs to allocate entries and set / clear ports in them. Patches #12-#13 convert the flooding configuration to use the new PGT APIs. ==================== Link: https://lore.kernel.org/r/20220627070621.648499-1-idosch@nvidia.comSigned-off-by:Paolo Abeni <pabeni@redhat.com>
-
Amit Cohen authored
The PGT (Port Group Table) table maps an index to a bitmap of local ports to which a packet needs to be replicated. This table is used for layer 2 multicast and flooding. In the legacy model, software did not interact with PGT table directly. Instead, it was accessed by firmware in response to registers such as SFTR and SMID. In the new model, the SFTR register is deprecated and software has full control over the PGT table using the SMID register. Use the new PGT APIs to allocate entries for flooding as part of flood tables initialization. Add mlxsw_sp_fid_flood_tables_fini() to free the allocated indexes. In addition, use PGT APIs to add/remove ports from PGT table. The existing code which configures the flood entries via SFTR2 will be removed later. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Amit Cohen authored
The PGT (Port Group Table) table maps an index to a bitmap of local ports to which a packet needs to be replicated. This table is used for layer 2 multicast and flooding. The index to PGT table which is called 'mid_index', is a result of 'mid_base' + 'fid_offset'. Using the legacy bridge model, firmware configures 'mid_base'. However, using the new model, software is responsible to configure it via SFGC register. The first 15K entries will be used for flooding and the rest for multicast. The table will look as follows: +----------------------------+ | | | 802.1q, unicast flooding | 4K entries | | +----------------------------+ | | | 802.1q, multicast flooding | 4K entries | | +----------------------------+ | | | 802.1q, broadcast flooding | 4K entries | | +----------------------------+ | 802.1d, unicast flooding | 1K entries +----------------------------+ | 802.1d, multicast flooding | 1K entries +----------------------------+ | 802.1d, broadcast flooding | 1K entries +----------------------------+ | | | | | Multicast entries | The rest of the table | | | | +----------------------------+ Add 'pgt_base' to 'struct mlxsw_sp_fid_family' and use it to calculate MID base, set 'SFGC.mid_base' as part of flood tables initialization. Signed-off-by:
-
Amit Cohen authored
Initialize PGT table as part of mlxsw_sp_init(). This table will be used first in the next patch by FID code to set flooding entries, and later by MDB code to add multicast entries. Signed-off-by:
-
Amit Cohen authored
Add an API to associate a PGT entry with SMPE index and add or remove a port. This API will be used by FID code and MDB code, to add/remove port from specific PGT entry. When the first port is added to PGT entry, allocate the entry in the given MID index, when the last port is removed from PGT entry, free it. Signed-off-by:
-
Amit Cohen authored
Currently when bitmap of ports is needed, 'unsigned long *' type is used. The functions which use the bitmap assume its length according to its name, i.e., each function which gets a bitmap of ports queries the maximum number of ports and uses it as the size. As preparation for the next patch which will use bitmap of ports, add a dedicated structure for it. Refactor the existing code to use the new structure. Signed-off-by:
-
Amit Cohen authored
In Spectrum-1, the index into the MPE table - called switch multicast to port egress VID (SMPE) - is derived from the PGT entry, whereas in Spectrum-2 and later ASICs it is derived from the FID. Therefore, in Spectrum-1, the SMPE index needs to be programmed as part of the PGT entry via SMID register, while it is reserved for Spectrum-2 and later ASICs. Add 'pgt_smpe_index_valid' boolean as part of 'struct mlxsw_sp' and set it to true for Spectrum-1 and to false for the later ASICs. Add 'smpe_index_valid' as part of 'struct mlxsw_sp_pgt' and set it according to the value in 'struct mlxsw_sp' as part of PGT initialization. Signed-off-by:
-
Amit Cohen authored
The PGT (Port Group Table) table maps an index to a bitmap of local ports to which a packet needs to be replicated. This table is used for layer 2 multicast and flooding. In the legacy model, software did not interact with this table directly. Instead, it was accessed by firmware in response to registers such as SFTR and SMID. In the new model, the SFTR register is deprecated and software has full control over the PGT table using the SMID register. The entire state of the PGT table needs to be maintained in software because member ports in a PGT entry needs to be reference counted to avoid releasing entries which are still in use. Add the following APIs: 1. mlxsw_sp_pgt_{init, fini}() - allocate/free the PGT table. 2. mlxsw_sp_pgt_mid_alloc_range() - allocate a range of MID indexes in PGT. To be used by FID code during initialization to reserve specific PGT indexes for flooding entries. 3. mlxsw_sp_pgt_mid_free_range() - free indexes in a given range. 4. mlxsw_sp_pgt_mid_alloc() - allocate one MID index in the PGT at a non-specific range, just search for free index. To be used by MDB code. 5. mlxsw_sp_pgt_mid_free() - free the given index. Note that alloc() functions do not allocate the entries in software, just allocate IDs using 'idr'. Signed-off-by: -
Amit Cohen authored
The device includes two main tables to support layer 2 multicast (i.e., MDB and flooding). These are the PGT (Port Group Table) table and the MPE (Multicast Port Egress) table. - PGT is {MID -> (bitmap of local_port, SPME index)} - MPE is {(Local port, SMPE index) -> eVID} In the legacy model, software did not interact with MPE table as it was completely hidden in firmware. In the new model, software needs to populate the table itself in order to map from {Local port, SMPE} to an egress VID. This is done using the SMPE register. Configure SMPE register when a {Local port, VID} are mapped/unmapped to a 802.1d and 802.1q emulated FIDs. The MPE table is not relevant for rFIDs as firmware handles their flooding. Signed-off-by: -
Amit Cohen authored
In the unified bridge model, the bridge type FID attribute is no longer configured by the firmware, but instead by software when creating and editing a FID via SFMR register. Set this field as part of FID creation and edition flow. Default to 0 (reserved) as long as the driver operates in the legacy bridge model. Signed-off-by:
-
Amit Cohen authored
Currently, 'bridge_type' is an attribute of 'struct mlxsw_sp_flood_table', which is defined per FID family. Instead, it can be an attribute of 'struct mlxsw_sp_fid_family' as all flood tables in the same family are of the same type. This change will ease the configuration of 'SFMR.flood_bridge_type' which will be added in the next patch. Signed-off-by:
-
Amit Cohen authored
Under the legacy bridge model, the field 'bridge_type' is used only in SFGC register, to determine the type of flood table (FID/FID offset). Under the unified bridge model, it will be used also in SFMR register. When a BUM packet needs to be flooded, SFGC is used to provide the 'mid_base' for PGT table. The access to SFGC is by {packet type, bridge type}. Under the unified bridge model, software is responsible for configuring 'bridge_type' as part of SFMR. As preparation for the new required configuration, rename 'enum mlxsw_reg_sfgc_bridge_type' to 'enum mlxsw_reg_bridge_type'. Then it can be used also in SFMR. In addition, align the names of the values to internal documentation. Signed-off-by: -
Amit Cohen authored
Using unified bridge model, RITR register no longer configures the rFID used for sub-port RIFs. It needs to be created by software via SFMR. Such FIDs need to be created with a special flood indication using 'SFMR.flood_rsp=1'. It means that for such FIDs, router sub-port flooding table will be used, this table is configured by firmware. Set the above mentioned field as part of FID initialization and FID edition, so then when other fields will be updated in SFMR, this field will store the correct value and will not be overwritten. Add 'flood_rsp' variable to 'struct mlxsw_sp_fid_family', set it to true for rFID and to false for the rest. Signed-off-by:
-
Amit Cohen authored
As part of transition to unified bridge model, many different firmware configurations are done. Some of the configuration that needs to be done for the unified bridge model is not valid under the legacy model, and would be rejected by the firmware. At the same time, the driver cannot switch to the unified bridge model until all of the code has been converted. To allow breaking the change into patches, and to not break driver behavior during the transition, add a boolean variable to indicate bridge model. Then, forbidden configurations will be skipped using the check - "if (!mlxsw_sp->ubridge)". The new variable is temporary for several sets, it will be removed when firmware will be configured to work with unified bridge model. Signed-off-by:
-
Sam Edwards authored
The addrconf_verify_rtnl() function uses a big if/elseif/elseif/... block to categorize each address by what type of attention it needs. An about-to-expire (RFC 4941) temporary address is one such category, but the previous elseif branch catches addresses that have already run out their prefered_lft. This means that if addrconf_verify_rtnl() fails to run in the necessary time window (i.e. REGEN_ADVANCE time units before the end of the prefered_lft), the temporary address will never be regenerated, and no temporary addresses will be available until each one's valid_lft runs out and manage_tempaddrs() begins anew. Fix this by moving the entire temporary address regeneration case out of that block. That block is supposed to implement the "destructive" part of an address's lifecycle, and regenerating a fresh temporary address is not, semantically speaking, actually tied to any particular lifecycle stage. The age test is also changed from `age >= prefered_lft - regen_advance` to `age + regen_advance >= prefered_lft` instead, to ensure no underflow occurs if the system administrator increases the regen_advance to a value greater than the already-set prefered_lft. Note that this does not fix the problem of addrconf_verify_rtnl() sometimes not running in time, resulting in the race condition described in RFC 4941 section 3.4 - it only ensures that the address is regenerated. Fixing THAT problem may require either using jiffies instead of seconds for all time arithmetic here, or always rounding up when regen_advance is converted to seconds. Signed-off-by:
Sam Edwards <CFSworks@gmail.com> Link: https://lore.kernel.org/r/20220623181103.7033-1-CFSworks@gmail.comSigned-off-by:
-
Christophe JAILLET authored
'vlan_bitmap' is a bitmap and is used as such. So allocate it with devm_bitmap_zalloc() and its explicit bit size (i.e. VLAN_N_VID). This avoids the need of the VLAN_BITMAP_SIZE macro which: - needlessly has a 'nic_dev' parameter - should be "long" (and not byte) aligned, so that the bitmap semantic is respected This is in fact not an issue because VLAN_N_VID is 4096 at the time being, but devm_bitmap_zalloc() is less verbose and easier to understand. Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/6ff7b7d21414240794a77dc2456914412718a145.1656260842.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Jakub Kicinski authored
Simon Horman says: ==================== nfp: add VEPA and adapter selftest support 1. Support for ethtool -t: adapter selftest 2. VEPA mode in HW bridge. This supplements existing support for VEB mode. ==================== Link: https://lore.kernel.org/r/20220624073816.1272984-1-simon.horman@corigine.comSigned-off-by:
-
Fei Qin authored
Add support for ethtool selftest. e.g. # ethtool -t DEVNAME test result like: The test result is PASS The test extra info: Link Test 0 NSP Test 0 Firmware Test 0 Register Test 0 Signed-off-by:
Fei Qin <fei.qin@corigine.com> Reviewed-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Yinjun Zhang authored
Add support for VEPA mode of HW bridge. The default remains VEB mode. The mode may be configured using ndo_bridge_setlink, and inspected using ndo_bridge_getlink. Signed-off-by:
Yinjun Zhang <yinjun.zhang@corigine.com> Reviewed-by:
-
Jilin Yuan authored
Delete the redundant word 'the'. Signed-off-by:
Jilin Yuan <yuanjilin@cdjrlc.com> Link: https://lore.kernel.org/r/20220625071558.3852-1-yuanjilin@cdjrlc.comSigned-off-by:
-
Jilin Yuan authored
Delete the redundant word 'use'. Signed-off-by:
-
Jilin Yuan authored
Delete the redundant word 'the'. Signed-off-by:
-
Deming Wang authored
Delete duplicate words of "the". Signed-off-by:
Deming Wang <wangdeming@inspur.com> Link: https://lore.kernel.org/r/20220624013114.1913-1-wangdeming@inspur.comSigned-off-by:
-
- 27 Jun, 2022 10 commits
-
-
Eric Dumazet authored
vif_dev_read() should be used from RCU protected sections only. ipmr_rtm_dumplink() is holding RTNL, so the data structures can not be changed. syzbot reported: net/ipv4/ipmr.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz-executor.4/3068: stack backtrace: CPU: 1 PID: 3068 Comm: syz-executor.4 Not tainted 5.19.0-rc3-syzkaller-00565-g5d04b0b6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 vif_dev_read net/ipv4/ipmr.c:84 [inline] vif_dev_read net/ipv4/ipmr.c:82 [inline] ipmr_fill_vif net/ipv4/ipmr.c:2756 [inline] ipmr_rtm_dumplink+0x1343/0x18c0 net/ipv4/ipmr.c:2866 netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380 netlink_dump_start include/linux/netlink.h:245 [inline] rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x334/0x810 net/socket.c:2489 ___sys_sendmsg+0xf3/0x170 net/socket.c:2543 __sys_sendmmsg+0x195/0x470 net/socket.c:2629 __do_sys_sendmmsg net/socket.c:2658 [inline] __se_sys_sendmmsg net/socket.c:2655 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2655 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fefd8a89109 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefd9ca6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007fefd8b9bf60 RCX: 00007fefd8a89109 RDX: 0000000004924b68 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 00007fefd8ae305d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc346febaf R14: 00007fefd9ca6300 R15: 0000000000022000 </TASK> Fixes: ebc31979 ("ipmr: add rcu protection over (struct vif_device)->dev") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jilin Yuan authored
Delete the redundant word 'in'. Signed-off-by:
-
Jilin Yuan authored
Delete the redundant word 'set'. Delete the redundant word 'a'. Delete the redundant word 'in'. Found the same error as before. Signed-off-by:
-
Subash Abhinov Kasiviswanathan authored
The following commits added support for printing the real address- 65875073 ("net: use %px to print skb address in trace_netif_receive_skb") 70713ddd ("net_sched: introduce tracepoint trace_qdisc_enqueue()") 851f36e4 ("net_sched: use %px to print skb address in trace_qdisc_dequeue()") However, tracing the packet traversal shows a mix of hashes and real addresses. Pasting a sample trace for reference- ping-14249 [002] ..... 3424.046612: netif_rx_entry: dev=lo napi_id=0x3 queue_mapping=0 skbaddr=00000000dcbed83e vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x0800 ip_summed=0 hash=0x00000000 l4_hash=0 len=84 data_len=0 truesize=768 mac_header_valid=1 mac_header=-14 nr_frags=0 gso_size=0 gso_type=0x0 ping-14249 [002] ..... 3424.046615: netif_rx: dev=lo skbaddr=ffffff888e5d1000 len=84 Switch the trace print formats to %p for all the events to have a consistent format of printing the hashed addresses in all cases. Signed-off-by:
Sean Tranchetti <quic_stranche@quicinc.com> Signed-off-by:
Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'linux-can-next-for-5.20-20220625' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2022-06-25 this is a pull request of 22 patches for net-next/master. The first 2 patches target the xilinx driver. Srinivas Neeli's patch adds Transmitter Delay Compensation (TDC) support, a patch by me fixes a typo. The next patch is by me and fixes a typo in the m_can driver. Another patch by me allows the configuration of fixed bit rates without need for do_set_bittiming callback. The following 7 patches are by Vincent Mailhol and refactor the can-dev module and Kbuild, de-inline the can_dropped_invalid_skb() function, which has grown over the time, and drop outgoing skbs if the controller is in listen only mode. Max Staudt's patch fixes a reference in the networking/can.rst documentation. Vincent Mailhol provides 2 patches with cleanups for the etas_es58x driver. Conor Dooley adds bindings for the mpfs-can to the PolarFire SoC dtsi. Another patch by me allows the configuration of fixed data bit rates without need for do_set_data_bittiming callback. The last 5 patches are by Frank Jungclaus. They prepare the esd_usb driver to add support for the the CAN-USB/3 device in a later series. ==================== Signed-off-by:
-
David S. Miller authored
Clément Léger says: ==================== net: add support for Renesas RZ/N1 ethernet su The Renesas RZ/N1 SoCs features an ethernet subsystem which contains (most notably) a switch, two GMACs, and a MII converter [1]. This series adds support for the switch and the MII converter. The MII converter present on this SoC has been represented as a PCS which sit between the MACs and the PHY. This PCS driver is probed from the device-tree since it requires to be configured. Indeed the MII converter also contains the registers that are handling the muxing of ports (Switch, MAC, HSR, RTOS, etc) internally to the SoC. The switch driver is based on DSA and exposes 4 ports + 1 CPU management port. It include basic bridging support as well as FDB and statistics support. Link: [1] https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-r-engine-and-ethernet-peripherals ----- Changes in V9: - Cover letter: - Remove comment about RZN1 patches that are now in the master branch. - Commits: - Add Vladimir Oltean Reviewed-by - PCS: - Add "Depends on OF" for PCS_RZN1_MIIC due to error found by intel kernel test robot <lkp@intel.com>. - Check return value of of_property_read_u32() for "renesas,miic-switch-portin" property before setting conf. - Return miic_parse_dt() return value in miic_probe() on error - Switch: - Add "Depends on OF" for NET_DSA_RZN1_A5PSW due to errors found by intel kernel test robot <lkp@intel.com>. - DT: - Add spaces between switch port and '{' ==================== Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Clément Léger authored
After contributing the drivers, volunteer for maintenance and add myself as the maintainer for Renesas RZ/N1 switch related drivers. Signed-off-by:
Clément Léger <clement.leger@bootlin.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Clément Léger authored
Add description for the switch, GMAC2 and MII converter. With these definitions, the switch port 0 and 1 (MII port 5 and 4) are working on RZ/N1D-DB board. Signed-off-by:
-
Clément Léger authored
Add description of the switch that is present on the RZ/N1 SoC. This description includes ethernet-ports description for all the ports that are present on the switch along with their connection to the MII converter ports and to the GMAC for the CPU port. Signed-off-by:
-
Clément Léger authored
RZ/N1 SoC includes two MAC named GMACx that are compatible with the "snps,dwmac" driver. GMAC1 is connected directly to the MII converter port 1. GMAC2 however can be used as the MAC for the switch CPU management port or can be muxed to be connected directly to the MII converter port 2. This commit add description for the GMAC2 which will be used by the switch description. Signed-off-by:
-
