| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Let modems we know don't suck use a zero send-delay at probe time,
which greatly reduces time required to probe AT-compatible ports.
|
|
Otherwise we don't get the expected "Incorrect password" error if the
PIN is wrong, just a generic error.
|
|
Avoids additional USB latency and groups the whole command into one
USB packet.
BUG=chromium-os:13506
|
|
|
|
New mm_serial_parser_v1_set_custom_regex() method.
|
|
So that cached values can be returned if querying while the port is connected.
|
|
If a port returns EAGAIN on write attempts, previously the code would
spin and attempt to resend the failed byte after send_delay
microseconds. This resulted in up to 3 second hard blocks in
the serial code when sending to ports that don't respond. While
in this blocking loop no other events or dbus commands could be
processed.
Instead, send each byte and reschedule sending the next byte in
send_delay microseconds, so that we can process other events in between
attempts to write to stupid ports.
This doesn't hugely decrease the amount of time that probing
requires, since we still need to probe all ports of the device
before exporting the modem to D-Bus, but it does let MM find
responsive ports much more quickly, and ensures that MM doesn't
block any D-Bus requests.
|
|
|
|
The new and old state arguments were flipped.
|
|
Isn't really needed since it's just the same as any other net
device port type.
|
|
BUG=chrome-os-partner:2394
TEST=gmerge modemmanager, watch logs, see detected as Samsung modem, connect to AT&T network
Review URL: http://codereview.chromium.org/6614026
Patch from Jun Woo Lee <jw86.lee@samsung.com>.
Change-Id: I913628ff4a1cd16c8180e3c808644b0134e69e31
|
|
From an HP un2400;
GMR: D1020-SUUAASFA-4352 1 [Apr 14 2008 18:00:00]
GMM: 88
|
|
|
|
|
|
It's part of the D-Bus API, so it needs to be implemented somewhere
even if it's not used yet.
|
|
|
|
Since platform devices don't usually have them.
|
|
And add new reason codes to the C headers.
|
|
|
|
We actually don't care about the result here. But we do in other
places, so we want to keep the warning in general.
|
|
|
|
|
|
|
|
|
|
We want to enable unsolicited responses on secondary ports too,
so that if the modem only sends unsolicited responses on the ports
on which they were enabled, that we can get resposnes off the
secondary port when the primary port is connected. But we can't
always trust devices to actually send them on the secondary port,
so we enable the unsolicited responses on both the primary and
secondary ports just in case.
|
|
|
|
Make it more flexible, add logging to a file, and absolute and
relative timestamps.
|
|
|
|
Based on a patch by Elly Jones from Google.
|
|
(testcases by dcbw)
|
|
If the SPERI response indicates the home network, then set
CDMA registration to HOME if it was REGISTERED (which is
less specific).
|
|
Also, MEID->Meid to follow standard D-Bus property semantics.
|
|
If the device only has one AT port that's being used for data and
thus we can't do more specific registration checking in MMGenericCdma
using AT commands, but generic registration checking was successful,
just use the less specific state.
Previously, an error would be returned when no AT port was available
even though less specific QCDM registration checking worked. That
was just stupid.
|
|
If the modem's IP Method changes after construction because the
modem's full capabilities were only discovered after it was created,
make sure the change notification gets emitted.
|
|
|
|
CIND indexes returned from helper are 1-based, not 0-based, because
that makes it easier to match against the modem's unsolicited CIND
message.
|
|
BUG=6885
TEST=built modemmanager and cromo
Change-Id: Ib73a093b13da05948a2f1da8f051fe7c55682584
Review URL: http://codereview.chromium.org/3517013
(cherry picked from commit f447c8e1a0062500e1171e031cf4c8fef76ffd59)
Conflicts:
src/mm-modem-cdma.c
|
|
Prevent ModemManager from probing virtual devices before their
associated files exist in /dev tree.
Contributed by Nasser Grainawi <nasser@codeaurora.org>
Review URL: http://codereview.chromium.org/2118005
(cherry picked from commit 617660e3572a7b79ed83f9fc0fda89b7efcb2d4d)
Conflicts:
src/mm-plugin-base.c
Change-Id: Ie5e8b98fb6b6c69e294175523ef99c934092433b
|
|
Amended: Install the files under their proper DBus names.
Review URL: http://codereview.chromium.org/1618004
(cherry picked from commit 89f7f05f1294485fa8b44cfdd3c9b0d924d45ac1)
Conflicts:
Makefile.am
Change-Id: I65b2b0c1b5e579bb5b1d5d5b390c3be2ae49543c
|
|
Review URL: http://codereview.chromium.org/661471
(cherry picked from commit 8475eb44b7ea41afa823919b017a39d82b07a5a2)
Conflicts:
src/mm-plugin-base.c
Change-Id: I825886cad62a27acb39dfe74da7028d83adf692a
|
|
The kernel appears to add the device first without any parents,
then to move it to the correct place in the hierarchy, with its
immediate parent being the device's HCI controller. So we need
to capture the 'move' event too since that's when the rfcomm
device is finally usable.
|
|
|
|
Which requires that we turn it into a GInterface that MMModemBase
can implement, because dbus-glib does not allow attaching more
than one introspection glue structure to an object at a time.
Also implement the standard D-Bus properties changed signal.
|
|
Ignore devices that aren't completely configured by udev yet. If
ModemManager is started in parallel with udev, explicitly requesting
devices may return devices for which not all udev rules have yet been
applied (a bug in udev/gudev). Since we often need those rules to match
the device to a specific ModemManager driver, we need to ensure that all
rules have been processed before handling a device.
Do this by adding an item to the environment of each device that MM
might possibly be interested in, and ignoring devices that don't
have that. When the device is fully processed by udev, MM will get
an 'add' event and the device will have all rules applied.
|
|
(bgo #636040)
Some devices always reply with 99 for AT+CSQ when in UMTS mode (Linktop LW273)
so if the modem supports it, use CIND/CIEV instead.
|
|
|
|
Some modems might not know their IP method until after the
modem object has been created.
|
|
|
|
|
