Use a sx lock to permit uiomove directly into/out of the the per-port
buffers. In addition, the sx lock provides a stronger guarantee that
I think this driver wants which is to single-thread read and write
calls even while paused. Finally, replace tsleep with dummy wait
channels with calls to pause_sig to more clearly communicate the
intent.
Differential Revision: https://reviews.freebsd.org/D35081
0 should only be returned from probe in legacy drivers that need to
preserve softc state between probe and attach.
Differential Revision: https://reviews.freebsd.org/D35080
The port number is still stored in the unit (si_drv0) but is the
entire unit value now.
While here, removed checks for NULL softc since those can never happen
from cdevsw routines. This also resulted in the close method becoming
a no-op, so it has been removed.
Differential Revision: https://reviews.freebsd.org/D35078
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Most calls to bus_alloc_resource() use "anywhere" as the range, with a given
count. Migrate these to use the new bus_alloc_resource_anywhere() API.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D5370
After I removed all the unit2minor()/minor2unit() calls from the kernel
yesterday, I realised calling minor() everywhere is quite confusing.
Character devices now only have the ability to store a unit number, not
a minor number. Remove the confusion by using dev2unit() everywhere.
This commit could also be considered as a bug fix. A lot of drivers call
minor(), while they should actually be calling dev2unit(). In -CURRENT
this isn't a problem, but it turns out we never had any problem reports
related to that issue in the past. I suspect not many people connect
more than 256 pieces of the same hardware.
Reviewed by: kib
