#
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
|