| Age | Commit message (Collapse) | Author |
|---|
|
Previously only the provider's display name was used. The text used depends
on how the SIM is configured and not just on the network in use (for example,
an MVNO SIM on another network will often display the MVNO's name rather
than that of the underlying network).
I have a SIM that roams to any network in my country - whichever network
it roams onto, the display name is the same, so you can't tell which
network you're really using. By printing the provider ID (in GSM-land this
is MCC+MNC) it's easy to lookup and check this.
As the provider was printed on the ifconfig line also showing subscriber-id
and ICCID it was already a bit long, and adding the provider-id there is
a bit too much, so move it to the output line showing APN, now looking like
: subscriber-id 2400xxxxxxxxxxx ICC-id 8946203xxxxxxxxxxxxx
: device EM7455 IMEI 01458xxxxxxxxxx firmware SWI9X30C_02.24.0
: APN key provider Tele2 IoT provider-id 23420
|
|
unsupported device to uvideo(4), but not to video(1), instead of just
keeping it unmatched. Also uvideo(4) will print a message about the
device not being supported.
ok mpi@
|
|
|
|
To issue an AT command (AT+QCFG="usbnet",2) to change to MBIM mode.
Tested by Shawn Chiou on rpi4; "of course" deraadt@
|
|
There's already such a barrier in usbd_transfer() code-path, but this
one is called when the frames are queued to the HC ring. The audio
samples are stored in memory by userland later, *after* the frames are
scheduled (but before they are sent on the wire) so a barrier is
needed there. Without this change, the data produced by userland may
stay in the CPU caches and is not "seen" by the HC's DMA engine, in
turn the device plays noise on certain arm64 machines (RPI4, for
instance).
Fix mostly from Luca Castagnini with few tweaks from me. OK patrick@
|
|
might end up sleeping in malloc(). This can only happen if uhidpp is the
first one calling the aforementioned routine which causes the sensors
task queue to be allocated.
Thanks to Justin Yang <linuxjustin at gmail dot com> for the report.
|
|
OK deraadt@
|
|
Patch by Jan Vlach.
|
|
|
|
|
|
it show up with the proper category in hotplug scripts.
From Tilo Stritzky
ok groth@ sthen@
|
|
Tests:
AR5418: Uwe Werler
AR9280: kn, jmatthew, Lauri Tirkkonen, Scott Bennett, Mikolaj Kucharski
AR9285: kevlo, trondd, myself
ok deraadt@
|
|
The rx early size is used to reduce the loading of CPU by letting a transfer
contain more data to reduce the number of transfers.
ok deraadt@
|
|
there's been multiple reports of severely reduced throughput using
ure(4) since 1.22 was committed, but all the gear we have to play
with is fine with it. i'm backing the diff out until we can get a
better handle on the problem
discussed with and ok kevlo@ jmatthew@
|
|
|
|
uvideo(4) currently, like the Chicony Integrated IR Camera. This is
especially helpful when you have two video devices of which the unsupported
one is attached first as reported by martijn@.
OK gnezdo@
|
|
originally from mlarkin@ for TEMPerGold_V3.1 (only a temperature sensor),
i just added TEMPerX variants to the mix - all those devices share the
same usb product id (boo), so differentiate them on the firmware string...
even if the device is labelled as TEMPerHUM and has a blue TXT button on
it, its firmware reports itself as TEMPerX_V3.3.
ok jung@ sthen@ mlarkin@
|
|
|
|
|
|
We are going to unlock PF_ROUTE sockets. This means `if_rtrequest'
handler will be performed without kernel lock.
umb_rtrequest() calls umb_send_inet_proposal() which touches kernel lock
protected `ipv{4,6}dns' array. Also umb_rtrequest() is the only handler
which requires kernel lock to be held. So push the lock down to
umb_rtrequest() instead of grab it around `if_rtrequest' call.
This hunk was commited separately for decreases PF_ROUTE sockets
unlocking diff.
ok gerhard@ deraadt@
|
|
|
|
technology where known. ok deraadt
|
|
|
|
work. Hence, add support for NTB32 in the transmit path. We already have
support for NTB32 in the receive path. We detect the supported format on
boot and can then decide on transmit which format to use.
From ehrhardt@ with gerhard@
Tested by jan@
ok sthen@
|
|
From gerhard@
"broadly OK" sthen@
|
|
ok gerhard@
|
|
Some devices present multiple configurations and the one chosen by default
is not always usable - for example, some have an CDC ECM config that does
not work with our cdce(4) - allow overriding to a specific config in those
cases.
From gerhard@ with tweaks to comments by me, ok patrick@
|
|
|
|
|
|
Jurjen Oskam on tech@ found that ure in a veb caused these extra
fcs bytes to be transmitted by other veb members. the extra bytes
aren't a problem usually because our network stack ignores them if
they're present, eg, the ip stack reads an ip packet length and
trims bytes in an mbuf if there's more. bridge(4) masked this problem
because it always parses IP packets going over the bridge and trims
them like the IP stack before pushing them out another port.
veb(4) generally just moves packets around based on the Ethernet
header, by default it doesn't look too deeply into packets, which
is why this issue popped out.
it is more correct for ure to just not pass the fcs bytes up.
ok jmatthew@ kevlo@
|
|
|
|
|
|
all times, before the device is enabled and after the device is
disabled by wscons.
This was originally needed by umt for the Microsoft Surface Type
Cover to avoid it resetting (or at least detaching and reattaching)
when the touchpad was touched while at the console.
A similar problem occurs with the Pinebook Pro's keyboard when
switching from X to the console due to the touchpad getting
disabled, so add it to ums as well.
with and ok kurt
|
|
|
|
from kurt
|
|
claiming multiple report ids once. This allows uhidpp to piggy back on
the same functionality making uhidev_unset_report_dev() redundant.
|
|
DVACT_DEACTIVATE to them once when walking sc_subdevs.
Fixes a regression reported and tested by Edd Barrett.
Input from and previous version ok anton.
|
|
from Fredrik Engberg
|
|
|
|
from Fredrik Engberg
|
|
There may be multiple matching devices on a single uhidev device but
the first device that responds to UHIDEV_CLAIM_ALLREPORTID will
block the others from attaching.
Change this to UHIDEV_CLAIM_MULTIPLE_REPORTID and require any
devices wanting some/all report ids to fill in the claimed array in
uhidev_attach_arg with just the reports it needs. uhidev can then
run match routines for other drivers with the available report ids.
ok anton
|
|
|
|
|
|
the first cut of this diff was made with coccinelle using this spatch:
@rule@
type caddr_t;
expression m, off, len, cp;
@@
-m_copydata(m, off, len, (caddr_t)cp)
+m_copydata(m, off, len, cp)
i had fix it's opinionated idea of formatting by hand though, so
i'm not sure it was worth it.
ok deraadt@ bluhm@
|
|
ok mpi@
|
|
ok mpi@
|
|
ok mpi@
|
|
arbitrary and inspired by other USB drivers.
|
|
|
|
reports about broken devices, e.g. for ukbd(4) and fido(4).
ok mpi@
|
