This removes the need for the second call. Reviewed by: dsl Differential Revision: https://reviews.freebsd.org/D47388 (cherry picked from commit 24d5a8e6eec2b9eed9591971f223d79b8d7044c9)
Reviewed by: dsl Differential Revision: https://reviews.freebsd.org/D43937 (cherry picked from commit 9b619f0e9082b8f97f0e20ec5176fe40ba8565f8)
PR: 282800 Reported by: phk Tested by: bz MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D47666 (cherry picked from commit c2dd2be344fbf59cf95f6773d4b09cc7dda0f876)
Packet capturing on dpni is only half-working given the BPF_MTAP call in the TX path is missing. Add it to see packets in both directions. Reviewed by: dsl Differential Revision: https://reviews.freebsd.org/D47103 (cherry picked from commit e69e172d40585cfbcfdb28433cec523ca4867cf1)
0480dccd3f34 tried to fix the MTU for software VLANs given dpni announces IFCAP_VLAN_MTU. Unfortunately the initial MRU during setup is reduced from the maximum supported by the HW to our maximum ethernet RX frame length so only after further mtu toggles the solution there would work. Set the maximum RX frame size (without CRC) to jumbo length + vlan encap len by default given we also announce IFCAP_JUMBO_MTU. While here improve the manual (ioctl) MTU setting by checking if IFCAP_VLAN_MTU is currently enabled and only then add the extra bytes. Fixes: 0480dccd3f347da0dbccf5917633435d5ce6cb86 Reviewed by: dsl Differential Revision: https://reviews.freebsd.org/D47066 (cherry picked from commit fa3dfeff95a5bafcf13accaed5164bfc4e028d9a)
MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D45853 (cherry picked from commit 36ef39831fe0e89f0b1672340a44c4ac1183158e)
Change 4787572d0580 made if_alloc_domain() never fail, then also do the wrappers if_alloc(), if_alloc_dev(), and if_gethandle(). No functional change intended. Reviewed by: kp, imp, glebius, stevek MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D45740 (cherry picked from commit aa3860851b9f6a6002d135b1cac7736e0995eedc)
dpni announces IFCAP_VLAN_MTU but internally does not increase the maximum frame length. Createing a vlan interface on top of a dpni interface will result in full-sized frames not passing. Extend the maximum frame length by ETHER_VLAN_ENCAP_LEN to allow at least for one layer of (software) vlans for now GH-Issue: https://github.com/mcusim/freebsd-src/issues/22 Reviewed by: dsl Differential Revision: https://reviews.freebsd.org/D42645 (cherry picked from commit 0480dccd3f347da0dbccf5917633435d5ce6cb86)
dpaa2_ni_media_change() was called in early setup stages, before we were fully setup. That lead to internal driver state being all synched and fine but hardware state was lost/never setup corrently. Introduce dpaa2_ni_media_change_locked() so we can avoid reccursive locking and call "dpaa2_ni_media_change()" instead of mii_mediachg() as the latter does not setup our state there either. In order for this all to work, call if_setdrvflagbits() just before rather than after the above. Also remove an unecessary direct call to dpaa2_ni_miibus_statchg() which mii_mediachg() will trigger anyway. This all fixes a problem [1] that one had to lose the link (either unplugging/replugging the cable or using ifconfig media none; ifconfig media auto) to re-trigger the all updates and get the full state programmed when hardware expected. GH-Issue: https://github.com/mcusim/freebsd-src/issues/21 [1] Reviewed by: dsl, dch Differential Revision: https://reviews.freebsd.org/D42643 (cherry picked from commit 964b3408fa872178aacf58f2d84dc43564ec0aa7)
'pcs-handles' are not mandatory in the device tree here so do not enforce them. This allows us to find dpmac entries needed for phys on the WHLE-LS1 as well. Reviewed by: jceel, dsl Differential Revision: https://reviews.freebsd.org/D42644 (cherry picked from commit 6c46ebb05dccdcee18f64dc122e6685c05180217)