Revision tags: release/14.0.0 |
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
6e778a7e |
| 08-Dec-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
SPDX: license IDs for some ISC-related files.
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0 |
|
#
e477abf7 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC @ r241285
|
#
a10c6f55 |
| 11-Nov-2012 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r242684
|
#
23090366 |
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
#
24bf3585 |
| 04-Sep-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r240095.
|
#
9f24e32b |
| 24-Aug-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Add some more diagnostic codes.
Obtained from: Qualcomm Atheros
|
Revision tags: release/8.3.0_cvs, release/8.3.0, release/9.0.0 |
|
#
f3959573 |
| 19-Mar-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Reserve a new diagnostic code for the channel survey code I'll add soon.
|
#
9b4fcf85 |
| 18-Feb-2011 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@218816
|
Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0 |
|
#
0dbe9289 |
| 20-Jan-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Break out the diagnostic codes from ah_internal.h and place them in ah_diagcodes.h.
Since we now have the source code, there's no reason to hide the diag codes from other areas.
They live in the HA
Break out the diagnostic codes from ah_internal.h and place them in ah_diagcodes.h.
Since we now have the source code, there's no reason to hide the diag codes from other areas.
They live in the HAL as they form part of the HAL API and should still be treate as "potentially flexible; don't publish as a public API." But since they're already used as a public API (see follow-up commit), we may as well use them in place of magic constants.
show more ...
|