Searched hist:4 (Results 1 - 25 of 17372) sorted by relevance

1234567891011>>

/freebsd-10.2-release/sys/dev/vt/hw/vga/
H A Dvt_vga_reg.hdiff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log:
Rename vt(4) vga module to dismiss interference with syscons(4) vga module.
267623 Log:
Remove stale link to deleted vt(4) xboxfb driver.
267624 Log:
syscons(4) and vt(4) can be built together now.
267625 Log:
Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
267626 Log:
Suspend vt(4) initialization if "kern.vt.disable" kenv is set.
267965 by emaste@ Log:
Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.
(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)
268175 by emaste@ Log:
Fix vt(4) detection in kbdcontrol and vidcontrol
As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence
of a vt(4) sysctl is not sufficient to determine that vt(4) is in use.
Reported by: Trond Endrestøl
268045 by emaste@ Log:
Add vt(4) to GENERIC and retire the separate VT config
vt(4) and sc(4) can now coexist in the same kernel. To choose the vt
driver, set the loader tunable kern.vty=vt .

Sponsored by: The FreeBSD Foundation
/freebsd-10.2-release/sys/dev/mii/
H A Dmii_bitbang.c226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
H A Dmii_bitbang.h226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
/freebsd-10.2-release/share/man/man4/
H A Dsnd_ad1816.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_als4000.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_cmi.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_cs4281.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_ds1.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_solo.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dmrsas.4diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
diff 265922 Mon May 12 18:07:33 MDT 2014 ambrisko MFC 265555

dd mrsas(4) driver from LSI official support of newer MegaRAID SAS
cards. LSI has been maintaining this driver outside of the FreeBSD
tree. It overlaps support of ThunderBolt and Invader cards that mfi(4)
supports. By default mfi(4) will attach to cards. If the tunable:
hw.mfi.mrsas_enable=1
is set then mfi(4) will not probe and attach to these newer cards and
allow mrsas(4) to attach. So by default this driver will not effect
a FreeBSD system unless mfi(4) is removed from the kernel or the
tunable is enabled.

mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas. The FreeBSD
version of MegaCli and StorCli from LSI do work with mrsas. It appears
that StorCli only works with mrsas. MegaCli appears to work with mfi(4)
and mrsas(4).

It would be good to add mfiutil(4) support to mrsas, emulations modes,
kernel logging, device aliases to ease the transition between mfi(4)
and mrsas(4).

Style issues should be resolved by LSI when they get committers approved.
The plan is get this driver in FreeBSD 9.3 to improve HW support.

Thanks to LSI for developing, testing and working with FreeBSD to
make this driver co-exist in FreeBSD. This improves the overall
support of MegaRAID SAS.

Submitted by: Kashyap Desai <Kashyap.Desai@lsi.com>
Sponsored by: LSI
H A Daltq.4diff 255736 Fri Sep 20 20:26:33 MDT 2013 davidch Substantial rewrite of bxe(4) to add support for the BCM57712 and
BCM578XX controllers.

Approved by: re
MFC after: 4 weeks
diff 255736 Fri Sep 20 20:26:33 MDT 2013 davidch Substantial rewrite of bxe(4) to add support for the BCM57712 and
BCM578XX controllers.

Approved by: re
MFC after: 4 weeks
diff 228370 Fri Dec 09 19:32:58 MST 2011 yongari After r228293, et(4) supports altq(4).
diff 228370 Fri Dec 09 19:32:58 MST 2011 yongari After r228293, et(4) supports altq(4).
diff 227348 Tue Nov 08 18:47:54 MST 2011 yongari ti(4) supports altq(4).
diff 227348 Tue Nov 08 18:47:54 MST 2011 yongari ti(4) supports altq(4).
diff 227276 Sun Nov 06 21:09:25 MST 2011 brueffer Add qlxgb(4).

MFC after: 3 days
diff 218792 Fri Feb 18 08:12:15 MST 2011 np cxgbe(4) - NIC driver for Chelsio T4 (Terminator 4) based 10Gb/1Gb adapters.

MFC after: 3 weeks
diff 218792 Fri Feb 18 08:12:15 MST 2011 np cxgbe(4) - NIC driver for Chelsio T4 (Terminator 4) based 10Gb/1Gb adapters.

MFC after: 3 weeks
diff 217974 Thu Jan 27 20:21:42 MST 2011 yongari ixgb(4) does not support altq(4) yet.
diff 217974 Thu Jan 27 20:21:42 MST 2011 yongari ixgb(4) does not support altq(4) yet.
H A Dsnd_uaudio.4diff 219004 Thu Feb 24 18:09:51 MST 2011 hselasky - Add missing xhci(4) manual page.
- Minor update in some USB manual pages.

MFC after: 3 days
Approved by: thompsa (mentor)
diff 204605 Tue Mar 02 22:14:14 MST 2010 joel The NetBSD Foundation has granted permission to remove clause 3 and 4 from
their software.

Obtained from: NetBSD
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_emu10k1.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_es137x.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dsnd_maestro3.4diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dlmc.4diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
H A Dsnd_sbc.4diff 166800 Sat Feb 17 10:30:00 MST 2007 joel Link snd_sb16.4 and snd_sb8.4 to snd_sbc.4.

Submitted by: ariff
diff 166800 Sat Feb 17 10:30:00 MST 2007 joel Link snd_sb16.4 and snd_sb8.4 to snd_sbc.4.

Submitted by: ariff
diff 166800 Sat Feb 17 10:30:00 MST 2007 joel Link snd_sb16.4 and snd_sb8.4 to snd_sbc.4.

Submitted by: ariff
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 08:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dvt.4diff 274865 Sat Nov 22 17:38:12 MST 2014 dumbbell drm: Take vt(4) default mode from loader tunables

By default, vt(4) gets the "preferred mode" from DRM, when using a DRM
video driver as its backend. The preferred mode is usually the native
screen resolution.

Now, if this mode isn't appropriate, a user can use loader tunables to
select a mode. The tunables are read in the following order:
1. kern.vt.fb.modes.$connector_name
2. kern.vt.fb.default_mode

For example, to set a 1024x768 mode, no matter the connector:
kern.vt.fb.default_mode="1024x768"

To set a 800x600 mode only on the laptop builtin screen:
kern.vt.fb.modes.LVDS-1="800x600"

Beside r274031, this MFC includes:

r274049:
drm: When reading connector mode tunables, list connectors

... and their associated tunables. This gives a way to know the list of
available connectors, no matter the driver.

The problem is that xrandr(1) can list connectors but it uses a
different naming.

r274050:
vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*

Those tunables are used to set a specific mode in vt(4) instead of using
the default mode.

Differential Revision: https://reviews.freebsd.org/D1098
Reviewed by: ak@, emaste@, kwm@

r274051:
vt(4): Improve the description of kern.vt.fb.modes.$connector

Differential Revision: https://reviews.freebsd.org/D1098
Submitted by: emaste@

r274053:
vt(4): Start new sentences on their own lines

Submitted by: brueffer@

MFC of: r274031, r274049, r274050, r274051, r274053
diff 274865 Sat Nov 22 17:38:12 MST 2014 dumbbell drm: Take vt(4) default mode from loader tunables

By default, vt(4) gets the "preferred mode" from DRM, when using a DRM
video driver as its backend. The preferred mode is usually the native
screen resolution.

Now, if this mode isn't appropriate, a user can use loader tunables to
select a mode. The tunables are read in the following order:
1. kern.vt.fb.modes.$connector_name
2. kern.vt.fb.default_mode

For example, to set a 1024x768 mode, no matter the connector:
kern.vt.fb.default_mode="1024x768"

To set a 800x600 mode only on the laptop builtin screen:
kern.vt.fb.modes.LVDS-1="800x600"

Beside r274031, this MFC includes:

r274049:
drm: When reading connector mode tunables, list connectors

... and their associated tunables. This gives a way to know the list of
available connectors, no matter the driver.

The problem is that xrandr(1) can list connectors but it uses a
different naming.

r274050:
vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*

Those tunables are used to set a specific mode in vt(4) instead of using
the default mode.

Differential Revision: https://reviews.freebsd.org/D1098
Reviewed by: ak@, emaste@, kwm@

r274051:
vt(4): Improve the description of kern.vt.fb.modes.$connector

Differential Revision: https://reviews.freebsd.org/D1098
Submitted by: emaste@

r274053:
vt(4): Start new sentences on their own lines

Submitted by: brueffer@

MFC of: r274031, r274049, r274050, r274051, r274053
diff 274865 Sat Nov 22 17:38:12 MST 2014 dumbbell drm: Take vt(4) default mode from loader tunables

By default, vt(4) gets the "preferred mode" from DRM, when using a DRM
video driver as its backend. The preferred mode is usually the native
screen resolution.

Now, if this mode isn't appropriate, a user can use loader tunables to
select a mode. The tunables are read in the following order:
1. kern.vt.fb.modes.$connector_name
2. kern.vt.fb.default_mode

For example, to set a 1024x768 mode, no matter the connector:
kern.vt.fb.default_mode="1024x768"

To set a 800x600 mode only on the laptop builtin screen:
kern.vt.fb.modes.LVDS-1="800x600"

Beside r274031, this MFC includes:

r274049:
drm: When reading connector mode tunables, list connectors

... and their associated tunables. This gives a way to know the list of
available connectors, no matter the driver.

The problem is that xrandr(1) can list connectors but it uses a
different naming.

r274050:
vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*

Those tunables are used to set a specific mode in vt(4) instead of using
the default mode.

Differential Revision: https://reviews.freebsd.org/D1098
Reviewed by: ak@, emaste@, kwm@

r274051:
vt(4): Improve the description of kern.vt.fb.modes.$connector

Differential Revision: https://reviews.freebsd.org/D1098
Submitted by: emaste@

r274053:
vt(4): Start new sentences on their own lines

Submitted by: brueffer@

MFC of: r274031, r274049, r274050, r274051, r274053
diff 274865 Sat Nov 22 17:38:12 MST 2014 dumbbell drm: Take vt(4) default mode from loader tunables

By default, vt(4) gets the "preferred mode" from DRM, when using a DRM
video driver as its backend. The preferred mode is usually the native
screen resolution.

Now, if this mode isn't appropriate, a user can use loader tunables to
select a mode. The tunables are read in the following order:
1. kern.vt.fb.modes.$connector_name
2. kern.vt.fb.default_mode

For example, to set a 1024x768 mode, no matter the connector:
kern.vt.fb.default_mode="1024x768"

To set a 800x600 mode only on the laptop builtin screen:
kern.vt.fb.modes.LVDS-1="800x600"

Beside r274031, this MFC includes:

r274049:
drm: When reading connector mode tunables, list connectors

... and their associated tunables. This gives a way to know the list of
available connectors, no matter the driver.

The problem is that xrandr(1) can list connectors but it uses a
different naming.

r274050:
vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*

Those tunables are used to set a specific mode in vt(4) instead of using
the default mode.

Differential Revision: https://reviews.freebsd.org/D1098
Reviewed by: ak@, emaste@, kwm@

r274051:
vt(4): Improve the description of kern.vt.fb.modes.$connector

Differential Revision: https://reviews.freebsd.org/D1098
Submitted by: emaste@

r274053:
vt(4): Start new sentences on their own lines

Submitted by: brueffer@

MFC of: r274031, r274049, r274050, r274051, r274053
diff 274865 Sat Nov 22 17:38:12 MST 2014 dumbbell drm: Take vt(4) default mode from loader tunables

By default, vt(4) gets the "preferred mode" from DRM, when using a DRM
video driver as its backend. The preferred mode is usually the native
screen resolution.

Now, if this mode isn't appropriate, a user can use loader tunables to
select a mode. The tunables are read in the following order:
1. kern.vt.fb.modes.$connector_name
2. kern.vt.fb.default_mode

For example, to set a 1024x768 mode, no matter the connector:
kern.vt.fb.default_mode="1024x768"

To set a 800x600 mode only on the laptop builtin screen:
kern.vt.fb.modes.LVDS-1="800x600"

Beside r274031, this MFC includes:

r274049:
drm: When reading connector mode tunables, list connectors

... and their associated tunables. This gives a way to know the list of
available connectors, no matter the driver.

The problem is that xrandr(1) can list connectors but it uses a
different naming.

r274050:
vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*

Those tunables are used to set a specific mode in vt(4) instead of using
the default mode.

Differential Revision: https://reviews.freebsd.org/D1098
Reviewed by: ak@, emaste@, kwm@

r274051:
vt(4): Improve the description of kern.vt.fb.modes.$connector

Differential Revision: https://reviews.freebsd.org/D1098
Submitted by: emaste@

r274053:
vt(4): Start new sentences on their own lines

Submitted by: brueffer@

MFC of: r274031, r274049, r274050, r274051, r274053
diff 274865 Sat Nov 22 17:38:12 MST 2014 dumbbell drm: Take vt(4) default mode from loader tunables

By default, vt(4) gets the "preferred mode" from DRM, when using a DRM
video driver as its backend. The preferred mode is usually the native
screen resolution.

Now, if this mode isn't appropriate, a user can use loader tunables to
select a mode. The tunables are read in the following order:
1. kern.vt.fb.modes.$connector_name
2. kern.vt.fb.default_mode

For example, to set a 1024x768 mode, no matter the connector:
kern.vt.fb.default_mode="1024x768"

To set a 800x600 mode only on the laptop builtin screen:
kern.vt.fb.modes.LVDS-1="800x600"

Beside r274031, this MFC includes:

r274049:
drm: When reading connector mode tunables, list connectors

... and their associated tunables. This gives a way to know the list of
available connectors, no matter the driver.

The problem is that xrandr(1) can list connectors but it uses a
different naming.

r274050:
vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*

Those tunables are used to set a specific mode in vt(4) instead of using
the default mode.

Differential Revision: https://reviews.freebsd.org/D1098
Reviewed by: ak@, emaste@, kwm@

r274051:
vt(4): Improve the description of kern.vt.fb.modes.$connector

Differential Revision: https://reviews.freebsd.org/D1098
Submitted by: emaste@

r274053:
vt(4): Start new sentences on their own lines

Submitted by: brueffer@

MFC of: r274031, r274049, r274050, r274051, r274053
diff 273511 Thu Oct 23 02:33:34 MDT 2014 emaste Add vtfontcvt(8) cross-reference to vt(4) man page

MFC of r273332
diff 273294 Mon Oct 20 00:32:27 MDT 2014 emaste MFC r273178: Update vt(4) for UEFI defaults and special keys

vt(4) is the default console for UEFI boot [1], and the bitmapped
kern.vt.spclkeys sysctl has been replaced with individual kern.vt.kbd_*
enable sysctls.

PR: 193710
diff 273294 Mon Oct 20 00:32:27 MDT 2014 emaste MFC r273178: Update vt(4) for UEFI defaults and special keys

vt(4) is the default console for UEFI boot [1], and the bitmapped
kern.vt.spclkeys sysctl has been replaced with individual kern.vt.kbd_*
enable sysctls.

PR: 193710
diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi

Second batch of MFCs to add support for Unicode keymaps for use with vt(4).

It contains the following changes:

- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.

Relnotes: yes
diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi

Second batch of MFCs to add support for Unicode keymaps for use with vt(4).

It contains the following changes:

- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.

Relnotes: yes
diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi

Second batch of MFCs to add support for Unicode keymaps for use with vt(4).

It contains the following changes:

- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.

Relnotes: yes
diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi

Second batch of MFCs to add support for Unicode keymaps for use with vt(4).

It contains the following changes:

- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.

Relnotes: yes
diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi

Second batch of MFCs to add support for Unicode keymaps for use with vt(4).

It contains the following changes:

- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.

Relnotes: yes
diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi

Second batch of MFCs to add support for Unicode keymaps for use with vt(4).

It contains the following changes:

- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.

Relnotes: yes
/freebsd-10.2-release/release/doc/share/misc/
H A Ddev.archlist.txtdiff 265856 Sat May 10 20:57:20 MDT 2014 brueffer MFC: r265264, r265270

Add rsu(4) and urtwn(4) to the hardware notes.
diff 265856 Sat May 10 20:57:20 MDT 2014 brueffer MFC: r265264, r265270

Add rsu(4) and urtwn(4) to the hardware notes.
diff 262686 Sun Mar 02 12:20:23 MST 2014 brueffer MFC: r262574

Add tws(4) to the hardware notes.
diff 261739 Tue Feb 11 08:20:46 MST 2014 brueffer MFC: r261487

Add qlxgbe(4) and qlxge(4) to the hardware notes.
diff 261739 Tue Feb 11 08:20:46 MST 2014 brueffer MFC: r261487

Add qlxgbe(4) and qlxge(4) to the hardware notes.
diff 237700 Thu Jun 28 10:16:20 MDT 2012 brueffer Automatically generate hardware notes for bxe(4).
diff 232355 Thu Mar 01 19:57:42 MST 2012 brueffer Add snd_hdspe(4) to the hardware notes.
diff 232060 Thu Feb 23 19:04:31 MST 2012 brueffer Add isci(4) to the hardware notes.

MFC after: 3 days
diff 231943 Mon Feb 20 19:50:36 MST 2012 brueffer Add oce(4) to the hardware notes.

MFC after: 3 days
diff 227666 Fri Nov 18 17:05:03 MST 2011 brueffer Add sfxge(4) to the hardware notes.
/freebsd-10.2-release/share/man/man5/
H A Dportindex.5diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references:

- ada(4): ad(4) - removed, ada(4) would be a self-referencing entry
- cd(4): ad(4) -> ada(4)
- da(4): ad(4) -> ada(4)
- DEVICE_PROBE(9): ugen(5) -> ugen(4)
- ed(4): dhclinet(8) -> dhclient(8) (typo)
- lmc(4): Netgraph(4) -> netgraph(4)
- security(7): rc.conf(8) -> rc.conf(5)
- sfxge(4): cpuset(8) -> cpuset(1)
- sbp(4): sysctl(1) -> sysctl(8)
- portindex(5): build(1) -> build(7)
- u3g(4): usbconfig(5) -> usbconfig(8)
- usb_quirk(4): usbconfig(5) -> usbconfig(8)

Found with: textproc/igor
MFC after: 3 days
/freebsd-10.2-release/sys/pci/
H A Damdsmb.cdiff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
H A Dintpmreg.hdiff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers:
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
/freebsd-10.2-release/sys/dev/bm/
H A Dif_bmreg.hdiff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
H A Dif_bmvar.hdiff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.

Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).

Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
/freebsd-10.2-release/release/doc/en_US.ISO8859-1/hardware/
H A Darticle.xmldiff 286039 Wed Jul 29 20:26:35 MDT 2015 gjb Add ixl(4) to the hardware notes.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
diff 286023 Wed Jul 29 17:35:51 MDT 2015 brueffer MFC: r285859 (via r286019)

Auto-generate hardware notes for pms(4).

Approved by: re (gjb)
diff 286039 Wed Jul 29 20:26:35 MDT 2015 gjb Add ixl(4) to the hardware notes.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
diff 286023 Wed Jul 29 17:35:51 MDT 2015 brueffer MFC: r285859 (via r286019)

Auto-generate hardware notes for pms(4).

Approved by: re (gjb)
diff 270680 Tue Aug 26 23:32:03 MDT 2014 gjb Fix alphabetical sorting with alc(4) addition.

Move atp(4) driver under 'Pointing Devices', added
to 'Keyboards' by mistake.

Sponsored by: The FreeBSD Foundation
diff 270680 Tue Aug 26 23:32:03 MDT 2014 gjb Fix alphabetical sorting with alc(4) addition.

Move atp(4) driver under 'Pointing Devices', added
to 'Keyboards' by mistake.

Sponsored by: The FreeBSD Foundation
diff 270678 Tue Aug 26 22:56:20 MDT 2014 gjb Add the following to the hardware notes:
- aacraid(4)
- alc(4)
- ath_hal(4)
- atp(4)
- cxgbe(4)
- hptnr(4)

Sponsored by: The FreeBSD Foundation
diff 270678 Tue Aug 26 22:56:20 MDT 2014 gjb Add the following to the hardware notes:
- aacraid(4)
- alc(4)
- ath_hal(4)
- atp(4)
- cxgbe(4)
- hptnr(4)

Sponsored by: The FreeBSD Foundation
diff 270678 Tue Aug 26 22:56:20 MDT 2014 gjb Add the following to the hardware notes:
- aacraid(4)
- alc(4)
- ath_hal(4)
- atp(4)
- cxgbe(4)
- hptnr(4)

Sponsored by: The FreeBSD Foundation
diff 270678 Tue Aug 26 22:56:20 MDT 2014 gjb Add the following to the hardware notes:
- aacraid(4)
- alc(4)
- ath_hal(4)
- atp(4)
- cxgbe(4)
- hptnr(4)

Sponsored by: The FreeBSD Foundation
diff 270678 Tue Aug 26 22:56:20 MDT 2014 gjb Add the following to the hardware notes:
- aacraid(4)
- alc(4)
- ath_hal(4)
- atp(4)
- cxgbe(4)
- hptnr(4)

Sponsored by: The FreeBSD Foundation
diff 270678 Tue Aug 26 22:56:20 MDT 2014 gjb Add the following to the hardware notes:
- aacraid(4)
- alc(4)
- ath_hal(4)
- atp(4)
- cxgbe(4)
- hptnr(4)

Sponsored by: The FreeBSD Foundation

Completed in 531 milliseconds

1234567891011>>