History log of /freebsd-current/sys/dev/bwn/if_bwn_pci.c
Revision Date Author Comments
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix


# b338e3ea 09-May-2022 John Baldwin <jhb@FreeBSD.org>

bwi/bwn: Remove unused devclass arguments to DRIVER_MODULE.


# 05bdf34a 09-May-2022 John Baldwin <jhb@FreeBSD.org>

Remove unused bhndb_devclass.


# 7163a849 01-Sep-2020 Mateusz Guzik <mjg@FreeBSD.org>

bwn: clean up empty lines in .c and .h files


# 329e817f 26-Sep-2018 Warner Losh <imp@FreeBSD.org>

Reapply, with minor tweaks, r338025, from the original commit:

Remove unused and easy to misuse PNP macro parameter

Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.

Mostly done with the coccinelle 'spatch' tool:

$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);

@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);

$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci

(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)

Tinderbox'd (-DMAKE_JUST_KERNELS).
Approved by: re (glen)


# b8e771e9 18-Aug-2018 Conrad Meyer <cem@FreeBSD.org>

Back out r338035 until Warner is finished churning GSoC PNP patches

I was not aware Warner was making or planning to make forward progress in
this area and have since been informed of that.

It's easy to apply/reapply when churn dies down.


# faa31943 18-Aug-2018 Conrad Meyer <cem@FreeBSD.org>

Remove unused and easy to misuse PNP macro parameter

Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.

Mostly done with the coccinelle 'spatch' tool:

$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);

@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);

$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci

(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)

Tinderbox'd (-DMAKE_JUST_KERNELS).


# 96b52361 13-Jun-2018 Warner Losh <imp@FreeBSD.org>

Add PNP info to PCI attachment of bwn driver

Reviewed by: imp, chuck
Submitted by: Lakhan Shiva Kamireddy <lakhanshiva@gmail.com>
Sponsored by: Google, Inc. (GSoC 2018)


# d177c199 05-Feb-2018 Landon J. Fuller <landonf@FreeBSD.org>

bwn(4): migrate bwn(4) to the native bhnd(9) interface, and drop siba_bwn.

- Remove the shim interface that allowed bwn(4) to use either siba_bwn or
bhnd(4), replacing all siba_bwn calls with their bhnd(4) bus equivalents.
- Drop the legay, now-unused siba_bwn bus driver.
- Clean up bhnd(4) board flag defines referenced by bwn(4).

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13518


# a225321f 19-Jan-2018 Landon J. Fuller <landonf@FreeBSD.org>

bhnd/bwn(4): Define a bhnd(4) softmodem device class for the v.90 modem
codec core, and mark the core as unpopulated on all BCM4306 bwn(4) devices.

Sponsored by: The FreeBSD Foundation


# 72759b48 19-Jan-2018 Landon J. Fuller <landonf@FreeBSD.org>

bwn(4): Add missing BCM4306 PCI IDs.

Sponsored by: The FreeBSD Foundation


# 19a63eb5 17-Jan-2018 Landon J. Fuller <landonf@FreeBSD.org>

bwn(4): Enable, by default, the opt-in support for bhnd(4) introduced in
r326454.

bwn(4)/bhnd(4) has been tested with most chipsets currently supported by
bwn(4), and this change should be transparent to existing bwn(4) users;
please report any regressions that you do encounter.

To revert to using siba_bwn(4) instead of bhnd(4), place the following
lines in loader.conf(5):

hw.bwn_pci.preferred="0"

Once we're satisfied that the switch to bhnd(4) has seen sufficient broader
testing, bwn(4) will be migrated to use the native bhnd(9) interface
directly, and support for siba_bwn(4) will be dropped (see D13518).

Sponsored by: The FreeBSD Foundation


# 0bffd217 13-Dec-2017 Landon J. Fuller <landonf@FreeBSD.org>

Add basic bwn(4) support for the (BCMA-based) BCM43224 and BCM43225.

- Add the BCM4322X D11 core revision and missing BCM43224 PCI device ID to
our device tables.
- Disable the DMA engine parity check (rather than adding parity support
to the to-be-replaced bwn(4) DMA implementation).

Currently, N-PHY support in bwn(4) is GPL licensed, and is not included by
default. Until this is replaced with Broadcom's ISC-licensed N-PHY
implementation, bwn(4) must be rebuilt to enable N-PHY support.

To build bwn(4) with N-PHY support, add the following lines to your kernel
configuration file and rebuild the kernel (and modules):

options BWN_GPL_PHY

To test bwn(4) with a BCM43224/BCM43225 device, install the firmware from
the net/bwn-firmware-kmod port, and place the following lines in
loader.conf(5):

hw.bwn_pci.preferred="1"

if_bwn_pci_load="YES
bwn_v4_ucode_load="YES"
bwn_v4_n_ucode_load="YES"
bwn_v4_lp_ucode_load="YES"

Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation


# 8d14ca9c 01-Dec-2017 Landon J. Fuller <landonf@FreeBSD.org>

Introduce bwn(4) support for the bhnd(4) bus.

Currently, bwn(4) relies on the siba_bwn(4) bus driver to provide support
for the on-chip SSB interconnect found in Broadcom's older PCI(e) Wi-Fi
adapters. Non-PCI Wi-Fi adapters, as well as the newer BCMA interconnect
found in post-2009 Broadcom Wi-Fi hardware, are not supported by
siba_bwn(4).

The bhnd(4) bus driver (also used by the FreeBSD/MIPS Broadcom port)
provides a unified kernel interface to a superset of the hardware supported
by siba_bwn; by attaching bwn(4) via bhnd(4), we can support both modern
PCI(e) Wi-Fi devices based on the BCMA backplane interconnect, as well as
Broadcom MIPS WiSoCs that include a D11 MAC core directly attached to their
SSB or BCMA backplane.

This diff introduces opt-in bwn(4) support for bhnd(4) by providing:

- A small bwn(4) driver subclass, if_bwn_bhnd, that attaches via
bhnd(4) instead of siba_bwn(4).
- A bhndb(4)-based PCI host bridge driver, if_bwn_pci, that optionally
probes at a higher priority than the siba_bwn(4) PCI driver.
- A set of compatibility shims that perform translation of bwn(4)'s
siba_bwn function calls into their bhnd(9) API equivalents when bwn(4)
is attached via a bhnd(4) bus parent. When bwn(4) is attached via
siba_bwn(4), all siba_bwn function calls are simply passed through to
their original implementations.

To test bwn(4) with bhnd(4), place the following lines in loader.conf(5):

hw.bwn_pci.preferred="1"

if_bwn_pci_load="YES
bwn_v4_ucode_load="YES"
bwn_v4_lp_ucode_load="YES"

To verify that bwn(4) is using bhnd(4), you can check dmesg:

bwn0: <Broadcom 802.11 MAC/PHY/Radio, rev 15> ... on bhnd0

... or devinfo(8):

pcib2
pci2
bwn_pci0
bhndb0
bhnd0
bwn0
...

bwn(4)/bhnd(4) has been tested for regressions with most chipsets currently
supported by bwn(4), including:

- BCM4312
- BCM4318
- BCM4321

With minimal changes to the DMA code (not included in this commit), I was
also able to test support for newer BCMA devices by bringing up basic
working Wi-Fi on two previously unsupported, BCMA-based N-PHY chipsets:

- BCM43224
- BCM43225

Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation & Plausible Labs
Differential Revision: https://reviews.freebsd.org/D13041


# 7d616280 05-Sep-2016 Landon J. Fuller <landonf@FreeBSD.org>

bwn(4): ignore BCM4321's unpopulated USB11 host controller core.

Broadcom Intensi-fi chipsets provided a common set of IP cores; on PCI/PCIe
devices, the USB11 host controller is left floating.

Approved by: adrian (mentor, implicit)


# 111d7cb2 03-Sep-2016 Landon J. Fuller <landonf@FreeBSD.org>

Migrate bhndb(4) to the new bhnd_erom API.

Adds support for probing and initializing bhndb(4) bridge state using
the bhnd_erom API, ensuring that full bridge configuration is available
*prior* to actually attaching and enumerating the bhnd(4) child device,
allowing us to safely allocate bus-level agent/device resources during
bhnd(4) bus enumeration.

- Add a bhnd_erom_probe() method usable by bhndb(4). This is an analogue
to the existing bhnd_erom_probe_static() method, and allows the bhndb
bridge to discover the best available erom parser class prior to newbus
probing of its children.
- Add support for supplying identification hints when probing erom
devices. This is required on early EXTIF-only chipsets, where chip
identification registers are not available.
- Migrate bhndb over to the new bhnd_erom API, using bhnd_core_info
records rather than bridged bhnd(4) device_t references to determine
the bridged chipsets' capability/bridge configuration.
- The bhndb parent (e.g. if_bwn) is now required to supply a hardware
priority table to the bridge. The default table is currently sufficient
for our supported devices.
- Drop the two-pass attach approach we used for compatibility with bhndb(4) in
the bhnd(4) bus drivers, and instead perform bus enumeration immediately,
and allocate bridged per-child bus-level resources during that enumeration.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7768


# 972459a6 23-May-2016 Adrian Chadd <adrian@FreeBSD.org>

[bwn] add BCM43225 to the BHND device list.

This is all for the bhnd(4) work in progress. It's enough to probe/attach
all the bhnd internals, but we're missing OTP support and some cleanup
code. And, well, all the rest of the bhnd(4) migration.

So no, this won't give you BCM43225 support. Sorry!


# 5025b8d5 16-May-2016 Adrian Chadd <adrian@FreeBSD.org>

[bwn] add opt_wlan.h and opt_bwn.h so we can enable bwn debugging as appropriate.

Tested:

* BCM4322, STA mode (11a)

Sponsored by: Palm Springs


# 148ed571 04-May-2016 Adrian Chadd <adrian@FreeBSD.org>

[bwn] [bhnd] initial support for using bhnd for if_bwn devices.

This is an initial work in progress to use the replacement bhnd
bus code for devices which support it.

* Add manpage updates for bhnd, bhndb, siba
* Add kernel options for bhnd, bhndbus, etc
* Add initial support in if_bwn_pci / if_bwn_mac for using bhnd
as the bus transport for suppoted NICs
* if_bwn_pci will eventually be the PCI bus glue to interface to bwn,
which will use the right backend bus to attach to, versus direct
nexus/bhnd attachments (as found in embedded broadcom devices.)

The PCI glue defaults to probing at a lower level than the bwn glue,
so bwn should still attach as per normal without a boot time tunable set.

It's also not fully fleshed out - the bwn probe/attach code needs to be
broken out into platform and bus specific things (just like ath, ath_pci,
ath_ahb) before we can shift the driver over to using this.

Tested:

* BCM4311, STA mode
* BCM4312, STA mode

Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6191