malo(4): Fix line breaks in attach output.

if_attach and if_initialize cannot fail, don't test return value

These were originally made failable back in 2017 when if_initialize
allocated a softint in every interface for link state changes, so
that it could fail gracefully instead of panicking:

https://mail-index.NetBSD.org/source-changes/2017/10/23/msg089053.html

However, this spawned many seldom- or never-tested error branches,
which are risky to have around. And that softint in every interface
has since been replaced by a single global workqueue, because link
state changes require thread context but not low latency or high
throughput:

https://mail-index.NetBSD.org/source-changes/2020/02/06/msg113759.html

So there is no longer any reason for if_initialize to fail. (The
subroutine if_stats_init can't fail because percpu_alloc can't fail
either.)

There is a snag: the softint_establish in if_percpuq_create could
fail, potentially leading to bad consequences later on trying to use
the softint. This change doesn't introduce any new bugs because of
the snag -- if_percpuq_attach was already broken. However, the snag
can be better addressed without spawning error branches, either by
using a single softint or making softints less scarce.

(Separate commit will change the signatures of if_attach and
if_initialize to return void, scheduled to ride whatever is the next
convenient kernel bump.)

Patch and testing on amd64 and evbmips64-eb by maya@; commit message
soliloquy, and compile-testing on evbppc/i386/earmv7hf, by me.

branches: 1.18.10;
Adopt <net/if_stats.h>.

branches: 1.17.2;
in many device attach paths, allocate memory with M_WAITOK instead of M_NOWAIT
and remove code to handle failures that can no longer happen.

Reduce always true comparison in malo_cmd_set_txpower()

powerlevel is already checked for >=30 in the previous condition.

Found by the lgtm bot.

use callout_destroy in malo_detach, not callout_stop

always use correct function to free our copy of the microcode

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.12.2;
Implement the BPF direction filter (BIOC[GS]DIRECTION). It provides backward
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.

This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.

bpf_mtap*() after ieee80211_encap() should be bpf_mtap3() rather than
bpf_mtap(). bpf_mtap3() is for raw bpf.

branches: 1.10.2;
If if_initialize() failed in the attach function, free resources and return.

branches: 1.9.6;
wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.2; 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

if_attach and if_initialize cannot fail, don't test return value

These were originally made failable back in 2017 when if_initialize
allocated a softint in every interface for link state changes, so
that it could fail gracefully instead of panicking:

https://mail-index.NetBSD.org/source-changes/2017/10/23/msg089053.html

However, this spawned many seldom- or never-tested error branches,
which are risky to have around. And that softint in every interface
has since been replaced by a single global workqueue, because link
state changes require thread context but not low latency or high
throughput:

https://mail-index.NetBSD.org/source-changes/2020/02/06/msg113759.html

So there is no longer any reason for if_initialize to fail. (The
subroutine if_stats_init can't fail because percpu_alloc can't fail
either.)

There is a snag: the softint_establish in if_percpuq_create could
fail, potentially leading to bad consequences later on trying to use
the softint. This change doesn't introduce any new bugs because of
the snag -- if_percpuq_attach was already broken. However, the snag
can be better addressed without spawning error branches, either by
using a single softint or making softints less scarce.

(Separate commit will change the signatures of if_attach and
if_initialize to return void, scheduled to ride whatever is the next
convenient kernel bump.)

Patch and testing on amd64 and evbmips64-eb by maya@; commit message
soliloquy, and compile-testing on evbppc/i386/earmv7hf, by me.

Adopt <net/if_stats.h>.

branches: 1.17.2;
in many device attach paths, allocate memory with M_WAITOK instead of M_NOWAIT
and remove code to handle failures that can no longer happen.

Reduce always true comparison in malo_cmd_set_txpower()

powerlevel is already checked for >=30 in the previous condition.

Found by the lgtm bot.

use callout_destroy in malo_detach, not callout_stop

always use correct function to free our copy of the microcode

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.12.2;
Implement the BPF direction filter (BIOC[GS]DIRECTION). It provides backward
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.

This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.

bpf_mtap*() after ieee80211_encap() should be bpf_mtap3() rather than
bpf_mtap(). bpf_mtap3() is for raw bpf.

branches: 1.10.2;
If if_initialize() failed in the attach function, free resources and return.

branches: 1.9.6;
wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.2; 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

Adopt <net/if_stats.h>.

in many device attach paths, allocate memory with M_WAITOK instead of M_NOWAIT
and remove code to handle failures that can no longer happen.

Reduce always true comparison in malo_cmd_set_txpower()

powerlevel is already checked for >=30 in the previous condition.

Found by the lgtm bot.

use callout_destroy in malo_detach, not callout_stop

always use correct function to free our copy of the microcode

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.12.2;
Implement the BPF direction filter (BIOC[GS]DIRECTION). It provides backward
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.

This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.

bpf_mtap*() after ieee80211_encap() should be bpf_mtap3() rather than
bpf_mtap(). bpf_mtap3() is for raw bpf.

branches: 1.10.2;
If if_initialize() failed in the attach function, free resources and return.

branches: 1.9.6;
wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.2; 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

in many device attach paths, allocate memory with M_WAITOK instead of M_NOWAIT
and remove code to handle failures that can no longer happen.

Reduce always true comparison in malo_cmd_set_txpower()

powerlevel is already checked for >=30 in the previous condition.

Found by the lgtm bot.

use callout_destroy in malo_detach, not callout_stop

always use correct function to free our copy of the microcode

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.12.2;
Implement the BPF direction filter (BIOC[GS]DIRECTION). It provides backward
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.

This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.

bpf_mtap*() after ieee80211_encap() should be bpf_mtap3() rather than
bpf_mtap(). bpf_mtap3() is for raw bpf.

branches: 1.10.2;
If if_initialize() failed in the attach function, free resources and return.

branches: 1.9.6;
wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.2; 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

Reduce always true comparison in malo_cmd_set_txpower()

powerlevel is already checked for >=30 in the previous condition.

Found by the lgtm bot.

use callout_destroy in malo_detach, not callout_stop

always use correct function to free our copy of the microcode

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

branches: 1.12.2;
Implement the BPF direction filter (BIOC[GS]DIRECTION). It provides backward
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.

This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.

bpf_mtap*() after ieee80211_encap() should be bpf_mtap3() rather than
bpf_mtap(). bpf_mtap3() is for raw bpf.

branches: 1.10.2;
If if_initialize() failed in the attach function, free resources and return.

branches: 1.9.6;
wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.2; 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

use callout_destroy in malo_detach, not callout_stop

always use correct function to free our copy of the microcode

Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

Implement the BPF direction filter (BIOC[GS]DIRECTION). It provides backward
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.

This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.

bpf_mtap*() after ieee80211_encap() should be bpf_mtap3() rather than
bpf_mtap(). bpf_mtap3() is for raw bpf.

branches: 1.10.2;
If if_initialize() failed in the attach function, free resources and return.

branches: 1.9.6;
wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.2; 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

If if_initialize() failed in the attach function, free resources and return.

wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

branches: 1.8.2; 1.8.4;
Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

wlan interfaces make interrupt routine running on softint context.

see http://mail-index.netbsd.org/tech-kern/2016/12/06/msg021281.html

tested device:
* ath at pci: AR5212, AR5424
* athn at pci: AR9287
* ipw at pci: 2100BG
* iwi at pci: 2915ABG
* iwm at pci: 3165, 7260, 8260
* iwn at pci: 4945, 6235
* ral at pci: RT2560
* rtwn at pci: RTL8192CE

Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)

Introduce m_set_rcvif and m_reset_rcvif

The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.

No functional change.

Introduce M_CLEARCTX and use it instead of open-coding rcvif

No functional change.

Use M_GETCTX

No functional change.

malo_rx_desc::status is uint8_t, so don't try to endian-twiddle it

PR/50948: David Binderman: Fix misplaced parens

branches: 1.3.4; 1.3.18;
Add pmf(9) handler to malo(4) wireless driver

Add missing $NetBSD$ tags and __KERNEL_RCSID().

Add malo(4)@pci driver for Marvell Libertas wireless adaptor

Ported from OpenBSD
Known issues :
- contrary to OpenBSD one, only support pci at the moment, because I don't
have the necessary hardware to test PCMCIA / CARDUS Marvell Card
- not connected to pmf(9) (unable to test it)