Both of the aforementioned macros have been present in FreeBSD
for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for
`DEVMETHOD_END`.

Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END`
and `KOBJMETHOD_END` as appropriate. This helps ensure that
future adaptations to drivers following patterns documented
in driver(9) can be made more easily/without issue.

MFC after:	1 week
Differential Revision:	 https://reviews.freebsd.org/D55414

- s/segement/segment/

MFC after:	3 days

When operating the multicast MAC filters, the current usage of
ECORE_FILTER_ADD and ECORE_FILTER_REMOVE are rather misleading.
ECORE_FILTER_ADD reads "adding new filter", but it actually removes
any existing filters and then addes a new one. ECORE_FILTER_REMOVE
reads "removing a filter", but it actually removes all filters.
Let's use ECORE_FILTER_REPLACE and ECORE_FILTER_FLUSH instead to
avoid confusion.

In the current implementation, only one MAC address is passed to
ecore_sp_eth_filter_mcast() and any previously installed filters are
removed, hence it breaks the multicast function. That can be observed
via either assigning new IPv6 addresses to the interface or putting
the interface as a member of lagg(4) interface with LACP aggregation
protocol. Fix that by calculating the multicast filter bins directly
from multicast MAC addresses and replace the filters every time
the bins changes.

Due to the nature of the multicast filter, which is hash based, a
full 1's multicast filter bin means all multicast packets are to be
accepted. Thus there's no need to make the vport into allmulti mode
when the number of multicast MAC addresses exceeds the limit
(ECORE_MAX_MC_ADDRS, 64).

Tested with a FastLinQ QL41212HLCU 25GbE adapter, both MFW_Version
8.35.23.0 and 8.59.16.0 are tested.

Note: Currently the VF port is set to promiscuous mode unconditionally,
and the setting of the multicast MAC filters for VF ports is
short-circuited, so the VF port functions as it did.

PR:		265857
PR:		290973
Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54892

Currently only the packets in the RX path can be captured by tcpdump
as the ETHER_BPF_MTAP call in the TX path is missing. Add it so that
packets in both directions can be captured.

PR:		290973
Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54891

There are two entry points to set the promiscuous and allmulti mode.
One is ioctl, and another is the init routine. Given they share almost
the identical logic, refactor a little to make the code more clear.

While here, for the ioctl, translate the error to EINVAL to avoid
confusing the net stack.

Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54890

Since the change [1], the init routine qlnx_init() works as intended.
Let ether_ioctl() handle SIOCSIFADDR to simplify the code.

Combined with the change [1], this shall be a better fix for PR 287445.

[1] c10e6bc0f007 qlnxe: Avoid reinitializing the interface when it is already initialized

PR:		287445
Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54888

qlnx_init_locked() unconditionally uninitialize the interface thus is
actually reinitializing the interface. Well the init routine qlnx_init()
is to initialize the interface by net stack when assigned with the first
inet or inet6 address. The ioctl SIOCSIFADDR for the first inet6 address
is handled by ether_ioctl() thus the interface is reinitialized no matter
it was initialized or not.

Add a driver status check for that to avoid reinitializing. Further plan
is removing SIOCSIFADDR ioctl from the driver and let ether_ioctl() handle
it.

Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54887

The driver-managed status flags should be lock protected to be touched.
Also this can serialize ioctls those check the IFF_DRV_RUNNING status.

Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54886

When an Ethernet interface is added to lagg(4) as a child interface, its
type, aka if_type, is changed from IFT_ETHER to IFT_IEEE8023ADLAG. Well
changing the link-layer address of the lagg(4) interface will be
propagated to all child interfaces, hence the drivers of child interfaces
shall not presume the type of the interface will not be changed.

Meanwhile, on initializing, an ifnet has been fully attached and it is
guaranteed to have non-null link-layer address so stop NULL checking for
it.

Reviewed by:	kbowling
Fixes:		792226e53023 qlnxe: Allow MAC address override
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54885

In case the device is VF, qlnx_get_mac_addr() returns ha->primary_mac
hence it ends up memcpy with same source and destination. Refactor
slightly to avoid that.

Reviewed by:	kbowling
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D54884