| History log of /src/sys/dev/pci/if_bwfm_pci.c |
| Revision | | Date | Author | Comments |
| 1.14 |
| 05-Jul-2024 |
rin | sys: Drop redundant NULL check before m_freem(9)
m_freem(9) safely has accepted NULL argument at least since 4.2BSD:
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/sys/uipc_mbuf.c
Compile-tested on amd64/ALL.
Suggested by knakahara@
|
| 1.13 |
| 23-May-2022 |
rin | branches: 1.13.10;
Audit unload/unmap v.s. free against DMA buffer for sys/dev/pci;
make sure that bus_dmamap_unload(9) [or bus_dmamap_destroy(9)] or
bus_dmamem_unmap(9) are preceding to freeing DMA buffer, if it is
loaded or mapped, respectively.
This is mandatory for some archs. See, e.g.:
http://www.nerv.org/netbsd/?q=id:20210511T013030Z.013443cc790088147e4beed43f53dedabeaf9312
http://www.nerv.org/netbsd/?q=id:20220511T172220Z.561179f0b6fcc5b9cd73e274f69d74e2ce9e4c93
XXX XXX XXX
Compile test only (for amd64/ALL).
Thanks riastradh@ for double check.
|
| 1.12 |
| 24-Apr-2022 |
skrll | Trailing whitespace
|
| 1.11 |
| 26-Aug-2021 |
andvar | Add missing RCSID in header files and one __KERNEL_RCSID().
|
| 1.10 |
| 08-May-2021 |
thorpej | Use pci_compatible_match().
|
| 1.9 |
| 30-May-2020 |
jdolecek | branches: 1.9.6;
discussed with thorpej@, and it seems it's better to allocate the bss
alignment buffer statically (as part of softc) just to be sure to not
affect performance
|
| 1.8 |
| 30-May-2020 |
jdolecek | constify, and make static where possible
|
| 1.7 |
| 25-Mar-2020 |
thorpej | - Refactor the firmware loading code into a set of common routines in the
core driver that understand how to find model-specific files before the
generic files. This greatly simplifies the firmware loading procedure
in each of the bus front ends. Adding additional firmware file types
(such as CLM files) much simpler.
- Make firmware image selection table-driven rather than a set of switch()
and if() statements.
- Add several additional firmware image entries.
|
| 1.6 |
| 09-Dec-2018 |
jdolecek | use pci_intr_establish_xname() everywhere
|
| 1.5 |
| 01-Nov-2018 |
martin | Make this compilable with 32bit paddr_t.
|
| 1.4 |
| 15-Oct-2018 |
maya | branches: 1.4.2;
Apply OpenBSD if_bwfm_pci.c:1.25 by patrick:
Add bus_dmamap_sync(9) calls to bwfm(4) so that we make sure the data
is synced properly before the CPU or the WiFi chip access the supplied
memory. Makes PCIe-connected bwfm(4) work on ARM-based machines.
|
| 1.3 |
| 03-Sep-2018 |
riastradh | 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!)
|
| 1.2 |
| 01-Sep-2018 |
riastradh | bwfm has only one tx descriptor; limit mbuf chains to one segment.
PR kern/53287
Can't use m_defrag because it always yields two segments.
Discussion on tech-net:
https://mail-index.netbsd.org/tech-net/2018/09/01/msg007031.html
Diagnosed and tested by maya.
|
| 1.1 |
| 11-May-2018 |
maya | branches: 1.1.2; 1.1.4;
add bwfm pci support, from openbsd
Tested on BCM43602.
|
| 1.1.4.2 |
| 08-Apr-2020 |
martin | Merge changes from current as of 20200406
|
| 1.1.4.1 |
| 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1.2.6 |
| 26-Dec-2018 |
pgoyette | Sync with HEAD, resolve a few conflicts
|
| 1.1.2.5 |
| 26-Nov-2018 |
pgoyette | Sync with HEAD, resolve a couple of conflicts
|
| 1.1.2.4 |
| 20-Oct-2018 |
pgoyette | Sync with head
|
| 1.1.2.3 |
| 06-Sep-2018 |
pgoyette | Sync with HEAD
Resolve a couple of conflicts (result of the uimin/uimax changes)
|
| 1.1.2.2 |
| 21-May-2018 |
pgoyette | Sync with HEAD
|
| 1.1.2.1 |
| 11-May-2018 |
pgoyette | file if_bwfm_pci.c was added on branch pgoyette-compat on 2018-05-21 04:36:06 +0000
|
| 1.4.2.3 |
| 02-Nov-2018 |
martin | Additional pullup for ticket #1072:
sys/dev/pci/if_bwfm_pci.c 1.5
Make this compilable with 32bit paddr_t.
|
| 1.4.2.2 |
| 31-Oct-2018 |
martin | Backport of bfwm code, requested by maya in ticket #1072:
sys/dev/ic/bwfm.c 1.14
sys/dev/ic/bwfmreg.h 1.3
sys/dev/ic/bwfmvar.h 1.3
sys/dev/pci/if_bwfm_pci.c 1.4
sys/dev/pci/if_bwfm_pci.h 1.8
sys/dev/usb/if_bwfm_usb.c 1.8
via patch.
|
| 1.4.2.1 |
| 15-Oct-2018 |
martin | file if_bwfm_pci.c was added on branch netbsd-8 on 2018-10-31 09:23:00 +0000
|
| 1.9.6.1 |
| 13-May-2021 |
thorpej | Sync with HEAD.
|
| 1.13.10.1 |
| 02-Aug-2025 |
perseant | Sync with HEAD
|
